It seems as if some of the recent dynamic language advocacy, and perhaps rhetoric, has irked one of RedMonk’s favorite Fortune 500 enterprise architects. In a post entitled “Large Enterprises and why they don’t care about Ruby,” The Hartford’s James McGovern writes:
The funniest thing is occuring in the blogosphere. Lots of folks who write for industry magazines have jumped on Ruby, yet you will never find a single large enterprise that is even considering it. Ever wonder why?
Several bloggers have jumped on James Gosling indicating he didn’t get the memo. This post asks for the following:
All were asking is that you stop spreading misinformation about the current state of dynamic languages to the press, analysts, and your customers. This does not require you to champion or otherwise support these technologies – just stop lying about them.
Hmmm. I would ask the same thing of the dynamic community. Right now, you folks are living on hype instead of stating facts. Name one single enterprise application in the ERP, CRM, etc space that either is written in a dynamic language and/or is being considered ported? Name one system Fortune 200 enterprise that has a mission-critical system written in a dynamic language. Of course, you can’t.
Strong words from a very smart, very pragmatic guy. But in this case, I’m not on board. I do think Gosling is being carelessly dismissive in this case,[1] and his colleague Tim Bray would, I think, admit that dynamic languages have a place.
The disconnect in this case, I think, is context. When James poses a question to the dynamic language crowd, it’s in the context of enterprise applications and mission-critical systems. Given that backdrop, he has a point. Dynamic languages are not prevalent in that arena, it’s still very much the province of Java. No, I don’t think his assertion that you can’t name a dynamic language ERP or CRM application is accurate. In those categories, Intacct’s ERP On Demand application is written in PHP, as is SugarCRM’s CRM application. Further, I sat on a panel at the Zend Conference with the likes of ADP and NASA who were discussing the increasing role of PHP – often at the expense of Java – within their respective organizations. And after I wrote this this piece looking at Ruby within the enterprise Jon Udell was kind enough to let me know of a fairly large DARPA application built in Ruby. Even the oft overlooked Perl has its share of advocates; Amazon’s reputed to run big parts of their application on the language. But objection sustained, as it were. I wouldn’t argue the claim that Java’s still top dog when it comes to enterprise applications.
And while I could perhaps defend that lack of a presence by pointing out that enterprises move in glacial terms, so the fact that dynamic languages haven’t been more successful at displacing or supplanting Java is hardly surprising, I don’t think that’s necessary. Because to me, the real question is why is the conversation binary? That type of discussion is fine for language advocates on either side, but I’d expect enterprises to be far more pragmatic about leveraging the strengths of the individual languages and platforms. Is Java and the JVM, as Tim contends, far more capable of threading then, say, PHP? Sure. Is it also far less accessible? And less common, outside of enterprise settings? You bet.
Nothing is without cost, and threading, for example, typically comes at the cost of complexity. That cost is worth paying in some situations, but less so in others. This is something that enterprises and IT staffs, in my experience, have become far more aware of in the past few years. Tradeoffs are a fundamental part of the decision making process; it’s the old “Pick Two” quandry.
To that end, it’s long been a RedMonk belief that many enterprises (fueled, perhaps, by the industry analyst reports they were paying for) overbought in the past few years, paying for functionality and scalability they’d never need. One of my last projects as integrator, for example, was for a Fortune 500 firm in the insurance industry that was planning the rollout of a portal system to be delivered to a captive audience of a few thousand sales agents, who were mostly 9-5 people with low expectations. What did they buy? WebSphere, because that was “scalable” and the safe pick. And what did they end up designing? A couple of servlets. No J2EE, no EJB’s. Because they simply weren’t necessary, and frankly neither was WebSphere – Tomcat would have been just fine. As would PHP, in all likelihood, if the experience of enterprises like ADP is any indication. But this particular customer was conservative, as most enterprises tend to be, and a couple of years ago the embrace of Tomcat in this type of application would have been high risk; PHP or another dynamic language would have been more or less unthinkable. Today, however? I suspect it’d be a much different decision making process, not least because of time to market considerations.
Times have changed with respect to the risk factor. Over time, the strengths of the dynamic languages became too compelling to ignore, and enterprises have embraced them reluctantly but increasingly; embraced them to the extent that ‘enterprise’ companies such as IBM and Oracle saw fit to acknowledge – at some risk to their own investments in Java – this adoption and partner accordingly.
Does that mean that technologies such as WebSphere and Java and EJB’s aren’t important? Hardly. If I’m James and I’m designing a high volume transactional back end system for, say, The Hartford’s underwriting requirements – something truly mission critical – odds are pretty good I’d select Java for the task because it’s proven in that role. But there are far more non-mission critical applications than there are mission critical, and in my view Java’s an option, rather than The Option, for those types of deployments. As are the dynamic languages.
In any event, Ruby development is proceeding apace with or without significant enterprise adoption. It’d be great to see some enterprise participation in RubyConf here in Denver, but I don’t think that’ll make or break the show or language. After all, Java wasn’t designed for enterprise usage, but for cable set top boxes. Ultimately, the dynamic languages will succeed or fail on the combination of their own merits and the adoption they encourage. Either way, dynamic languages will continue to have a role within the enterprise, one way or another.
[1] Not just of dynamic languages, but C# as well – what do you think the folks at Duke Energy would think of those remarks, James?
