Separating code from its environment

Programming languages and environments are an abiding passion of mine. I'm always on the lookout for a better mousetrap, and lately I've been working with three relative newcomers: the PHP (PHP: Hypertext Preprocessor)-based plug-in architecture of the WordPress blogging engine; the Ruby on Rails framework; and Mark Logic's XQuery-based Content Interaction Server.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Each of these languages does very different things for different reasons, and their associated environments are likewise very different. But in each case, the language is tightly bound to its environment in ways that I often wish it wasn't.

Exhibit A: WordPress. The WordPress engine is written in PHP, so of course you write plug-ins in PHP, too. Except … why? The things that a WordPress plug-in has to do -- perform regular expression searches, read and write XML, create or traverse in-memory data structures, compose HTML forms -- are things that I already know how to do in Perl, Python, Java, JavaScript, and a bunch of other languages. Relearning all these skills in PHP feels like a massive waste of time and effort.

Exhibit B: Ruby on Rails. By way of background, Ruby is an open source, dynamic, object-oriented language with roots in Perl, Python, and -- like all modern dynamic languages -- Smalltalk. I've only scratched the surface of Ruby, but when I recently started a project that required a Web-based interface to a SQL database, I reached for Ruby on Rails, because I'd heard it's a great way to automate the tedious chores of Web development. If there is another object-relational mapper that is as powerful and yet as lightweight as Ruby on Rails, I haven't seen it. And yet when you open up the files it magically conjures, you're expected to write Ruby code inside them to do all the routine stuff. Granted, if I knew Ruby better I'd want to do that, but why can't I leverage what I already know in other languages?

Exhibit C: Mark Logic's Content Interaction Server. If you check out the experiments on my blog, you'll see how I'm using this XQuery engine to make XHTML content come alive. The environment, in this case, is an XML database married to an app server, and the language is XQuery. It's a wildly powerful combination. In XQuery, XML is a native data type. The central XQuery construct is FLWOR (pronounced "flower"), which expands to "For, Let, While, Order By, Return." FLWOR is analogous to SQL's SELECT statement, and it's a unique feature of the XQuery language.

But what about the basics? When my code threw an exception, I looked for a way to handle it.

Instead of the expected try/catch syntax, the official XQuery docs recommended an awkward use of if/then/else. I checked with Mark Logic, and it turns out they've implemented try/catch -- and maybe that'll even find its way into the XQuery standard. But should XQuery have to re-implement every standard control idiom? Should it have to re-create all the standard libraries?

Languages and environments have always been fellow travelers. At some point they'll begin to part ways. Domain-specific languages will continue to flourish; they're the future of programming. But they'll target fewer environments. The most obvious of these are the JVM and the .Net Common Language Runtime, along with their class frameworks. It'll take another turn of the evolutionary crank, but we'll get there.