I’ve been playing around with Ruby and reading up on Ruby on Rails lately (yes, I have joined the bandwagon) and it interests me how Ruby’s popularity (at least in some of the circles I partake in) seems to have resparked the debate of dynamic languages being better than static languages. Static language advocates will suggest that they have frequently less bugs in the class of wrongly assigned data types because the compiler provides them with one level of feedback. Of course this does not mean that static languages (such as Java) exclude this class of bug completely (which is why we have our most favourite ClassCastException). This level of feedback comes at the cost of its programmers having to endure a much higher level of verbosity.

Although I code everyday in a static language for my current project, I’ve written some development tools and worked on a project all based in Perl (gasp!) and enjoyed the freedom its dynamic typing provided. My suggestion for people looking at using dynamic languages for a production system is that the higher level of power that the language provides also requires a corresponding higher level of discipline from developers who use it.

My response to people who strongly advocate for static languages solely based on its type safety is that this issue goes away if one actually writes tests for it (and even better, test drives the entire system). It amuses me to no end to see how many projects (both production and even many open source projects) fail to even compile when you take a copy from their source control system. Although seeing a project fail to compile gives me one level of feedback (yes, you won’t even be able to run it), I think it’s bad that when you do see a project compile successfully, it gives people a false sense that the system must be working correctly. Yes this requires high discipline from developers to write useful unit tests but is this any different from what you are currently doing or what you expect your team to be doing? I really hope not.