Summary. The linked text is just a rant, didn’t address real practical problems in the Haskell language and complains about the wrong subjects, in my opinion.

The linked text infuriates me. And it is so because it is uninformative and unnecessarily spreads fear, uncertainty, doubt with no back-up data or references.

It can be read as a rant, at most, and as so it should be tagged, in my opinion.

But I want to address what I find wrong in this text.

• IO problem. Besides the fact that main = putStrLn "Hello, World!" is a simpler “Hello, World!” program than its C counterpart, what I learned is that Haskell forces the programmer to think about, design and implement data transformation first, then process the input or output of it. In Java-esque language, one concerns about the business logic, then moves to the user interaction part (which will be encapsulated in IO monad). When I wrote a compiler, interpreter and simulator (for a metabolic language) in Haskell, I learned that lesson smoothly because most of my design models were already mathematical, so I was (theoretically) mainly focused on the “business logic”. Later, when I had to add the HTML5 user interface, it was actually easy, and I could never feel this IO problem with my rustic MVC design.
• Monoid abstraction. I am not kidding, but the 5th-grade children in my homeland learn what a monoid is, so I think any other programmer can as well.Of course they don’t learn the name “monoid” (or “group”, in the mathematical sense), but they do learn all the other nomenclature: set, binary operation, identity element, associativity. And they have exam on the subject, in which they have to recognize which pairs of sets and binary operations forms a monoid or not. Do I come from a genius land? Certainly not! The real problem is not how difficult is to understand the monoid abstraction, but the semantics it contains after all the social media complaint about Haskell, monad and its sordid definition as “a monad is just a monoid in the category of endofunctors”. If monoid would be presented as the Clock Arithmetic design pattern in a Gang of Four book, I think most people would accept it. (Well, most people accept the monoidal properties of Promise and Future in Java without naming it monoid or even monad.) My opinion is that a lot of programmers are “mentally lazy” and want an easy, served-on-a-plate simple solution for their problem instead of reflecting a little on concepts—design patterns are great examples of obvious instances of applied object-oriented concepts which most people can just “go to the shelf and take the canned solution” if they don’t want to design their own architecture using the basic set of object-oriented concepts.
• “Not made for this world.” I think the correct term would be “ahead of its time”. The syntax is not ALGOL-like (but mathematical); the language stimulates reasoning on data and, consequently, use of types; it also stimulates determinism (via pure functions); on the other hand, it makes non-determinism easy (top of my head, Applicative and lists are nice to fool around with it); the easiness of polymorphism (compare it with C++ templates) and type classes; lazy evaluation; several styles for concurrency and parallelism; and so on… The list of features that makes Haskell ahead of its time (of course it is not the unique language in this group) is incredible! But when we are stuck with strict-subset languages of the 1970s (yes, most of our dear programming languages are a strict subset of ALGOL 68), then we tend to think any breakthrough language is not made for this world.

Uff! I took out of my system.

However, I want to briefly point out some of my practical criticisms towards Haskell, which I (as a not-very-experienced Haskell programmer) think the article should have addressed.

• Memory consumption. Do you remember the compiler/interpreter/simulator I told you before? Yeah… To translate a couple of rules to a primitive assembly, my application consumed 5GB of my working memory. And it is not because I am a lousy programmer (could be, though), but because the “standard way of doing it” (no advanced Haskell trickery) tends to generate memory consuming programs, in my experience.
• Debugging. I am fan of debugging. I do use GDB almost daily, both to understand calls, as well as, to debug buggy applications. I still don’t know how to do so in Haskell, although I haven’t dive into it.
• Performance. Haskell is fairly good at it, I must admit: it is comparable to Java and Go (given it is comparable to Java). But I think it has the potential to get closer to Rust—so I can have some chance to convince my employer to start using it.
• Retrievability and documentation. The Haskell Wiki is a gem, in my opinion: almost any subject concerning programming languages (deliberately exaggerated comment), particularly Haskell, in in there. The problem is to find it (when one wants or needs it). Books? The landscape has been changing (thank you, @bitemyapp), but compared to Rust (and it is impressive free book, thanks @steveklabnik), for instance, it is light-years behind. And to find the correct (maintained) library for common tasks is not easy, but there are initiatives on the way.
• Reputation. “The Haskell Pyramid” is a real problem, in my opinion. Maybe one of the biggest problems in Haskell.

It is obvious that Haskell isn’t perfect and lacks tools for “practical, industrial application”. Unfortunately, those were not addressed in the unique paragraph (out of eight) in that text.

P.S.: it seems that <br/> doesn’t work in item lists in this Markdown.

P.P.S.: I didn’t mean to say the Rust book(s) are better than “Haskell Programming from First Principles” (@bitemyapp, I am a fan of your book and I cannot recommend it enough). What I meant is that the (series of) Rust book(s) are part of the documentation Rust documentation available (for free) in the Rust’s website and it is easy to find it, read it and understand Rust from it. In Haskell, the closest equivalents are the Haskell Wiki and the Haskell Wikibook, which isn’t as maintaned as the Rust book.

I may be simplifying it too much, please let me know if I am making a straw man out of this, but my interpretation of the argument is:

P1. IO is the interface towards users

P2. In order to be considered useful for user facing programs a language has to make IO easy

P3. Haskell makes IO difficult

Conclusion: Haskell is not useful for writing user facing programs

I would not discuss P1, we can take it for granted

P2 seems fairly arbitrary to me, without deeper reasoning, it seems to me that is a weak premise. I can imagine parallel ones that are quite obviously unsound. “Your feet are the most important part of your body since they are the ones interfacing with the ground”, “Sales is the most important department of any company as they are he ones bringing in the money”, etc.

P3 Is subjective, whether it is difficult or easy depends on how well you know the tool (haskell), and what are you trying to use it for (which problem). However, let’s just focus on a supporting premise for that one, picked from the tweet that is linked

In other words, “open file a, then open file b” is one of the harder programs to write in Haskell.

I am interpreting “harder” as most difficult, which again depends on who is doing it. It wasn’t really hard at all for me at least:

import System.IO

main :: IO ()
main = openFile "/tmp/foo" ReadMode >> openFile "/tmp/bar" ReadMode >> return ()

A complete beginner that hits the right tutorials would likely do something like this even before knowing that there is something called monad

import System.IO

main = do
  f1 <- openFile "/tmp/foo" ReadMode
  f2 <- openFile "/tmp/bar" ReadMode
  return ()

And someone that really hates monads and would like them not to exist could write

import System.IO

main =
  let ops = openFile <$> ["/tmp/foo", "/tmp/bar"] <*> [ReadMode]
  in sequence_ ops

The last one is just to make the point that the relationship between monads and IO is weaker than people superficially claim, once you put some time into it.

Now, some people would have a more difficult time writing any of these, but now that you know, it is not that difficult, is it?

So, if you don’t want to use a particular language, that is fine. If you want to use a particular language, that is fine too. If you want to claim that a particular language is useless, you are starting from a very difficult to sustain position. People have written usable and useful software in virtually any language, including Brainfuck and Malbolge, both of them explicitly designed not to be of practical use.

Aside

I did a PhD in the type of math that necessitates a lot of category theory, and I have looked at your use of category theory, and judged it to be unnecessary and pretentious and mainly focused on making you look smart while being entirely trivial. But this is not that kind of blog post.

Well, if it is not that kind of blog post, then don’t write this. Some people have worked a lot on these pretentious and unnecessary use of category theory. It is quite unfair to claim that they just focused on looking smart while being entirely trivial unless you have pretty strong evidence (not the kind, “I worked on this before, so I know) to support it.

I think the author is just venting off and the article doesn’t have any useful points to discuss.

Edit: It was pointed out to me that my original comment was rude.

Here’s the most recent update of a video game I’m working on in Idris, a sort of Haskell-on-steroids: https://youtu.be/wWswmxpLrgA

The various type-level abstractions helped with making it. I guarantee to you that IO was not an issue here. I’m sure that there are people who have genuine arguments against pure functional programming (or at least legitimate grievances based on lots of experience), but I have a sense that a lot of these vague rants come from people who haven’t actually bitten the bullet and done the work.

It requires getting used to, but I’ve completely bought into the idea that you actually have to think about things like state, IO, or exceptions explicitly. By the time I got to the point where I had to load and parse game data (levels, objects, scripts, etc.), it was a natural thing for me to make use of the Either a monad (rename it into Checked and give it a fail constructor), in which this data could be validated and converted into in-game representations, using it looks something like this:

  -- read a joint description for Box2D
  objectCast dict = with Checked do
    type <- getString "type" dict
    case type of
      "revolute" => with Checked do
        bodyA <- getString "bodyA" dict
        bodyB <- getString "bodyB" dict
        localAnchorA <- getVector "localAnchorA" dict
        localAnchorB <- getVector "localAnchorB" dict
        collideConnected <- getBoolMaybe "collideConnected" dict
        pure $ MkJointDescription bodyA localAnchorA bodyB localAnchorB collideConnected
      _ => fail "joint type must be of \"revolute\""

objectCast here will produce a Checked JointDescription, which is either an error message (look at the fail call below) or a JointDescription. All of these functions can fail, for example if getString cannot find the key it was given, or if that key isn’t a string, it will produce the appropriate error. This type of code is as easy to write as it looks. I mean I don’t see anything in it that could be called boilerplate, and it’s approaching Python-level readability for someone unfamiliar with the code.

But there is so much more to this. People act like monads are some cumbersome burden that stands in the way of doing useful things. That’s plain wrong. They’re just a general class of types which happen to be useful in describing a myriad of computations (namely those that produce results and compose, for example functions are monads, but so are stateful computations). No need for fancy category theory if you bother to understand the types and do the work.

This abstraction, monoids, then comes with the added benefit of being abstract enough that all of your programmers can spend their time explaining it to each other instead of writing programs that use the abstraction to do IO, and therefore deal with any actual users.

That’s real.

Myself, I always found the IO monad a bit too all-encompassing to be useful. First, no one is keeping you from using unsafePerformIO—it will not be reflected in the type. Second, people still make libraries for logging and debug prints distinct from the “normal” IO, not always reflected in the types. Third and most important: there’s no distinction between different kinds of impurity. Writing to the console, deleting a file, and starting a rocket to the Moon are very different things, and when they are all “equally” impure, it’s just as good as when nothing is guaranteed to be pure.

My bet is on algebraic effects.

It in fact makes you so unhappy that you’ll drag the entire lost-at-sea community of category theorists into the orbit of your language just so you can have an abstraction for doing IO that fits into your model of the world.

Loved the tone of this piece! This bit right here makes it worth the price of admission IMO :)

I don’t know Haskell and also don’t know category theory, though I have an eventual desire to learn the latter, and possibly even the former since I’ve been repeatedly told doing so can engender some incredibly powerful ideas in the learner.

I love this rant because it absolutely captures my beginner experience with Haskell and PureScript.

• Write 20 pure functions that do exactly the thing you want it to do - 2 hours
• Now try to paramtetrize it so you can use argv[1] as an input and print the stuff back to the terminal - 10h +

(Yes, I’m simplifying here, but add a little bit of networking and even the numbers work out.) Also I’ve used functional languages before and I enjoy them. I do not enjoy this IO stuff at all.

This abstraction, monoids, then comes with the added benefit of being abstract enough that all of your programmers can spend their time explaining it to each other instead of writing programs that use the abstraction to do IO, and therefore deal with any actual users.

Don’t you mean monads here?