If you were impressed by GMail, prepare for a surprise. Some very talented individuals have been creating demos that push the graphical power of Javascript and DHTML into the realm of 3D games. Of particular note are redbug (online demo, IE recommended) and neja.

Bonus: The author of neja, P01, has a brilliant technique for drawing lines, and explains it in a very lucid tutorial.

It's funny, but I'm still impressed as I watch browser-based apps pick up functions we used to think were limited to desktop software. This isn't going to stop, though, and pretty soon the web will be a platform that blends the best of client-server software and the best of desktop software. When that happens, Microsoft is going to be pissed off.

I have a confession to make: I'm learning Ruby and Rails. And I dig it. It is, as it claims, a great leap forward in productivity compared to complex frameworks like J2EE, Struts, or even ASP.NET. I was always prepared to believe this— I would say the same for the PageKit framework for Perl, which I've been using for 4 years, and has been pretty stable for at least 5. But until recently, I wasn't believing the hype that Rails could be much better than PageKit.

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.]

I've cleaned up some data, and frassle is back online. Sorry it took longer than expected, but I think my gardening is enough to allow me to keep running the service. Welcome back!