Rebol 3 compared with Red

I opted to wait a day before replying to this thread. There's little to be gained from friction between the two projects.

"Buggy clone of Rebol2 written in a made-up assembly language the world wasn't asking for."

Well, let's be brutally frank. :slightly_smiling_face: Two points:

  1. Both projects have defects, flaws, and significant language-designs or features in transition.
  2. The world isn't asking for either of these languages--- one could describe both projects as "vanity projects."

I hope that both efforts continue to pursue visions which minimize complexity while shining a light on the unique properties made available by extremely dynamic evaluation (in a rich-data homoiconic language). This particular niche of computing hasn't been thoroughly picked-through and I think there's still a lot of benefits that can be brought to life.

I've been watching and using Rebol for two decades, and I don't ever think there's ever been a more exciting time for it. Both projects have a lot to do, and life's short so make haste!

1 Like

@hostilefork thanks for your detailed reply it does correct some misunderstandings I'd had (e.g. I'd not realized Red was started before Rebol 3 was open sourced that's interesting).

I should say I'm impressed by the passion I see from you guys whether about Rebol 3/Ren-C or Red.

In my case I'd not even heard of Rebol till I heard Douglas Crockford say he'd gotten the idea for JSON from Rebol in a talk I saw him give at the Strange Loop conference some years back.

I've always liked programming languages in general and often learn just a smidge of different languages for fun and that's been the case for me with Rebol/Red so far I've just been sitting on the fence not really using either one but just admiring some of the language design choices.

Returning to my original question and some of what you replied - I started this recent surge of interest just because a. I happen to look at Red when I hadn't in a couple years and was pleasantly surprised there appeared to be some better progress than when I'd first looked at it and b. I'd had some days off work last week for the holiday and was bored. :slight_smile:

I didn't know anything about the status of Rebol 3/Ren-C prior to that.

In the spirit of being open as you were with some of your comments, I can say I feel torn about these projects in that I'm really excited by their potential, but simultaneously frustrated neither Rebol 3/Ren-C or Red seem to be something I could/would really use in their current states. And it feels to me like progress on both of them is slow.

To be clear, for me the basic appeal is the GUI dialects if they could be used to easily do apps that talk to RESTful services and are able to run in browser, iOS, and android from a single code base.

It's ok if they're not the prettiest in the world, or not the fastest in the world (within reason), and I don't even mind that much if the executable file size is esp. big or small (i.e. as often mentioned about Rebol/Red).

For me it's just about productivity of building these types of apps on those platforms.

That's what led me to the thought of focusing my efforts on learning Rebol 3 or Red better with the goal of trying to become a contributor and see if I can help advance things.

But I'm torn. I did C/C++ for the first 15 years or so of my career (though it's been awhile now). And maybe that's biasing my view but for me the Rebol 3/Ren-C approach, in combination with Qt and emscripten, seems - how to put this - "pragmatic".

otoh I do see the community support around Red, yet I'm having trouble understanding where to begin. Maybe it's just because I don't know Rebol itself well enough yet. But otoh is there any kind of Red/System single step debugger? There's not right? i.e. Wasn't a lot given up with the decision to start from essentially nothing and not build on C as the bottom?

And yet I know it's a tradition to bootstrap languages esp. lispy languages, and write them in themselves. I admire the ideas, I'm just not sure, between Red/System and the choice to use only native widgets for GUI, how quickly they can complete the overall vision with all that's being promised. It wouldn't surprise me if it's another 5 years or more before android, iOS, and browser are useable in Red.

Where for me as I said, I really want the promised cross platform vision right now.

Anyway rambled and wrote too much sorry. Just thinking out loud what's been on my mind as I try and decide where to focus my efforts.

1 Like

It would be fantastic to have you involved. I have done what I could to make the code accessible to basically anyone who can read the K&R C book...

That shouldn't be difficult to do for compiled code--in the scheme of things. The debug format is reasonably documented, and they just have to spit out some file/line number mappings for the generated instructions. Hardly rocket science.

The real problem is--surprisingly (or not)--building a debugger when the code is interpreted.

If you want to question the basic premise behind Red, I guess you can. But my "when-in-anger" remarks above aside...this choice, to me was what made it more exciting than the other clones. I actually think Red/System is the most interesting part of that project.

1 Like

@BlackATTR fwiw I had some of the same feeling you expressed. i.e. that it's important to be considerate in critiquing/contrasting these efforts considering how very very hard it is to do the things these projects are attempting. Clearly there's a lot of hard work and passion surrounding these efforts and I really admire what both you guys and what Red/DocKimbel are doing.

But at the same time I appreciated the frankness in some of @hostilefork's reply in that they opened up what seem to me the fundamental questions I've been trying to understand:

a. whether realistically the Red efforts are so ambitious that they are going to take longer than I'm willing to wait before it's production worthy on all the platforms I need to target,

Leading to the corresponding question of whether

b. does the Ren-C effort have a plan to get there quicker and exactly what is that?

I think (not sure) I've sensed there's a plan where Ren-C is the new rebol-core, and the next steps are to create the equivalent of rebol-view by putting the Draw and GUI dialects atop Qt rather than AGG? i.e. In order to get quickly to supporting all the major platforms including iOS and Android?

And that even this might be the answer as well for the browser, considering you guys already have Ren-C working thru emscripten, and that Qt has demos of their stuff working through emscripten in the browser...

(where am I right that what you guys have shown so far has been using ASM.js but my understanding is getting the smaller files sizes of WebAssembly is mostly just using some different emscripten options - so there's a nice upgrade path for that).

I don't remember if I'm saying Qt because of @hostilefork saying this plan explicitly or just because I saw that he was using Qt for his Ren/Garden IDE. But regardless, the only downside I personally know about with Qt (from playing with their mobile demos a couple years ago) is their app file sizes were fairly large. But to me that's not the most important concern...

As for:

The world isn't asking for either of these languages

I'll be honest I'm partly asking myself if I have time or am willing to get involved in these efforts at all.

And e.g. earlier I remembered a language I'd looked at a bit couple years ago called "Nim" that does have some of the macro/templating/metaprogramming/lisp-inspired-features like what draws me to Rebol.

So I looked at that a bit earlier today and for a minute I thought - oh boy this is it they're hitting everything I want they even compile to javascript and they mention iOS and Android.

But then I looked at their GUI examples and there's nothing remotely as simple or appealing as the Rebol GUI dialect.

So I keep coming back to the thought that there is something special in Rebol.

Something that brings the power people always attributed to Lisp in a far more approachable package.

And to wrap up, I should clarify I meant my comments about using Qt as a question.

Is that the plan?

And if so, another question I had is whether there is already a way to deploy to e.g. iOS and Android as a single deployable file? By just bundling the rebol source files together with the interpreter? I googled and it looks to me like maybe there was already a way to do that with Rebol 2 (if I'm reading it right I might not be...). Would that be the plan for mobile deployments with Rebol 3/Ren-C?

1 Like

Sorry Darren--
I've used rebol 2.x and the View dialect a fair amount, as well as rebol 3 (for the Unicode support). But I haven't attempted to get any of these working on a mobile device. If you'd like to get into the View dialect, I'd start on Rebol 2.x. If you need to do anything on a mobile device, I'd probably be looking at creating a rebol web-service that you can access via your handheld (via http). Getting to Rebol via a traditional web-cgi approach isn't likely what you were hoping for.

If you need to be executing code on a mobile device I don't think rebol, ren-c or rebol are ready yet. That's just the impression I get and I'd be happy to be misinformed. Red has Android as one if its primary goals, but you may be waiting a while until they've built up sufficient foundation and tool-chain. I'd ask on the gitter chat forum for some idea of their roadmap.

@BlackATTR Maybe I've been more optimistic because I'd installed and run Saphirion's Rebol 3 Android apk:

Not that I've done much with it but the "Demo" they include on their menu does display all the GUI widgets and seems to run fine.

It looks to me like it downloads the demo .red file when you bring it up (for a brief moment is says "Fetching...") which I believe would violate the app store terms (well come to think of it I'm thinking of Apple's terms but this is Android - I'm not sure what the android app store terms say!)

But of course this apk was "side loaded" so no app store involved this way anyway.

@BlackATTR were you familiar with this app? I think I was told Saphirion never released their source for it. But to me it demonstrates there's no fundamental reason Rebol 3/Ren-C can't work on Android that I know of. Or do you know something I don't?

The android build that Cyphre did demonstrates that it's doable. The Android build that he did was even funded by donations on the promise that it would be open sourced, yet disappointingly no source was ever released.

The only definite expressed intention is for Atronix to build View on Ren-c (presumably still using AGG), and they have also stated they want to get OpenGL working. Qt has been mentioned by @hostilefork as he did Ren Garden in this, and he has Qt experience. And he has mentioned many a time that he could do it, but only if someone were to specify how the dialect would work.

In the meantime, there are a couple of possibilities:

  1. Ren-c to load libRed to bring up a GUI if you didn't want to wait for a "native" ren-C GUI.

  2. And there's also the SL4A for building Android apps. @giuliolunati has taken that idea further and you can download demos from GitHub and the apk from sl4abox

I was one of the testers and I found it very slow, with anomalous behaviours on different devices.


IMO, one mistake many people make is...because they enjoy "Reboling" and the art of it...they get over enthusiastic about skeleton crew projects...and try to use them for everything. This has helped push the boundaries--but also complicates the optics.

If you are trying to solve a problem on a timeline, there are much larger communities with better documentation and libraries than either Rebol or Red. And if you have professional obligations, using a more mainstream language is going to lessen your stress in the long run. Also, I'm not personally sure the ideas behind Rebol can actually be made to "work" (for my definition of "work") I'm referring there, to how the binding model operates.

Globally speaking, this is a small number of people working on a kind of nutty idea. I like Haskell too, for completely different reasons and principles (that are actually a lot less nutty, it's a more obvious thing). But I'd similarly tell an entrepreneur "don't bet the farm on Haskell, just because it seems like good magic". I've seen people regret that decision also.

Yet Red and Rebol can be a useful tool, even if you're not using them for everything. So my advice is to model it more that it's like a coding Swiss Army Knife. Learn PARSE and see how you like writing little tools just for yourself, before you go hog wild trying to build a web service or killer cross-platform mobile app. Use it a bit before you decide what it is good for and not good for.

Once you start tinkering, you might find yourself asking why you can't use it for other things...even if it doesn't fit yet. As Carl said:

A friend of mine says it's like the movie "Matrix" where you are offered either the red pill or the blue pill. Most programmers stick with the blue pill. The folks who take the REBOL red pill wake up and can never go back. I've had companies call me to complain that a few of their programmers started using REBOL and are now "ruined" because they refuse to go back. REBOL is a highly disruptive technology.

Really I think Rebol/Red would be better served if people didn't ask so much, so soon. What's wrong with small successes, built to larger ones? It's a big world, not every project must reach the moon on day one. Or year 18. :slight_smile:

Errr... I've never gone on the record, when it comes to timelines or promises or anything. Ren-C has always been a research project. Red is the project that kept saying a lot of (unrealistic) drop points.

I said I was going to try and attack some technical problems. I solved some of them. I'm proud of some designs and confident about them, I feel nervous about others ("was that right?")...and I also have other things to do in life--as most people do. It's great and validating to have Atronix on board, but they aren't in the language design business. They make a single product. So their timeline is all about that product, not about giving you a solution for writing mobile apps or whatever. If you can use it great, but be realistic here.

To summarize: no, nothing about Ren-C is about getting to any point faster than Red. It's about doing some things better, and hoping the community can convince Nenad that I actually did come up with good ideas, and adopt them.

Ed, are you aware of the ren-c builds on Android, and the apk with the demos?

No, I haven't been active in the mobile development space (using Rebol). The Saphirion website appears to not have been updated in years and the documentation there is sketchier that what's available for other projects.
I didn't mean to suggest that Redbol is incompatible with Android. My impression was that this platform lacked a reliable, well-supported/documented redbol solution there yet-- at least not until Red gets there.
I defer to others on this subject, as I don't want to put misinformation out there.

No I wasn't. Thanks for correcting the record.

I think that having some competition will be good for both. If you can make some things work that RED doesn't do so well then it will probably be added to RED. I think if you can get a killer GUI system on R3 it will push RED. My only complaint about RED is it is using the standard system library for GUI back end and there's no backup.

1 Like

There is backup, you can either write your own GUI in Draw or add another backend. It is lot of work, I know, but not impossible.

If I recall correctly, for Julia it is now possible to use the Red GUI. How about using something like that for r3 :clown_face:. Downside it would only work on supported platforms.

Presumably the documentation for Red GUI is good enough for you to try and do this?

One part of the question is not if it is possible, but if it adds something, is it wanted, or would it be a waste of time and time better spent on some other initiative to provide GUI.

If you do it, I'll use it!

Yeah nah. Nenad likely has even less of an entrepreneurial mind than Carl Sassenrath.

It is going on nine years with Red and Nenad has yet to get to 1.0. Heck, he has yet to get to 0.7. He still hasn't done ports and the full set of protocols. As well, there is no Red for Linux to speak of.

At least Carl had a full op GUI for the major OS platforms in a scant five years. Oh and Carl conceived of the whole thing. All Nenad has done is copy someone else's work.

Oh and did I mention Nenad is French? When have you ever met an entrepreneurial Frenchman, ever? Frenchmen go to their government for subsidies.

A true entrepreneur would have taken the open source REBOL 3 code, stylized as R3 and fixed up anything that needed fixing.

Much has happened since Nenad started his project:

  • Decentralized Computing has taken off - block chain, federation
  • AI and analytics, which has brought R to the fore and even Matlab along with newer langs like Julia
  • IoT filled with http servers and Lua along with the usual suspects (C, C++, Java)
  • The majors (Google, Apple, Moz Foundation) putting out Swift, GO, Rust
  • node.js, which is a jailbreak of Javascript from the browser and which has recreated REBOL, albeit clumsily using json as the "REBOL data part" and Javascript as the "REBOL code part"

Each day that goes by, Python and node.js Javascript become further entrenched. Red falls further behind.

Nenad seems to have suckered people, likely the Chinese, hence the name Red, to toss him $500,000, but he has not delivered much in nine years. The guy seems to be the furthest one can get from being an entrepreneur.

If only Carl Sassenrath would come back to the scene and come out with REBOL 4 by fixing the errors of design in R3 and making it so it can be embedded.

So what do you think the Red coin was if not entrepreneurial? Perhaps they made enough money from that they've retired now?