So there's a general rhetoric in here...about what the "rebellion" really means. It's the kind of thing echoed in "Fight Software Complexity Pollution":
http://www.rebol.com/cgi-bin/blog.r?view=0497
I won't dwell on all the agreements I have. But I thought there were some interesting remarks, worth critiquing in a historical context:
Once the language is complete and in distribution, the second phase is to develop a small and flexible operating system which is integrated in a unique way with the language.
...
Applications can still be written in C and various other languages, but some aspects of their system interface will be done through the OS language.
I believe this goal was something that limited Rebol's success. It gave rise to the table of functions that represented the "host" abstraction. These were functions named OS_Some_Thing(), that spoke in terms of C types, e.g. here's the POSIX OS_Get_Time:
This was the abstract OS. It wasn't Windows or POSIX, it was a set of C functions that represented the things Rebol might want to do... e.g. OS_Get_Time() would be the service routine that the Rebol command NOW would call.
But its hands were tied. Don't be fooled by REBOL_DAT into thinking that this abstract OS was allowed to inspect and manipulate the internals of Rebol data structures. Quite the opposite, REBOL_DAT was a structure that the Rebol language had no need for that was defined purely for the purpose of communicating with this abstract OS. It was just jumping through hoops, which would be much easier if the implementation could assemble Rebol values.
Ren-C's goal was to tear out this abstract OS and implement extensions differently. The work is starting to pay off... but it certainly is a lot of work.
For years after creating the Amiga's multitasking OS architecture I assumed operating systems would continue to improve.
I was among the kids who thought the Amiga was great. (Though I didn't actually have one until someone gave me one when they were cleaning out their closet, and it was a piece of history by then.) I experienced it secondhand, when things like MOD file players were ported to PC. But the influence of the Amiga and demoscene was still quite present.
But I think the difference between multi-tasking and multi-threading is very profound...and there were a numerous indications that Carl did not have experience with the practical matters of the difference.
People have asked me about the TASK! concept and how that would go, and I hated to be the person to break it to them that it was all simply was too unsophisticated to actually work. The only way it could have been made to work would be something I think most people would find unsatisfactory--exposing semaphores and mutexes--which seems to cut across the intended use case of Rebol at a high level. Basically, Rebol programmers would be C programmers at that point.
But I dissected many other mistakes:
For myself, my time on StackOverflow has been very humbling--to try things and get a real-time education from someone who knows a lot more than you do about whatever you were asking. It happens often. I like to write about these experiences... things I thought I knew, and then I look at it another way and learn something. Carl's Rebol has given me opportunities on both sides of this--I have thought some newfangled technology would make things better, but tried it and performance analyzed it... considered the "real cost" of the abstraction, and realized my conventional wisdom was wrong. But I've also found a lot of problems, and been the correcting factor.
I understand that after 15 years he had to move on. On my end, it's been a bit over two years now since the beginning of Ren-C. I still have little puzzles I want to solve... I think great strides have been made. But I have to shift into other work now, so prioritization of what time I spend on Rebol-oriented tasks is going to be much more important.