Pagelib Retrospective

I have always been in love with magic: one of the first languages I taught myself once I was old enough to understand what I was doing was Perl, and it fit me like a skin-tight sci-fi spacesuit that we thought we were all going to wear in the future, back in the 1980's.  Steve Yegge's rant about Perl was entertaining, but I can't say as I identified with it much, since references weren't hard for me, nor do I have his problem of forgetting everything when I don't use the language for a while.  Maybe I don't drink enough.

Still, being in love with magic and DWIM doesn't mean that there aren't any hazards.  It's rather like fairy-tale magic, which can result in nasty, surprising, unexpected consequences if used without the utmost care.  This is a story about me exercising a complete and utter lack of care, utmost or otherwise.

Quickie: The Cross Platform Quandry

When an app runs on multiple platforms, it seems like there are two basic designs that they can choose to follow.  Either they try to integrate with each platform, or they try to appear the same on each platform.

It's not clear to me that either of these ways are correct.  Obviously, in the case where the differences between the platforms are hidden to the greatest degree possible, the app doesn't match the look and feel of platform-native applications.  This is the situation with old Mozilla builds that drew virtually all the UI themselves: the chosen GTK+ theme had no effect on Linux.  An app that looks "the same everywhere" can look like it belongs with at most one platform.

Meanwhile, since Mac users in particular are vocal about their dislike for using non-Mac-like apps, most modern cross-platform apps have switched to trying to integrate with each platform.  Firefox has a different theme and adjusts its button order on the various platforms; likewise, GIMP for Windows switches its button order to match the Windows custom of putting Cancel in the corner instead of OK.

As a habitual user of Firefox, Gimp, and Pidgin on both Linux and Windows, this second approach turns out to be less-than-ideal for people who frequently switch platforms.  In this case, the "same" app behaves differently on the different platforms, and I have to remember which platform I'm on so that I can hit the correct buttons.  Of course, this doesn't always happen, so frequently in Windows Gimp, I spend a couple of minutes selecting the perfect color, only to hit Cancel by mistake.  Another frequent source of mistakes is the way that Pidgin's tray icon toggles the buddy list with a double-click on Windows, but a single-click on Linux.  I'm frequently opening-then-closing Linux Pidgin with a double-click.

One last problem with writing a cross-platform app for Linux/BSD specifically is that these are not all-in-one platforms.  An app like Firefox that's written in GTK and follows the Gnome HIG is still going to fail to integrate with the KDE desktop on the points where their respective conventions differ.

Given these difficulties, it's not surprising that most apps aren't cross-platform.  The ones which are face the choice of whether they should integrate with platforms and appear different in the details to people who work on multiple platforms, or whether they should look the same everywhere and look alien or second-class on each platform.

Perfectly Flexible

Sometimes, a stakeholder doesn't like the idea of requiring a Programmer to make lengthy changes to a project's code if the requirements were to change at some future date. The proposed solution is always simple: The System just needs to be more flexible.

Having been the unsuspecting Programmer on a couple of these projects, I can report that the simple solution does not work.

On XML and data formats

In many discussions of XML, there seems to be a faction of programmers who are completely dead-set against XML.  They'll insist on JSON, or YAML, or any other cool technology that isn't supported in that 5-year-old version of whatever language your company is still running.  The usual complaints leveled against XML-based formats are verbosity and the complexity of the DOM.  (Sometimes, leading or trailing whitespace on element contents in pretty-printed XML will bite a project, but this never seems to come up in internet flamewars.)

The really young, or maybe just incurably naive, programmers will even chime in that anything that can be done in XML can be done, or even done better, in JSON.  I even thought this once, until I tried to write a generic XML-to-JSON converter, which showed me how wrong I was.

Functional vs. Object Oriented

By the time I reached my first programming job, I had learned a number of languages well enough to program in, and thought of myself as a pretty good programmer.  Then I met Brian, who frequently talked about Lisp, but had trouble articulating the advantages himself.  (This turns out to be a common problem.)  He introduced me to the SICP videos, and I found Slava Akhmechet's "The Nature of Lisp" essay on defmacro.org at about the same time.  Certain things about Perl and Javascript suddenly made sense, filling me with newfound wonder.

What I thought I knew about OOP as taught in college—Encapsulation, Polymorphism, and Inheritance—seemed like a sham.