Related link: http://www.oreillynet.com/pub/wlg/8317#thread
In the talkbacks on
“Our Long Java Nightmare”,
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.
Indeed
If you hire programmers who don't know the language well or don't care to use it well, then it's your fault for hiring them.
Indeed
I tend to disbelieve anyone who says that language A is more or less "maintainable" than language B. Back to a Clintonism, "it's the programmer, stupid".
That being said, I've seen it all. The 50,000 line C program in one file because the team didn't understand header files or splitting a program up into multiple files. The Java program that blindly adheres to some poorly defined MVC framework's idea of separation which requires six classes for every simple form, and the rails program by a programmer who never took the time to understand DRY.
rope to hang yourself, gun to shoot yourself in the foot
There's a simple tradeoff - greater flexibility and manual control can mean greater possibility for errors (I'll gladly sacrifice the ability to manage my own memory for the ease of garbage collection). But, as you say, some programmers can write unmaintainable code in any environment - those who refuse to use the language's idioms, those who don't care about the aesthetics of the code (can someone read it without wrinkling his/her nose?), those who just don't consider maintainability although most actual code work is done after the initial write.
Indeed
No then it's your fault for not firing them. Anyone can lie in the hiring process. Too many companies hire new people rather than fire the old problems.