Writing a program is fun. Like writing an essay, the endeavor has two kinds of results: stuff that gets written down, and stuff that changes the way you think. Sometimes you’re aiming for the written product, to fulfill some external obligation. But other times, you’re aiming for enlightenment. The end product is irrelevant next to the understanding you developed in making it.

Most computer book authors wouldn’t claim to be writing about enlightenment. They’ll tell you that if you learn their language, framework, or methodology, you’ll win clients and impress coworkers. In this category there are a lot of useful introduction and reference books, along with a lot of buzzword-laden crap. But there’s another genre altogether, that doesn’t make these claims; it reflects the geek tradition of explaining interesting because they’re interesting. Looking back on experiences that really shaped my thinking as a hacker— a great algorithms course in college, a talk on “Tricks of the Perl Wizards” by Mark-Jason Dominus, Philip Greenspun’s book on web publishing— it’s clear that the most profound things I’ve learned spring from that tradition. Practical Ruby Projects is an exceptional book because it does, too.

Topher Cyll, author of the book, is a friend of mine. In college, Topher and I worked together on a community website for students as well as spending a lot of time in the same computer lab. In both roles, he was always full of clever and thoughtful ideas. Practical Ruby Projects is full of such ideas, expanded to project form and in an approachable buffet layout. The projects are indeed eclectic, from computer-generated music to gaming to genetic algorithms, but their common strand is the curiosity they all reward. If you’re one of the unusual folks who maintained this curiosity beyond school, or perhaps if you’re a professor who wants to assemble an intermediate projects course that will appeal to the most curious and passionate of students, this book is for you. With books like this and an open, curious mind, enlightenment might still be unreachable but at least you’re getting closer.

After all, both PageKit and Rails had the whole MVC thing going, which is the most important advantage. (MVC stands for Model-View-Controller, a pattern whose incarnation in web apps generally means that you have HTML-like files describing page layout, and Perl (or Ruby or Java or whatever) modules containing program code that provides data for that view.) The difference seemed to be mainly that Rails included an object-relational mapping tool.

I am not a fan of object-relational mapping tools. I consider them a special case (no pun intended… well not originally at least) of CASE tools. CASE stands for Computer Assisted Software Engineering, and is based around the idea that you can write programs to do part of the job of software engineering, and thereby make humans more productive.

CASE tools are bullshit. It's not that productive tools aren't helpful to hackers — they certainly are. But tools that write code necessarily degrade the design of your software in a very severe way. If you can't just write the code in an appropriately uncomplicated way, the solution isn't to have a fancy program produce the complicated code. The solution is to change the language you're using so you can express exactly what you need to express, concisely.

That is basically why I like dynamic languages. They remove a large set of restrictions on how you can redefine the meaning of utterances in the languages, so if you decide that looking up the key sasquatch in an associative array has a special meaning anywhere in your program, then damnit, you can have it work in a special way. Easily.

For those who argue that this enables sloppy code, I have two answers:

1. With great power comes great responsibility. Not everyone is capable of accepting the responsibility of programming in a wide-open language, and if you think you need the sort of guidance that the Java wizards at Sun can produce (aimed at a target market of all application programmers in the world), you should use Java. I'm not going to say great programmers don't need guidelines or rules, because they do— they are constantly both affecting them and affected by them— but their rules are crafted and evolved around the subtle needs of their partners and customers, not pronouncements from language priests.
2. The alternatives are still sloppy code or code generation. If your language won't let you say things elegantly, you can either buy/invent a new language that will, or you can write inelegant code.

Anyway… back on topic: Object-Relational Mappers. First a definition: an O-R Mapper is a gadget that bridges the divide between your relational database's idea of the important data types in your application, and your programming system's idea of the important data types in your application. Your DB will be relational (stuff goes in tables, powerful querying is built-in) and normally persistent (saved to disk), while your programming system's data will be object-oriented (data is abstracted within object interfaces, querying has to be custom-built) and normally transient (in memory only).

I have so far been doing my web applications in a pretty traditional way, database-wise: my Perl code contains strings of SQL. Then the Perl code processes the results of the SQL query and munges it into data structures (lists of hashes or something) that my templates can handle. This is OK; I've gotten pretty good at dashing out SQL. But:

• it's hard to reuse code for queries needed in multiple places
• Perl may not be the most visually clean language, but it has a style, and dropping a fat SQL string into the middle of it is like carpeting the floor of a rainforest
• each data structure is specifically designed to match the template where it is used, so changes in what details are displayed require changes to SQL and to SQL-result-processing code
• there isn't an obvious place to put common functions relating to a certain data type.

Well, that list is exactly what O-R Mappers are supposed to solve. Unfortunately, I thought none of them actually worked, mostly because code generation produces very brittle code and it's not OK for code that depends on my (rapidly evolving) database design to be brittle.

Thanks to Rails' ActiveRecord, I now realize O-R mappers aren't doomed. ActiveRecord creates the mapping at runtime, which is possible because it's running in a dynamic language, all of which means that I can add a column to some table and then just program with it. And because things are just expected to have the same name convention everywhere, there's no need for bloated configuration files that tell you totally obvious crap, eg. that the DB's people table's birthday column goes into the Person object's birthday field. And you can still write SQL if you must, though AR will do most of the joins you need.

This O-R stuff isn't as huge a productivity gain as moving from J2EE to anything dynamic and MVC. So the PageKit to Rails transition isn't as huge as most transitions to Rails. But the benefit, though marginal, is significant. Consider me impressed.

[Of course, if someone had done this in Perl it would have been faster! —ed.]

Perhaps it's too late to turn my own (upcoming) to-do list application into an experiment with Ruby on Rails, but my beloved Perl on PageKit still let me get a prototype of voo2do kicking in about a day. Definitely, the vast majority of my time on v2 has been spent tweaking CSS and Javascript to make the interface work.

But I'll save the rest of the hype until you can actually visit and try voo2do…

A friend emailed me asking what I thought about Ruby. I've only recently picked up a book on Ruby and am charmed by its comprehensive non-annoyingness. Here's what I wrote back to him. What do you think?

Will it take off? I doubt it. I think it has been steadily gaining over
the past few years, but there isn't anything so revolutionary about its
design or its culture that I think will let it dethrone Perl, PHP, and
Python (perhaps it's the lack of a letter P). At least not in the US. Ruby
originated in Japan, and may well be a leading scripting language there.
It's well-enough known, it has its O'Reilly books, but I don't see it
becoming THE HOT THING. It certainly has little traction in big software
companies.

There is a web application framework for Ruby called Rails [here's a promising recent article], which is rumored
to be a very lightweight, easy-to-start-with framework. Their website has a
10 minute video where someone installs it and builds a sample site. This
is highly laudable in a world where suits insist on web applications written
in J2EE, a framework so byzantine that it makes Software Architects
confident they cannot understand the details of programming, while making Programmers confident they cannot understand the scope of design.

Ruby is a sweet little programming language. It has some of the Perl ethos of inspiration by natural language, and it is simple. It's smaller and less well known than Perl, but as you can tell by the name, it's probably roughly in the same family of programming languages. Future project: take an afternoon and learn it. This guide seems like a fun, skimmable way to start. And if I don't learn it soon, it'll be hard to be the first kid on the block hacking it.

(I'm betting there are a lot of geeks on my block, which seems probabilistically true although I have no first-hand evidence. Another project: get to know my neighbors better?)