First of all, I was exaggerating the negatives of Java. There are 2.0+ programmers writing in Java every day. The vast majority of these would prefer to use another language, but that's another story.
My experience is that most 1.5+ developers, when forced to use Java, react in one of two ways. The first is to scale back their general tendency toward ambition in coding and tolerate uninspired patterns, such as objects with 25 getters and setters. This works, and it can produce quality software, but it's not fast and it's definitely not fun. The second is to follow Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) which describes the process by which a skilled programmer, confronted with under-powered tools for his job, creates a personal DSL (and usually a bad one) for solving the problem. Rich Hickey and Martin Odersky are counterexamples: instead of writing shitty DSLs, they built full-fledged, awesome languages.
Are there 1.5 and 2.0 programmers in languages like Java? Absolutely. Is it common? No. Is it likely that a person exposed to only Java and C++ will ever crack 1.5? Absolutely not.
You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for.
You're taking it a bit far. Obviously, there are exceptions. Multiplier effects happen on bad languages, but you have to either (a) fight the language the whole way through, or (b) deliver a complex system, which ends up being a divider effect if someone other than you ever has to maintain it.
To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill.
Disagree, unless you're taking a very strict view of what "functional programming" is. A 1.5 programmer in Python will find himself using a lot of list comprehensions. Are his Python programs likely to be "purely functional"? Absolutely not. It's not idiomatic for the language. But his code will be in a state where the average Lisper will understand what he is doing and why, and in which the average Java developer will be asking "where are the Factories?"
My experience is that most of the highly skilled engineers that I have worked with don't really care about the language that much. Most of them are much more interested in what they are building, and interested in how they are building it to the extent that it gets in their way or gets in the way of future maintainers. There are those that are much more productive in languages other than Java, but for most the barriers to productivity or delivery time are not the language but the environment. Using a well-supported and mature platform like Java (both the language and the JRE) helps a great deal here, as does the wide variety of libraries and frameworks available in the Java world. The same applies to the .NET platform, and some other mature platforms that are available.
Languages like Scala and Clojure blur the line here a bit, because they are 'more powerful' languages on an mature platform. The Java language still holds some benefits over these languages, mostly in it's stability.
> but it's not fast
No, let's not start the 'Java is slow!!!!' debate again.
> Greenspun's Tenth Rule
I think Greenspun is wrong about why this happens. I think it's a sign of weak program design, rather than a weak language.
> Are there 1.5 and 2.0 programmers in languages like Java? Absolutely. Is it common? No.
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. There are some technologies that I don't like or find not to my taste (PHP springs to mind), which have been the basis for some fantastically successful projects.
I might admit that the median skill (measured by the ability to deliver effective results) of people who chose Java is lower than those who chose other languages, but my experience suggests that those differences disappear quickly as you move upward.
> Disagree, unless you're taking a very strict view of what "functional programming" is.
Expanding your definitions to preserve your point is a symptom of fallacious reasoning.
Engineers chose tools for many reasons, and a good engineer will have a wide set of tools they know and good judgement about which is the best to use. Looking at which tool they happen to have chosen isn't a good indicator of skill - the actual outcomes are much more useful. Is what they built useful? It is maintainable? Was it delivered on time? Was it delivered in budget?
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 1.5+ developers, when forced to use Java, react in one of two ways. The first is to scale back their general tendency toward ambition in coding and tolerate uninspired patterns, such as objects with 25 getters and setters. This works, and it can produce quality software, but it's not fast and it's definitely not fun. The second is to follow Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) which describes the process by which a skilled programmer, confronted with under-powered tools for his job, creates a personal DSL (and usually a bad one) for solving the problem. Rich Hickey and Martin Odersky are counterexamples: instead of writing shitty DSLs, they built full-fledged, awesome languages.
Are there 1.5 and 2.0 programmers in languages like Java? Absolutely. Is it common? No. Is it likely that a person exposed to only Java and C++ will ever crack 1.5? Absolutely not.
You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for.
You're taking it a bit far. Obviously, there are exceptions. Multiplier effects happen on bad languages, but you have to either (a) fight the language the whole way through, or (b) deliver a complex system, which ends up being a divider effect if someone other than you ever has to maintain it.
To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill.
Disagree, unless you're taking a very strict view of what "functional programming" is. A 1.5 programmer in Python will find himself using a lot of list comprehensions. Are his Python programs likely to be "purely functional"? Absolutely not. It's not idiomatic for the language. But his code will be in a state where the average Lisper will understand what he is doing and why, and in which the average Java developer will be asking "where are the Factories?"