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.
DideC
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.
Arnold
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.
DocKimbel
@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. ;-)
Geomol
"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).
Gregg
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.
Bo
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.
Geomol
"As for portability, if C solves that problem, why has the number of REBOL platforms gone from 43 to 3?"
The way I see it: if I have code in ANSI C, I have the option to move to just about any platform. That is not the same as I would move to every platform. Having code in many other languages, and you don't have the option.
Creating ones own compiler can resolve such considerations, I guess. Especially if you can compile for another CPU than where the compiler runs.
eFishAnt
cool
GrahamC
@Gregg .. rebol3 runs on 4 platforms. And more actually.
It also runs on Syllable, and the BeOS derived Haiku.
GrahamC
It does look as though Syllable is in palliative care mode though