Why Rebol Matters

Rebol Might Be the Language for the Rest of Us

It's a question that Carl Sassenrath is often asked, especially since he released his messaging language Rebol in Sept. 1998.

It's also a question that Carl has asked himself off and on for the past 20 years. And for 17 of those years he allowed himself to be dissuaded by it. In jobs at HP, Apple, and Commodore, he had access to early releases of Smalltalk, wrote a C compiler and a version of Forth, developed a system of remote procedure calls for Pascal, and wrote a LOGO interpreter. All along, he was refining his views on just what features a language ought to have, but he kept them to himself rather than foist on the world yet another programming language.

Meanwhile his contemporaries like Larry Wall and Jim Gosling went blithely ahead and added to the babble by creating new languages that became wildly successful and changed the face of programming. Languages that were, in Carl's opinion, not all that new.

"Is it reasonable to believe that we should be using 1970s language technology in the year 2000?" he asks, pointing out that the idea of bytecode interpreters and virtual machines didn't originate with Java, but can be found in Xerox Smalltalk manuals from the late 1970s. Carl's aware of Java's virtues, but thinks he has a better idea. "I'm after a new model of distributed computing," he says, "not just another language."

So, late in 1998, Carl released Rebol. The current version is 2.1.1 and is available for free for more than 30 platforms, including Windows, the Mac OS, BeOs, Solaris, and the major Linux releases. It's a functional language, like Lisp but without the parentheses.

Simplicity and productivity

Michael Dertouzos, director of MIT's Laboratory for Computer Science, has been championing the idea that computers and related technology should allow us to do more by doing less. There are other ways of putting it, but it's the holy grail of software development: to simultaneously deliver simplicity and increased productivity.

It's tough: productivity seems to come from power, and power seems to lead to complexity. But now and then we see an example of a product or a technology or an insight that makes simplicity and productivity turn out to be two sides of the same coin. And when greater productivity can be bought with less complexity, that's a breakthrough.

It's just possible that the Rebol model contains the seeds of such a breakthrough.

Here's the model: a core language that lets casual users do basic things very simply, but that has the power to let advanced users do much more. Plus Rebol has the ability for advanced users to extend the language into task-specific domains so that casual users in those domains can do the things that are simple only to them.

Carl calls this latter capability dialecting. A Rebol dialect for handling legal documents, for example, would have capabilities and would understand terminology specific to that domain. It's still Rebol, but the lawyer's dialect knows about torts, while the chef's dialect knows about tortes.

Most programming languages have some facility for extending their capabilities, through libraries of functions or new classes. The Rebol model is different, and is designed specifically to enable the development of these domain-specific dialects of Rebol.

Why is dialecting important?

Some of the world's work is just hard no matter how you measure it, but a great deal of it is not—it's simple, routine, drudgery. Every profession has its unique drudgery, which may look to outsiders quite complicated and obscure, but to the professional is just a chore. Just as the core of Rebol makes generally simple things simple, the dialects make these professional chores simple.

Think of the typical professional's work as falling into three categories:

• The simple, universal tasks that everybody has to perform, like sending email.
• The profession-specific tasks that are obscure to others but simple and routine to someone in the profession.
• And the genuinely hard tasks.

Rebol makes the first two categories so easy that intelligent non-programmers can use the language to do them. That, anyway, is the theory.

Profession-specific dialects should sound familiar to anyone who has programmed in Forth. Chuck Moore created Forth so that astronomers could program telescopes using astronomer-talk rather than computer-talk. But he didn't put a word of astronomer-talk in Forth; he just provided the mechanism for creating what, using Carl's terminology, one would call an astronomical dialect of Forth. Similarly, choreographers can create a choreographic dialect.

All of which probably proves that it's pretty hard to come up with a truly new idea in programming languages. But Rebol doesn't go about dialecting in quite the way that Forth does, and besides, is there any such thing as a casual user of Forth?

Not-so-hard core

Certainly no casual user is going to program in pure, unextended (undialected) Forth. But it's Carl's intention that Rebol be almost English-like. He intends that casual users should be able to use it, with only slight coaching, to do such things as:

• Sending a quick email message:
  send [email protected] "Hi, Mike. Just testing Rebol."


• Reading their email but leaving it on the server:
  print read pop://luke:[email protected]
  (That example makes more sense if you realize that functions, like read and print here, are applied in right-to-left order.)


• Grabbing a web site and saving it as a file:
  write %swaine.html read http://www.swaine.com
  (We've lost the most technophobic at this point with that % prefix for file names.)


• Executing a Rebol program on a remote site via ftp:
  do ftp://ftp.site.com/scripts/test.r


• Creating and using math functions:
  factorial: func [a] [return either a > 1 [a * ! (a - 1)] [1]]
print factorial 5
  (OK, recursive function definition is not something that a casual user is going to do, but this is simple stuff for some of us, and this example shows how Lisplike the language is.)


• Convert all line terminators to those used by the local computer (PC, Mac, Unix, Amiga, etc.):
  file: to-file ask "Filename? "
write file read file
  (This just shows off one of the core functions built into the language.)

Simple things done simply is Carl's mantra for Rebol. To most users, checking their email and working with money and dates would fall into that category, so Rebol has the necessary protocols and data types built into its core. Rebol's built-in datatypes include types for currency, times, dates, numbers, strings, words, tags, logic, lists, hashes, data types, and objects (although Rebol is not really an object-oriented language). Built-in networking protocols include HTTP, FTP, SMTP, POP, SMTP, NNTP, Finger, and Daytime.

But there's not a lot of fat in the core. Keeping it simple helps to keep the footprint extremely small, around 250K.

Then there's dialecting. 'Simple' is meaningful only in context. What's simple for a doctor is not the same as what's simple for a stock broker. Here's a message written in a hypothetical stock broker dialect of Rebol:

sell 500 shares of "Microsoft" if above $130 a share

Some of the terms in this message are functions, some are data, and nearly all are dialect-specific. The syntax of the language makes it possible to use user-defined elements in expressions that look much like English sentences.

Caveats and criticisms

On the other hand, that same sort of free-form syntax (function names and arguments strung together without parentheses or other syntactic sugar, Forth-like right-to-left application of functions, Lisp-like nesting of functions) can also create hard-to-read code:

return copy/part head insert/dup tail form data " " length length

Carl Sassenrath places more emphasis on the messaging capabilities of Rebol than I have here. While Rebol's ability to talk the various talks of the Internet and its possibilities as a language for distributed computing are not to be ignored, I think its more obvious benefit lies in its ability to deliver increased productivity to many groups of users while remaining relatively simple to learn and use. This benefit depends, though, on the development of useful dialects of the language. It's a promise, and not one that Rebol Technologies can keep without help from developers.

Then there are the tradeoffs that come with ease of use and portability. Carl expects to have Rebol implemented on 50 different platforms by the end of the year, and there are costs associated with this kind of versatility.

One cost is platform-specific capabilities. Rebol doesn't have any. Another is openness. Rebol isn't open source and probably won't be: the model is for the company to take direct responsibility for all those implementations. And the decision not to implement any sort of operator precedence has certain advantages, but it makes the language less familiar to those coming to it from other languages.

None of these issues matter, though, if the language doesn't produce efficient code. Rebol 1.0 was very slow, but 2.0 was a big improvement. I haven't seen any independent benchmarks yet, but my own informal comparisons seem to support the company's claims that Rebol programs now perform comparably with those in Perl and other relevant scripting languages.

Beyond that, there has been some work done by Joe Marshall on an open source compiler for Rebol. For portability, it doesn't actually compile to machine language, but to Scheme. The author has published some preliminary benchmark results at his site.(Site no longer available.)

Until we begin to see some significant dialect development it'll be hard to say how important Rebol will be. Just the core functionality makes it a competitor to other scripting languages, but, given the installed base of Perl and Python users and the maturity of those languages, probably not a winning competitor. Dialects, it seems to me, will spell success or failure for Rebol.

Why Rebol Matters