the hubris of programmers

September 20, 2010

By far the most interesting part of the year for a competition robot programmer is a few weeks near the end of the build season called “Driver Training. If someone made a screenplay involving driver training, it would sound like this:

DRIVER and PROGRAMMER stand around control board, talking

PROGRAMMER:…and this is the main traction control enable/disable which you should use if you think there’s an issue with the accelerometer or the robot seems sluggish, but if the wheels are spinning out you want to hit this button instead to increase the proportional factor of the PID loop

DRIVER:uh huh

PROGRAMMER:Okay, now try driving it forward

DRIVER attempts to drive the ROBOT backward and forward at the same time. ROBOT beeps and tries to eat the PROGRAMMER’s shins.

The problem is really quite simple: the programmers have followed a rigid set of rules, laid out on a piece of paper called a “design specification”–supposedly, the best possible design that you could come up with. You program the mechanisms in the design spec then you put in the inputs that the design spec says to put in, and you see if you get the outputs it says you should get. If you do, the system is perfect, because the design spec is obviously the best possible design you could come up with and there’s no reason to do anything that’s not in the design spec. That’s not to say nothing changes during build, but it usually changes only if the original design doesn’t produce the correct outputs in when presented with particular inputs.(according to the design spec)

The problem is, that spec doesn’t necessarily line up with common sense. A power-on procedure might involve turning on components in a certain sequence to avoid a race condition, but an uninformed user will likely flick the first power switch they find. So are they wrong? No. Regular logic dictates that to turn something on you should look for the button labeled “on”. But the design spec logic might contract this completely, because it logically makes sense, given knowledge about the design, that certain system have to be online first. In both cases, the logical thought process is correct, but the outcome is different because of different base knowledge and circumstances.

Programmers and users have struggled with this problem ever since the days of Charles Babbage, who wrote:

On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Luckily, robotics completions are pretty unimportant in the grand scheme of things(shin-eatings are painful, but not debilitating). But what about other fields–like cryptography, which secures bank transactions, encodes trade secrets, and helps millions of people in totalitarian countries evade internet filtering?.

As it turns out, cryptography and hiding information is basically considered a solved problem. After all we’ve made ciphers that are completely impossible to crack, which should be the final accomplishment of a field dedicated to designing difficult to crack ciphers, right? On the design spec for a cipher, impossibility of cracking is pretty much the only item. So if you make one that can never be cracked, you’re done. Handshakes, math prizes, and all your researchers go retire in Bermuda or something.

One problem:Those uncrackable ciphers? They’re almost useless.

In fact, it turns out, if you try to use one under real-world conditions, you almost always break it and end up with an easily crackable XOR cipher. Even with the more robust public key cryptography systems used for encrypting email, far more research has gone into expanding the time required to crack an email from 500 years to 1000 years than has gone into designing a system that saves the user from having to mess around with public and private keys. The factor that limits the application of cryptography to email is not that PGP is a faulty algorithm, it’s that users don’t want to read a treatise on cryptography before they can email their coworkers.

Enhanced by ZemantaHow to you solve this problem? Well, there’s one answer that ‘s painfully simple:have the end user create the design spec.
“But how do I know how to write a design spec?” you might ask. Truth is, you probably don’t. A proper design spec is an immensely complex document that requires not only an intimite understanding of the technology, but also an intuitive sense of what will work and what won’t.
But at some point, the design spec started off as a general idea–something that anyone could come up with. All the complexity comes later, in a process fueled by argumentative engineers, greasy pizza, and lots of caffeine.
Which, incidentally, is something you can simulate on a computer.
More or less–it’s called a genetic algorithm, and it’s a way of designing an original solution given only a vague design spec–all automatically.
So what if you could design a computer program that could write a custom program based on exactly what you wanted it to do? It doesn’t seem that hard.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: