Getting smart about languages and libraries

The ever-quotable Sean McGrath penned another of his trademark aphorisms this week: “The library IS the language.” By “library” he means the great edifices of reusable code that are, in their modern form, delivered as the core Java and .Net class libraries. Mastering them is a challenge that can take years, McGrath wrote. Mastering programming languages, he suggested, is comparatively trivial.

In principle that’s true. In practice we are not quite there yet. Recently, for example, I’ve done a lot of programming in a pair of languages I know fairly well by now: Python and JavaScript. I’m using them in tandem because Python is great for general-purpose service delivery and Java­Script is the magic wand that waves AJAXian features into existence.

Combining the two languages is a useful strategy as clients and servers become more equal partners. But it’s a challenge to keep track of the subtleties of these languages, and an even bigger challenge to corral each into its own mental compartment.

This interwoven use is complicated by the fact that each language has its own virtual machine and its own libraries. That isn’t necessarily a given. For example, both of these languages have been implemented on the .Net Common Language Runtime. Andrew Clinick led Microsoft’s development of JScript .Net (back when that was a live project). Jim Hugunin leads Microsoft’s development of IronPython now. Clearly it’s possible for both languages to share common .Net -- or indeed Mono -- services.

Such an arrangement would make some things a lot easier, especially if the shared engine were ubiquitously deployed both server-side and client-side. At the end of the day I don’t care whose string, XML, database, communication, and graphics libraries are the sexiest. I want to learn one set of them that I can count on to be virtually everywhere and that I can rely on to do most of what I need.

My latest project, the InfoWorld explorer, uses Python and JavaScript along with a pair of common sublanguages: XPath and regular expressions. The first incarnation was heavily AJAXian. Then I ported it to a more conventional, server-based Web architecture. Porting isn’t quite the right metaphor, though, because both versions use the same four languages. It was more like a shift of emphasis from client to server.

To the extent that data manipulation was encapsulated in XPath queries and regular expressions, I was able to reuse it. Because Python and Java­Script wrap different APIs around these subsystems, though, I had to do some common things in different ways. Common services that are similar, but not the same, can be a blessing and a curse.

All programming languages present subtleties that I must constantly relearn. To minimize friction, I standardize on common idioms where possible. So for example, I added map and filter functions to JavaScript in order to emulate Python’s built-ins. It can be amusing to create these kinds of illusions, but there are better uses of brain cells. The fact that JavaScript’s library lives inside the browser, and Python’s lives outside, is merely a historical accident. If I could erase that distinction tomorrow, I would.

Today the ratio of languages and libraries is still roughly 1-to-1. But the numerator will grow faster than the denominator. We don’t need more of the same old ways to say the same old things, but we do need new ways to say new things.