Before I risk offending anyone with my provocative title, I’ll give away the answer: it’s “no”. However, there’s an interesting discussion to be made of this. Not to pick on Haskell or Erlang or Clojure in particular, Piaw Na made this comment in this Quora answer.
A fixation on programming languages is the sign of a 2nd rate engineer/computer scientist.
[...]
Even when I was hiring to fill an Erlang server position, I found that the Erlang specialists were much worse engineers than hiring a great all-rounder and having him learn Erlang (or whatever) to fill the position.
Na’s argument is similar to the attitude that is in vogue in technology companies founded in the 1990s, such as Google and Amazon. At the time, programming language research was considered to be a dead and probably useless field. Large applications were written in C++ and possibly Java. Python, ten to twenty years ago, was considered cutting-edge and risky, and languages like Lisp or Haskell were hardly used at all. Paul Graham deserves a lot of credit, not just for the decision to use Lisp for his startup, but for his eloquent defense of it and expressive languages (like Python) in general. From his essay, “The Python Paradox” (all emphasis mine):
In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.
I didn’t mean by this that Java programmers are dumb. I meant that Python programmers are smart. It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.
Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.
These passages don’t necessarily contradict each other, but they suggest different hiring strategies. Piaw Na would suggest that you should be more leery of people who identify strongly as Clojure or Haskell engineers, while Paul Graham suggests that you want programmers who hold strong enough opinions about languages to invest themselves heavily in the more obscure ones.
So who’s right? Obviously, they both are to some degree; otherwise, this wouldn’t be an interesting essay.
Programming languages are important to great software engineers. There’s a “languages don’t matter” attitude among managers and “architects” in many software companies, held by people who haven’t written a line of code since Macarena came out. People who actually still write code care immensely about their tools. All that said, Piaw Na is correct on the tendency of monoglot programmers toward mediocrity. Great engineers want to use the right tools for each job, and programming languages are an area where there isn’t one right tool for every job (far from it!)
Whether it’s Java or an arguably superior language like Haskell or Erlang, a programmer who refuses to learn things that are outside of his comfort zone is likely to be a mediocre one. While any programming task can technically be achieved in any language (Turing completeness) they vary rapidly in practical capability, and there really isn’t a single language that dominates the others, because programming is diverse. Some algorithms are nearly impossible to write efficiently without manual memory control, which necessitates using a language like C. For a typical production server that should never fail, Haskell is probably the strongest choice. For interactive exploration, Clojure’s first-class “repl” (interactive console) is hard to beat.
I’ve bashed Java a fair amount (perhaps unfairly) and that’s because I absolutely loathe the “Java Shop” culture. Giant XML files, AbstractFactoryManagerSingletonFactory patterns, IDE-dependent builds… all that nonsense can go fucking die in a taint fire. The lack of taste in the corporate Java culture is astonishing. It generates ugly code with no personality and that falls apart rapidly because no decent engineer wants to maintain it. The monoglot nature of the corporate Java community is, quite likely, correlated to these cultural problems. When you have incurious developers, short-sighted and clueless management, and a language that basically works as long as you throw enough engineers at the problem, you’re simply not going to stumble upon a reason to use anything other than Java.
The noticeable trait of mediocre Java developers (and it’s probably similar for .NET, and maybe even C++) is that their conception of programming is limited to what can be done in Java. Their bosses won’t let them use other languages, so why learn anything but Java? Ask one of them how an assembler or an operating system works and you’ll get a blank stare. Ask about machine learning or computer graphics and you’ll hear grumbling about how linear algebra was taught at 8:00 am. They’ve forgotten how to write programs and haven’t run one since college; they just make classes all day, and it becomes the job of “some smart guy” (the same “some smart guy” who gets you productive again if “your Java”, meaning your IDE, breaks) to staple them together and throw something into production. The corporate programmer culture has dumbed software engineering down to this, and the result is that CommodityJavaDrones haven’t been near actual computer science in years, even if they’re up to speed on how to write “user stories” and groom “back logs” and play politics.
It’s not Java’s fault. The language has its warts, but business-driven stupidity didn’t come into being in 1995 and it would have glomped on to something else if Java hadn’t come along. James Gosling didn’t intend AbstractFactoryVibratorSingletons when he invented the language. He needed a fairly low-level language (like C) for the JVM. For the problem he was trying to solve, Java worked well.
Comfort zones are for losers
Piaw Na’s right that not all programmers in the more interesting languages (e.g. Erlang, Haskell) are first-rate. Bad code and sloppy engineering can be found in all languages. Sometimes, a neophyte will have the luck of landing in a first job using a more expressive language, but still fail to grow. It’s rare, but I’ve seen it happen.
This is an industry in which anyone who wants to be decent can’t afford to have comfort zones. If you cop an attitude of, “I’ll never use a statically typed language” or “I just don’t do low-level” or “I stay away from the browser because Javascript is ugly” or “I’ll never understand operating systems” then you’re probably not going to become a first-rate programmer. It’s paradoxical and difficult, because you have to be very selective in what you work on to keep learning and stay sharp, but you can’t rule out whole areas of computer science, either. (You can rule out process bullshit like “story points”; that will just rot your brain.)
If you’re a curious person, you’re not going to ignore a whole area of computer science just because it’s difficult. Things change too often. Obviously, it’s fine (and expected) to have preferences. It’s setting up brick walls that I have an issue with. Of course, we all create brick walls by necessity when we’re starting out and we need to be selective in what to focus on (lest we get a mediocre knowledge of many things). I’d just argue that the better computer scientists are the ones willing to break those walls down when there’s a good reason to do so. If you’re doing computer science right, then every problem should be new and they should tend to progress in reward, complexity, and challenge. The solved, repetitive stuff should be automated when possible.
Paul Graham warns about the danger of using a language as a comfort zone by introducing the concept of “Blub”. Blub is a stereotypical mediocre language that a monoglot, corporate programmer uses as his model for all forms of programming. The Blub programmer sees lower-level languages as braindead, and higher-level languages as abstract and just plain weird. Blub is, of course, not a specific language but an artifact of an attitude. Java, at least of the enterprise variety, is probably the Blubbiest of Blubs, but there’s nothing that stops a person from taking Haskell as his own personal Blub.
So what makes Java such a common Blub? Part of it, I think, is that the language does many things well-enough. If you are going to be a one-language programmer (or, worse, a one-language company, a “$LANG Shop”) then Java isn’t such a bad choice. It’s not hard to learn, it’s possible to write performant code, and the library support is strong. Let’s look at the standpoint of a middling engineer, because good engineers are almost certainly going to be polyglot, and crappy ones don’t care about languages or software engineering. This middling vantage point is also useful because in business-driven engineering shops, middling engineers tend to be the ones emerging as leaders. A middling Python engineer is going to realize, quickly, that some routines need to be written in C, because Python generally isn’t fast. (Crappy engineers don’t think or care about performance. It’s just mathy voodoo to them.) He might not be proficient in C or enjoy using it, but he’s not going to write the language off. The middling Java engineer will never need to know what C even is.
As far as Blubs go, one could do worse (on language fundamentals) than Java. It’s not PHP or Javascript or Visual Basic. Culturally, however, it tends to be a toxic Blub. Na points out that someone who refuses to code outside of Erlang is probably not a first-rate developer. Fair. I’m a huge fan of Haskell and would probably pick it for most projects if I called the shots, but I’ve also exposed myself to Clojure, C, Python (for the data science libraries) and Scala. I certainly think that comfort zones are a sign of a second-rate programmer. Even still, the CommodityJavaDrones are often third-rate. What’s more pathetic than holding fast to one’s own comfort zone? Living inside someone else’s.
Business-driven engineering (or: waterfalls of sewage)
For an aside, one of the reasons why first-rate engineers don’t seem as adamant about programming languages is that, often, they have the credibility to make technical decisions. (If they don’t, they’re in a company that doesn’t recognize talent, and should leave.) If you’re junior and powerless, you care a great deal about whether you wind up at a “Java shop” or a “Python shop”, because you’re not going to be allowed to use anything but the house language. If you’re senior and have clout, you tend to work on new projects and get to choose the tools. Great engineers avoid business-driven engineering and closed allocation, at any rate. Of course, no one is born as a first-rate engineer, so in our “good, working toward great” years, we do have to pick companies based on those sorts of signals. If a company’s a Java shop, it sends a really bad signal.
Java isn’t my favorite language, and I don’t have much use for the (false) claim that languages don’t matter, but it is the right language for some problems. If you have to be on the JVM, and can’t afford the (small, but nonzero) overhead of Clojure or Scala, then Java’s the right choice. As I’ve said, the ugliness of Java isn’t all intrinsic to the language, but has a lot to do with the anti-intellectual culture of corporate Java.
For those who’ve been lucky enough to avoid the hideousness of most programming jobs, here’s how many software companies work: business comes up with the ideas and defines the work, product managers intermediate and sit in on interminable meetings, and programmers just implement. Most “scrum teams” are just ticket shops. The engineer has no autonomy. This is business-driven engineering. I’d call it “waterfall of sewage engineering”, but decrying a “waterfall” makes it sound like I support much of what is called “agile”, and I don’t. The problem with “agile” is that it’s still closed-allocation, business-driven engineering, meaning that nothing was accomplished. Trying to “fix” business-driven engineering is like putting salt on a turd to make it edible: it just doesn’t work that way.
This may be paradoxical, but when you have an engineer-driven firm, you get better engineering and better business. See, business-driven engineering rots the mind, because it takes what should be a creative and challenging discipline and turns it into “Write me seven classes and 17+i story points by Friday.” It’s also part of why there’s an age-discrimination problem in technology; if you spend your 20s doing that crap, you actually will be a corporate executive (as in premature dementia; not necessarily as in rank and salary, unfortunately) by age 30.
Are there excellent engineers who happen to use Java? Absolutely. Are there not-great programmers in the Haskell community? Sure. If you really want to encounter that underclass of non-programming programmers, though, you have to descend into the shit-lava inferno of business-driven engineering.
As for bets and things…
Hiring is, to a very large extent, about making the bets with the best odds. Does using Haskell guarantee that you’re going to have excellent programmers? No. And Piaw Na is right that talented programmers unexposed to it shouldn’t be written off in hiring, because great engineers can learn new languages quickly. (It takes longer to learn an average corporate Java codebase, those being verbose and generally of low quality, than to learn Haskell or Clojure.) Do the odds favor using languages like Haskell and Clojure, if you want to get mostly wheat in your hiring process? Absolutely. Not only do you get (on average) better developers in those languages, but you’re also going to be in access to stronger communities.
I’ll say this, too, for most Haskell and Clojure engineers that I know: most of them aren’t monoglots who stick to their comfort zones. At a conference or talk dedicated these more “elite” languages, there are plenty of presentations that bring in ideas from other languages and paradigms, whether it’s logical programming or assembly hacking. What makes these languages and communities different and somewhat special isn’t that there are no mediocre engineers, but that the average engineer is quite strong. That creates an energy, and a sense of friendly competition, that you just don’t see in an enterprise Java shop.
The Python Paradox doesn’t guarantee great hires all the time. That requires, well, great hiring. But I think it’s pretty obvious, on the “do languages matter?” debate, which side the odds favor.
