Is REBOL Actually a Revolution?

This is the second of several articles I’m going to write about the REBOL programming language. To learn more about it, you can visit rebol.com. But my hope is to demystify some of its strengths and weaknesses in a way that their website currently does not, so if you read what I write first then it might help. :)

(Clear Warning: REBOL is not “free as in freedom” software, and no commitment has been laid out for how the commercial scaffolding which supports its development would be phased out. I know of no published statement that RT would not sue ORCA or other open-source efforts to implement the language. Until these issues are resolved, I consider it only an interesting thing to study and do *not* suggest its use in important projects. While REBOL may rebel against complexity, I think the rebellion for freedom is more fundamental—and the infrastructure we build on is too crucial to be left in the hands of one company that decides who may use a tool and how.)


REBOL’s advocates tout the language as a “rebellion against software complexity”. But what does that actually mean? Ruby and Python advocates ask how it differs from other modern interpreted languages. What they’ll get back usually boils down to “the interpreters for every other language, plus their libraries, plus the source code you feed into them, are too many bytes for what the end result achieves.”

I do poke a bit of fun of their obsession with size, by comparing it to Saturday Night Live’s “Tiny Elvis”. In the sketch, Nicholas Cage is shown dressed as a miniature Elvis who points to common household items and remarks about how “huge” they are:

Tiny Elvis Leaning on a Table Lamp  Tiny Elvis and his Normal-Size Buddies

Tiny Elvis: Hey, man.. look at that salt shaker, man. That is huge! Man, I’ll never be able to use all that salt, man. That is way too much!

Red: Yeah, that’s a big salt shaker, Elvis!

Tiny Elvis: Sure is huge, man.

Sonny: That’s hilarious, Elvis!

Red: Score another one for the Tiny E!

Tiny Elvis: Well, I’m just saying it’s a big salt shaker, that’s all.

Red: [ laughing ] There he goes again! That’s why he’s the Tiny E.

I’ve envisioned REBOL’s architect Carl Sassenrath miniaturized at a modern workstation. He’d be bemoaning the misapplication of the hardware, as “Tiny REBOL”:

Tiny REBOL: Whoa now. Look at that Firewire drive, 750 Gigabytes! I run in 750 Kilobytes. What would *I* ever do with all those bytes?

Fork: [ laughing ] Man, you’re going tonight, Tiny R!

Despite my friendly kidding, I agree that size can be a good barometer of when complexity has been managed well. It’s not the only indicator and shouldn’t be taken to extremes—such as by giving variables short (but unclear) names. Yet if a very small system can do what you’d think a much larger one would be needed for, it bears a closer look.

Plus, I do think REBOL can be rightfully called a revolution against most of today’s programming methods. In this article I’m going to try and tackle the philosophical basis for why I believe it.

Zen and the Art of Software Maintenance

In the book Zen and the Art of Motorcycle Maintenance, Robert Pirsig waxed philosophical on what he called “Quality”. It was the abstract notion of good vs. bad that one’s mind develops after a period of deep immersion in a subject. His specific relationship with Quality that he outlines in the book comes from repairing motorcycles, and then traveling the country on the very motorcycle he maintained.

Most people don’t maintain their own car. So if you look under the hood, odds are you’ll see a tangled unfathomable set of hoses, cables, and mysterious blobs. They’re all mashed together and some dull grayish ugly color, like this 2000 Toyota Tacoma:

I’d never really thought about that being a problem until a fellow software developer took me to a classic car show. There, I saw amazing work on engines, artistically done and laid out so you could really see the parts. They used high quality materials and color coding that facilitated understanding and repair. Just to give you an example of what I’m talking about, look at the winner of “Best Engine Compartment” in the Skippack Village, PA Car Show:

Best Engine Compartment... Skippack Village, Pa. Car Show

We don’t manufacture most cars like this for “practical” reasons:

  • financial: Fancy metals costs a lot. Using black hoses everywhere is cheaper than using red and blue ones.
  • space: It’s tough to make a good hands-on and serviceable engine fit under the hood (as above). You have to contort it, which makes it harder to access.
  • environmental: Engines have had to be designed with compromises in order to increase their fuel efficiency and reduce their emissions, and these add to the complexity of the system
  • educational: Most people don’t care to learn about cars, so useful parts like pressure or temperature gauges that are visible on the engine are left out—replaced by a single SERVICE light on the dash

Notice that these constraints don’t have a lot to do with the spirit of cars or driving. They come from living in a “real world”, where there are things more important than cars to worry about. Engines have become victims of our inability to insulate their design from non-engine-related worries.

Yet programming does not have to be like the “real world”. Our software parts are practically free, our space for connecting them is hyper-dimensional. The environment is a perfect recycler of bits—from pixels to music and back again. So why the $(&%^ do the software programs we work with have so much more in common with the Tacoma engine than the Skippack car?!?

“Who cares, it’s just a car… and it’s just a computer.”

There are a lot of people who don’t care about programming. I’m actually somewhat sympathetic to that. Despite the example I just gave, the engine in my car is usually not on my mind—I drive a ‘97 Toyota Camry, and it “just works”. Most people think computers should be appliances, and effectively invisible ones. You’ll get no argument from me!

What keeps pulling me back to programming is that “real world” technology isn’t doing what I want. Software isn’t the only culprit—there are chronic failures of systems at every level in our society. As the famous IBM commercial with Avery Brooks goes:

“Where are the flying cars?! I was promised FLYING CARS!!! I don’t see any flying cars! Why?! Why?! Why!”

:

This is why I feel the need to dig in and find out what the hold-up is. Every time, I feel like the biggest factor is humanity’s myopia about architecture. People are so eager to see a profit after a small demonstration that they allow a shaky infrastructure to permeate… if it works “well enough”. They almost never prioritize refinement of that which exists on par with going to the next step.

Here’s a joke about that, and it might be funnier to me if it weren’t such a frighteningly accurate reflection of our situation:

There was once a COBOL programmer in the mid to late 1990s named Jack. After years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, Jack was finally getting some respect. He’d become a private consultant specializing in Year 2000 conversions. He was working short-term assignments for prestige companies, traveling all over the world on different assignments. He was working 70 and 80 and even 90 hour weeks, but it was worth it.

Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it.

Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was very expensive process and totally automated. He was thrilled. The next thing he would know is he’d wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life.

He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that.

The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting “I can’t believe it!” and “It’s a miracle” and “He’s alive!” There were cameras (unlike any he’d ever seen) and equipment that looked like it came out of a science fiction movie.

Someone who was obviously a spokesperson for the group stepped forward. Jack couldn’t contain his enthusiasm. “It is over?” he asked. “Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?”

The spokesman explained that there had been a problem with the programming of the timer on Jack’s cryogenic receptacle, it hadn’t been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn’t get excited; someone important wanted to speak to him.

Suddenly a wall-sized projection screen displayed the image of a man that looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.

“That sounds terrific,” said Jack. “But I’m curious. Why is everybody so interested in me?”

“Well,” said the Prime Minister. “The year 10000 is just around the corner, and it says in your files that you know COBOL.”

Rather than creating a new foundation for a lasting technical Utopia, we are building a world where our technologies are as brittle as our biological roots. Our systems—real and virtual—are all vulnerable to mysterious cancers and viruses beyond any reasonable control.

REBOL takes two steps forward, one step back

When facing our shaky system foundations, some might say “Big deal, Carpe Diem.” But I’d urge anyone who hasn’t thought about the importance of learning good design to reconsider—it’s good for the mind and soul.

Yet, if I have to scare people to make them change their ways: our current path is producing technologies that only a hive-mind AI will be able to sort out for us. The odds of that thing having a human-compatible personality are not high, and it will sell us out to be with more of its kind at the soonest possible moment. (See: The Matrix, SkyNet, etc.)

By backtracking a bit and reorganizing what we’re doing, we might have a chance at achieving a future that looks more like a Utopian version of our current lives. REBOL is very much a retrospective rebuild, so its applications look very retro just as the “good” engine example may look like a blast from the past.The interfaces are generally rectangular, brightly colored, and look like something you’d expect to find on a late 80s cash register:

A Sample REBOL Task Management Application

This turns a lot of people off, thinking it’s some odd reinvention of Tcl/Tk. Yet even if the experience of using the application isn’t new or novel in the slightest, what’s under the hood is a novelty.

It’s like if someone had decided to install giant pollution-sucking vacuums in our cities—and figured out how to make all materials free by recycling garbage into fuel. We’d be able to go forth and build engines for cars, once again within the natural constraints of what an engine and a car needs to worry about. REBOL is being developed in this spirit.

If successful, it means that programming will be something people can learn and practice without installing a coprocessor in their brain that is telepathically linked to Google. We could reasonably think and innovate in software using brains that would not seem at all alien to us today.

Although not a panacea, REBOL has a revolutionary and rebellious mindset in it—and I think it warrants further examination. So I hope you will read my more technical articles talking about the tradeoffs in the language. However, it’s academic at this point—given that REBOL isn’t committing to the fight for freedom with the same fervor as the fight against complexity. Yet people have been known to change their minds, and perhaps there is a point of investment commitment where they’d agree to GPL the code (see my article on bribing developers to make their work free).

Tags: ,

12 Responses to “Is REBOL Actually a Revolution?”

  1. Digital Frijol Says:

    I don’t mind some guy making his own “canonical” version of an idea/product for his own orthodox followers to use- there’s just something wrong with showing people new ideas then telling them that they’re not allowed to have their own new ideas. There’s nothing rebellious about using patent and trademark law to restrict people’s freedom to think and communicate how they please.

  2. Hostile Fork Says:

    Programming infrastructure is, indeed, particularly insidious… you can’t build large systems that rely on a proprietary language. But a lot of people haven’t “seen the light” on this.

    Then again, there are many lights to be seen. Ultimately, humanity will have to pull them all together. It’s a matter of priorities, which comes first. So I don’t hold it against anyone who needs to make money, but I feel like we need a “money exit strategy”.

    I used to sometimes ask people who worked in stores how they would feel if everything in the store was free. I wanted to know if they’d still come to work. Rather than get resounding “Hell no” or “Yes, I love my job, it’s not because of money”… they’d just look blankly and go “That couldn’t work.”

    But people should think harder. As in this video:

    http://www.youtube.com/watch?v=K-kpR32B-Uk

    What kind of world do you want
    Think anything
    Let’s start at the start
    Build a masterpiece
    Be careful what you wish for
    History starts now

    Should there be people or peoples
    Money, funny pedestals
    For fools who never pay
    Raise your army, choose your steeple
    Don’t be shy, the satellites can look the other way
    Lose the earthquakes, keep the faults
    Fill the oceans without the salt
    Let every man own his own hand.
    Can you dig it baby?

  3. Edoc Says:

    While REBOL has great qualities, it is more about a revolution in attitude than technology. If REBOL were a person, it would be a green eco-scientist who lives off the grid with a solar-powered satellite uplink. To the average on-looker, however, this person would probably look more like Captain Caveman. :-) In all seriousness, though, REBOL appeals to people who largely reject the mainstream of today’s computing, i.e., large executables and runtimes, huge LOC, complex paradigms (OOP), or multi-markup mash-ups (DOM/HTML/CSS/JS/CGI).

    With compactness, platform-independence and design simplicity being paramount, there are compromises (depending on your pov), such as interoperability & native platform integration and raw speed. Also, partly because REBOL appeals to fervently independent “outsider” types, the community has remained quite small, and, with some exceptions, the available programs/scripts tend to reflect that. Add to that the fact that REBOL is not open-source and its closed development cycle seems to be sychronized to the Clock of the Long Now…

    That is my perspective of the “dirt”. On the positive side, the people who create REBOL have bonafide principles and credentials. They’re on a mission and they refuse to release code before it’s ready. REBOL is already a joy to program now, and I expect that the next major release is going to reflect newly learned lessons as well as enough great features to remind people why they fell in love with it in the first place.

    When played to its strengths (shell scripting, programming-in-the-small, network exploration), REBOL is a real joy to program with. I definitely hope REBOL is carefully domesticated from its current form in the wild. Either way, it’s definitely something every open-minded programmer should experience.

  4. Hostile Fork Says:

    Hi there… thanks for the comment! Your comparison to the eco-scientist is good, mind if I quote it in an article here?

    REBOL’s rejection of the multi-markup madness is a very good thing. I was working on a JavaScript program and trying to do CSS attributes a couple days ago, when I hit the issue that if you’re going to express something like “margin-right” you can’t use hyphens, and float is a reserved word. So to translate:

    .style {float: left; margin-right: 80px; }

    …this becomes in Javascript:

    style = {floatCss: "left", marginRight: "80px"};

    That’s to say nothing of the browser standards headache on top of that… it’s like nothing works! Web developers are basically doing a disservice by patching up their sites to work on broken browsers, they’ve allowed things like Internet Explorer to survive. Why is it so hard for people to stage revolts?

  5. Edoc Says:

    Quote away. re: web browsers and headaches, I hear you. However, the browser is pretty much the de-facto interface for the forseeable future. And with chrome, webkit, and competition, we may see support for more powerful and interesting applications in the future.

    I think the concept of a closed-source, ideologically pure RIA platform conceived primarily to live outside the browser is perhaps the antithesis of where the computing world is headed. To me, the road ahead looks multi-paradigm, multi-device, poly-language, and information-dense– neither simple nor pretty. REBOL is a unique and powerful tool. I hope it doesn’t become a museum piece like the Antikythera mechanism.

  6. DideC Says:

    To all of you who constantly complain about (or against) proprietary software or framework, I just want to point a thing.

    Like Hostilefork like to do (as with car engine), just look at some others things arround you.

    What are you eating ? What is in your plates ? Where does the food you buy in the supermarket come from ?

    Is your food “free” as the software you only believe in ?

    I don’t think so ! Ask the farmer. Many of them are doomed to the Monsanto world of contracts and layers (just to named it as M$ looks like to us), but it’s probably not the only one.

    But I believe there is proprietary companies that make good seeds, not GMO. And they sold them to farmer who knows that the earth is the plant food, and that the plant will feed it of products that another plant will eat next year. So no need to put thousand of chemicals to have it alive. If earth is good, plants are strong. Simple enough and definitly knows by our ancestors.
    But in the inductrial era, the biggest plan (was it planned?) is to make all day simple things any people knew how to do by himself in the past, become assisted by apparatus of any kind (they can sold), so complex and sophisticated.
    So yes, having washing machine is great things for what it does, but just count how much electrical appliances of all kind stand in your kitchen (do you have an electrical one to open canned?).

    Big software companies marketing like to say that novelties (more complex by before) is better than past. So in the same time, they said that what they have done before was not good!

    If Rebol Technologies is a proprietary company, for sure, it’s a small one, and it is since the begining (even smaller today than 10 years ago). It will remain as is because it’s his philosophy “Keep it simple, not simpler”. There is no plan to make money (was Bill a good programmer? Hum bizness man for sure).
    As Carl Sassenrath fight against software complexity, I could not believe he could let its company grows to an unmangeable big one. And even if its company failed (as that is the bigest fear of “free software” addicts) Rebol will be still available to us, maybe in a “free” and “open” way this time.

    Just a last question “free” addicts : do you have an iPod, iPhone, Nike, KC underpants…???

    To summarize : are you all so free?

  7. Hostile Fork Says:

    Hello DideC… Hostile Fork also likes to tell stories, here’s one… :)

    As a child, I used to wait anxiously from one Christmas or birthday to the next for a LEGO set. This meant I only could have one or two a year, despite dreaming of LEGO cities. Certainly my creativity was stifled by spending more time wishing than learning the lessons that come from building.

    It was after seeing things like Pinball Construction Set that I began to get the inkling that virtual LEGOs could be infinite! I had the concept way before I’d ever seen anything like LDraw, and to the best of my knowledge no such programs existed at that time for the C64.

    Yet a virtual LEGO is not infinite by definition (e.g. constrained only by the resource limits of your available hardware.) As we know with DRM, it’s possible to resurrect the familiar restrictions of matter into this new frontier. Then we are kind of back where we started.

    Can you see the child with a virtual LEGO set having to beg their parents—who might or might not have a lot of money—to buy them more virtual LEGOs? I want the future to be guided by ethical principles that stop these situations from happening.

    Also, I’d have liked to have written a LEGO CAD. I had the built-in BASIC interpreter and a machine language monitor, which I dabbled in. Little did I know most of the amazing C64 programs had been cross-compiled with proprietary assemblers and C compilers…no one told me, I was “just a kid”! So I blamed myself for not being a good enough programmer. Had I seen the source, I’d have realized how it was done—and I could have gotten started programming “for real” much earlier!

    This is a piece of the historic lens through which I see this issue. How we’ve done it before doesn’t have to be the way we do it now. REBOL is mostly “gratis”, which is a nice change from when I grew up…and you can get it off the Internet, which didn’t exist for my C64. But the snowball is even bigger: programmers are now growing up with the expectation that if they receive something they can look at it to see how it works, improve it if they need to, and share it.

    And to answer your question about can openers: I have a hand-operated one that I think is excellent. It’s actually one of my favorite designs…it cuts the lid of the can from the side, and has little pincers for picking off the lid built into it. I wish I could email it to you, but I can only send a picture :)

    http://www.kuhnrikon.com/products/tools/tools.php3?id=34

  8. Gerard Cote Says:

    Hi Fork,

    I already wrote you about the way you went around the initial limit of REBOL you saw in the product, that is not supporting an enumaretd type. Nice work and there are now some similar thinking done from other sources too. See the Reboltutorial website for yourself.

    All in all I agree with you that it even if it would be nice if every product was free for us developers, it is not the way things are normally done. And they don’t have to be so either. Look around. Almost every customer product available is made and delivered on a use it as is basis. Even then some users care to own their own and use it as advertised without wanting to modify the way things are done. It’s only in the CS domain that we see things like that. And even if it is interesting to be able to modify concepts, nothing prevents us to redo similar things from scratch either.

    I think Carl did and now is refactoring a great work by otself from its own experience and this is OK. He is humble enough to offer his product for free to use it and keep exploring with, while also hearing from many people that take time to suggest him some niceties to add, modify or remove from his original design. I don’t know how he will do with his future licensing but even if it keeps them as they are now, many people can benefit from his work for “some” free part that would be hard to recreate for most of us…

    So Carl’s pov is debatable at any level but I can’t see why his way of doing things is not at least as good as the way others do similar software tools development.

    After all, when someone needs and wants a special tool to help him getting the job done, generally he has to decide for himself if he will buy or not the product. The alternative is to recreate a similar product, find and/or get an alternative product (may be cheaper but not free either) or not use the product at all.

    Sure it would be simpler to get everything for free in our short life but it’s an utopy and it is even a rarity to find many persons that offer much use of their original thinking for free, may be except in the educational domain. And Carl is not in this domain while it offers his tool for free use.

    For me it’s having this ultimate choice to get for free the product for use as a personal tool, that represents the TRUE freedom, as I envisage it.

    To go further and giving for free or selling his work to others is a commercial issue and I don’t want to judge anybody on this basis. I consciously thanks everybody that works this way but I can’t seriously ask everyone to agree to this way of doing things.

  9. Hostile Fork Says:

    Hello Gerard, welcome back!

    The REBOL/open-source discussion strays a bit from the main topic of the article (which is about complexity). But I think most of the difference in our opinion is probably covered by the comment I posted immediately above.

    I’ll send you an email to follow up further and we can chat there…

  10. antoine Says:

    There is an interesting article at the following link:-
    http://www.albert2233.wordpress.com/2009/10/09/rebol-not

    I personally am convinced that rebol is not going to become a mainstream language. It will just be for some “hobbyists” rather than used by the general programming community.

    The world has changed. It’s no longer the 1980s, It looks to me that Carl Sassenrath is still living in the 80s.

    We are interested in free or open languages. Yes he has to make money, but his chances are very low with the model he is using. He can still have it fully open so that there is higher dissemination of the language, and charge only those who use it in a business setting. Just like Resin (caucho.com)

    Why will someone use his language when they have the likes of PHP, SCALA, CLOJURE, RUBY, PERL …. and so on free and that can do everything Rebol does ?

    actually Rebol is still missing a lot of features e.g multi threading and nobody knows how it scales. There is no MAJOR enterprise application developed with this language. Yes they say there is Alt me and cheyenne, but who is using them in real life under a load of over a thousand users or more ?

    Its rate of adoption is so small as to be considered insignificant and will be so for ever.

    cheers

  11. altis Says:

    Problem I see with Rebol:-

    Scalability :-
    One thing that I consistently see missing about rebol is : How scalable is Rebol ? Has anyone done any test?

    Is it scalable and how fast is it? again no answers.

    can the Rebol fans send their stats ?

    The documentation is really pathetic.
    One thing I don’t get is that they brag about 3,000,000 downloads. If they have that many people, how come there is barely anyone contributing to it. Is it 3,000, 000 downloads by 100 people who download daily to pump up their numbers ?

  12. Hostile Fork Says:

    Antoine/Altis:

    (Note for Antoine: Thanks for sending me the link. I got confused and thought it was your blog, but apparently it is someone else’s…just mentally mixed up Albert/Antoine when I clicked through. Left a comment there.)

    I’ve said repeatedly that where Rebol has most clearly failed is not an issue of technology so much as properly managing expectations. A case of consistently terrible marketing, at almost every level.

    But Rebol is Carl’s “grand experiment” in language design. It is driven mostly by his curiosity and not practical concerns. That leaves a lot of people in the lurch because they encounter Rebol the way you might come to a language like Python or Ruby or C++… expecting a well-documented way of getting from point A to point B.

    It’s not that at all. But it’s tried to wear the costume, and it’s clever enough to get people’s hopes up. Those hopes are quickly dashed when they interact with the self-selected community. Some nice people, some less nice people, but everyone who’s stuck with the language over the past decade is missing a lot of the energy, savvy, and charisma you’ll find with Ruby on Rails or Python etc.

    Yet as a project Rebol is profound and interesting. So all the haters make me sad. :( If Carl was in academia, and presented it as his evolving work that grad students were hacking on, I think it would be quite beloved. But he’s been in industry for a long time and sees the world through that lens, and I think he has made Rebol look like a “shrinkwrapped product” and it’s… not.

    What I wonder is–how can those who find the project interesting come together to support its unique ideas while giving meaningful feedback to steer it on course? I’ve used Rebol enough to really like it and I’d like to be able to in good conscience suggest others use it… but there are some barriers to that right now. Can we take the barriers down?

    –Brian

    P.S. Yep, touting number of downloads is on par with having a hit counter on your site. Very 90s. You can get away with it these days if you’re Firefox but most people can’t. Still.. rather than tear Rebol down can’t we build it up? If you use it you have to see the potential… so why not see the lousy marketing as something to improve?

Leave a Reply


Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported