Io, Io, it's Off to Play I Go

Call me slow, but I hadn’t come across the Io language before today. I popped over to its site (http://iolanguage.org/) and played for an hour. It seems to have a lot going for it:

• full OO (like Smalltalk)


• very simple semantics (even assignment is a message)


• nice orthogonal structure


• very compact


• fast enough


• different enough to be interesting, similar enough to be easy to learn

You can even get Io T-shirts and mugs at www.cafeshops.com/IoLanguage (what else do you need in a language?).

Io’s objects are generated by cloning existing objects, rather than instantiating classes (so it has some similarity to Self). So I could create a Dog object using something like

  Dog = Object clone
  Dog sound = "woof"
  Dog bark = block( write(self sound, "\n") )

  Dog bark

The first line creates a new object based on Object, assigning it to a slot called Dog. The second creates a slot in Dog called sound and arranges for it to reference the string “woof”. The third lines creates an anonymous block (which writes “woof”) and assigns that block to the bark slot in Dog. Finally we call it.

We can now create some objects based on a Dog: note that the mechanism is the same:

  rover = Dog clone
  fido  = Dog clone

  fido  bark              #=>  woof
  fido sound = "bow wow"
  fido bark               #=>  bow wow
  rover bark              #=>  woof

Io has differential prototyping: the only slots created in sub objects are those specialized in those objects.

Io has lots of interesting features. It keeps its code lying around in a message tree structure, allowing you to inspect and alter it at runtime (yup, alter. You can write self-modifying Io programs, so I guess adding aspects would be fairly straightforward).

Because it’s becoming a tradition, here’s 99 bottles of beer in Io (taken from the distribution).

  bottle = block(i,
    if(i==0, return "no more bottles of beer")
    if(i==1, return "1 bottle of beer")
    return i asString("%i") .. " bottles of beer"
  )

  for(i, 99, 1,
    write(bottle(i), " on the wall, ", bottle(i), ",\n")
    write("take one down, pass it around,\n")
    write(bottle(i - 1), " on the wall.\n\n")
  )

I’m not sure if Io is a keeper for me. It is certainly interesting, but it has a slightly pedantic feel to it (especially compared with Ruby). But it’s fun to play with.

That which is overdesigned, too highly specific, anticipates outcome; the anticipation guarantees, if not failure, the absence of grace.

William Gibson. All Tomorrow’s Parties

Every day in every way…

Imagine a simple (and somewhat boring) card game. In each round, all players are dealt one card each. Each player may hold at most three cards (so after the third round they must start discarding). After an arbitrary number of rounds, the player with the highest card total wins.

The strategy is pretty simple: when forced to discard, always discard your lowest card. No rocket science here: when you can’t control the cards you’re dealt, you win by eliminating the weakest of your holdings.

This seems to be a reasonable strategy in any situation where you need to optimize some collection of “things,” but where the resources you receive have unknown characteristics.

Our industry is suffering from an embarrassment of bad programmers. Much of the blame can be leveled at the hiring frenzy that occurred during the dot com boom, where anyone who could play Quake (or who had once watched someone play Quake) could get a job coding (and playing foosball at work). Many of these people are still in the industry.

So now we have a problem. Interviewing and recruiting good people is very difficult; For most organizations we’ve seen it’s a hit or miss affair. This means that the bad get let in along with the good (just like being dealt random cards). However, once the bad folks have been hired, it turns out to be hard to fire them. Unlike the card game, they stay in your hand, dragging down your overall score.

There are three things to be done here. First, companies could get better at recruiting. Unfortunately, one of the best indicators available to recruitors, past performance, is hard to come by. In the US at least, employers now tend to give anodyne references to ex-employees rather than tell the truth and risk being sued.

Second, we could find a way to fire the ineffective developers. If that happened enough times to an individual, they might get the hint and leave the industry (which would be good for all of us). Unfortunately, that’s also unlikely to happen. Even though most developers in the US are employees at-will (meaning they are in theory employed at the whim of their employer), in reality the various anti-discrimination laws make firing a risky business for most companies.

Our third strategy isn’t available to the card players: we can improve the individual cards in our hand. This means working hard to train and retrain folks, not just in the specifics of technologies and languages, but also in the soft disciplines: communications, business practices, and so on. Some developers aren’t trainable, but I’m thinking that the vast majority will benefit.

Interestingly, there are companies who recognize the value of attrition. GE, for example, has every level of manager rank their employees. After justifying these ranks to the manager’s manager, the company then puts in place an action plan for the bottom 10% (a plan which can include termination, a performance improvement plan with a time limit, or a move to a more suitable position). I don’t think I like the rigidity of GEs policy (at least as externally stated), but I think the intention is good.

Over the next few years, we all have to do something to improve the quality of the work delivered by our industry. If we don’t, we’ll find legislators doing it for us (possibly with professional licensing schemes and attempts to hold developers liable for faults in software). And improving the quality of work means improving the quality of the development community. Maybe it would be in our long-term interests to find ways to make recruiting more reliable (perhaps by setting up a way for employers to comment truthfully on a developer’s past performance). We need to make it easier to fire the truly bad developers (contract to hire and probationary periods are a good interim measure). And we need to find ways to promote on-going professional training. If we don’t help ourselves, someone in government will do it to us.

Passing Information to Our Children's Children's ... Children

There’s a great article in the January 2003 CACM which describes some very long-term data storage technology (Organic Data Memory using the DNA Approach).

In a nutshell, you encode your information using sequences of DNA base triplets (AAA, AAC, AAG, and so on), then splice these on to the end of a DNA strand, making sure that the stuff you write is past that strand’s stop codon. You then perform the necessary magic to get this DNA into the host’s genome. That way the new material will not take part in protein synthesis, but will be passed down as genetic material from generation to generation.

This isn’t science fiction: the researches encoded the words of “It’s a Small World”, added them to a bateria’s genome, then extracted the information again. Because bacteria can withstand all kinds of abuse (dessication, extremes of temperature, and so on), they believe that this gives us a good long-term storage scheme. (There’s the problem of mutations to deal with, but decent error correcting codes could probably deal with this).

Now, of course, we’ll see the RIAA step in to the act and insist that they need to add unique digital signatures into every human being.

Learning from Mistakes

I read a lot of aviation magazines. In every one, you’ll find at least one column dedicated to reporting on accidents. These reports are fairly dry: a restatement of the facts issued by the various government agencies that investigate transportation problems. Depressingly, a large number end with the summary “pilot error.”

Are our pilots a bunch of cowboys, recklessly flying planes in to the ground? Quite the reverse, the vast majority are conservative, careful aviators. So why does “pilot error” figure so prominently?

The authorities quite rightly give the pilot of an aircraft ultimate authority over that aircraft’s operation. It’s up to the pilot to check the weather, the condition of the plane, the distribution of weight, the fuel required, and many other factors, all before setting foot inside the plane. Once flying, the pilot’s job continues, monitoring weather, fuel remaining, aircraft performance, navigation, collision avoidance: the list is long and complex.

It isn’t easy keeping all these factors balanced, particularly not when the weather is closing in, fuel is starting to look marginal, turbulence is jarring your teeth loose and you’re at the end of a long, exhausting day. And yet we all (quite rightly) expect our pilots to maintain a level of near perfection. So pilots, being human, make mistakes, and sometimes these mistakes have tragic consequences.

That’s where the accident reports come in. Pilots read them, and read them avidly. They aren’t reading to gloat. They’re reading to learn. The pilots they’re reading about are for the most part every bit as careful as they are, and yet still something went wrong. So pilots read the reports to find out what happened, and maybe to try to tune their personal procedures to stop it happening to them. By reading these reports, pilots improve both their own performance and aviation’s overall safety.

Computer programming is perhaps half the age of powered flight. We face different issues; our mistakes can cause inconvenience, but rarely loss of life. But perhaps still there’s something that programmers can learn from the attitudes of pilots. Is it conceivable that we might one day have a way for developers to report problems during development to some anonymous forum so that others might learn? Could we start to use our own history as a tool to help us all improve?