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: 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.

(more…)

This is the first 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 is built on the foundational concept of a flexible series, and that’s what I’m going to focus on here. It’s one of the many things that give the language a kind of elegant uniformity. In my article about Computer Languages as Artistic Medium, someone likened it to modeling clay (mold is even a keyword in the language). I thought that might even make a good marketing visual and made a prototype, so keep the words “flexible”, “artistic”, “uniform”, “workable” and “fun” in mind.

(more…)

Not many people have the ability to look at the few fundamental elements of a system (such as constructs of a new computer language) and extrapolate the long-term implications of their use. But rather than jump in and tackle the difficult question of understanding the expressive power and limits of computation, I’ll start by talking about a simpler problem. Don’t panic: it involves crayons and coloring!

This example is going to seem pretty easy on the surface, and you may be familiar with it already. It involves trying to find a way to color in maps so that no areas which share a border are going to be the same color. Here’s an example of a simple coloring with 5 crayons, and then finding a method for doing it with only 4 (taken from Wikipedia’s article on the subject):

Without prior knowledge, the average Joe can only guess at how many crayons he’d need to reliably fill in any map he is given. Just by trying a few cases, he might get an intuition that a small box of different colors will do the trick. But if Joe knew the Devil was going to be presenting him with an arbitrary map and getting his soul if he couldn’t color it properly, he’d probably buy Crayola’s biggest box…120 colors! (Plus, because he doesn’t know for sure that even THAT would be enough, he’d also probably try to round up the discontinued colors off of eBay!)

Yet there is salvation from this kind of paranoia. Early formalisms of the map-coloring-problem from mathematicians comforted us with proof that it *never* took more than 5 different colors…and that 3 will certainly not always be enough. After considerable debate and experimentation over the years, we ultimately found that we only need four unique colors for any map the Devil—or anyone else—makes.

(Note: Depending on your purposes, discovering it was 4 vs. 5 might be somewhat academic. I myself feel that the more crucial step was bringing in math to save us from needing to pack a potentially infinite number of crayons.)

Now…what if the “Devil’s Map” you must solve is instead an arbitrary selection from mankind’s constant creation of new ideas for software? That raises a lot of questions about what a programmer needs in their backpack to be confident they could correctly “color in” any program specification with a working implementation.

(more…)