Dynamic languages and choosing a technology for a project

An extended post responding to James Gosling’s Java is Under No Serious Threat From PHP, Ruby, or C# (that site, java.sys-con.com, is the worst I’ve enountered for quite a while with regard to ad content — annyoing pop-up DHTML ads not caught by Firefox’s pop-up blocker, a million flashing, blinking, and whirling ads. awful):

I believe that a majority of people in IT now consider dynamic languages like Perl, Ruby, Python, and PHP to be very much capable of sitting at the table with Java and .NET for a wide range of common technical problems.

The people who are still unconvinced are those that just don’t care or are too lazy to spend a small amount of time researching and validating the arguments, which brings us back nicely to James Gosling’s recent statements.

It’s an interesting read and has lots of links to other such things. I haven’t read the article he’s responding to yet. Interestingly, Gosling’s article has C# on the “no threat” column along with dynamic languages. The response post on lesscode.org lumps .NET and Java in the same technical pile (which is correct).

Most projects’ technology are selected by default. If the project is “modify an existing product” (and most are), then the language that project is that of the existing product. If the project involves tight integration with existing library or code, then the language for the new project must be one that can interact with the existing code (which usually means “the same as the exsiting code”). The argument I have third most frequently heard in favor of using a particular technology is “the team that will do it already knows this technology.” That can be pretty compelling argument if the team has only one language or technology in common and nobody can make the case that the advantages of another language outweigh the cost waiting for everyone to come up to speed on the new language. I’m using the words “language” and “technology” relatively interchangably here, since this choice comes up whether one is considering an entirely new language (e.g. Python instead of Java) or a new approach or framework (e.g. J2EE vs “just write a bunch of Java code”).

Sadly, rare is the project where one (and one’s team) really has the freedom to choose the very best technology for the job, measured soley on that technology’s ability to get the job done when used by experts. Fortunately (or not), the success and velocity of a project usually has more to do the “who” of a project than the “what they’re using to do it.” The affect of the expertise and passion of the people doing the work will, in all but the most extreme circumstances and particular when the choice is between any reasonably modern language and platform, dwarf any effect from the technology being used to do the work. Of course, if the people are using technology they enjoy using, it’s going to be easier for them to be passionate about doing the work…