Okay, but two other things are now playing. First Carl has a job at Roku (I don't know if it is full-time) and how about the investors of R2 and (possible) reuse of code even if created new by Carl.
I rather would see Carl joining Red team in his free time, advising the new R4 way
not a single world against that, but we all know Carl - he is a solist, likes to work in isolation, etc. And yes, Roku job seems to be a full time job, so works against him. I think that Carl is mostly developing it for his own home automatition reasons and pure joy.
It seems a bit unfair to R3 guys, trying to push things further. Red has its own plan, development team and is moving forward no matter what ....
The R3 guys did great things, mostly in getting the unity back in the language. Without access to the main repo it was a lost cause. It was fun doing all stuff but to attract developers and users the wrong path was followed. Because all we want is to get as quickly back on the road that R2 opened up: cross platform inclusive GUI. Go there and add sound, 64 bit, Android/mobile support and you get a chance.
Now that Red has rounded the first GUI release it has become a really great option. After 0.7 it will really become a force to recon with. The fact it will be independent of C is becoming more attractive.

The Atronix R3 windows build, which is 64bit and has a decent CALL implementation, was good enough for me to move everything from R2 to R3 ... but GUI and cross-platform aren't that important to me anymore. Point being, different folks will have different "key feature" requirements that will cause them to choose R2, R3 or Red; although I'm hopeful that Red will eventually become a superset of R3 at which time I can migrate from R3 to Red (or R4 depending on where it goes).
I also wouldn't overstate the differences between each flavour ... converting several hundred scripts from R2 to R3 took me less than a day; it's not like C vs C+ vs C#.
To me, Rebol4 would be based on R3, not a full rewrite. There is plenty of source code already opensourced, so reusable for R4.
But let see it (may be) on day ;-)
Maybe before it is released, Carl decides to come up with Rebol 5 :-)
I think Pekr has a very good idea of the reasons Carl does what he does. He starts building a house (Contra) and then decides the foundation would be better if he did it a different way (R2). So he improves the foundation and starts building another house, only to decide to improve the foundation again (R3). After a while, he gets a REALLY good foundation (some future iteration of the original idea), but still no house. But when he finally finishes building a house on that REALLY good foundation, it will be a REALLY good house!
His job at Roku is full-time and more. I believe that building languages is something that Carl does to satisfy his creative intellect.
What I have never understood fully, though I do get the rationale, is why, with REBOL being a tool you can use to build tools, Carl never fully embraced it to build the next version of itself. While I want "One R to rule them all", I'm not opposed to specialized versions. e.g. a Forth-like version that implements only the most necessary bits at the lowest level, and is as small as possible for IoT and such. But what really resonates with me in Red is that is uses REBOL, and will then self-host. Dialects all the way down.
I think the thing that Carl is missing with his foundation is what Doc isn't with Red/System. If there was a Rebol/System, then he could do that.
But optimizing a Rebol/System (or Red/System for that matter) compiler is a huge job, something that is already done with C.

As I said, I get the rationale. What I don't understand is why Carl didn't build in the pieces to rely less on C and more on REBOL itself as time went on.
My guess is that its the past of Carl : he does C code since it's first time. He is an impressive C coder and does all day long. So why would he want to do other way, as said, Rebol/system woild be a longer path and not optimized.
Doc doesn't have the same history.
Because Rebol is interpreted and slower than compiled C code, Gregg? And because Carl already has lots of experience in C coding, so coding in C is no problem at all and code can be compiled on almost any platform.
@Didec, I use to code in C/C++ regularly for about 10 years, before fully switching to Rebol. Ability to code in Red/System is a relief compared to C: 5 seconds to setup the compiler on any new machine and cross-compilation built-in. We are still lagging behing C tools for debugging, though, we'll catch up quickly. For the performances difference with C, it will resolved later this year. ;-)
"What I don't understand is why Carl didn't build in the pieces to rely less on C and more on REBOL itself as time went on."
I remember - about 10 years ago - at the time moving from R2 to R3, Carl also found it an interesting idea to create Rebol with Rebol. I can't remember, who brought it up first, me or him (probably thought about it independently). I do remember, others didn't see the benefit in that idea back then. It was mentioned in another AltME world, we had back then for moving Rebol forward.
I started creating the World language in ANSI C, because there is a benefit in that, as you have such a compiler everwhere (it was started before I knew of Red). I don't like C very much, as it is a less developed language. Also I didn't have much assembler experience beside 6502 ASM on the BBC Micro (6502 eventually developed into ARM). It makes sense to create Rebol kind of languages within same kind of languages. The trick is to make it simple and efficient (good performance).
Red is proof that it can be done, even in fully interpreted REBOL. As for portability, if C solves that problem, why has the number of REBOL platforms gone from 43 to 3? Yes, there is always effort to maintain more platforms, which may not have value, or have gone the way of the dodo themselves, but it took a lot of effort because they needed a machine and OS for each one (as I understand it).
Of course Carl and code in any language he wants (because he can). Yes, there is surely the product side of things, offering something fast because C existed, early on. I'm just overjoyed that Doc has shown the world what REBOL can do, and can't wait to see the future.
I also am looking forward to diving deeply into Red. I did a real-time video motion detection project utilizing Red/System a few years ago. I'm sure it has evolved a lot since then. BTW, my cameras that are using that Red/System code are still running today. :-)
It's great to hear that the Red tools for debugging are going to catch up quickly and the performance difference with C will be resolved later this year. I'm dying to have a unified language for doing everything from microcontroller programming (ATmega328, PIC, etc.) up to GUIs and dialects! I am computerizing my 1978 Ford 4x4 and I want to do as much of it as possible with Red.

Last message posted 17 weeks ago.