This is the third 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.)

We know from the English language that humans are a bit lazy when it comes to expression. We’re always dropping syllables off of words if we use them often, or taking difficult combinations of letters and turning them into something easier to pronounce. Yet of course, this means we live in an environment ripe for ambiguity:

(Note: Image via Deena Hyatt)

By contrast, computer languages typically make programmers be redundantly clear in their notations. You’re always dealing with syntax… putting in parentheses before a list of arguments to a function, putting a close parentheses to say when you’re done. There are semicolons in many languages to tell the computer when you finished a line.

Yet we get a lot done with English without that symbol soup. Somehow, we communicate to each other with little more than a series of words separated by spaces. Essentially, that’s what a REBOL program is… “words” separated by “spaces”. It has conspicuously few parentheses or semicolons. Or equals signs, for that matter! If you strip out some of the incidental uses of symbols in names, it might be mistaken for human writing.

(Note: Some of the stranger notational aspects are just for show, for instance the function named none? could have just as easily been called is_value_none… you can change it to that if you want to. But the question mark convention is nice for boolean functions.)

So keep that interesting aspect in the back of your mind while I go straight for the jugular in terms of things about REBOL that may seem totally insane. I’m just being up front and honest with you about things you will find surprising. I will talk about the curious upsides after we’ve banged our heads against our keyboards a few times.

(more…)

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…)