Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

11–20 of 322 posts

Re: Pain Points of Haskell

#11
post #9

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

That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.

Can't it be both?

Re: Pain Points of Haskell

#12
post #9

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

That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.

IIRC, even Simon Peyton Jones has stated lazy evaluation was a design mistake.

Re: Pain Points of Haskell

#13
post #9

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

That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.

Recursive Big O that isn't defined until runtime is not usually considered a good thing.

Re: Pain Points of Haskell

#14

The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.

I'd say it is at least twice as fast as Scala, and faster than Swift in compilation time.

Any besides OP that experienced slow Haskell compilations?

Re: Pain Points of Haskell

#15
post #2

Warning possible flamebait: could Clojure be the solution?

I’m a huge Clojure fan, but I don’t think so. They are very different languages with fundamentally opposed opinions on the use of static vs dynamic types, for example.

Re: Pain Points of Haskell

#16
As a guy who casually (definitely not in-depth) reviewed working with Haskell about 2 years ago I'd say the most relatable part of the article to me is: complexity in tooling and unnecessary tension when working with libraries. Also the String situation (several types of them).

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.

Re: Pain Points of Haskell

#17
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.

Re: Pain Points of Haskell

#18
post #9

Earlier quoted context omitted.

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.

From what I've seen of Ocaml it's similar but with strict evaluation. Then again, it has no support for unicode strings so I never really looked at it again.

But algebraic data types, exhaustive pattern matching, and modules make it the next best thing, I think.

Re: Pain Points of Haskell

#20
post #9

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

That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.

I want higher-kinded types (heck, I want kind polymorphism) though.

Hopefully Idris will become production-ready and I'll have the best of all worlds, but that's a way away.

Post reply on HN