1. 26
  1.  

  2. 8

    one of the authors here - this one was fun to write. after all, if you can’t find something to complain about in your favourite system, how well do you really know it…

    1. 6

      Please ask your coauthor to remove the bad link rel="canonical" href="https://lorepub.com" /> from his markup. :)

      1. 4

        done :)

        1. 4

          Should be fixed now.

        2. 3

          One heuristic I like is that you don’t really like something before you know one bad thing you get by using it and one good thing you lose by not using something else. Once you can rant about how terrible Haskell is and still choose to keep using it, then you know your love is genuine.

        3. 7

          I believe this is the proper link.

          1. 6

            This might be a good companion read http://dev.stephendiehl.com/hask/ A lot of us used Haskell 6-7 years ago and my perception is that it’s a lot different now.

            Also, some Haskell humor https://twitter.com/gabrielg439/status/701871069607505921

            1. 3

              I like Stephen’s work. Quite different, of course, in that he’s offering positive advice on what to do. We’re just mapping out the trapdoors and deadfalls.

            2. 6

              I am actually learning haskell these days.

              I regularly encounter a pitfall not listed here, it’s the non exhaustive patterns exception. And it seems I am not the only one struggling with that.

              This trap is not coming from any library but from a more general design mistake. How do advanced developers deal with that? Are you always writing a wildcard pattern match as a worst case scenario match? How are you reasoning in order to avoid this kind of error?

              Any kind of advice would help me here.

              1. 8

                Enable -Wall and fix all warnings whenever you compile. Use -Werror during development (Stack has a –pedantic flag for this) - don’t ship with the flag because you don’t know what additional warnings might get added in the next version of GHC.

                1. 6

                  Do you mean you’re accidentally writing functions with non-exhaustive patterns and getting exceptions at runtime from them? Turning on -Wall is supposed to make GHC warn you about every pattern match that isn’t exhaustive in your code.

                  Do you mean you’re running into cases where you’re using conditional guards and patterns and GHC can’t infer that all cases are covered because it can’t prove that at least one conditional must be true? You can usually restructure one or two functions so that you’re doing exhaustive pattern matches that are visible to GHC, e.g. replacing (x > y) or (x == y) or (x < y) with case compare x y of { LT -> …; EQ -> …; GT -> …; } as seen in http://stackoverflow.com/questions/10699532/why-is-ghc-complaining-about-non-exhaustive-patterns

                  edit: That’s only advice for “I missed a pattern because I forgot one”. General advice for avoiding non-totality to begin with, I’m less sure about. Mostly using Maybe to represent missing data explicitly.

                  1. 5

                    Excellent point - we thought about including this in the article, but as you say, it’s a design technique rather than a pitfall that’s already there in the libraries & base language, so we left it out. Maybe in another article, that one was long enough.

                    I would recommend -Wall and -Werror in development as puffnfresh suggests, and never using wildcard pattern matches: they seem like a good idea, but frequently, you’ll add new branches to sum types to represent some business logic, and you really want the compiler to tell you “hey, i don’t know what to do with this new branch”. It’s like a little todo list.

                    1. 4

                      Thanks!

                      The -Wall flag is really useful, great tip!