1. 14

  2. 8

    As someone making a product with a Haskell backend I have a lot of opinions here. There is a tremendous amount of power and safety in a strong, descriptive, type system and modern code generation techniques. I’m deep in the Haskell community and quite happy with Haskell. At the same time users pay for these benefits every step of the way - it’s trailblazing (or more negatively phrased, bushwhacking) with each step and that does hurt.

    Some examples of bushwhacking: Working with a database other than the top three SQLs will very likely require you to write your own bindings. Same with interacting with other SaaS services like New Relic. Use of a large swath of existing libraries likely means you’ll be the only production user of some of them. Cached build require you to invest in a Shake cloud or Nix build system because neither stack nor cabal do cached builds right (yet).

    More on the topic - this very old post has it right that getting to a functioning point takes too much effort. Things can and should be easy. Python libraries are made so users can get a complex task done with ease while Haskell libraries are made to be fully generic and keep the most options open to users. This isn’t a language issue but a culture issue and we must learn to change.

    1. 6

      What is in this that is not either out-of-date or hasn’t been rehashed endlessly at this point? As of May 2020 Is there any new insight to be gained in talking about how math-y and hard Haskell is, or framing Haskell vs. Go as The Right Thing vs. worse-is-better? And finally, do we have to take terribly conceived-of diagrams seriously if the author self-identifies as a “Haskell ninja?”

      Plenty of people are writing Haskell and using it in production or for their hobby projects. Stack and cabal and nix taken as a whole have made major inroads into dealing with “cabal hell” (or “DLL hell” as this piece calls it). Go continues to be both decidedly mediocre and inflexible, easy to pick up, and more popular than ever. Haskell remains pretty different from a lot of other languages and has a steep learning curve. News at 11

      1. 5

        Since 2011…? Off the top of my head, as a casual (and no-longer-zealous) Haskell user:

        • Space leaks are still a serious and deep-rooted problem. Better tooling to deal with them now exists, though.
        • There are now two major package management systems, not quite compatible with each other, and a fair amount of lingering ill-will from the split. Three if you count Nix.
        • Hackage is kind of like NPM: tons of low-quality and half-finished libraries with no easy way to find the good ones.
        • The proliferation of language extensions has fragmented the language even further, and many local dialects have emerged. Libraries can be inscrutable. Reminds me of C++.
        • Learning curve steeper than ever. Plenty of beginner books of dubious quality. Plenty of academic papers pushing the state of the art in FP. Not much in the middle.
        • Culture still largely privileges cleverness “elegance” above practicality. Oh, academia.

        So, overall, I think the post isn’t exactly a brilliant epiphany, but presents a fairly even-handed perspective, and has aged pretty well. You might have seen these points rehashed endlessly, but I don’t think everyone on Lobsters has.

        The language itself has many great points, certainly rewards the effort put into learning, and for a few domains it’s by far the best choice despite these drawbacks. I wouldn’t fault anyone for not wanting to use it, though, especially if they’re not in one of those domains. Go or something else might very well be a better choice, especially if you need to hire.

        The community, as such, is kinda bleh in my highly subjective opinion, but hardly the worst. Hard to climb that steep curve without engaging with the community. Might just be my perception, but it seems net language snobbery has increased along with industrial uptake. The established academic users are as magnanimous as ever, but now surrounded by a rising population of younger, more competitive and hungrier users, some of whom are maybe just a little insecure about the secret-weapon superpowers they haven’t quite mastered.

        1. 1

          I was objecting to the context-free drive-by posting of an old, fluffy, somewhat out-of-date article on a topic that is already discussed a lot here, or at least feels that way to me. I don’t necessarily disagree with any of your points but they weren’t raised in the piece and only seem to be relevant because they are criticisms of Haskell, of which there are plenty to go around. It doesn’t seem like you or other posters are responding to my actual comment, and more disappointingly it seems like my comment has become yet another excuse for some to go off on negative rants about Haskell. Damned if I do, damned if I don’t…

          1. 1

            Submitter here. I checked to see if this had been submitted before posting, it had not.

            I found it via the author’s Ninja piece, linked here earlier.

            I was interested to see what the Lobste.rs community had to say about this piece, 9 years later.

          2. 0

            edit: forgot the quote that triggered this… well quasi-rant. I think it’s related to the perception of secret-weapon superpowers that people seem to have about Haskell. I used to think Haskell was Superman: An alien from another world that has all of these incredible powers that other mere earthlings cannot achieve. Now I think it’s more Batman.

            The established academic users are as magnanimous as ever, but now surrounded by a rising population of younger, more competitive and hungrier users, some of whom are maybe just a little insecure about the secret-weapon superpowers they haven’t quite mastered.

            I keep finding myself looking for a nice, cozy functional language to roll around in. Every time I look I hear people speak of the beauty and elegance of type systems, or the lack of side effects, or laziness, and it all sounds just so magical!

            Often I sit down to start with one of these languages and immediately find myself a bit lost in the syntax. It’s not the mathy parts - it’s the quirks of how the language changes the names of common things.

            Let’s use an intro CS example:

            • putStrLn (Haskell)
            • IO.puts (Elixir)
            • text (Elm)

            Yeah, you can probably guess what these things do. Yet how many of them would you guess on day 1 of switching to that language? How many computer science, or even basic programming courses start with a language that uses anything except a variant of “print”? (Before you go “MIT with Scheme!”, they’ve switched to Python.)

            There’s a thing authors do when they’re trying to immerse you in a world that is supposed to feel alien, and that’s changing familiar things to make them feel unfamiliar. That’s fine and all, but not particularly accessible. I’m not looking for some unique, immersive experience, I’m looking to get stuff done. I get it: It’s not a line printer anymore. The save icon is still a floppy disk though, and the idiom of “Print” is well established and has been for like decades now.

            1. 2

              Uuhh print and putStrLn are two sides of the same coin, normally I’d use print since it has the more flexible signature (Show a => a -> IO () vs String -> IO ()).

              So in haskell print = putStrLn . show, a dsitinction is drawn, but it’s not missing.

              1. 1

                TryHaskell Haskell.org shows putStrLn first, and you have to dig into the I/O functions to find print.

                In the Haskell wiki, they even call the action of putStrLn printing, then switch to print later on without explaining it. Clear as mud. OK, so let’s play with some output to see if we can figure it out.

                Prelude> putStrLn 4
                error: No instance for (Num String) arising from the literal ‘4’ 
                Prelude> putStrLn "4"
                Prelude> putStrLn "四"

                Got it. Integers aren’t strings, so that no worky. OK, so print = putStrLn . show.

                Prelude> print 4
                Prelude> print "four"
                Prelude> print "四"

                Wait, what happened to that last one? Why wasn’t it "四"? Well, it turns out that Show’s signature is show :: a -> String, but the devil’s in the details. The byline is “Conversion of values to readable Strings.” but the detail is that show outputs syntactically correct Haskell expressions, not plain strings. For some reason, this means I get the quotes around the string (even though they’re not part of the string) and a conversion of UTF-8 to a string of the code point rather than the character itself.

                Everything fed into show keeps its types though, right?

                Prelude> show [1,2,3]
                Prelude> show ["a","b","c"]
                Prelude> show ['a','b','c']

                Wait, what? Ohhhh, strings are just a list of chars in Haskell, and they get auto-converted to a string, losing their “listyness” for basic output.

                Just for giggles, let’s try something similar in python:

                >>> print (4, "four", "四")
                4 four 四
                >>> print([4, "four" , "四"])
                [4, 'four', '四']
                >>> print(['f', 'o', 'u', 'r', '四'])
                ['f', 'o', 'u', 'r', '四']

                Yup. Looks like what I asked it to print alright.

                1. 2

                  Fair point. I suppose if you use Text and OverloadedStrings maybe print would have behaved better but these are indeed not very good defaults.

                  1. 1

                    Most people would probably just shrug at it and keep coding, in all fairness. Haskell is far from the only language with that weirdness too! It just seems so unnecessary, and so prevalent in the popular functional languages.

                    1. 1

                      Yes but it was designed by a comittee decades ago so in my mind it gets a pass on some of these legacy papercuts. In return I get a rock-solid language with lots of mature libraries.