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

41–50 of 322 posts

Re: Pain Points of Haskell

#41

Post by vkazanov »

spekcular wrote: post #36
wk_end wrote: post #33

Earlier quoted context omitted.

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/...

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

Re: Pain Points of Haskell

#42

Post by bjz_ »

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 - ie. it generates a lockfile by default, scopes packages locally to individual projects, and lets you use more than one package of the same version in the same project.

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.

Re: Pain Points of Haskell

#43

Post by SeanDav »

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 what they actually are. "

and

> " The Wikipedia article has quite a good example of non-explanation."

Re: Pain Points of Haskell

#44

Post by logicchains »

js8 wrote: post #34

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.

Another happy user of classy-prelude here. It massively reduced the amount of imports I need at the top of every file.

Re: Pain Points of Haskell

#45

Post by gridlockd »

lmm wrote: post #22
gridlockd wrote: post #7

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

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.

Re: Pain Points of Haskell

#46

Post by yaantc »

vkazanov wrote: post #41
spekcular wrote: post #36

Earlier quoted context omitted.

Note that multicore OCaml is almost ready: https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...

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.

Re: Pain Points of Haskell

#47

Post by exdsq »

johndoe42377 wrote: post #31

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

What does this comment or linked article even mean? :D

Re: Pain Points of Haskell

#48

Post by dunefox »

spekcular wrote: post #28
dunefox wrote: post #19

Earlier quoted context omitted.

I'm gonna need a source for that.

The exact quote and source (powerpoint slides) are in this HN comment: https://news.ycombinator.com/item?id=1924061 . See also the insightful comment of plinkplonk on that thread.

That has to be the worst set of slides I have ever seen. Thanks.

Re: Pain Points of Haskell

#49

Post by ghostwriter »

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…

It is in your interest to have multiple string-like datatypes in a lazy language, especially when some of them are not real strings, but rather streams of binary data.

https://mmhaskell.com/blog/2017/5/15/untangling-haskells-str...

Re: Pain Points of Haskell

#50

Post by dan-robertson »

dunefox wrote: post #25
lmm wrote: post #20

Earlier quoted context omitted.

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.

Isn't there a compiler extension for hkt?

Not for ocaml
Post reply on HN