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. :)
UPDATE
Rebol version 3 is now open source under the Apache 2.0 license, so all those disclaimers I used to have in my Rebol articles about not getting attached to a proprietary language are no longer applicable! Use it without hesitation!!!
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?"Red: (laughing) "There he goes again! That's why he's the 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:
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 is actually contributing to that problem in ways...we seem to be so mired in it that it's derailed everything else. As the famous IBM commercial with Avery Brooks goes, where he says we don't need flying cars because we have software...
Where are the flying cars?! I was promised FLYING CARS!!!I don't see any flying cars! Why?! Why?! Why!
Except rather than dismiss it, 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:
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.
