What Level Programmer Are You?

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 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.

An overall objection: though it does both, it focuses on coding solutions rather than understanding problems. While there's a case for defining a programmer as "someone who programs", to me, understanding the problem (aka asking the right question) is the difficult bit (see Douglas Adams).