Coding Horror

The standard computer keyboard is the quintessential human input device. Although it's amazingly adaptable, a recent Tom's Hardware review of the Ergodex DX1 underscores the limitations of the keyboard as an input device-- and also highlights some of the crazier keyboard alternatives out there:

So far, technology hasn't provided us with the ability to customize a hardware interface that meets our individual needs. Thus, we are usually forced to retreat to the 138-year-old quintessence of ubiquity: Christopher Sholes' "QWERTY" keyboard.

This is a collection of just a few of the author's pit stops along his quest to find the perfect input peripheral. (The rest can be found in a landfill somewhere.) They are, clockwise from the top: The Devilfish, Saitek Command Pad, Ideazon Zboard, Essential Reality's P5 Glove, Belkin's Nostromo Speedpad N52, and Microsoft's Strategic Commander.

Keyboard alternatives have always fascinated me. I've owned two of the peripherals the author lists, and I recently ordered the Ergodex DX1.

Unfortunately, my unit arrived DOA and is in the process of being exchanged, but you can read reviews of this unique "have it your way" keyboard in the following places:

• Scott Hanselman, fellow input junkie
• GameSpot
• ExtremeTech
• IGN
• Tom's Hardware

None of these devices, including the Ergodex, are positioned as true "throw away your keyboard" alternatives. I'm not sure that's even possible; I can tell you from personal experience that the struggle to defeat a decade of existing keyboard muscle memory is a losing battle. It's really the same problem the Dvorak keyboard layout has always had. However, these keyboard alternative don't replace but complement your existing keyboard by presenting an optimized subset of what you already know. Even then, it's a tricky business. But I suspect that the extreme flexibility of the Ergodex will make it workable where all the others failed.

Paul Graham's essay Revenge of the Nerds is a nearly pornographic love letter to Lisp. If you can manage to read all the way to the end, there's an interesting footnote buried at the bottom:

Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.

He should have opened the essay with that evidence, because it strengthens his conclusion considerably:

In the OO world you hear a good deal about "patterns". When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

There's a Wiki entry called Are Design Patterns Missing Language Features? which expands and elaborates on Paul Graham's hypothesis. It even has a handy chart of the classic Gang of Four patterns and the corresponding language features that implement each one. It then degrades into a weird little Wiki-fight, but the saner comments look like this:

Has anyone ever considered that design patterns are the way that programming languages evolve? In the same way as communicative language, commonly used abbreviations ( or patterns ) may become standard. In english words like "won't" and "isn't" are abbreviations, but are more or less considered standard words today. In the same way, 'if-then-else' or 'do-while' could be considered design patterns that have now become standard features in many languages. Perhaps later languages will include many design patterns as standard features.

According to Graham, Lisp is so malleable that design patterns immediately become part of the base language; they are indistinguishable from the original core language constructs. Lisp doesn't need to evolve-- it just instantly becomes. One wonders, then, why Lisp hasn't become sentient and taken over the world by now. As Paul helpfully points out, it could be because we're so stupid:

I also disagree that it is not believable that the vast majority of programmers have been boneheads for 40 years. It seems to me entirely possible.

All kidding aside, I tend to agree on two points:

1. Excessive reliance on design patterns is indicative of failings in the language. As many commenters in the wiki point out, you'd see dozens of "design patterns" in assembly or C code; these are language features that we take for granted today. We've certainly seen evolution along those lines even in the modest lifetime of .NET so far. There are plenty of "syntactical sugar" constructs such as Using which encapsulate common patterns, and even more (such as Nullable and Generics) on the way.
2. Languages evolve-- slowly. It takes time to figure out the failings, shortcomings, and weaknesses of any language. Even Lisp. That's why the language family tree has roots going all the way back to 1954. New languages are created; old ones fall out of favor. And there's a lot of cross-pollination between family trees. Almost all modern languages have a very complete implementation of regular expressions, which is one of the central features of the PERL language.

If anything, Lisp is strong evidence that computer language evolution is quite slow; it's one of the oldest languages on the chart, and we're still adapting features from it.

I'm currently writing my first ASP.NET 2.0 website. VS.NET 2005 is worlds better than VS.NET 2003, but I was mildly surprised to find that Microsoft still hasn't added a recursive overload for Page.FindControl. So, courtesy of Oddur Magnusson, here it is:

private Control FindControlRecursive(Control root, string id)
{
if (root.ID == id)
{
return root;
}
foreach (Control c in root.Controls)
{
Control t = FindControlRecursive(c, id);
if (t != null)
{
return t;
}
}
return null;
}

This makes life much easier when you're trying to get to controls that are themselves contained within other containers, eg, a TextBox inside a DataView or DataList. Would it have killed Microsoft to add an overloaded, recursive version of this?

One interesting semi-undocumented feature of Page.FindControl: you can specify a full "path" to a control using colons as seperators, like so:

Page.FindControl("DataList1:_ctl0:TextBox3")

That's assuming all the containers in the hierarchy have explicit names. You can view source to determine what the dynamically generated 'null' IDs are.

I was recently reminded of this Dani Berry quote:

One of the great pioneers of computer and online gaming, Dani Berry died in 1998. He was born 'Dan Bunten,' but underwent what she always referred to as her "pronoun change" in the early 90s. Some of her aphorisms are still frequently quoted by game developers, including "No one ever said on their deathbed, 'Gee, I wish I had spent more time alone with my computer.'"

Strangely enough, Dani is just one of a number of transgendered game designers. But you may remember Dan Bunten as the mind behind 1983's M.U.L.E., revered by many as among the finest computer games ever published.

M.U.L.E. was designed for 4-player multiplayer, a rarity in games of that era:

M.U.L.E. is widely considered considered a groundbreaking classic in multiplayer computer gaming today, but it was widely underestimated at its time. Compared to popular arcade games of the eighties like Arkanoid, Frantic Freddie or The Last Ninja, M.U.L.E. had simple graphics and did not depend on joystick skills. Like chess, it required thinking skills and strategy to win, especially when playing against other human players. M.U.L.E. was somewhat complex to learn, at a time when electronic entertainment was new and simple.

Dani also went on to design Modem Wars, which was arguably the first commercially released network multiplayer game:

Basing the design around head-to-head modem play gave Modem Wars an unparalleled fun factor, but it is ultimately what caused the game to fail. Consumer modems in 1988 topped out at 1200 baud and were expensive peripherals. The networking technology employed by Modem Wars ensured that the low bandwidth wasn't a problem, but the relatively low installed base of modems was. The fact that you had to scare up a friend who also had a modem (and a mouse, as most PCs in those days were controlled via the keyboard) didn't help matters.

Programming has been described as "a private love letter between the developer and the hardware", but the explosive growth of the internet makes me wonder if any developer can truly be alone while using a computer today. It's hard to imagine using a computer – any computer – without being immersed in IM, blogs, message boards, email, skype, and a dozen other "always on" communication services.

Dani Bunten spent a significant part of her career writing computer games that encouraged social behavior. It was the topic of her final lecture at the 1997 GDC titled Imaginary Playmates in Real-time. It's unfortunate that she didn't live to see the internet fully expose the computer as the social tool she so clearly wanted it to be.

The always entertaining Dan linked to something I hadn't seen before-- an archived page of the Google server hardware circa 1999:

Here it is in all its, uh, glory. I don't know what's more impressive, the two dual Pentium II 300 servers, or the 90gb SCSI drive array made from Duplo blocks. Here's a summary of all the systems listed on that page:

• 2-proc Pentium II 300mhz, 512mb, five 9gb drives
• 2-proc Pentium II 300mhz, 512mb, four 9gb drives
• 4-proc PPC 604 333mhz, 512mb, eight 9gb drives
• 2-proc UltraSparc II 200mhz, 256mb, three 9gb drives, six 4gb drives
• Disk expansion, eight 9gb drives
• Disk expansion, ten 9gb drives

That's a total of:

• 1792 megabytes of memory
• 366 gigabytes of disk storage
• 2933 megahertz in 10 CPUs

Humble beginnings, indeed. I'm trying to remember the first time I used Google, and I think it had to be sometime in 2000. This motley bunch of hardware grew to own the internet in a little more than five years. That's incredible.