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

71–80 of 322 posts

Re: Pain Points of Haskell

#71

Post by runeks »

ghostwriter wrote: post #57
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/use…

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

I’m guessing OP is referring to reasoning about time/space usage by reading code, rather than by running the program.

Re: Pain Points of Haskell

#72

Post by runeks »

logicchains wrote: post #23
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

The -XStrict language extension is a lifesaver here, for when you want a language like Haskell but without lazy evaluation.

Except it only lets you define your own strict functions and data structures — i.e. you still need to consider laziness when using existing libraries.

Re: Pain Points of Haskell

#73

Post by danielscrubs »

barking wrote: post #2

Warning possible flamebait: could Clojure be the solution?

Correct me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time.

Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat the world.

Re: Pain Points of Haskell

#75

Post by ghostwriter »

runeks wrote: post #71
ghostwriter wrote: post #57

Earlier quoted context omitted.

> 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/use…

> In what scenarios does it make hard to reason about those complexities? I’m guessing OP is referring to reasoning about time/space usage by reading code, rather than by running the program.

This is not trivial in strict languages either, because implementation details of a particular language/library dictate the rules. For instance:

    l = list(range(N))
    for _ in range(M):
        x = list(l)
CPython will have MxN iterations (allocations?), whereas other languages/libraries where data is immutable may decide to optimise the list() constructor and return a reference to the same object when the input is an instance of a list.

In lazy-by-default languages I can at least rely on normal evaluation order.

Re: Pain Points of Haskell

#76

Post by runeks »

spekcular wrote: post #12
dunefox wrote: 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.

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

SPJ said laziness-by-default was a design mistake. I.e. he’d still want laziness in a future version of Haskell, but not turned on by default.

Re: Pain Points of Haskell

#77

Post by pdimitar »

ghostwriter wrote: post #49
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...

Sure, same as Erlang has "binaries" (which can be C strings or literally any binary data as you said) and Elixir built on top of that to give us UTF-8 strings. But, you know, only these two. No more.

I quite dislike when languages start choking me with analysis paralysis. There have to exist sensible defaults!

Re: Pain Points of Haskell

#78

Post by pdimitar »

ghostwriter wrote: post #58
yaantc wrote: post #46

Earlier quoted context omitted.

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.

This is my main worry about Multicore OCaml. You nailed it. There's a lot of legacy in the ecosystem -- which is not a bad thing at all! Many people appreciate stable environments and learn to circumvent their problems. All completely fine and we all do it.

But I worry that by chasing backwards compatibility and not just saying "guys, you need to modernise your libraries to do X and Y, otherwise you will never be Multicore OCaml-friendly" the maintainers will invite a lot of legacy cruft -- which will now be subtly broken -- that they will either have to fix themselves or just concede that it's impossible.

Then again, I suppose they don't want the Python 2 vs. Python 3 split (or Perl 5 vs. Perl 6 / Raiku; EDIT: It's actually "Raku" as a commenter below clarified). But I fear it will happen anyway due to the reasons above.

I very quickly fell in love with OCaml but eventually settled at Rust for these, and a few other reasons. It's an otherwise excellent language and has one of the most underrated compilers on the planet. It's a shame that it's moving so slowly... :(

EDIT: As for safe parallelism, here's what one of the maintainers said soon ago: https://news.ycombinator.com/item?id=22735176

It looks like they prefer to do the lowest level possible so people can build their own abstractions on top. Completely fair though, not criticising.

Re: Pain Points of Haskell

#79

Post by xrisk »

johnday wrote: post #54

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.

You can put it behind Cloudflare and it should provision a certificate instantly.

Re: Pain Points of Haskell

#80

Post by foldr »

One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution.

(I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)

Post reply on HN