So, you wanna to shit on Haskell as part of your virtue signalling?
Here, bro, try to argue like a man.
https://karma-engineering.com/lab/wiki/FirstPrinciples/Haske...
Pain Points of Haskell
31–40 of 322 posts
Re: Pain Points of Haskell
#32Linked page just says “something went wrong” at the moment; cache:
https://web.archive.org/web/20200608072453/https://dixonary....
Re: Pain Points of Haskell
#33Earlier 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.
They're similar but not really the same. The big differences are:
* Haskell is pure whereas Ocaml is not
* Haskell has a great story for parallelism whereas Ocaml does not
* Haskell has ad-hoc polymorphism (via typeclasses) whereas Ocaml does not
* Ocaml has an exceptionally powerful module system whereas Haskell does not
Re: Pain Points of Haskell
#34I 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.
Re: Pain Points of Haskell
#35The 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?
When Template Haskell or multiple packages join the fray, compilation times can get quite high, quite quickly. This is more an experience with stack, as there are means for incremental caching to avoid full rebuilds when a top-level change is made - nix-build and bazel being a few.
It doesn't help that sometimes stack can't tell if it should rebuild TH or not - a long standing bug.
Re: Pain Points of Haskell
#36Earlier quoted context omitted.
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.
They're similar but not really the same. The big differences are: * Haskell is pure whereas Ocaml is not * Haskell has a great story for parallelism whereas Ocaml does not * Haskell has ad-hoc polymorphism (via typeclasses) whereas Ocaml does not * Ocaml has an exceptionally powerful module system whereas Haskell does not
Note that multicore OCaml is almost ready: https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...
Re: Pain Points of Haskell
#37The 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. Ultimatel…
I agree that this is a pain point. I not familiar with Cargo and would like to know how this actually works. Don't you risk binary incompatibility issues because the same symbols are occupied by different versions of the same package? For example, what if my package depends on A(v1.0) and B, B depends on A(v2.0), and furthermore B exposes a type from A(v2.0) in its API? Does the package manager distinguish internal d…
I think Rust gives the symbols unique hashes for each crate version to avoid this. See this answer on Stack Overflow for more information: https://stackoverflow.com/a/51722134 - not sure if there is a better reference document though.
You sometimes get weird errors like expected `A` but found `A` in the unusual event that you actually run into this, but this is probably something that could be fixed.
Re: Pain Points of Haskell
#38The 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. Ultimatel…
Using bazel as a build tool (on top of cabal) allows you to provide patches or modifications to found versions.
What happens if you are building a library that is published to Hackage?
Re: Pain Points of Haskell
#39Earlier quoted context omitted.
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.
They're similar but not really the same. The big differences are: * Haskell is pure whereas Ocaml is not * Haskell has a great story for parallelism whereas Ocaml does not * Haskell has ad-hoc polymorphism (via typeclasses) whereas Ocaml does not * Ocaml has an exceptionally powerful module system whereas Haskell does not
I've heard it best as: both Ocaml and Haskell are pure functional languages. Haskell is Extra Virgin.
That said, the notion of purity is a bit BS. At some point in your program you are definitely going to invoke the world-at-large. Whether you do it through IO(), tap your nose and call it "pure" or you do it other way is all down to semantics (not in the PLT sense of the word - the PLT term to use would be "pragmatics"). The core of both Ocaml and Haskell are pure functions.
Also, Ocaml doesn't really need typeclasses. Modules. Modules are everything
Re: Pain Points of Haskell
#40Earlier quoted context omitted.
I agree that this is a pain point. I not familiar with Cargo and would like to know how this actually works. Don't you risk binary incompatibility issues because the same symbols are occupied by different versions of the same package? For example, what if my package depends on A(v1.0) and B, B depends on A(v2.0), and furthermore B exposes a type from A(v2.0) in its API? Does the package manager distinguish internal d…
I think Rust gives the symbols unique hashes for each crate version to avoid this. See this answer on Stack Overflow for more information: https://stackoverflow.com/a/51722134 - not sure if there is a better reference document though. You sometimes get weird errors like expected `A` but found `A` in the unusual event that you actually run into this, but this is probably something that could be fixed.
Thank you for the link, that clarified it for me. It seems that it requires compiler support to do it in the same way as Rust does it, but I like that approach better than complicating the package definitions with two types of dependencies.
Reading that post also reminded me of the Unison language [1] which would even allow the same type from different versions of a library to be identified as the same if it wasn't altered. It does this by identifying every type and function by the hash of their respective definitions.