On a plane flight, the only reading material I had available was someone else’s copy of Joel Spolsky’s User Interface Design for Programmers. It’s very short… and took about an hour to read:

I’m afraid I have to mostly side with the less positive reviews on Amazon. When people buy texts on user interface instead of reading “some guy’s blog,” it’s usually because they are looking for well-vetted and researched ideas they can apply. But anyone experienced enough to properly take action based on this book’s glib advice (like “users don’t read!”) is probably smart enough to make all the necessary realizations on their own.

Joel nevertheless has an entertaining and frank way of talking about his personal experiences in the software industry. So I think it would come off better with a less ambitious title…like Joel Spolsky’s Top Anecdotes About User Interface. The cover could have Joel at a party with a martini, with his hand over the shoulder of a nervous bespectacled guy who’s about to get another earful about some Windows dialog box that sucks.

I’m not saying that kind of presentation is not useful or fun. In fact, most of my software development conversations are little more than me ranting in that fashion. Then again, I don’t charge anyone for it! (To be fair, Joel only charges for “about half” of the book, the rest is free on his website.)

Rather than debate the merits of the book any further, I decided to just write down a few things that reading it got me started thinking about. So begin <rant>…

Read the rest of this entry »

(UPDATE 26-Jun-2009: A fuller development of the Arecibo Ascii code is now available at http://hostilefork.com/uscii/)

Every programmer who knows English is aware of the ASCII code, which declares that 65 means “A” and 66 means “B”, etc. Yet there is nothing intrinsically “A-like” about the number 65 (binary: 1000001), nor anything B-like about the number 66 (binary: 1000010). To see that, just imagine living in the 1800s and this fell from the sky on a piece of paper:

1000001100001010000101000001

Even if you knew it was supposed to represent text, I think it would be impossible to read that as “ABBA” with any degree of confidence. You might be able to get a clue that 7-bit sections were significant if you had a large body of data and realized they were always multiples of seven in length, but any single signal like this would not be enough. You’d be in an especially bad position if you didn’t know anything about alphabetical order (which isn’t a strict prerequisite of being able to read or write English successfully)!

To address this, I created something called “Arecibo ASCII”. It’s named after the infamous Arecibo message—a binary sequence transmitted into space that tried to explain some things about humanity. The goal was to make as few assumptions about the receiving aliens as possible…only that they had an understanding of physics and math (and obviously, the ability to detect electromagnetic waves).

When Carl Sagan and Frank Drake composed the message, they took it to Richard Feynman without explaining to him what it was. They figured if Feynman couldn’t decode it—given his upper hand of already knowing Earth science—then the aliens wouldn’t have a chance! Luckily, Feynman got pretty much all of it.

In the spirit of that test, I’ll send you an “Arecibo ASCII” message before I tell you how it works!

11111​11111​11111​11111​11111​11111​11111​01111​11111​11111​11111​11111​11111​11111​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​11101​11111​11111​11111​11111​11111​11111​11110​10001​10001​10001​11111​10001​10001​10001​00000​00000​00111​01000​11000​11000​10111​00000​00000​00011​11100​00011​10000​01111​10000​10000​10011​11100​10000​10000​10100​01000​00000​01000​00000​01000​01000​01000​01000​01100​00100​00100​00100​00100​00100​01110​00000​00000​00111​01000​11111​11000​00111​10000​00000​00000​00000​00000​00000​00000​00011​11110​00010​00011​11010​00010​00010​00000​00000​00000​11101​00011​00011​00010​11100​00000​00000​10110​11001​10000​10000​10000​00100​00100​00100​10101​00110​00101​00100​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​11101​11111​11111​11111​11111​11111​11111​11110​11111​11111​11111​11111​11111​11111​11111​01111​11111​11111​11111​11111​11111​11111​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​1110​

Want to test your alien-codebreaking-savvy? See if you can figure out what that says before you read the rest of the article! Otherwise, just read on as I spill the beans…

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »