Related link: http://www.oreillynet.com/pub/wlg/8317#thread
In the talkbacks on
“Our Long Java Nightmare”, href="http://weblogs.oreillynet.com/pub/au/1712">Rick Jelliffe and I have
had a small debate over the relative maintainability of Perl and Java. My
position is that no single language can enforce maintainability in the ways
that really matter most.
Certainly languages that lack certain features — meaningful error
messages, namespaces, encapsulation, abstraction, code-reuse — can do a lot
to discourage maintainability, and certain language features, when
abused, don’t help maintainability (operator overloading, macros, code
generation), but at some point your programmers have to take responsibility
for their own actions.
For example, if a team of Perl programmers refuse to use lexical variables,
making all of their subroutines work on global variables, is that the fault of
Perl for allowing global variables?
If a team of Java programmers re-invents leap-year checking code badly and
gets it wrong for century years, is that the fault of Java?
I don’t believe any programming language or compiler can ever analyze a
program on its own and verify that it truly meets the needs of the customer.
Nor do I believe that any tool can analyze the design of a package or class or
function or method and judge it appropriately maintainable. I reject the idea
that any automated tool can reject invalid, inappropriate, or irrelevant
symbol names. These abilities require axioms completely outside the set of
rules of a programming language — yet these are better criteria for
maintainability than the choice of programming language.
At some point, if you hire programmers who don’t know what they’re doing or
who do sloppy work, you’re going to get bad results. Blame it on the language
they used if you want — but expect few improvements from switching to another
language, platform, library, or toolset.
Your programmers really can’t read punctuation symbols? That’s… odd.