Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

Post reply on HN
Print view View original

51–60 of 322 posts

Re: Pain Points of Haskell

#51

Post by pdimitar »

bjz_ wrote: post #42
pdimitar wrote: post #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 messag…

> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…

I got told some months ago to look for these docs: https://news.ycombinator.com/item?id=22395595

It seems all we want can be made to work but it does require some tinkering and being aware of the tools' options.

Re: Pain Points of Haskell

#52

Post by ghostwriter »

bjz_ wrote: post #42
pdimitar wrote: post #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 messag…

> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…

> Really hoping OCaml and Haskell can improve their package management story - they are getting there, but it still holds me back from really using them on a daily basis.

Cabal 3.x with Nix-style buildscovers all packaging needs that I ever had with Haskell ecosystem[1]. And there's a new wave of tooling based on incremental Nix builds, that you can begin using today [2]

[1] https://cabal.readthedocs.io/en/latest/nix-local-build-overv...

[2] https://github.com/nmattia/snack

Re: Pain Points of Haskell

#53

Post by ghostwriter »

> 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

Re: Pain Points of Haskell

#54

Post by johnday »

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.

Re: Pain Points of Haskell

#56

Post by rednum »

SeanDav wrote: post #43
rednum wrote: post #6

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-techni…

You seem to be disagreeing with the OP about how to explain Monads, yet the link provided by the OP is referred to as a "non-explanation". It is true that Monads are a pain point in Haskell. They are extremely powerful but not easy to grok, even by some very smart programmers. Quote from main article about Monads: > "Monads.....Despite many attempts though, I don’t think we have yet found the best way of explaining w…

To rephrase what I mean: I disagree with the idea that we can explain all technical concepts in non-technical way, which OP seems to support. I don't think we can get much better with teaching monads than providing actual formal definition plus motivating examples. I simply believe monad is too abstract and we can't have a nice analogy similar to the one OP provides ("Functors can be broadly explained in terms of containers..."). In my opinion the "platonic ideal of a monad tutorial" is more or less the (semi) formal definition of monad + some motivating examples. This is also something that cannot be understood if you don't have proper background (which is understanding simpler typeclasses like monoid and functor).

I also would not call monads a pain point to be fair.

Re: Pain Points of Haskell

#57

Post by ghostwriter »

spekcular wrote: post #5

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

In what scenarios does it make hard to reason about those complexities?

I find GHCs profiler statistics clear and meaningful[1], I lack the efficiency of its reports in other environments I work with, namely Python.

[1] https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: Pain Points of Haskell

#58

Post by ghostwriter »

yaantc wrote: post #46
vkazanov wrote: post #41

Earlier quoted context omitted.

Oh-h-h-h... I've heard this so many times before :-)

This time is different ;) Look at the end of the GP link on multi-core Ocaml progress report: everything under the "OCaml" title is work on the upstream compiler. It's still limited, but the upstreaming process has started.

Having an SMP compiler/runtime is half of the story, the other half is safe parallelism. I expect another decade is going to be spent on chasing bugs due to mutable data escape hatches in OCaml world.

Re: Pain Points of Haskell

#59

Post by lmm »

gridlockd wrote: post #45
lmm wrote: post #22

Earlier quoted context omitted.

If the compiler finds problems that you'd otherwise need a test suite to catch, then as long as the compiler is faster than that test suite you still come out ahead.

If the compiler is slow, I feel unproductive. I need to try out things quickly, I need to iterate. The bugs don't matter at this stage.

You may not need a full compile for that though. Some combination of incremental compilation, non-optimising compiles, or a presentation compiler / typechecker only can be enough to iterate with.

Re: Pain Points of Haskell

#60

Post by bjz_ »

ghostwriter wrote: post #52
bjz_ wrote: post #42

Earlier quoted context omitted.

> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…

> Really hoping OCaml and Haskell can improve their package management story - they are getting there, but it still holds me back from really using them on a daily basis. Cabal 3.x with Nix-style buildscovers all packaging needs that I ever had with Haskell ecosystem[1]. And there's a new wave of tooling based on incremental Nix builds, that you can begin using today [2] [1] https://cabal.readthedocs.io/en/latest/nix…

Yeah, it's really great to see the progress there. However, afaik, it still doesn't freeze packages by default, or let you have multiple packages of the same version in a dependency tree[1]. The former can be worked around, but it's annoying that it's not the default. The latter is more frustrating however!

[1] https://news.ycombinator.com/item?id=23454711

Post reply on HN