I met Paul Kedrosky for the first time last week and we had a great conversation. We share a connection through ActiveState: Paul was a member of the board of directors and I was on the technical advisory board. (We've both since resigned those positions.) It occurred to us that, ironically, the original mission of ActiveState -- to create professional tools for open source programming languages -- may now be more relevant than ever.
It's ironic because ActiveState is now a division of Sophos, which acquired the company on the strength of a product that had been, for ActiveState, a sideline: the PureMessage email filtering system.
Meanwhile, dynamic languages are finally making headway in the enterprise. They've always been there, of course, but were usually confined to ghettos: data reduction, system administration, build automation. The recent rhetoric is more inclusive, as seen in this builder.com article cited by Patrick Logan:
Once considered simple toys by serious programmers, scripting languages are becoming first-class citizens in the world of corporate software development. [Builder.com: Grassroots computing languages hit the big time]Patrick invites us to "spot the misconceptions" in this article. Here's one:
"Scripting (languages are) just getting more popular and powerful simply because they're easy to use," said Tim Huckaby, CEO of consulting firm and Microsoft partner InterKnowlogy. "It's all about time to market and money, not about how elegant it is underneath."
It's true that PHP is the path of least resistance for certain kinds of Web development, and I won't quibble about whether or not that's elegant, but here's a very different example that clearly is. Last summer I mentioned Rich Kilmer's use of Ruby to control a large-scale simulation system. As Rich noted in his OSCON 2004 talk, a key aspect of the project was to develop a control language specific to this domain. It had to be expressive enough to encapsulate a lot of complexity, yet simple enough to be learned and used by the scientists who run the simulations. Although I can't verify this assertion, because I've only dabbled in Ruby, Rich says that it's a language particularly well suited to the creation of other domain-specific languages.
The notion of custom-built "little languages" goes all the way back to Lisp and Smalltalk, as ultimately everything related to dynamic languages does. It's one of those deeply elegant principles that can take decades to unfold.
Interactivity is another. When I met with Jim Hugunin recently, he told me that when he shows IronPython to folks inside Microsoft, they're most impressed by his ability to wield .NET libraries in an exploratory way from the command line. Who would have thought that the read-eval-print loop would seem like breakthrough technology in 2005?
I've struggled for years to map out the shape of this elephant we call dynamic languages, and I've yet to nail it down. So it's hard to define what kinds of tool support they require. IDEs (integrated development environments) are at least part of the answer. ActiveState's Komodo is the leading example of an IDE for dynamic languages, but I've yet to find anyone who thinks Komodo is giving Visual Studio or Eclipse a run for their money.
One programmer who would love to see that happen is Arlo Belshee, who I met at last summer's Vancouver Python Conference at which I gave a talk on the present and future value of Python. Arlo told me he uses C++ more than Python in his enterprise engagements. He does so reluctantly, and with a fascinating twist. He's reluctant because he values dynamic languages. The fascinating twist is that he's built C++ idioms to emulate some of Python's dynamism, while preserving the familiar and powerful Visual Studio environment.
I do think that professional tools can help dynamic languages consolidate the ground they've been gaining. And to that end, conventional capabilities -- such as suport for testing, debugging, and version control -- will be prerequisites. But dynamic languages really are different in important ways, and their tools should be as well. It's time for some fresh thinking on this topic, and for some new approaches.
Former URL: http://weblog.infoworld.com/udell/2005/05/23.html#a1236