The more interesting situation to me isn't novice vs expert. It's the same one that bothers the person who wrote the top of the original article: pro vs pro.
A former boss of mine said that programmers are like hairdressers: whenever she changes to a new stylist, the first thing they say is, "Oh my god, what did that last person do?" That's certainly what I say when I have to examine an existing codebase. More expressive languages allow for more stylistic variation, and one's style is deeply rooted in one's values and experiences. One person's brilliance is another person's WTF.
I think the right solution to this involves developing a house style, which for my team involves zero code ownership and a lot of collaboration. Eventually the team converges on a set of idioms that work for everybody, so style issues are minimal.
But that's not always the working reality. If I have to inherit a bunch of code from a random developer, I'd much rather it be in Java than, say, Ruby. Java definitely limits brilliance, but it also limits too-clever-by-half idiocy. The downside risk with a Java code base is smaller.
I agree about developing a house style. It is not my Java programming experience that the Java language limits the too-clever-by-half idiocy.
If you want to say that the kinds of companies that hire Java developers don’t hire clever idiots, that’s a different discussion. But I’ve seen so many convoluted architectures built out of Java that it feels to me like too-clever-by-half is a constant across all languages, and the very best thing for me is discouraging cleverness, with second best being let people do their clever things in a language that helps them, rather than making them write even more inscrutable clever code just to get away with being clever in Java.
This is my point above, and perhaps it doesn’t match your experience, namely that some clever things will be done, and Java will not prevent them from being done, but merely prevent them from being done simply and cleanly. So why not have this other “pro” do what she is going to do, but do it simply and cleanly thanks to a powerful language, rather than resorting to XML and other shenanigans?
But honestly, I fear we are now having a weird discussion where our working assumption is inheriting code from people we don’t respect. It’s far, far easier to simply work with reasonable, sane people, than to make all your choices predicated on the idea that your colleagues are psychopaths.
Hmmm. I think I still maintain my preference for bad Java over bad Ruby. The AbstractSingletonProxyFactoryBeanImpl insanity is painful, but I feel like most Java problems can be solved with pruning shears. Ruby's metaprogramming, on the other hand, puts COMEFROM-style functionality into the hands of noobs, and its duck typing makes it very hard to answer basic questions about what the hell X is. In Java, I can always tug on something and figure out what it's connected to. But perhaps that's just a matter of my personal debugging style.
Broadly, though, I think you're right: it's irrelevant to the real problem. Java is the new COBOL because most large software development organizations are functionally insane. They can't tell good code from bad, and rig things in a way that bad code is almost guaranteed anyhow. So naturally they'd prefer a language in which bad code is merely painful, not fatal. Because that lets them cover up their failings for much longer periods.
My personal solution is yours: stop working with other people's shitty code. I'd like to see the problem solved across the industry, but focusing on language choice doesn't seem like it's getting us anywhere.
A former boss of mine said that programmers are like hairdressers: whenever she changes to a new stylist, the first thing they say is, "Oh my god, what did that last person do?" That's certainly what I say when I have to examine an existing codebase. More expressive languages allow for more stylistic variation, and one's style is deeply rooted in one's values and experiences. One person's brilliance is another person's WTF.
I think the right solution to this involves developing a house style, which for my team involves zero code ownership and a lot of collaboration. Eventually the team converges on a set of idioms that work for everybody, so style issues are minimal.
But that's not always the working reality. If I have to inherit a bunch of code from a random developer, I'd much rather it be in Java than, say, Ruby. Java definitely limits brilliance, but it also limits too-clever-by-half idiocy. The downside risk with a Java code base is smaller.