I was mostly agreeing with you until you starting on the technology bigotry.
> Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure
What about people like Doug Lea and Josh Bloch? What about people like Trustin Lee? Why do these people not qualify as 'multipliers' in your framework because of their choice of technology?
The idea that using a single technology or approach - in your case a functional language and not even a functional style - would be the difference between an adder and a multiplier is simply absurd.
And then you go on to say:
> This is because the Java+IDE environment, and operating systems like Windows, are designed to bring up the rear (0.7 to 0.9) while holding back the best programmers, artificially imposing that “ceiling” around 1.2-1.5
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. What about many of the really useful sites and services that are served from Windows (or Java running on Windows, gasp!) or the innovative and world-changing pieces of software which are primarily developed for Windows? Excluding all the people behind those from being upper levels seems like a stretch.
> these technologies are intentionally designed for a performance-middling effect– to make it possible for huge teams of “commodity” developers to produce something while holding the excellent back from producing great things.
This is the core of my problem with your argument. I can think of many more things I would call great that used technologies like C++, Java and Windows than used technologies like Lisp, Scala and Clojure.
> Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects).
You are simply wrong about this. There are many marks of a good engineer. An interest in different programming paradigms is one of them, for sure. 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.
I have been lucky enough in my career to work with many great engineers, leaders in their fields, who have chosen to use the technologies you deride and are therefore forever stuck at the lower levels of your hierarchy because of those choices.
(On the other hand, I may have just fed the troll).
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/
> Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure
What about people like Doug Lea and Josh Bloch? What about people like Trustin Lee? Why do these people not qualify as 'multipliers' in your framework because of their choice of technology?
The idea that using a single technology or approach - in your case a functional language and not even a functional style - would be the difference between an adder and a multiplier is simply absurd.
And then you go on to say:
> This is because the Java+IDE environment, and operating systems like Windows, are designed to bring up the rear (0.7 to 0.9) while holding back the best programmers, artificially imposing that “ceiling” around 1.2-1.5
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. What about many of the really useful sites and services that are served from Windows (or Java running on Windows, gasp!) or the innovative and world-changing pieces of software which are primarily developed for Windows? Excluding all the people behind those from being upper levels seems like a stretch.
> these technologies are intentionally designed for a performance-middling effect– to make it possible for huge teams of “commodity” developers to produce something while holding the excellent back from producing great things.
This is the core of my problem with your argument. I can think of many more things I would call great that used technologies like C++, Java and Windows than used technologies like Lisp, Scala and Clojure.
> Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects).
You are simply wrong about this. There are many marks of a good engineer. An interest in different programming paradigms is one of them, for sure. 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.
I have been lucky enough in my career to work with many great engineers, leaders in their fields, who have chosen to use the technologies you deride and are therefore forever stuck at the lower levels of your hierarchy because of those choices.
(On the other hand, I may have just fed the troll).