There's no cognitive dissonance needed: popularity is simply not a strong indicator of quality. I'm not saying that "popular things are bad" but rather that "popular things can be bad" and that quality is mostly orthogonal to popularity. There's no more conflict in saying that Go is bad despite its popularity any more than there is in saying that Big Macs are poor quality food. (Which are, of course, developed by leading minds at one of the largest food processing corporations in the world...)
There's been some fascinating research in this regard, finding that things get popular based on social factors (namely the shape of the social graph) coupled with some amount of random change, largely removed from any intrinsic qualities of the thing in question[1].
Another annoying thing this article—and similar ones like it—does is conflate "different" and "unfamiliar" with "complex". Even if you don't understand it, the Haskell type system is not complex: it's a slight elaboration of the lambda calculus which can be fully described on half a piece of paper with type theoretic notation which translates to maybe a page or two of prose. (Which is only needed to provide some general background information.) Haskell really does boil down to a simple kernel like this which is even used by the compiler (as an intermediate form called "Core"). Everything else is just syntax sugar, usually in transparent ways.
In a similar vein, the article conflates simplicity of implementation with simplicity of language. The two diverge as soon as you start caring about performance—performance breaks all abstractions. That's the only reason GHC is complicated; writing an interpreter for Haskell is actually probably easier than Go because, again, it's just the lambda calculus. That's literally something we teach freshman in a general-purpose intro course (SICP[2]). It's easier to understand what a Haskell program means because of this; it's only harder once you start worrying about low-level optimization. The dynamic semantics of Haskell—what happens as an expression is evaluated—can largely be summed up in a single rule describing function application. That's it! Even if you find it difficult, which is understandable, it is not complex; difficulty is as much a function of your background as anything else.
Popularity is a terrible way of evaluating programming languages on anything but their popularity. Simplicity of implementation is not simplicity in general. This article is decidedly unconvincing.
[2]: The Structure and Interpretation of Computer Programs, an book introducing CS still used at many universities and available free online: https://mitpress.mit.edu/sicp/
Indeed. The only objectively valid measure of a programming language's simplicity is the size of its formal semantics, with a large penalty for any behavior left undefined. Mathematics, unlike English, doesn't let you sweep details under the rug.
Comments
There's no cognitive dissonance needed: popularity is simply not a strong indicator of quality. I'm not saying that "popular things are bad" but rather that "popular things can be bad" and that quality is mostly orthogonal to popularity. There's no more conflict in saying that Go is bad despite its popularity any more than there is in saying that Big Macs are poor quality food. (Which are, of course, developed by leading minds at one of the largest food processing corporations in the world...)
There's been some fascinating research in this regard, finding that things get popular based on social factors (namely the shape of the social graph) coupled with some amount of random change, largely removed from any intrinsic qualities of the thing in question[1].
Another annoying thing this article—and similar ones like it—does is conflate "different" and "unfamiliar" with "complex". Even if you don't understand it, the Haskell type system is not complex: it's a slight elaboration of the lambda calculus which can be fully described on half a piece of paper with type theoretic notation which translates to maybe a page or two of prose. (Which is only needed to provide some general background information.) Haskell really does boil down to a simple kernel like this which is even used by the compiler (as an intermediate form called "Core"). Everything else is just syntax sugar, usually in transparent ways.
In a similar vein, the article conflates simplicity of implementation with simplicity of language. The two diverge as soon as you start caring about performance—performance breaks all abstractions. That's the only reason GHC is complicated; writing an interpreter for Haskell is actually probably easier than Go because, again, it's just the lambda calculus. That's literally something we teach freshman in a general-purpose intro course (SICP[2]). It's easier to understand what a Haskell program means because of this; it's only harder once you start worrying about low-level optimization. The dynamic semantics of Haskell—what happens as an expression is evaluated—can largely be summed up in a single rule describing function application. That's it! Even if you find it difficult, which is understandable, it is not complex; difficulty is as much a function of your background as anything else.
Popularity is a terrible way of evaluating programming languages on anything but their popularity. Simplicity of implementation is not simplicity in general. This article is decidedly unconvincing.
[1]: Here's a nice summary with references to peer-reviewed studies: http://nautil.us/issue/5/fame/homo-narrativus-and-the-troubl...
[2]: The Structure and Interpretation of Computer Programs, an book introducing CS still used at many universities and available free online: https://mitpress.mit.edu/sicp/
Indeed. The only objectively valid measure of a programming language's simplicity is the size of its formal semantics, with a large penalty for any behavior left undefined. Mathematics, unlike English, doesn't let you sweep details under the rug.