TITLE: Language Choice and Inheriting a Codebase AUTHOR: Eugene Wallingford DATE: September 17, 2007 6:40 PM DESC: ----- BODY: In an XP mailing list thread "Are current "popular" programming languages enterprise grade?", someone raised a concern that some languages result in "buggier" code. William Pietri responded to a more general concern:
From the "enterprise" perspective, I think there's some legitimate worry about more flexible languages. If I have to inherit a great code base, I'm sure I'd be happy if it were in Ruby. But if I have to inherit a bad one, I'd rather it be in Java. Its surly and restrictive nature makes some sorts of archeology easier, partly because it prevents some of Ruby's beautiful magic. Now personally, I'd solve this problem by making sure all code bases are great ones. But if one already has a culture of tolerance for mediocrity and/or building one's house on sand, then restricting people to "safe" tool choices isn't crazed.
Maybe I haven't been paying attention, but this is the first time I recall seeing someone say in quite this way why "better" languages are risky for general use. A more powerful language enables beautiful magic that makes digging into a new codebase more difficult. The claim seems to be that it is easier to understand bad code written in a less powerful language. I'm not sure how I feel about this claim just yet. Is it really easier for a Scheme programming expert to understand bad Scheme code than bad Java code? Is difficulty more a function of the beautiful magic a language allows, or more a function of the programmer's skill. William speaks of his inheriting someone else's bad code, but maybe our concern should be a weak programmer inheriting someone else's bad code? This is the heart of many people's concerns with using powerful but non-mainstream languages in production systems, that there just aren't enough good programmers prepared to work in those languages. But William's answer has me thinking. It provoked another interesting message, Phlip's response that took the claim in a different direction:
That's just a way to say this ...static typing is a form of unit tests
...Java enforces static typing viciously
...I'd rather inherit a project with any unit tests.
This is a great way to think about manifest typing: Types are a degenerate form of unit test, and languages that enforce manifest types require programmers to write degenerate tests. In Phlip's idea, William is happy to receive a bad Java codebase because at least it has types as tests. But if the Ruby codebase you inherit comes with unit tests... Many agile developers extol the virtue of programming in more flexible -- and powerful -- languages, and most know that by writing tests they mitigate the loss of manifest typing and end up with a net win: code whose tests tell us much more than the manifest types would have anyway, and they benefited from using a more powerful language. I'd argue that for a large many programmers, using a more powerful language can be a lot more fun, too. Ultimately, the issue comes back to an old question: Can we prepare the majority of programmers to use Scheme, Ruby, Smalltalk, or Haskell effectively enough to make them suitable for the mainstream. I still think yes, and believe that the drifting of powerful concepts into popular languages such as Ruby is a sign of gradual gains. Whether this pans out in the long run, we'll have to see. -----