Are tribal monocultures the future of software development?

Fans of IronPython, IronRuby, and other dynamic languages on Microsoft’s .Net platform suffered a blow earlier this month with Jimmy Schementi’s announcement that he had left his job at Microsoft. Until recently, Schementi and his team had been the foremost champions of .Net dynamic languages, having been responsible not only for IronPython and IronRuby but also the Dynamic Language Runtime, a set of APIs that make it easier to port dynamic languages to .Net.

Schementi attributes the end of his tenure at Microsoft to “the typical big-company middle-management issues every software developer has.” Where once his team enjoyed broad leeway to implement IronRuby and IronPython as it saw fit, more recent management decisions had reduced staff and limited the team’s agility. According to Schementi, “roadblocks have cropped up that made my job not enjoyable anymore.”

Reading between the lines, however, some developers have wondered whether Microsoft’s treatment of Schementi and his team signals not just a lack of support for dynamic languages on .Net, but a general trend toward homogeneity on the platform. With IronPython and IronRuby now reduced to second-class citizens, is the Microsoft developer ecosystem creeping ever closer to becoming a strictly C# world?

Any color you want … True language independence on the .Net platform has always been elusive. For example, Visual Basic .Net, which Microsoft first released in 2002 alongside C# and ASP .Net, was significantly different from its predecessors and broke backward compatibility for many applications. Some developers have gone so far as to describe it as C# with a different syntax (albeit a familiar one).

Still, that’s somewhat to be expected. Implementing a truly language-independent virtual machine environment is difficult, and other attempts — such as Parrot, the virtual machine that runs Perl 6 — have enjoyed only limited success.

Java, the .Net platform’s most visible competitor, also supports several languages, including Groovy, Jython, and Scala. Support for these alternatives has been growing; for example, the high-traffic microblogging service Twitter has transitioned much of its code from Ruby to Scala.

But although work continues to make the JVM a more language-neutral runtime, from its inception it has been heavily biased toward Java. By contrast, the notion that the Microsoft’s Common Language Runtime (CLR) is language-independent has been a major selling point of .Net from the very beginning. For Microsoft to back away from that aspect of the platform now would be troubling, to say the least.

Languages as tools for lock-in Still, if Microsoft is leaning ever further away from the concept of a language-neutral development platform, it’s only a symptom of a larger trend in the IT industry. Platform vendors, eager to capture the loyalty of developers and end-users alike, have increasingly seen programming languages as differentiating assets, rather than mere tools.

Perhaps the most visible example is Apple. Developers who want to build applications for Apple’s Mac OS X and iOS platforms can choose between C, C++, and Apple’s pet language, Objective C — and only the latter can claim first-class status. Early on, Apple insisted it would support Java on Mac OS X as well, but the Java-Cocoa integration effort was aborted in 2005. As for iOS, Apple’s stance toward alternative development environments on its mobile platform — including Java and Adobe’s Flash — couldn’t be plainer: It’s a no-go.

By effectively restricting developers to a single programming language, Apple achieves two things. First, it guarantees that applications for its platforms will be written to a single, consistent set of APIs, minimizing bugs and other flaws that could lead to crashes.

Second, and perhaps more important, it creates a platform-centric developer monoculture that Apple can leverage to its own advantage. Because there is no Objective C support for the .Net runtime, software originally written for Mac OS X can’t easily be ported to Windows, for example. And apps written for the iPhone tend to be exclusive to that platform until their developers rewrite them in an entirely different language, such as Java — often at considerable expense.

Rise of the monocultures Apple isn’t alone in adopting this strategy. Microsoft developed C# with the .Net platform, and although an open source implementation is available in the form of Mono, C# development remains strongly associated with Windows and .Net. Sun Microsystems took a fairly laissez-faire approach to Java, but Oracle’s recent lawsuit against Google suggests a far more proprietary stance. And even Google itself is developing a new language, called Go.

Major IT vendors have always had a hand in developing programming languages. C, for example, was developed at Bell Labs in tandem with the Unix operating system. But while earlier languages were adopted by broad, diverse developer communities, the new breed seem to be more limited in scope. Their aims — and even their syntaxes — seem similar, yet they are different enough that they create pocket communities devoted to single vendors. Increasingly, tomorrow’s developers won’t be C programmers; they’ll be Apple programmers (using Objective C), or Google programmers (using Go), or Oracle programmers (using Java).

Microsoft doesn’t need to go this route. Windows remains the most popular IT platform on the planet; developers scarcely need more enticement to write software for it.

For now, Schementi says he will remain involved in IronRuby development, as the first non-Microsoft core contributor. What would be even better, however, would be if Microsoft would make a clear commitment to the languages itself, and to dynamic languages on the .Net runtime in general. As Steve Ballmer famously observed, Microsoft owes much of its success to independent developers. It would be a shame if Microsoft chose to limit developers’ choices now out of a misguided desire to follow in its competitors’ footsteps.

This article, “Are tribal monocultures the future of software development?” originally appeared at InfoWorld.com. Read more of Neil McAllister’s Fatal Exception blog and follow the latest news in programming at InfoWorld.com.