My experience is that most of the highly skilled engineers that I have worked with don't really care about the language that much.
My experience is that most good engineers are conscientious. They don't want their code to be tomorrow's legacy disaster. This makes them care a lot about languages, if we're talking order-of-magnitude differences like Scala vs. Java. If we're talking about Clojure vs. Python, then maybe not.
Friends don't let friends maintain Java code.
No, let's not start the 'Java is slow!!!!' debate again.
Java is slow to write. And very slow to read. Ever maintain a Java or C++ project? It's glacial. I'm talking about human performance, not runtime speed.
I think Greenspun is wrong about why this happens. I think it's a sign of weak program design, rather than a weak language.
I think it's a sign of bad practices. One thing that impels people toward bad practices (and not the only thing) is using the wrong tools.
C was designed for simple programs that need tight control over resource use and speed, or that need direct, reliable hardware access. As per the Unix philosophy, these programs were never supposed to become large; they should be modular and communicate through pipes or sockets. For those purposes, it's excellent. But if you have a 250 kLoC C++ program, you're doing something wrong.
One causative factor for the Greenspun effect is inappropriate language choice. It's not the only one.
I think you are wrong about this. I have seen little evidence in my career of a correlation between chosen technology and ability to deliver results.
"Deliver results". Here is your problem. A 1.2 programmer can code software to spec, meet deadlines, et cetera. That's an additive effect: cranked it out, met deadlines, went home. The difference between a 1.2 and a 2.0 is the ambition (in the latter) toward multiplier effects-- toward using technology to make whole teams or companies more effective. It's not just about "results"; it's about what those results are.
Expanding your definitions to preserve your point is a symptom of fallacious reasoning.
I guess my point was that it's not accurate to say that 1.5+ programmers always use functional programming, but the weaker claim is true that, for complex tasks requiring high-level languages, they prefer languages that support the functional style.
Enterprise Java idioms are slow to write and slow to read, but if you use Clojure to write the same sort of crap you end up with same sorts of crap. Read Vuse's source code for a fresh look at what it means to use Java. http://dev.vuze.com/
My experience is that most good engineers are conscientious. They don't want their code to be tomorrow's legacy disaster. This makes them care a lot about languages, if we're talking order-of-magnitude differences like Scala vs. Java. If we're talking about Clojure vs. Python, then maybe not.
Friends don't let friends maintain Java code.
No, let's not start the 'Java is slow!!!!' debate again.
Java is slow to write. And very slow to read. Ever maintain a Java or C++ project? It's glacial. I'm talking about human performance, not runtime speed.
I think Greenspun is wrong about why this happens. I think it's a sign of weak program design, rather than a weak language.
I think it's a sign of bad practices. One thing that impels people toward bad practices (and not the only thing) is using the wrong tools.
C was designed for simple programs that need tight control over resource use and speed, or that need direct, reliable hardware access. As per the Unix philosophy, these programs were never supposed to become large; they should be modular and communicate through pipes or sockets. For those purposes, it's excellent. But if you have a 250 kLoC C++ program, you're doing something wrong.
One causative factor for the Greenspun effect is inappropriate language choice. It's not the only one.
I think you are wrong about this. I have seen little evidence in my career of a correlation between chosen technology and ability to deliver results.
"Deliver results". Here is your problem. A 1.2 programmer can code software to spec, meet deadlines, et cetera. That's an additive effect: cranked it out, met deadlines, went home. The difference between a 1.2 and a 2.0 is the ambition (in the latter) toward multiplier effects-- toward using technology to make whole teams or companies more effective. It's not just about "results"; it's about what those results are.
Expanding your definitions to preserve your point is a symptom of fallacious reasoning.
I guess my point was that it's not accurate to say that 1.5+ programmers always use functional programming, but the weaker claim is true that, for complex tasks requiring high-level languages, they prefer languages that support the functional style.