The age old debate between static and dynamic languages has only become more prominent with the advent and wider adoption of languages like Ruby, Groovy. Recently, Pathfinder was approached by a client for an unbiased opinion on what technology stack would be suitable for their next endeavour, which is a re-write of their 10 year old existing application. Looking at their existing system, which had no traces of unit tests and code coverage, I felt uncomfortable suggesting Ruby/Rails. Why? a dynamic language (like Ruby/Rails) requires more disciplined approach to software development and can become unmaintainable for large projects if not managed properly with right tools and processes. Yes, that is one big statement. While I may have found a few supporters in static-language tent, I held doubt about it myself. To say the least, it is not proven. So, I set out to find what others have to say about these assumptions:
Dynamic languages depend on automated tests more critically than static languages. Or do they? (as was discussed here)
Again, folks who have only recently transitioned from static side to dynamic (including me) may nod “yes”. True, dynamic languages don’t have compiler checks to warn us of potential problems. We have to depend on tests to validate our logic. But are static languages with compiler check equal to or better than dynamic languages with tests? Do I feel comfortable with static language code-base that does not have any or enough test coverage? After all these years of experience, a big NO. As I found here, compiler checks may eliminate the need of few tests (structural tests) but they do not establish the complete correctness of the program behavior. In fact, with some experience writing tests, we find that we don’t need compiler checks as much as we used to. I guess, it is fair to say that tests with proper code coverage are required irrespective of whether we use static or dynamic language.
For large projects, dynamic language require more discipline compared to static language. True or false?
Sure .NET and J2EE existed before the practice of testing became main-stream. But for every .NET or J2EE project delivered successfully without tests, there were at-least twice as many Python, PHP projects which powered successful production applications. Still, static languages do have few advantages: compiler checks and intelligent IDEs account for few caught bugs before hitting production. Reduced flexibility of language do keep things simple, language and compiler constraints help document software design, and intelligent IDEs help make code understandable. This tenets goes a long way in keeping code-base maintainable for a relatively longer period of time, all in the absence of automated tests. So yes, as long as we anticipate real-world factors like rotating teams (read: less responsible members), long-term code fatigue (read: bloated code, multi-nested conditionals and other anti-patterns) and especially team that can’t promise decent test suite, we are probably better off with static language (read: slow and painful death compared to dynamic language). For the rest, who have experienced the goodness of automated tests, these benefits of static languages may not outweigh the productivity and flexibility of dynamic languages.
So, why remain static?
If these observations are true, it begs a question. So, if we are committed to automated tests as first-class citizens in your project, why should we ever choose static over dynamic? I guess, the choice is not static vs. dynamic but better-code+productivity+flexibility+IDE-support vs. less of all those. Unit tests encourage shorter, better code, period. If run-time class modification (adding methods), method_missing, language syntaxes like blocks and closures are the reasons for productivity, static languages can attempt to achieve those with code-generation, byte-code modification techniques etc. Flexibility may be harder to achieve without modifying language itself but an attempt can be made to port some of the concepts to static languages. If these things can be achieved while retaining language support for intelligent IDEs etc, then static languages may have a chance.
Static languages may start dropping some of the language/compiler constraints to unleash the flexibility and power while retaining some controls (prevent monkey patching?). Testing practice may start to get incorporated as a required (compiler?) check before compilation finishes. It seems that at some point the boundary between static and dynamic may blur.
Game plan:
So, how would my recommendation for the client change? Probably not much. If they didn’t have a solid testing practices and continuous-integration in place, they should set a goal of achieving those with static language first. Once team is sold on those, they can start playing with dynamic language for non-mission-critical internal tasks and gain experience. As it can be said spiritually, the decision to adopt dynamism cannot be imposed, it is a state of mind that has to be arrived at by self reflection and training and a little bit mentoring 
What’s your take?
Langauge family X vs language family Y is an old debate. My take is “use the right tool for the job”. If your company has 90% java/dotnet people, it’s obvious that you’ll use java/dotnet. The same thing with PHP, Python, Ruby. Also, some languages are good at doing something, others aren’t that good. With PHP you can have a website up and running in a matter of hours, for example. But it’s not suited for desktop applications. It realy is a amatter of the right tool for the right job.
[...] and the best use of a developer’s time and effort. It’s been dormant for a while, but Sharad’s comments on static v. dynamic, which I largely agree with, and this short piece by David McLaughlin on defensive programming gave [...]