8 ms·

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 rea

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.

sdegutis 8y ago
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.
- KirinDave 8y ago
  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.
  - hhmc 8y ago
    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.
    - gizmo686 8y ago
      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 https://wiki.haskell.org/Numeric_Prelude
    - KirinDave 8y ago
      I'm curious what languages do it better. I'm looking for something new to learn.
  - TheCoelacanth 8y ago
    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-about-lazy-i-o https://stackoverflow.com/questions/5892653/whats-so-bad-abo...
    - KirinDave 8y ago
      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.
      - sdegutis 8y ago
        By saying "algorithmic," I used the wrong word. Lazy IO is a great example of what I meant.
        KirinDave 8y ago
        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.
- mwerty 8y ago
  Could you give examples of algorithms done wrong?
- deleted 8y ago
  [deleted]
- gowld 8y ago
  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.
seanmcdirmid 8y ago
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.
- gowld 8y ago
  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?
  - wbillingsley 8y ago
    More often, you do have a use case, you just don't quite know what it is yet.

sdegutis 8y ago

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.

KirinDave 8y ago
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.
- hhmc 8y ago
  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.
  - gizmo686 8y ago
    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 https://wiki.haskell.org/Numeric_Prelude
  - KirinDave 8y ago
    I'm curious what languages do it better. I'm looking for something new to learn.
- TheCoelacanth 8y ago
  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-about-lazy-i-o https://stackoverflow.com/questions/5892653/whats-so-bad-abo...
  - KirinDave 8y ago
    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.
    - sdegutis 8y ago
      By saying "algorithmic," I used the wrong word. Lazy IO is a great example of what I meant.
      - KirinDave 8y ago
        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.
mwerty 8y ago
Could you give examples of algorithms done wrong?
deleted 8y ago
[deleted]
gowld 8y ago
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.

seanmcdirmid 8y ago

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.

gowld 8y ago
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?
- wbillingsley 8y ago
  More often, you do have a use case, you just don't quite know what it is yet.