Middleware Matters

The blogosphere occasionally shows unusual alignments. First, Jon Udell mentions in his blog my notion of "middleware dark matter", which I first wrote about nearly two years ago. I used the term "dark matter" to refer to middleware based on dynamic languages such as Python, Perl, PHP, Ruby, etc. that invisibly and yet very successfully runs many systems out there, especially the Web. In my universe, at least, everyone talks about "traditional" middleware such as J2EE, CORBA, EAI, and MOM, and there's nary a mention of these dynamic languages as middleware. Jon correctly points out that there's a parallel universe where the opposite is true, where everyone is instead normally focused on using dynamic languages for integration, and there's little to no attention paid to J2EE, CORBA, and friends. Maybe it's like the "Mirror Mirror" episode from the original Star Trek series -- perhaps somewhere out there, there's another Steve Vinoski, but only with a moustache and beard like Spock's, who views my traditional middleware as dark matter. I wonder which one of us is the evil one?

Then, the ever-insightful Sean McGrath talks about "baking the distributed computing abstractions you want into the heart of the programming languages programmers will use," with the goal being to realize "RESTian SOA." He mentions both Python and Ruby as examples of such programming languages. I couldn't agree more -- while we Java, C++, and C# snobs think we're the only ones out there who can actually program, we need to get over ourselves. Not only do our numbers pale in comparison to the masses out there who are successfully developing applications in such "dark matter languages," often our programming capabilities and productivity pale in comparison too.

After that, the also-ever-insightful mnot commented on Sean's comments, saying that REST is what we really need to bake in. I agree. Someone added a comment to mnot's post saying that with tools like the Eclipse IDEs that support incremental compilation and refactoring, you can get the power of dynamic languages in non-dynamic languages, but I don't agree, because the dynamic languages are just easier, quicker to develop and deploy, and most importantly, can be a lot more flexible at runtime.

This particular "blogosphere alignment" provides another indication of something I've been slowly realizing for awhile, the very something that drove me to write the "middleware dark matter" piece in the first place: that the world really is moving away from edit/compile/debug approaches using statically typed languages toward more of a dynamic language "edit and run" approach. Apparently mnot and likely many others are all independently also realizing the same. As a long-time Perl user and occasional Python hack, this is way cool. I love it when a plan comes together.

On a related note, I coincidentally learned the other day while building Perl 5.8.x on my Linux box that my name is still in the Perl distribution. It got there because I ported Perl to Apollo Domain/OS back in, I think, 1988. It's amazing that running the Perl configure script today is basically the same as it was way back then. (BTW, Domain/OS was, and still is, the best OS ever, though OS X, which I really like, is starting to come close to matching it.)