The Great Dynamic Hope: another hum-drum hype waiting to happen

Over the past few years, dynamic programming languages that are based around an interpreter have gathered quite a lot of attention. They’ve made an impression with language constructs that are more high-level than those of older languages and they’ve served as vehicles for some new ideas in software development (and also for some “new” ideas, i.e. old ideas that have been rebranded, like the DRY Principle). Dynamically typed languages are not a new idea at all of course (see Dylan, BASIC and FORTRAN), but the past few years has seen their resurgence in a generation of interpreted languages that have earned themselves the moniker “cool”. Among the languages of this new generation are Ruby, Groovy and Python.

This generation of languages has run the entire gamut of early-days-just-getting-started languages and is now on the verge of moving into the mainstream of software development. They’ve gone from being the new research platform to being the cool thing to play with for students and developers working pet projects and they’ve evolved further to the point where a number of custom development projects (ones that are relatively self-contained) have been done in them for commercial clients and other organizations. They’ve also gathered enough attention that they’ve been embraced by some mainstream platforms (the Java platform for instance has been extended with support for so-called scripting engines to allow bidirectional communication). In short, these languages have arrived at the point where they’ve gathered a following and that following is about to become a real pain in the ass.

In Dutch, we have a nice expression: rondrennen als een kip zonder kop (literally: running around like a headless chicken). This saying is used to describe people who dash about blindly without really knowing what they are doing. Every now and again it is extremely applicable to groups of developers in the ICT community; this usually happens when a new thing or idea reaches the stage that dynamic scripting languages have reached now. Because at that stage suddenly large groups of developers start believing that the new idea will be the “X-killer”, X being a mainstream development tool/paradigm/etc. of the day. Right now the growing idea among the headless chickens is that dynamic languages (particularly Ruby and its Ruby on Rails framework) are going to be Java killers. This idea seems to live in a belief in two things: that dynamic typing makes life easier because the compiler is less restrictive and the fact that Rails-like frameworks use convention over configuration in order to make the infrastructure of your application simpler.

Starting with the latter point I have to admit that convention over configuration has its benefits. One can see this in tools like Maven and in the varied applications of the JavaBeans Specification. It is true that using convention over configuration allows you to create a lingua franca among developers and speed up infrastructure definition on a project (as long as you don’t require anything out of the ordinary). However, does that make dynamic scripting languages Java killers? First of all, one must wonder whether convention over configuration is really solely the domain of scripting languages. The existence of Maven, IDEs and things like the Spring Framework and its namespace extensions lead me to believe the answer is “no”. Especially regarding a platform that has made assimilation of other people’s good ideas a way of life. But moreover an important question is: does convention over configuration really help all that much? After all, infrastructure is not where an application lives. Applications live in the design of their domain model, particularly the core domain (as explained by Eric Evans). Convention doesn’t help you there — otherwise it wouldn’t be custom development.

The idea that dynamic languages have an advantage because the compiler is less restrictive is, as far as I am concerned, patently ridiculous. The reason for this is quite simple. According to believers in dynamic typing, statically typed language compilers force you to do all sorts of tricks in order to follow the typing rules of the language whereas in a dynamic language you just send an object a message and if the object cannot answer, it will let you know. How nice. However, let’s step back a little and try to see the world through the eyes of Edsger Dijkstra: a computer program is a walk through the state space, taking you from a known precondition to a desired postcondition. A program is correct if, starting from a state that implies the precondition, it terminates in a state that implies the postcondition. Otherwise it is incorrect. So how does this apply to dynamic languages reporting inability to handle a message? Simple: if an object in your program cannot answer a message it receives, the program is incorrect. So, in order for the program to be correct, no object in the program had better receive a message that it cannot handle. In other words, to build a correct program, you had better write your code to deliver at least the assurances that a static compiler forces you to deliver. So where does that leave the freedom allotted you by dynamic typing? Again simple: it doesn’t help. Not one iota.

At this point some wise-ass will probably remark that I am simply against using dynamically typed scripting languages. This is incorrect. I am against running around like a chicken without a head, jumping blindly on the bandwagon of the latest cool hype and expecting the world when I can promise you this one, absolute truth: in the end, it won’t make a lick of difference. I learned a long time ago that quality of software, correctness of software and even productivity of developers come from your design, from your ability as a software engineer and not from the language you use. It’s a piss-poor developer who says that he is productive because he uses Ruby/Groovy/[fill in the blank]. It is also a piss-poor developer who says that he is productive because he uses Java/C#/[fill in the blank]. That is not where software engineering lives and we should all know better than to proclaim that it does.

By the way, it’s also a piss-poor developer who keeps reinventing the wheel. So if you do happen to believe in DRY and so on, then I suggest that running your scripting language on top of a JVM or CLI platform is your way to go. After all, why throw away all the existing abilities of those platforms if you can reuse, right? RIGHT?