Pain Points of Haskell(dixonary.co.uk)
dixonary.co.uk
Pain Points of Haskell
https://dixonary.co.uk/blog/haskell/pain
313 comments
As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned.
However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-technical way (as linked from the post) will always fail. It makes as much sense as explaining time signatures in non-musical terms, or a Banach space in non-mathematical terms. I've seen this sentiment recurring every now and then; it feels like some people really want to avoid formal definitions for the sake of it, even when formal definitions make things easier. When it comes to monads, I think you can't get any better than the semi-formal definition (typeclass with return and join) plus some motivating examples. For me looking at Reader/Writer/State helped get this; I agree with OP that List is kinda weird.
However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-technical way (as linked from the post) will always fail. It makes as much sense as explaining time signatures in non-musical terms, or a Banach space in non-mathematical terms. I've seen this sentiment recurring every now and then; it feels like some people really want to avoid formal definitions for the sake of it, even when formal definitions make things easier. When it comes to monads, I think you can't get any better than the semi-formal definition (typeclass with return and join) plus some motivating examples. For me looking at Reader/Writer/State helped get this; I agree with OP that List is kinda weird.
This is nice, and yet, not much different from what the Haskell community was dealing with 5 years ago. They are also mostly programming concerns, as opposed to engineering concerns.
How do you deal with simple things like exceptions and string interpolation? There are guides trying to explain monads, but no straightforward answer for dealing with these sorts of things, with building separate libraries / packages, setting up your own CI with your own stackage repo. And we haven’t gotten into production yet. The ecosystem doesn’t have these things built out, or, it’s just not documented/agreed upon so you’d effectively be starting from scratch.
While it might be nice to use Haskell for math-y things, in the end, you’d have to be able to instrument it, monitor/log it, etc. That doesn’t appear to be in place either. When I worked with Haskell last, these were all blockers.
How do you deal with simple things like exceptions and string interpolation? There are guides trying to explain monads, but no straightforward answer for dealing with these sorts of things, with building separate libraries / packages, setting up your own CI with your own stackage repo. And we haven’t gotten into production yet. The ecosystem doesn’t have these things built out, or, it’s just not documented/agreed upon so you’d effectively be starting from scratch.
While it might be nice to use Haskell for math-y things, in the end, you’d have to be able to instrument it, monitor/log it, etc. That doesn’t appear to be in place either. When I worked with Haskell last, these were all blockers.
This is a great post. However, there are so many more things that should be on here!
If I could suggest just one, it would be lazy evaluation by default, which makes it exceedingly hard to reason about time and space complexity.
Also relevant is the author's article on problems using Haskell on Arch Linux: https://dixonary.co.uk/cabal-2020
If I could suggest just one, it would be lazy evaluation by default, which makes it exceedingly hard to reason about time and space complexity.
Also relevant is the author's article on problems using Haskell on Arch Linux: https://dixonary.co.uk/cabal-2020
Linked page just says “something went wrong” at the moment; cache:
https://web.archive.org/web/20200608072453/https://dixonary....
https://web.archive.org/web/20200608072453/https://dixonary....
I would say all this is improving, and while these are all pain points, they are much less a pain point than they were just couple years ago.
My personal ergonomics improved when I ditched standard prelude for classy-prelude. Regarding Strings, I just use Text type.
My personal ergonomics improved when I ditched standard prelude for classy-prelude. Regarding Strings, I just use Text type.
The new improvements to Cabal have been super nice of late, but one thing I _really_ wish Cabal would do is allow for multiple versions of a library to be used in the same project. Having to satisfy a single library version is incredibly frustrating, and the solver errors are incredibly confusing. This is especially confusing when it complains about a library deep in your dependency graph being in conflict.
Ultimately the failure mode means that you can't build your package and are blocked until a fix is made upstream, where as with a package manager like Cargo you can still build your project. The downside is that you have a duplicate in your dependency graph - but this can be fixed upstream in an asynchronous fashion.
Ultimately the failure mode means that you can't build your package and are blocked until a fix is made upstream, where as with a package manager like Cargo you can still build your project. The downside is that you have a duplicate in your dependency graph - but this can be fixed upstream in an asynchronous fashion.
Thanks for hugging my site to death!
Note to admins: I've swapped it to Github Pages for the time being and the DNS change should propagate soon.
Edit: Github Pages doesn't support adding HTTPS to a newly added domain for some reason.
Note to admins: I've swapped it to Github Pages for the time being and the DNS change should propagate soon.
Edit: Github Pages doesn't support adding HTTPS to a newly added domain for some reason.
The complaint about records is interesting because there aren't that many major languages that actually do records well. For a language of its age, it actually does records rather well. People sometimes forget that Haskell is older than Java and like Java it has a ton of baggage from its early days.
The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using docker and hosting your own package mirror (as you should be for a professional deployment) it's perfectly serviceable.
The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using docker and hosting your own package mirror (as you should be for a professional deployment) it's perfectly serviceable.
One additional pain point for me is the number of symbolic operators. It’s hard to search for what some of them do, and even harder to have a conversation with a coworker when half your code is things like <$> or >>=.
While there are lots of benefits for choosing Haskell it is certainly not without its flaws as a development platform.
IDE has been my largest point of pain so far. I'm just used to a more interactive development experience, and sadly the tooling is just not there yet with Haskell. That said, there's great effort right now in that area so hopefully it'll improve.
On top of the broken record system, another annoying part is that the runtime monitoring and introspection story isn't so great compared to the likes of Erlang.
IDE has been my largest point of pain so far. I'm just used to a more interactive development experience, and sadly the tooling is just not there yet with Haskell. That said, there's great effort right now in that area so hopefully it'll improve.
On top of the broken record system, another annoying part is that the runtime monitoring and introspection story isn't so great compared to the likes of Erlang.
I've been doing professional FP work for 20+ years at this point. Haskell has community was the biggest killer for me. It was great when I made the jump from Standard ML to Haskell about 15 years ago. About 5 years ago I just couldn't stand what it had morphed into any longer - from the tension created by certain companies to well known community members who were just trouble for one reason or another. Instead of returning to Standard ML, I've been doing Ocaml for the last 5 years or so and couldn't be happier.
Surprised that no one mentioned what a headache arrays are in Haskell. First, there are several different libraries: Data.Array, Data.Vector, Repa, etc. Second, the syntax is very clunky, especially if you are using multidimensional arrays. It's a real shame, since most machine learning/scientific computing programs are very heavy on arrays.
> There is no featureful Haskell plugin for any major text editor which can be installed without command-line intervention
This is not true for at least a year already, as there's IntelliJ Haskell:
* https://github.com/rikvdkleij/intellij-haskell
* https://plugins.jetbrains.com/plugin/8258-intellij-haskell
This is not true for at least a year already, as there's IntelliJ Haskell:
* https://github.com/rikvdkleij/intellij-haskell
* https://plugins.jetbrains.com/plugin/8258-intellij-haskell
One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution.
(I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)
(I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)
I think Haskell would be the perfect language to write reference implementations in. I.e., stuff that gets spec'd out by committees like RFCs or Web technologies.
I personally don't understand the hangup on the existence of an IDE.
Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language server efforts in Haskell have yielded.
A (perhaps) valid criticism would be "the Haskell community has not done enough to make sure the language server is easy usable" - and I wouldn't even say that that was the case.
Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language server efforts in Haskell have yielded.
A (perhaps) valid criticism would be "the Haskell community has not done enough to make sure the language server is easy usable" - and I wouldn't even say that that was the case.
Does Cabal still have issues with multiple, conflicting versions of packages installed globally?
Stack's main advantage was that packages (essentially everything, including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.
Stack's main advantage was that packages (essentially everything, including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.
I would add a debugger to this list.
The one built into GHCi is the only working one I know of, and it has major failings (such as telling me that variables aren't in scope when they clearly are).
The one built into GHCi is the only working one I know of, and it has major failings (such as telling me that variables aren't in scope when they clearly are).
It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."
The community has different priorities than industry
The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.
Warning possible flamebait: could Clojure be the solution?
A lot of the other points could be addressed but the community's seeming unwillingness to tackle everyday productivity sends to me the message: "Keep out!". :(
As a comparison, Elixir's Mix and Rust's Cargo are amazingly ergonomic build systems and provide all the tooling you need to work with the languages and your projects.
And hey, don't kill me. As I said, I reviewed it casually for several days while comparing it with Rust and OCaml. They aren't the easiest to start with either but Rust's tooling is excellent, OCaml's is also excellent but not immediately obvious (their docs have improved a lot), and Haskell's is... kind of there, as the article points out.