Pain Points of Haskell
dixonary.co.uk
Pain Points of Haskell
1–10 of 322 posts
Re: Pain Points of Haskell
#2Warning possible flamebait: could Clojure be the solution?
Re: Pain Points of Haskell
#3Warning possible flamebait: could Clojure be the solution?
Solution to what exactly? Clojure is Lisp like jvm language with different characteristics.
Re: Pain Points of Haskell
#4Warning possible flamebait: could Clojure be the solution?
Scala
Re: Pain Points of Haskell
#5This 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
Re: Pain Points of Haskell
#6As 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.
Re: Pain Points of Haskell
#7The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.
Re: Pain Points of Haskell
#8Warning possible flamebait: could Clojure be the solution?
A solution to which of the listed pain points?
Re: Pain Points of Haskell
#9This 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
That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.
Re: Pain Points of Haskell
#10This 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
That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.
Then maybe an argument can be made that this should be front-and-center in the docs? (Note that I am not claiming anything though, haven't checked Haskell's docs in a while.)
It's also a surprise to me that you seem to say that OCaml is Haskell without the lazy eval being the default, mind expanding on that? Quite interesting.