21 January 2008 - 21:36Communication problems in dynamic languages

I was reading this post on manageability.org which is hi-liting some of the problems with large projects in dynamic languages. I am not familiar with these problems, never having to code in a dynamic language on a large-scale project, but I am currently working on a large scale project in Java with many distributed teams and in such an environment it is crucial that the code created by different teams is put together fast and reliably. Putting the code from various sources together fast is necessary for efficient collaboration between teams.

Probably the number one problem of distributed teams working on the same project is to make sure that the code doesn’t contain references to methods which don’t exist or which have changed. Statically-typed languages solve this problem by their own definition at compile time. Dynamically-typed languages probably have some solutions to this problem (I heard some people documenting the Ruby code that they write), but the biggest drawback of them is that this type of solutions are human-powered and not automated, an automated solution would be something similar to a compiler inspecting your code for invalid method calls. I would say that the solving code-conflicts that arise in distributed teams are more expensive in dynamic languages than in static languages, therefore when choosing a dynamic language you should probably stay away from coding in a distributed development environment (*).

One problem that I see with Ruby and all those elegant languages is that they are not very expressive to a large audience. They encourage brevity, but I find that they encourage it at the expense of readability and this narrows their audience (this is why I find it unlikely that Ruby will break out of a small elite). A developer working on an application needs to understand pretty fast what a particular method does rather than marvel at the “beauty” of that particular piece of code. I find that the information stored in Ruby code is harder to extract than the same information stored in Java code. It is “beautiful” (**), but also inefficient and it is more expensive to work with it.

I would say that the biggest challenge using dynamic languages revolves around collaboration and communication. Statically-typed languages put a smaller cost on communicating thru code, dynamic languages can achieve the same thru some external mechanism. While dynamic languages have more features, this freedom comes at the expense of collaboration. Evidence would seem to make this supposition true, most development in dynamic languages happens in small teams concentrated locally where the needs for communication are small.

* All the above being said I remember Martin Fowler talking about agile projects coded by distributed teams which did very well. He didn’t mention what language these teams are using, but given the fact that ThoughtWorks seems to favor Ruby I would assume that these distributed teams were using Ruby as well. It would be interesting to see the steps taken by them in order to be able to handle these communication problems.

** I personally find it brain-dead to talk about the “beauty” of code because this is not the purpose for which code is written. A statue should be beautiful because this is its purpose, to be enjoyed by who watches it, a piece of code’s purpose is to work as it is supposed to.

Later Edit: The communication and collaboration costs of dynamic languages will define the population of developers that use them and their usage within that population. I would not be too surprised is most of Ruby and Groovy usage will be restricted to small scripts which do not require a lot of collaboration while a small niche of very productive teams will be able to use them on a large scale.