Quick, Nimble Languages
» 01 Oct 2009
or Why the Mainstream Will Never Steal Our Surplus
I am a programming languages bigot. There — I admit it. I write Rails code for startups and turn my nose up at those who slave away in Eclipse working with Java. I have always assumed that the promised land of modern, dynamic languages bears fruit for anyone who seeks it.
I never really considered the “why” of Java, as that would interfere with my unbridled hate. My Software Engineering class is centered around the Miltonian task of justifying Java’s ways to man. The professor constantly harps on the benefits for maintenance that the safety, strictness, and explicit verbosity provide to the development team, yet dynamic languages feel more productive and seem to entirely outstrip Java development in getting things done.
Many prominent figures support this observation. David Heinemeier Hansson refers to the productivity gap as the great surplus, while Steve Yegge comments on how much more productive dynamic languages are. Yegge’s talk addresses how the current complaints about tooling, performance, and maintainability in dynamic languages are mostly bunk. DHH believes that if the Mainstream started using Rails, we’d lose our competitive advantage over them. The maintenance issue in large systems is generally dodged by asserting that those who use dynamic languages don’t NEED millions of lines of code.
Would switching to nimble, dynamic languages give mainstream Java code shops the surplus or productivity boost that so many of us enjoy?
From the code I’ve seen, the average developer writes overly verbose dynamic code. This can be quite bad because of the extreme expressiveness of these languages, where every extra line makes the program more likely to hit upon the issues that legitimately make dynamic code unsafe. The added strictness and constant line noise of Java more readily highlights potential sources of failure. The other issue is that many programmers depend on rich IDE tooling and debuggers to understand even the standard operation of their code.
Java makes doing dangerous (or interesting) things painful. It protects programmers from themselves. If nothing else, it allows bad code to be isolated and encapsulated away from the rest of the system, protecting the other workers. This comes at the cost of velocity.
I believe that this speed penalty is only a major factor for better programmers, because Java only contributes to the slowdown caused by inefficient tools. The other form of slowdown is the kind caused by not fully understand the problem or solution. The latter is by far the more significant source of pain for the developer, and in comparison the specific technology stack is largely irrelevant.
The development team needs to consist of good programmers to make the best use of dynamic languages. Larger or more mixed teams are probably better off sticking with safer Java. This is also advantageous because nearly everyone knows Java, so finding staff is much easier.
This helps explain why dynamic languages are such a great fit for startups. For startups, time is the critical factor, teams are small and carefully selected, earning potential is high, and the applications tend to be exciting and consumer oriented. These factors conspire to attract developers who can make the most of the latest and greatest technologies.
Dynamic languages might be our “secret” advantage, but there is little danger that the mainstream will be able to use them to overtake us.