Hacker News Reader

Comment by gabipurcaru | Hacker News Reader

I think the main reason is that there is no _actual_ problem that OP needs to solve. If there was one, then he would get pragmatic and figure out one of the reasonable solutions to this and move on with his life.

Though it's true that Haskell is easy to put you into a mindset where you want to simplify and generalize the code as much as possible, leading to wasted time on overly general solutions. Which shouldn't be the case, because e.g. if you want to extend the solution from lists to traversables, Haskell gives you the confidence to safely refactor the method at a later time.

View on HN

There are some languages that tempt more abstract navel gazing than others. I’m not sure about Haskell, but Scala tends to do that. Anyways, there is something about human behavior and language design that can lead “more is less” situations.

If you don't have a use case creating a need that your program solves, what's the difference between figuring out make a zygohistomorphicanedoreticular for polynomials and writing a working library that no one uses? Either way, you do whatever is fun for you. If you have an actual customer requirement, then that guides your prioritization and attention?

More often, you do have a use case, you just don't quite know what it is yet.

I lost confidence in Haskell's ability to let me write something one way and safely refactor it later, when I found out that you can't use a ton of the algorithmic functions in the standard library because they do things all wrong.

What?

Other than strings desperately needing to be purged from the library, what are you talking about?

Haskell has some really solid standard libraries, and it's extended library set has some of the most sophisticated algorithms packages in the world.

I'm not the commenter you're replying to, but I've often found the Haskell numeric classes (Num, Fractional, Integral etc) prickly. The almost, but don't quite, map to (mathematical) algebraic structures.

Having use Haskell for math programming, I agree with this sentiment. Haskell's standard classes are in an uncanny valley of matching the mathametical structures.

If you want to do that sort of thing with Haskell, I would suggest switching to the numeric prelude [0]

[0] https://wiki.haskell.org/Numeric_Prelude

I'm curious what languages do it better. I'm looking for something new to learn.

A big one is lazy I/O[1]. It is really easy to mess up the order that operations happen in when using IO operations from Haskell's standard library. The non-standard library alternatives like conduits or pipes are more complex, but much harder to mess up.

[1] https://stackoverflow.com/questions/5892653/whats-so-bad-abo...

I agree lazy file I/O can be dangerous and needs to vanish, but I'm not sure this counts as an "algorithmic" complaint, which is what I was really curious about.

I also don't think you need Conduit or Pipes or any other performance destroying free Monad libraries to deal with it. My hot take: Conduit is in fact awful and radically overused and multiple superior options exist.

By saying "algorithmic," I used the wrong word. Lazy IO is a great example of what I meant.

I totally agree the prelude is full of cruft and needs to be scraped and redone fully. But the data structures libraries are all really good and if we could just pull in the succinct and unordered stuff, it's gone some of the best data structures a standard library can ask for.

Could you give examples of algorithms done wrong?

That sounds like the classic category of "I hate Haskell because in any other language* I know it's impossible to write a correct program so I don't care about being wrong, but Haskell tempts me into thinking it's possible to get it right."

Not counting obscure special-purpose langs like Coq.

Reply on news.ycombinator.com