A couple years ago, I read an article that gained popularity on social-bookmarking sites which was entitled “8-year-olds should test my code”. It’s a story about a child named Brian (no relation :P), who crashed UCBLogo only seconds after encountering it for the first time:

The author is an engineer at Google, and said this:

“I had played with UCBLogo for two weeks and hadn’t made it crash once. Brian brought the whole thing down in three commands. The most telling part is that when I tried to reproduce the defect a week later I couldn’t. I issued rt with a ton of 9s and just couldn’t get it to break. As it turns, it only crashes when you omit the space, which of course I didn’t think of doing. It took me more time to reproduce the defect than it took Brian to discover it.”

We’re offered the conclusion that we need legions of 8-year old testers, since their lack of preconceptions makes them great sources of unanticipated input. I strongly disagree.

For one thing, automated fuzz testing can be made much more genuinely random. But more importantly: 8-year-olds have better things to do than feed random data into programs that were developed using defective methods! It’s much more gratifying if kids are using solid software tools that enable creativity and learning. Even better is if their curiosity about the tool can be satisfied by reading its implementation!

This is not as unattainable as it sounds. I’ll go deeper into this example to make my case…by showing what caused this bug and how far ahead modern techniques are.

(more…)

Now and again, I look at the searches that bring people to hostilefork.com For some period of time, the largest search phrase bringing people here is “extjs fork”. Sadly, they aren’t looking for the articles I wrote in 2007. Instead…it turns out there was a huge backlash against the Extjs project surrounding a change of the license from LGPL to GPL.

People have been up in arms and threatening to fork the codebase, and independently develop it under the previous contract. (To the best of my knowledge, the only place such a forked codebase has been posted is OpenEXT. But with very few commits and the most recent patch being applied in October of 2008 it is not too promising.)

Since people are finding my blog because of this question, I’ll take a stab at addressing the issue and offer my thoughts. I think they made a mistake in doing this change the way they did. Extjs should revert the current 2.0 repository to LGPL—applying the GPL to only 3.0 and beyond—so anyone using v2 who needs LGPL can use all the bugfixes that body of code has.

I’ll explain in more detail.

(more…)

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

(more…)

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

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