I wrote this to someone in a GitHub issue and thought it was pretty salient:
What has drawn people to Rebol historically has varied. But a large number who praised it and used it were less interested in the language itself, rather the properties of the executable. It was small, and you could run on any OS without installing anything else...it came with a GUI built in.
But when serious language theorists look at Rebol, they notice it is riddled with design holes. The language itself wasn't composable the way one might like languages to be: mixing constructs in new ways that weren't specifically accounted for never worked. It was more like a "scriptable app" that had a few features that pleased its userbase...and had to be extended by the designer every time a new need came up.
So put briefly: If you don't understand what these holes are, then you won't appreciate the many issues that Ren-C is trying to solve. Starting from scratch inevitably makes the same mistakes.
Once you know that historical Rebol was fundamentally broken, there are basically 3 choices:
- Inventory and address the holes one at a time and try to fix or mitigate them
- Ignore the holes and just hope that if you add enough features and integration no one will notice
- Turn away and run from the crackpots using it, and work with a more solidly designed language
(1) is Ren-C's hard-chosen path. Energy is spent on identifying certain patterns in source that users must be able to write and have work, if the language is to justify its existence at all. While it would be nice if stack traces were beautiful and if building the sources was 100% easy, all of that would be meaningless if the punch line was "oh, and the language this is all supporting doesn't actually work"
(2) is chosen by people like Red and Oldes's branch of R3-Alpha, as well as some clones that have popped up over the years.
(3) is probably the most sensible choice, but if I didn't think there was some promise in the language I wouldn't be pursuing (1).