tecosystems

PHP, Python & Ruby: Lining Up Behind a Language

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Remember the good old days, when the language landscape was a simple two party battle, defined by Microsoft and .NET on the one hand, with Java and virtually every other large ISV on the other? Yeah, me neither.

While I’m as open to a conversational shortcut as anyone – I’m an analyst, after all – I never did quite understand the school of thought that argued that those two were the only two communities that mattered from an application development perspective. And yet that was largely the case when I got into the analyst business, at least in the context of the conventional wisdom. The underlying subtext to many an analysis was that Java and .NET were not just the past and present, but the future. In large part, however, this was a consequence of the marketing budget behind those respective platforms – and the corresponding lack of budget behind some of their open source competitors.

As is so often the case these days, however, that volume of marketing dollars no more sealed the dynamic languages’ fates than they ensured the success of the ISVs that spent them. Oh sure, the current market position of both Java and .NET is at least partially attributable to the vast sums of money invested in efforts to establish the platforms and convince conservative enterprise buyers that they represented safe investments. But there are also, clearly, strong technology reasons developers have flocked to those platforms.

It’s been just as clear, however, that there are equally strong reasons to utilize dynamic languages alongside of – and occasionally in lieu of – their static counterparts. [1] And so we’ve been talking dynamic languages fairly heavily the last couple of years, both publically and privately. The public stuff – i.e. blogs, conferences and the like – you know about. The private stuff – actively championing dynamic languages within both customers and non-customers – you don’t, but the message wouldn’t surprise you. At no point have we taken the position that dynamic languages are the only approach, but we have strongly recommended that they be an approach – and a first class one, at that.

That different languages have different strengths (and weaknesses) seems self-evident to me, just as it does to DHH. Here, in fact, is what I wrote on the subject back in 2004:

I find much of the commentary…around the languages and platforms to be based on a flawed – in my view – assumption that a single platform can be all things to all developers. If there is such a language/runtime combination, someone please let me know – it’ll make my job as an analyst a lot easier.

In this context, results like this or these don’t really surprise me. They interest me from an academic perspective, but don’t tell much that I didn’t already know; I expect languages closer to the metal to perform faster. Just how much faster is an interesting question for some applications, not particularly relevant for others.

For many, however, findings such as these are fighting words. I shouldn’t, perhaps, be surprised by that either, because it seems to be human nature to pick sides and defend them at all costs. Technology has no monopoly on this behavior, of course. I was amused to read the following discussion of the history of maize in the outstanding 1491 (more on that later) and think immediately of exchanges I see on a daily basis:

By now the reader will not be surprised to learn that an apparently arcane debate about the distant past could become vehemently personal. Relations between the two men became cold, then bitter, then explosive. Botanists chose sides and wrote caustic letters about each other.

Substitute a string or two in the above, and we could just as easily be describing the flame war that erupted following Spolsky’s “Language Wars” post. While I tend to align more closely with critics of that piece, neither do I think Spolsky’s arguments are without merit. Nor, I think, would dynamic language advocates such DHH himself – or Ted. And yet we’ll continue to see volumes of contentious and occasionally vitriolic commentary as a result. Sigh. Having said my piece on this issue too many times previously before to count, I think I’ll pass with but one comment: has anyone DTrace’d any of the dynamic language runtimes yet? I’d be interested in that.

The reason I can afford to pass, however, is potentially an interesting subject – not to mention the ultimate point of this entry. That reason is this: I don’t feel any need whatsoever to defend dynamic languages in general or Ruby more specifically because they’ve made it. In truth, they made it a long time ago, but conventional wisdom is not all that…dynamic. Just as I argued at OSCON that open source had crossed the chasm, reached the tipping point, pick your metaphor of choice, so too have dynamic languages (many of which are, as Michael notes, open source themselves). As proof of this I offer up the following:

  • IBM & PHP: 1 & 2
  • Microsoft & (Iron)Python: 1 & 2
  • Sun & (J)Ruby / Strongtalk: 1 & 2 & 3

Just in case you’re link averse, let’s review: three of the more significant ISVs on the planet each annoint in turn languages that are not only competitive with their traditional fare – Java, ASP/VB.Net, and Java respectively – but dynamic in nature. Any more questions?

Well, actually, there should be one: does supporting implementations of dynamic languages on top of VMs, e.g. IronPython rather than Python or JRuby over Ruby, actually qualify as supporting the parent languages? It’s no secret that I’ve been critical of this approach before – giving Sun specifically a hard time for it in an entry here, and going into more detail on my concerns and Tim Bray’s response here. Despite my misgivings technically, however, I don’t think this type of action can be considered anything but support for the original languages (with apologies to David Berlind). Clearly Microsoft and Sun view opportunities within the dynamic language space; while we might break on the size of the opportunity for hyrbid VM/dynamic opportunities, their actions will ultimately benefit the upstream communities, IMO and apparently Avi’s and Senor Williams‘.

If we can agree that it is support, then, what does it all mean? Jeff connects some dots for you here, but I’ll put it more bluntly: vendors are waking up to the power not just of the languages but the communities that support and defend them. The very reaction that I lament above – see the comments to the DHH post linked above – is simultaneously Exhibit A of the passion that some of the language advocates bring to their platform of choice. What we’re seeing is IBM, Microsoft and Sun seek opportunities to engage with communities outside their traditional base – to make new friends, as it were. It’s almost as if they were taking our advice 😉

While you will see none of these vendors foolishly anger competitive language communities, there is unquestionably a new set of ecosystems and alliances forming. IBM going for the far and away volume platform leader in PHP, Microsoft is aligning itself with the language of choice for many talented developers like Adrian (not to mention Google, who employs this fine gentleman), and meanwhile Sun is staking out some territory in perhaps the “coolest” and most visibly growing language in Ruby. I could go on. IBM’s not terribly flashy, neither’s PHP. Sun’s hardware at least is polished and quite stylish; so too are many of today’s Ruby apps (check out Typo). Microsoft’s…well, I can’t think of one for that, but maybe one of you can help me out there. At any rate, if you think about it, the choices make sense – not that I think we’re done.

The most positive consequence of all of this, as far as I’m concerned, will be a greater ability to mix and match technologies to solve particular problems. With any luck, as commercial vendors see increased financial opportunities in dynamic languages, we’ll begin to see more neatly integrated multi-language solutions, less Frankensteinian bolted together monstrosities. I’d also expect to see better IDE support for the dynamic languages (I like RDT/RadRails, but would love to have autocomplete), better application management support for dynamic applications, and an increased associated M&A volume. All of which, as I see it, is good news. Should be a lot of fun to watch either way.

Disclaimer: IBM & Sun are clients; we’ve done work with Microsoft previously.

[1] Just as a note, I’m using the static/dynamic distinction not because I think that’s the salient differentiator, but rather because it’s the simplest means of describing the two. Scripting isn’t an inclusive enough description, IMO.

6 comments

  1. It is unfair for you to mention RDT and not to mention pydev! http://pydev.sourceforge.net/ In my opinion it’s miles ahead.

    — From a Python biggot 🙂

  2. I’ve used pydev and found it pretty darn cool.

  3. An excellent dynamic language that runs on the Java Virtual Machine is Groovy. In my mind, it is what Java could have been and should be. Have a look at http://groovy.codehaus.org/ for details.

    Fred

  4. Seo & christopher: apologies for the PyDev omission. i listed RDT/RR simply because that’s what i’m familiar with. i’ll give PyDev a shot as well, although i’m not a Python guy, as soon as i upgrade to Eclipse 3.2.

    Frederic: yup, the Groovy fans are out there. it’s not mentioned here simply because i don’t run into quite enough Groovy folks. whatever works for you, though.

  5. No need to appologize to me. I was just surprised by how useful pydev is considering it is a secondary language in Eclipse.

    Liked the post. I don’t expect you to cover every corner in a blog post. That’s what bloggin’ is about. Shootin’ from the hip. That’s what makes it fun. As opposed to the C++ article I’m working on. That’s drudgery.

    I think RedMonk is great. Analysts that represent the geeks. Keep up the good work guys.

  6. thanks for that compliment, christopher. that’s what we try to be 🙂

Leave a Reply to Seo Sanghyeon Cancel reply

Your email address will not be published. Required fields are marked *