Rebol 3 compared with Red

As someone somewhat new to the community here I'm maybe a tiny bit confused about the Rebol 3/Ren-C efforts as compared to Red.

Clearly it's a friendly relationship right.

But as someone new I confess for a bit I was thinking the message was that Red is the future and the Rebol 3 efforts were more or less defunct and replaced by Red.

I realize now that was mistaken, but can someone clarify for me - if both efforts are continuing into the future are there ways in which they are truly different/complementary?

Looking to the future when would I be likely to choose one versus the other?

1 Like

Partial Backstory: Nenad was probably the most prominent publisher of open source Rebol programs (e.g. Cheyenne, mysql driver, curecode)...and also someone with an entrepreneurial mindset. Hence, more than others, he was affected by the ever-increasingly-slow developments in closed-source Rebol...it wasn't just messing with his "hobby", it was hurting his bottom line. After repeated broken promises from RT, Red became a declaration of independence from that state of affairs (some have cynically wondered if Rebol was open-sourced only in response to how many people were embracing Red at that time).

Given the above starting conditions, that is far from obvious. But Rebol becoming open source was an opportunity for it to come under new collective management and unify...in theory. That's what I had hoped...see in particular what I said here in "Red's Method is the Future":

http://blog.hostilefork.com/media/rebol-state-union-july-2013/e-rebolus-unum.pdf

Circa 2013, I felt Nenad had a worthy mission, and with limited resources was executing on it doggedly. He's a hard worker, though these days may seem sometimes a "work harder not smarter" worker. (I still don't know why he's writing so much darn cross-platform 80's cash register code on desktops vs. following through with IoT or mobile...I thought we'd all agreed the latter was the point. Maybe he knows something I don't, or maybe he's wasting a lot of time for nostalgia's sake, of the world us old people are more at home with. :-/)

So it appealed to me to see a Rebol-like language that was doing its lower levels...a C-like systems language and an IL...without ever leaving the same homoiconic data structure domain. That smooth slope could really change how people experience the system they're working in, because the systems we use today make us feel so "out-of-touch". If we could really hold it all in our hands, it might "bring back the Fun". "The feeling from the 80s".

But Rebol had been around for well over a decade, with literally thousands of filed bugs, deep-thought wikis, and things from the R3-Alpha developers' area of concern. These people from the R3-Alpha age were ignored by Nenad; these were academic questions to him. He was mostly mad that his web server was slow, or not giving him the interop he needed...and there's nothing he could do about it without changing paradigms. He didn't want to, so he cast out the meditations of the monks and got to making the Rebol he needed...assuming his interests were more pertinent to most developers than tackling the "academic" issues which were stalling the process.

That's why when I get irritated enough, I've cynically called Red the "Buggy clone of Rebol2 written in a made-up assembly language the world wasn't asking for." Another R3-Alpha guru called it "Rebol's design ghetto". But if Nenad is right and is gauging the market correctly, then the explosion of hits on social media of those clamoring for his angle would be a validation for his direction.

However: if he's wrong in focus, we could reasonably call it a "vanity project".

Despite things I might say about Red when I'm feeling particularly pissed off--YOU don't have to choose. Many people participate in both projects, regardless of the divide between the organizers.

So whether we politically can collaborate today or not--given the personalities involved--the actual efforts are complementary, and ultimately convergent.

2 Likes

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:
http://development.saphirion.com/experimental/builds/android/r3-droid.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.

Yup.

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!