tecosystems

James McGovern on Dynamic Languages

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

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 we’re 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?

9 comments

  1. I don’t think I understand this “Proven in the Enterprise” phrase that keeps showing up.

    It sort of implies that the programming language instead of the people programming in it are responsible for the success or failure of the software project.

    It’s not like an interpreter’s going to explode or anything.

  2. What do you mean, “admit”? I’m not “admitting” that dynamic languages are hot stuff and a big part of the future, I’m shouting it from the rooftops to anyone who’ll listen and some others who don’t want to.

    You’re right, McGovern’s wrong. -Tim

  3. I left a couple of comments on James’ blog:

    http://www.haloscan.com/comments/duckdown/114225134760338074/#44998

    I’d love to get some hard argument out of him on this.

  4. I haven’t had a chance to watch the full interview with James Gosling, and the text quotes are somewhat filtered, so I’d rather not comment on them.

    This blog entry of his from a few months ago is interesting though:
    http://blogs.sun.com/roller/page/jag?entry=radlab_scripting_and_scale

    quote: “Over the years I’ve used and created a wide variety of scripting languages, and in general, I’m a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.”

    One thing that does spring to mind in these kinds of discussions though is that the “question” seems to get a little lost. Are we focusing on new trends? How much emphasis do we give: time to write a “hello world” level program, a pretty functional demo, getting a system into production or “TCO”? Do we factor in the effect tools have? Are efficiency, security, reliability or scalability special factors to consider or just part of TCO analysis? Are we interested in solutions where it’s harder for developers/managers to go wrong, or do we assume “best practicies”? Some of these are referenced in James’s blog entry but the above are my thoughts.

    PS I do a lot of paid work in PHP and Perl but recently I had a small project using JSPs. Developed on one platform (using NetBeans) but deployed on a completely different platform in WebSphere. *sigh* It’s amazing how clunky that program is – the cross-platform issues were non-existant but WebSphere is so clunky in setup and use that it added a noticible bit to the overall project time. Just because the customer wanted to go via “support” to get software installed.

  5. Now that this has blown over a little… I have to say, I think the quality of discussion has gone up pretty significantly this time around. The trolling in the lesscode.org comment thread was barely visible and McGovern’s comments (http://www.haloscan.com/comments/duckdown/114225134760338074) are full of great stuff, like this comment by Michael Fasosin:

    “… the end game for agile languages is to make it possible for end users to orchestrate services and compose them at some point in the future.”

    McGovern came back with some questions that clarify his original post a bit and I think his position makes a little more sense now. Seems his post was more of an inquiry and less of a statement. I’d say he’s probably getting what he was after in your response plus the comments over there (which seem distinctly high quality, btw).

    OT: Steve, what are the chances of getting some basic markup capabilities in comments over here? a, em, and blockquote is all I really need.

  6. I want to jump out a window. Folks still keep ignoring the point. I have never said that dynamic languages wouldn’t be used in the enterprise or don’t have a place. I can find Perl at work for an example, but ask yourself want is it used for. Sooner or later, Ruby will show up on our doorstep but I can tell you that it won’t be used for anything worth hyping in magazines and certainly won’t be used for any mission-critical enterprise applications.

    Of course, you won’t find speakers from the Fortune enterprises to speak at conferences on this topic because no one would consider embarassing themselves to talk about there usage of dynamic languages. Sure, we have some on web applications that are customer-facing. I guess if the clever folks in the blogosphere want to overload the term of what an enterprise application is then they could rationalize anything.

    I still defy anyone in the blogosphere to name a single ERP/CRM or other mission-critical application either currently being built and/or can be purchased that is or will be installed into production this year for any Fortune 200 enterprise. You simply can’t!

  7. Oops, Stephen yes you named a CRM application written in a dynamic language, but is Intacts or Sugar really an enterprise application? Can you name a Fortune 200 that has either installed in production?

  8. James- ADP…

    payroll processing is kind of mission critical. last time i didnt get paid i know it hurt me bad.

    An ADP official agreed.

    “So far, PHP has certainly scaled and I know from an architectural standpoint, we’ll have the capability of getting around any bumps in the road that we see,” said Mark Rankin, director of application architecture and infrastructure at PHP user ADP.

    http://www.macworld.com/news/2005/10/20/php/index.php

  9. Danno: it’s more than enterprises are conservative. if you’re designing a multi-million dollar mission critical system, and you have two options for language/platform: one which lots of people have used successfully, and one which is largely unproven, most will go with the former.

    Tim: appreciate the clarification; i was trying to be circumspect regarding your committment to dynamic languages, and in the process undersold it. apologies.

    Ryan: just read them, will have a follow up post. .
    James M: will have a follow up to answer your questions.

    James G: good citing

Leave a Reply to stephen o'grady Cancel reply

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