A Trifle Absurd

Open Source and Continuity

Every job is temporary, these days. Nobody expects (at least in the U.S.) to work for the same company for thirty years, or even for fifteen. Maybe, though, open source can provide the continuity that jobs no longer do — both for individuals and their employers.

Consider, for example, a developer who works on an open-source project as part of her job. When she leaves that job, she can take that experience (and code!) with her and keep contributing to the project. Her former employer wins, too, as they still get to use her subsequent contributions. The project itself is the biggest winner, though, as it gets the benefit of her expertise for longer than a single job-quantum.

So what are the consequences of this? First off, open-source developers will be known more for their projects than for their particular jobs. This is already true for open-source stars like Linus and Guido, but I suspect it’s also becoming true for developers in the trenches. When it comes to getting a job, for instance, it’s a lot easier to point to an open-source contribution portfolio than to talk about the NDAed project you worked on in your last job.

Second, employers can benefit from someone’s work before, during, and after their actual job tenure with the company. This could make it easier to start a company, given a pool of open-source components and available developers. It might also make individual jobs even more temporary, and tilt the balance in favor of consulting and contracting.

Finally, open-source projects will have, in the best case, a long-term scope that extends past the profit-focused myopic vision of (most) individual companies. It’s too early to tell if this will actually happen, though I see glimmerings of it in metaprojects like Gnome and Apache.

These are exciting times to be living in. The creative ferment of computerdom has never been frothier, and over the last decade, the open-source community has done most of the churning. I can’t wait to see what bubbles up next.

PostgreSQL, Perhaps?

PostgreSQL has entered the running as a potential Trifle component. I’ve been intrigued by it in the past, but couldn’t consider it since it wasn’t cross-platform; now, though, it runs natively on Windows, completing the platform trifecta I need.

What intrigues me in particular about Postgres is its table inheritance feature, which maps naturally to the idea of nested categories that I’m borrowing from Agenda’s data model. Especially useful is the default behavior of “query this table and all its child tables”. There could be a performance hit, since indexes don’t cover child tables, but right now performace takes a back seat to just getting something working.

I have to admit, though, that the thought of using Postgres as Trifle’s back end conjures thoughts of gnats and sledgehammers. At the very least, it seems like a big dependency to introduce this early in the process. Wouldn’t it be more natural to start with a simple hand-coded data store, iterate through a few prototypes, and then move up to a ‘real’ database once the design is more solid?

But on the other hand, isn’t prototype-based iterative development best supported by building atop powerful general-purpose components? Maybe I should start with something like Postgres and only replace it with a specialized items-and-categories database if necessary.

Client-Side Rendering Reborn

I just read John Wilger’s article about how GMail works, and he pointed out an aspect I hadn’t heard of before: most of the HTML rendering is done on the client using JavaScript.  I knew that GMail used XMLHttpRequest extensively to shuttle data back and forth, but I didn’t realize that Google had pushed it to this degree.

As Wilger points out, this approach has a lot of advantages for a Web application.  The one that jumps out at me is the clean model-view separation.  In particular, if you build the interface right, you could write a generic any-browser JavaScript library that renders to HTML, but later write a Mozilla-specific library that renders to XUL instead without changing the server-side (model) code.

This also leapfrogs the tar pit of Web templating systems: instead of a template that mixes markup and code, you build your own abstraction layer to separate the concerns. I agree with Wilger that ideally there would be an open-source JavaScript library to handle the basics; perhaps components like Kupu could be combined toward that end.

I Wanna Write a Language!

Okay, I admit it. For years, I’ve really wanted to design a programming language. I made half-baked attempts in high school and in college, but now that I actually know what I’m doing, I could really do it.

In fact, my early plans for Trifle included designing a language to write it in. After a little experimentation, I shelved that idea, thinking that if the goal was to get Trifle up and running, the shortest path did not include designing and implementing a language. Also, if I wanted to attract other developers to work on Trifle, I thought I’d better write it in an existing language.

Designing a language just seems like so much fun, though. Maybe I should just abandon all thoughts of practicality and build it. As I mentioned, I want to stoke the coals by following what gets me going, and language design is definitely something that gets me going.

Lately I’ve been dreaming of a dynamically-typed language with Haskell-ish syntax and algebraic data types (including type classes). It’d be mostly strict, to avoid the knots Haskell can get tied into, but with some kind of support for pipeline patterns (Icon-esque generators, perhaps?). But maybe I’m just dreaming this up as another way to get sidetracked from the in-the-trenches work of building Trifle.