One of the points the author touches is documentation. I just couldn't get why then he gave advantage to Haskell, since the documentation of Haskell libraries famously consists of a few definitions of types. So, you know that there is an abstractly named monadic function, you know it takes a foo and returns monad foo. What more guidance would you ever need?
But when it comes to CL, he has expectations:
>I’ve opened an issue on GitHub of one quite popular library, asking the maintainer to write documentation, but after 6 months it’s still not written (strange, right?).
I am one of the people who are interested in Haskell and find its documentation lacking. I don’t miss comprehensive language books, I miss module documentation. It almost looks as the Haskell community has something against examples in documentation. I stress that the types are not enough. Contrast that with Elm, where I was able to write a working app in a day or so. But Elm is written off quite harshly in the post, so I am again left with the feeling that Haskell may not be the language meant for people like me.
I think, coming from other languages, it takes a while to really absorb how much you can rely on types to tell you what a function is doing - to the degree that for some functions you can infer the implementation from them[1].
That said, Haskell documentation tends to be really lacking on some of the basics that other ecosystems get right, like where to start, shielding beginners from functions for more niche usecases, examples of how to build or deconstruct values, or end-to-end case studies. Some of the nicest things to _use_ have an API that primarily comes from typeclasses in base, and don't provide any documentation beyond a list of typeclasses. My impression has been that most Haskellers seem to be on the same page that those things need work, though - I'm optimistic about the situation improving, but it's still hard to recommend to anyone expecting the experience of working with popular libraries from more mainstream ecosystems.
That's a fair criticism. I think the reason that happened was because its just so much more natural to talk abstractly about Haskell :)
Here's a recent experience I can share: I've been working on a Haskell project for three days now, I've been type-checking as go, but I haven't been running the program I'm writing. This is mainly because I started "in the middle" and so I couldn't just run it, I'd have had to have written supporting code.
I've finally got to the stage where I _can_ run it. I've just tried it now and thanks to the style in which I write Haskell, where I clamp down quite severely on unnecessary effects/complexity before they become issues, it works perfectly. Creating specialized monads is just one aspect of the style of writing. This wasn't a trivial project either, I've essentially written a cross between a database and distributed source control.
Why bother doing that when you're still fiddling with the language?
To me, that sounds entirely backward :) I've never implemented a language I haven't already designed "on paper". (Why bother? With a good reference document, you can write and test programs in your head. Implementation is tedious; I only want to do that once.)
In terms of CS friendliness, I get the impression that Haskell is far more popular […]
It is. I don't really know why. Haskell has a lot of libraries and a good compiler, but it's otherwise pretty boring. Its type system is nothing special (OCaml and Mercury have very similar but more interesting systems, notably w/r/t subtyping), monadic I/O is one of the silliest contortions I've seen (uniqueness types in Mercury and Clean are much easier to work with), and laziness isn't all that useful (it is useful but I've never missed not having it).
(I say this with all respect to the Haskell designers: it's a very good language, and they successfully met their self-imposed goal of being fully functional; I just happen to think that that goal led to Haskell being ultimately boring.)
Erlang has "functional" and "actors", but not a lot of other stuff that seems to be of interest to the CS crowd, like types.
That's exactly it. It doesn't have a lot of stuff. The language is incredibly simple, EVERYTHING is explicit, it doesn't encourage first-class metaprogramming, and it ships with its own parser and pretty-printer. That's a CS researcher's dream. That's why Dialyzer (which is better than many, if not most, built-in type systems) can exist. You don't need a built-in type system if your language is simple and analyzable enough to admit a 3rd-party one.
No way at all? I think you can tell a lot about a language without some kind of formal documentation.
Sadly, all I can tell from the tutorial and front page is "Elixir has some kind of metaprogramming that's probably based on Ruby or Javascript". Like I said, I'm a huge fan of metaprogramming done right, but that hinges on lots of specific language details that aren't clearly documented.
Without specifics, any discussion about Elixir's metaprogramming features might as well be a discussion about Javascript's or Ruby's, because that's all I have to go on.
I couldn't maintain or understand the low-level code Java depends on without great effort (I know I could if I devoted enough time, which I usually don't have). Same for low-level libraries for C or any other language.
I think the argument here is that -- given that there are no problems with the library; otherwise you're screwed in any language -- type information for Haskell libraries gives you more useful information than docs & tutorials for libraries in other languages.
The author repeatedly asserts that he is not scared of math, and would probably be able to understand the libraries he uses if he spent the time. It's just that he doesn't need to.
I can't speak for the author, but I do know the reason I personally left it: Haskell-the-language is amazing, Haskell-the-ecosystem is awful.
Like the other commenter I completely agree that knowing Haskell makes you a better programmer, and when I code in other languages I really miss certain parts of it. On the other hand, the entire Haskell ecosystem feels like a half-finished PhD thesis, and often-promoted libraries suffer from fundamental flaws which are "open research questions". There's a constant drive in many Haskellers to make their code as abstract, type-safe, and generic as possible, but unfortunately practicality and ease of use are often forgotten along the way.
It's a great language, but if you're trying to write production code which builds upon the wider ecosystem you're in for a world of pain. In 2024 Rust has probably rifled enough through Haskell's pockets to make it mostly irrelevant as anything but a testbed for programming language researchers.
I am aware of that sentiment. I didn't want to imply that all those abstractions don't get shit done. A lot of them are very much worth learning and solve many problems. So much for the "useful" part.
But what use is a powerful abstraction without usage examples and guidance to use it? And what use is an abstraction that is just not there yet? Or if it is hard to learn the correct abstractions for certain problems, because there is no guidance about that? The lack of examples in many Haskell libraries and projects is striking and I usually resort to working through similar libraries to see how they are doing it.
My problem are not the paper-writing academics, but those that should do the footwork and make their knowledge and brightness accessible to others.
As always, its a combination of many factors.
Also, don't overinterpret words: I never said that Haskell is not useful for getting things done (some things just work tremendously well!). Its just that guidance on practical problems is hard to come by, even if the abstractions fit. Thats why I think that Real World Haskell is such a strong book, because it actually provides that.
None of what you wrote contradicts that examples could be given in the docs.
But defending the lack of documentation kind of shows why haskell will not see much adoption.
Also, rust for example is much more rich when it comes to examples in docs and rust people could also argue to not provide docs because of type signatures. They just decide to provide documentation and succeed in attracting people.
I taught myself Haskell because people say it improves you as a programmer. I didn't see that, but I have a math PhD so maybe I'm just too familiar with abstract types to gain new insight from Haskell.
As a language, it's sterile. You can tell it was designed by committee.
I have in most years learned some nicher languages: Elm, Rescript, Racket, Common Lisp.
But nothing is even remotely bad as Haskell is.
Even just setting up an IDE to have basics like syntax highlight or go to definition is a giant chore.
On the official Haskell devcontainer offered by GitHub is nearly impossible to add any external dependency, so having a one-click shareable Haskell environment in the cloud (the very basic to onboard people on the language without wasting them days into having their own inconsistent environment) is a must.
Another thing that I feel sucks is the default documentation for Haskell libraries. Doesn't say anything useful at all, bundles few definitions here and there, 0 examples, and more often than not there's 0 documentation.
On the one hand, the parent's comment is certainly hyperbole.
On the other hand, it's also the case that too any Haskell projects are under-documented. Probably worse than the typical language, and certainly worse than the best-in-class.
On the gripping hand... while types make poor documentation, they are always correct documentation, and they are automatically generated documentation. When I write Python or (apparently) Common Lisp, I can expect to get reasonable documentation by interrogating anything someone hands me. In Haskell, insofar as I have learned to get good information from the types, I get some (correct!) documentation for things that I have newly assembled myself!
Yes, Haskell is missing tutorials, how-tos, stuff that make those more complex concepts easier to understand.
As an example, the single kind off complex library I created (called "interruptible") is still lacking a good explanation of what it is good for, because despite having created it to solve a specific problem of mine, I still could not find a good way to explain it.
Somewhat off topic: My problem with Haskell is that every time I've tried to read the documentation, I've felt like I needed a PhD in type theory to understand all of the terminology. As a practitioner (not a researcher), I just want to know how to do things, but the documentation has always been a roadblock to me. So, after a number of attempts at learning to use Haskell, I've decided its not for me. Not because of the language itself, but because of the traditions around it.
A large part of this (and why you will find it hard to find Haskell developers who admit the state of the documentation is lacking) is that documentation isn't bad -- it's specifically apprentice-level documentation for specific libraries/use-cases that is bad.
In other words, journeyman users who are experienced in "following the types" will find plenty of really high-quality documentation. Total novices who need an introduction to the language will also find high-quality material (though this is more of a recent development).
However, once you're past the novice stage and at the apprentice level where you want to accomplish something specific using some libraries, there's nothing for you there. You have to ask someone at the next journeyman level to sit with you and guide you through following the types.
Why don't you argue against the points made in favor of Haskell in the article? You can probably tell more about why they use Haskell that way. It's certainly a better indication than your ridiculous TLD divination.
I mean that as a whole it's daunting and feels "unfriendly" to a lot of people. The heavy use of operators is part of it, but it's more than that. Haskell gets really abstract, which is cool, but it's hard to think about. Like I said, even monoids and monads seem hard to people learning Haskell despite being really simple. And look at the FAQ on that Lens library — it's an abstraction on top of things that are already pretty abstract in Haskell to offer "a vocabulary for composing them and working with their compositions along with specializations of these ideas to monomorphic 'containers'". That's cool and I really don't mean to criticize it, but it's undeniably esoteric and abstract.
Haskell is fantastic. In fact, it is by far my favorite language. Strict types and functional programming come together in a perfect union. Monads are very similar to JavaScript callbacks, actually. After extensive use of the language, I finally decided to give it up for 2 reasons. 1) Stack and package management. Specifically, after building many websites with Haskell's "supposedly" production ready framework, Yesod. After an upgrade, every site I made completely broke and there was almost no documentation on any version changes for this framework. Which leads me into complaint 2) Lack of good documentation. I'm not trying to take sides on the debate of self documenting code, however, when using higher level libraries, it is completely infeasible to rely on reading source code to determine what a function does. Haskell programmers believe that because of such strict typing, the code should speak for itself. Unfortunately, the real side effect of this is you end up coding trying to match up your types instead of focusing on your goal at hand.
I was considering writing roughly the same thing you did, thanks. There's a lot of terrible documentation in every language, but I think it may be a losing battle to show this as a counter example unfortunately.
I think it's just that the gap to get proficient with Haskell for an imperative programmer is a hurdle they are blind to (I was blind myself!), and they assume a few simple tutorials will bootstrap them into the language like it did the other handful they learned.
This is clearly an education problem, but I guess we still have a ways to go to get acceptance.
I think you missed the point. Haskell, keeping up with research, allows for further research. That research allows you to explain your ideas better and explore. It could save you refactoring time if you could explain it right the first time.
But when it comes to CL, he has expectations:
>I’ve opened an issue on GitHub of one quite popular library, asking the maintainer to write documentation, but after 6 months it’s still not written (strange, right?).
reply