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
<A HREF="http://tech.groups.yahoo.com/group/extremeprogramming/message/135236">
   responded</A>
to a more general concern:

<BLOCKQUOTE><EM>
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.
</EM></BLOCKQUOTE>

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 <EM>beautiful magic</EM> that makes digging into a new
codebase more difficult.  The claim seems to be that <STRONG>it
is easier to understand bad code written in a less powerful
language</STRONG>.

I'm not sure how I feel about this claim just yet.  Is it
<EM>really</EM> 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,
<A HREF="http://tech.groups.yahoo.com/group/extremeprogramming/message/135237">
   Phlip's response</A>
that took the claim in a different direction:

<BLOCKQUOTE><EM>
That's just a way to say this

...static typing is a form of unit tests <BR/>
...Java enforces static typing viciously <BR/>
...I'd rather inherit a project with any unit tests.
</EM></BLOCKQUOTE>

This is a great way to think about
<A HREF="http://c2.com/cgi/wiki?ManifestTyping">
   manifest typing</A>:
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.
-----