Duct Tape And Turing Machines

My apartment can sometimes not be the best place for coding (dinosaurs with loud stereos live upstairs), so I’ll often borrow my girlfriend’s Powerbook and do some hacking at the library or a coffee shop on the weekends. I’m starting to work on the AI thingy (or at least fire some tracer bullets in that direction), and I needed to get the Ruby OpenGL bindings install on that machine so I can start get the graphics portion up and running.

Ruby actually has a wonderful package system called Gems (very similar to Perl’s CPAN), but unfortunately the OpenGL stuff hasn’t yet been packaged up that way. Having tried manually installing both the original bindings and the updated ones from svn on Rubyforge, I was pretty much at my wit’s end until I stumbled across the Oblivious Sponge’s entry on this very topic. About an hour after installing and updating MacPorts, I had ruby-opengl up and running. The only sticking point was ports complaining about an older version of autoconf, which I manually updated using the same.

I’ve got this problem where random little seeds for projects pop into my head at during the day. To keep from forgetting some of the good ones before I get around to ‘em, I wrote a little project idea aggregator in Ruby.

Usage: projects [options]
    -a, --add                        Add a new project.
    -l, --list                       List current projects
    -d, --delete NUM                 Delete project NUM
    -h, --help                       Show this message
    -s, --search-desc REGEX          Projects with descriptions matching REGEX
    -t, --search-dur REGEX           Projects with durations matching REGEX

Sample output:

1.      Begin learning elisp.
        Duration: Afternoon
                       ----------------------------------
2.      Install Gentoo on ichabod
        Duration: Weekend
                       ----------------------------------
3.      Crush all vi users.
        Duration: half an hour

Hope it’s useful to some of you cats out there.

Being a web developer by day, I’ve been working pretty much exclusively with high-level, interpreted languages. A great stinkin’ deal of that has been in Javascript, with a smattering of Java, Python and Ruby (ignoring non-Turing complete stuff like CSS and HTML).

On Friday at work, I was confronted with a relatively straightforward problem. I’d traced some odd problems with a particular project to a rounding error within a Dojo widget. It turned out to be a simple floating-point precision error: what should have been 10 was really 10.0000000002. In the context of this code, this value needed to be rounded up to the next highest integer if it wasn’t already an integer, so the imprecision meant that what should have been 10.0 became 11.0, causing much wailing and gnashing of teeth.

I needed to be able to round off my number to a certain number of significant digits. I looked at Javascript’s Number and Math class without much help- I could convert it to a fixed precision string and convert that back to a number, but that’s slow and kludgy. I asked some of my coworkers for help and after drawing a blank for a bit, we finally stumbled across Dojo’s supplemental math library, which, among other things, has a round function that optionally specifies significant digits. I wanted to see what was going on under the hood and make sure they weren’t just doing the same string-conversion technique, so I dug into the source and…

dojo.math.round = function (number, places) {
       if (!places) { var shift = 1; }
       else { var shift = Math.pow(10, places); }
       return Math.round(number * shift) / shift;  //  float
}

Just plain old, garden-variety bit shifting. What’s puzzling me is why neither I nor any of my very smart, very capable co-workers thought of this on our own. A collective brain fart and a desire not to reinvent the wheel aside, I think it’s a surprising negative result of working at such a high layer of abstraction all the time. I guarantee that if there’d been a good C programmer among us, they would have immediately proposed something like the above.

Before I’m bound and thrown into the weasel pit, I am not trying to say that high-level languages are a bad thing. They’re an Extremely Good Thing. I do not particularly want to manage my own memory while writing fluffy web interfaces. What I am saying is that it’s a good thing for a well-rounded programmer of any stripe to get back into the bits and blinking lights occasionally. Do some graphics coding, perhaps: muck about with matrix transformations and manage a video card’s buffers. Write a little C program to generate content for your website of Fourier transforms of pictures of your cat. Heck, use gcc -S to see what all those optimization flags really do.

Or, y’know, write a compiler. Food for thought.

What’s in my unordered tech book queue at the moment:

• The Cathedral And The Bazaar: Just started reading this one the other day. Eric S. Raymond’s manifesto of the open-source movement.
• In The Beginning… Was The Command Line: It’s Neal Stephenson, for Christ’s sake.
• The Pragmatic Programmer: Same guys who wrote the Pickaxe book. One of those books that Every Programmer Is Supposed To Read.
• Mastering Regular Expressions: One of the books that made O’Reilly’s reputation. I use regular expressions literally every day at work.
• OpenGL Programming Guide: The famous Red Book. Supposed the be the classical way to pick up OpenGL, though if anyone has found something better, I’d love hear it.

Any suggestions from the travelers of this series of tubes?

There’s a hell of a lot of brain-cycles out there being devoted to the idea of Getting Things Done. A quick survery of the common viewpoints:

• On one extreme, there are the office managers who worship the god Productivity, while managing to avoid any meaningful measure of work accomplished. Haven’t met your TPS quota this month? Bill Lumburgh gets to throw you into the company shark tank. Thank god I don’t work at a place like that.
• In the sane median are the folks looking for good tools, languages and frameworks to automate the kind of tedious tasks that kill one’s creativity. This is everything from the latest whiz-bang IDE that does your laundry while you refactor code to one-time text-munging scripts you write to avoid hours of reformatting or searching by hand. I can’t tell you how much pointless variable-renaming emacs’ replace-regexp command has saved me.
• Finally, some people almost fetishize the alpha-geek mindset of maximizing what you can do with your time. There are entire sites like 43 Folders and lifehacker devoted to this approach. They contain some useful things, but there’s fairly obvious feedback loop here above a certain threshold.

I think that most programmers- at least, those of us programming for fun as well as profit- perpetually have a project or two on the back burner. Mine? I’ve been kicking around something involving a little simulated physical environment with a bunch of autonmous robots running around and interacting. Basically, I think AI is neat and this seems like a fun way to explore the subject. Think about it. Herds of bots swarming around and dealing with environmental hazards and predators; colonies of robots changing to their surroundings to suit them and propagating; gladiator-style matches between war-bots with different brains governing their actions. The idea was to create an easily extensible world where you could build up these sorts of things from simple building blocks. Neat, huh?

How’s it coming along? Um. Look, a distraction!

There’s a plethora of reasons this AI-bots thing hasn’t gotten off the ground. For one, I was in school up until a few months ago and a great deal of my time was consumed by schoolwork. I rarely had the contiguous blocks of free time one needs to design and implement any project of decent size. And, of course, there was coding burnout: What, your mom died? Fuck you, I’m writing a compiler.

More importantly, as I’m realizing now, is that I was setting myself up to get stuck by how I approached the project. There was an essential problem of scope. For example, I wanted sweet 3D graphics with pretty models and effects. Great, but I’m not an artist. So I wasted a lot of the time I did have learning to use modeling tools like Blender and 3D libraries like OGRE. I’d inevitably get frustrated while trying to do too much for a one-man army in the time I had and just mentally bag the whole thing for months.

Is learning GLSL so I can programmatically create cool-looking lava really necessary for an AI playground program? No. The problem here is that I’m really very interested in all these sub-problems. Computer graphics is a really cool subject to learn about. So is simulated physics. So is artificial intelligence. Instead of trying to approach this project as a huge monolith to be scaled while learning all of these things, I need to create some smaller, toy projects to write while I learn the basics. Perhaps a Tetris clone while I teach myself OpenGL from the ground up. From there, a maybe simple arcade reflexes-shooter with a similarly simple physics engine. These learning projects need to be interesting enough to work on in their own right. They also need to be simple: if it’s something I can make measurable progress on during a Saturday afternoon, then I’ll keep working on it. With patience, I can use the mistakes, knowledge, and code gleaned from these learning projects to really get started on the Really Neat Idea I’ve been kicking around for so long.

We’ll see how this goes; I’ll certainly share anything interesting or shiny that I come up with.

Of course, before I get started on any of the above, I need to finish website renovations for Inksplot Studios. I spent some of last Sunday writing some CGI scripts so Liz can add content without me editing the source and realized with an hour or two that I really ought to be using a decent framework and not reinventing the wheel with some homebrew CMS. I’m actually looking into Ruby On Rails; let’s see if it lives up to the hype about saving developer cycles.

A neat little series of exercises I ran across a while ago: 21 code kata. It’s a set of problems that challenges you to approach each problem from many angles and explore the tools you use to solve it; the journey is more important than arriving at a solution. I’ve done a couple of these in the process of learning Ruby and they’re actually pretty fun.

Speaking of Ruby, the guy who wrote the kata is one of the authors of the Pickaxe Book. I recently picked up the dead-tree edition that covers Ruby 1.8 and was very impressed. It’s some of the best technical writing I’ve read- up there with The Little Schemer and Thinking In Java.