The Flub Paradox

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it.

Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lot. If the code is garbage, well... perhaps you learn what not to do. Compared to the slog of learning a new corporate codebase, the effort involved in learning Haskell isn't that much... and the hope with Haskell is that the next software project you write won't be unmanageable... and I think that even average-case Haskell realizes it. (I focus on the average case because, of course, you can write shitty code in any language and you can write good code in any language, but languages differ in what tends to happen on average.)

>summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person.

I wouldn't summarize it that way. More accurate would be: "the effectiveness of a programming language is driven by multi-dimensional factors instead of a single factor such as expressiveness of syntax. One's expert usage of a language can lead him to overestimate its overall effectiveness."

When people debate programming languages using words like "simple", "powerful", "better", it's not very precise. It's actually misleading. All those labels have multidimensional factors but people discuss them as if they are a single dimension scalar.

E.g. "Golang is simple" -- it's simple in keyword count but not simple in terms of implementing a family of algorithms that differ only by type. The paradox of "simple" has contradictory conclusions because that word has multiple dimensions. Therefore, if one's typical use case of Go does not involve templated algorithms, it is perceived as "simple" and one would proceed to evangelize the language as "simple."

Same type of analysis can be done for words like "power", "better", "easier", etc.

Yes, languages like Haskell/Lisp/Ocaml/F# etc have more expressive syntax but there are other dimensions in creating software that can overwhelm that advantage. This is why PG can have reasonable opinion on the "power" of Lisp but Aaron Schwartz came to a different reasonable opinion[1] and determined Python in his case to be more appropriate for Reddit. Aaron was not stupid and he knew how to write Lisp. To understand Aaron's viewpoint, you have to notice that he's using different dimensions of the word "better".

[1] http://www.aaronsw.com/weblog/rewritingreddit

I really don't expect Rust to exhibit what most people mean by "increased productivity", ever. Most people mean something fairly local by that, or at most medium sized, that it allows them to take some task and write code faster than other languages that accomplishes the task. Rust is always going to labor under the disadvantage that it holds you to a higher degree of correctness than other languages, and at best it can tie with another language that doesn't hold you to those guarantees of correctness.

Where it'll increase productivity or not is at larger scales. If Servo comes out at production quality in some reasonable time (call it 2 years or less from now, given where they are), able to function on the general web most of the time, and it's also faster than current renderers by a significant margin, and with some small fraction of the development effort (probably even if you include the entire Rust development effort; do not underestimate the effort poured into the existing engines!), I will consider Rust's story proved. We've now had many people take cracks at writing renderers, in the fastest language of the time for the task (C++), and I daresay they've converged at fairly similar levels of performance with little reason to believe the renderers are going to get much faster. Said renderers have had massive optimizations applied to them, and this Servo that I'm expecting to be much faster will actually be version 1.0, basically.

If Rust is to work at all, there will very, very rapidly be a class of development that it will be actually insane to write in anything but Rust... but that will only be the very high-and-large end. (It will take many more years for this fact to penetrate through to the development community at large.)

This is intelligently argued and articulate but the content is a bit lacking.

First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statically typed languages.

Now, PG probably intended "Blub" to mean a mediocre language du jour like C++ (in the early 1990s) or Java (since the late '90s) but Blub is more of an attitude than a language. Yes, there really are one-language programmers who can't think out of a specific paradigm. They exist, and they're the ones who write FactoryVisitorFactory classes because they haven't been exposed to functional programming and the right way of solving certain problems. That said, there are cases where C or Java is the absolute right language to use. Not many, for Java, but they exist. Not everyone who uses those "Blub languages" is a mediocre programmer; Java is not always Blub, and C is definitely not always Blub (in fact, it's out of fashion among the Blubanistas, who avoid low level programming because "it's too hard".)

As for "Flub"... I don't even know where to begin. Just going to snipe specific points.

'Power' and 'Expressiveness' turn out to be separate concepts. In the end, there is no simple continuum that you can use to line programming languages up, nose to tail, feeble to awesome.

I agree with this, whole-heartedly. Assembly and C, I would argue, are more powerful than Haskell because it makes it so much easier to create custom control flows and to manage memory explicitly. Haskell is more expressive. You trade some power, in exchange for a language that allows you to write very robust code, very quickly. But sometimes you need that power and C is the best option.

To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices.

No, we dislike IDEs (actually, we don't; we dislike broken languages and codebases that require us to use IDEs) because it's a lot easier to keep flow when you're using the keyboard only. Switching to the mouse to recompile breaks flow.

IDEs also have a stigma because they're most useful when you're maintaining other peoples' code, which generally is a disliked sort of work given to juniors. So, IDEs tend to be associated with the second-class programmers who spend most of their time on maintenance work. I, personally, think the "reading code is for losers" attitude that many programmers cop is stupid and counterproductive. I enjoy reading good code and I wish that I had better tools for doing it.

A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days.

Oh, this shitty argument. "Your tech should be boring, your product should be interesting." Yawn. It's a bullshit argument and I'll tackle it another time.

Google was originally written in Python, which was more of a reach than Haskell is now. Python sucked in 1998. Also, the late '90s were a time when PL was considered to be a dead field, so PL never worked its way into Google's DNA and it's stayed that way. They use C++ because it was the best choice in the late 1990s, and they tolerate Java in the context of acquisitions, and when they tried to come up with their own language... the best they could do is Go.

Facebook started on PHP but is increasingly innovative on the language front, with Erlang, Ocaml, and Haskell getting a presence.

You put a group of merely good Lisp programmers on a project, and embed them in a corporate environment, and the stellar results are likely to be not reproducible. (I don't doubt they will be more productive than Java programmers. But will the result blend?)

"Will it blend?" I'm sorry, but I prefer not to think of my work as something that will be ground to a pulp. If that's the kind of work you want, then hire a Scrum drone, not someone like me.

Big companies understand this problem well, and prefer Blub programmers, who are easier to source and come with less attitude.

False. Do Haskell programmers come with more "attitude" than mediocre Java programmers? Yeah, there's probably a slight difference. However, the problem isn't "Haskell programmers" or "Java programmers" but people. People are just a pain in the ass: all of us, to some degree. Since you need 30 Java programmers to do the work of 5 Haskell programmers, you not only have more sources of "attitude" with the 30, but you have more politics and less per-person productivity on account of the larger team.

Just out of curiosity, what makes you say IDEs are bad?