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

21–30 of 322 posts

Re: Pain Points of Haskell

#21

Post by pdimitar »

dunefox wrote: post #18
pdimitar wrote: post #10

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

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.

Yeah, one of the things I dislike in it as well. UTF-8 should be built-in, not relied upon by libraries, even if they are commonly used by everyone.

Re: Pain Points of Haskell

#22

Post by lmm »

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.

Re: Pain Points of Haskell

#23

Post by logicchains »

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.

Re: Pain Points of Haskell

#24

Post by dunefox »

Gormisdomai wrote: post #11
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.

Can't it be both?

Sure, but I believe that Haskell is great just because it tries stuff that isn't in other languages, like laziness by default. If it's really a pain point you can always switch to Ocaml or others.

Re: Pain Points of Haskell

#25

Post by dunefox »

lmm wrote: post #20
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.

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?

Re: Pain Points of Haskell

#26

Post by logicchains »

dunefox wrote: post #24
Gormisdomai wrote: post #11

Earlier quoted context omitted.

Can't it be both?

Sure, but I believe that Haskell is great just because it tries stuff that isn't in other languages, like laziness by default. If it's really a pain point you can always switch to Ocaml or others.

Seems like an overreaction to suggest someone move to another language when there's a very simple solution to laziness in Haskell: the -XStrict language pragma.

Re: Pain Points of Haskell

#27

Post by logicchains »

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.

Compilation time generally isn't a problem if you work from the REPL (it's super-quick to reload the REPL after changing a file). The only time you pay for a full compile is for release.

Re: Pain Points of Haskell

#28

Post by spekcular »

dunefox wrote: post #19
spekcular wrote: post #12

Earlier quoted context omitted.

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

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.

Re: Pain Points of Haskell

#29

Post by ulrikrasmussen »

bjz_ wrote: post #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. 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 dependencies from dependencies that are exposed in the API of the package?

Re: Pain Points of Haskell

#30

Post by thepratt »

bjz_ wrote: post #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. Ultimatel…

Using bazel as a build tool (on top of cabal) allows you to provide patches or modifications to found versions.
Post reply on HN