1. 31

  2. 15

    Somewhat controversially, I think stack and most libraries written by Snoyman comprise the bad parts of Haskell. Namely in that they tend have lots of brittle dependencies and complex APIs.

    1. 4

      I understand where you’re coming from, but the way I see this is that a lot of what Snoyman/FP Complete produces is hyper-focused on the problems that they deal with regularly, which are largely about writing web applications with a database backend, and in a specific way according to Snoyman’s experience writing Haskell. I haven’t done the work of investigating everything he’s pitching, but it does seem to me that he is pretty thoughtful about what he’s proposing, at least.

      As such I feel like it’s valuable to at least consider his perspective (if you are writing web apps in an industrial setting), even if you come down on the side of disagreeing with the choices he’s made. In a sense I feel like it’s a microcosm of Haskell, where the initial learning curve and amount of detail you have to absorb seems kind of high, but becomes extremely valuable once you’ve built up that intuition–if you’re working within the system he’s laid out.

      And I do also think stack deserves credit for pushing the Haskell community in a positive direction, even if I find some of the conversations around stack vs. whatever to be rather unnecessarily contentious (and only use cabal/nix myself).

      But, yeah, I think people can reasonably disagree about the value of his very opinionated approach.

      1. 6

        cabal-install was fairly new and the introduction of stack split the ecosystem. Now when you release a library you need to make sure it works with both. A split for something that core to a language has only done harm. I think backpack has made cabal-install much more reliable but we are still stuck with stack.

        There is another tendency of NIH with Snoyman/FP-Complete libraries but that’s not as a big deal since they are just libraries. I think there are better libraries for doing web development that aren’t so brittle.

        1. 7

          Backpack is a red herring, I think. Haven’t seen many libraries use it. Cabal’s v2-build commands (f.k.a. new-build commands, a.k.a. “nix-style local builds” (even though Nix isn’t involved)) have been an absolute godsend, fixing the old “cabal hell”, and removing the need for cabal sandboxes.

          I think stack gave cabal a kick in the pants to get moving, but these days I find it hurts more than helps:

          • It has a different and incompatible way to specify targets within a package (on the command line)
          • It has a different way to specify projects made up of multiple packages, so if you want “cabal people” and “stack people” to be able to hack on your project, you need to provide both
          • It has a nasty habit of wanting to rebuild entire packages if you breath on it the wrong way
          • casa.fpcomplete.com was on-and-off unreachable for a while, and this caused a bunch of CI failures
          • It adds extra fiddling if you need to pull in extra packages beyond an LTS package set
          • Many stack projects do not provide proper bounds for their dependencies, because they get them from LTS. This means that if they do end up on Hackage, you can get invalid build plans. I don’t like that the tooling uses other people’s explicit dependency bounds to create an environment where people don’t give back to the shared resource (the resource being: a shared Hackage where bounds are maintained and can be trusted)
          • hpack-by-default in the templates creates yet another reinvention of existing Haskell tooling. Again, this gave the cabal file format a good kick in the rear, but now we have common stanzas and backpack, there are things you can say in .cabal which you can’t say in package.yaml. This slows down the evolution of the cabal ecosystem.
          • In general, I think yaml is a terrible file format and the less people use it, the better.
          1. 5

            It feels a bit unfair to place the blame for difference between new-style cabal and stack purely with stack, given that stack was first to provide a usable interface. (I still find cabal very confusing to work with, probably largely because there’s both “new-” and “v2-” and old style commands in one package, combined with an entirely unclear versioning story on the cabal file format side. To the extent that nix becomes appealing…)

            Regarding versioning of packages, I feel like you’re very much discounting the positive aspect that stackage has on the consistency of hackage versioning. I’m positive that we’d be seeing far more version incompatibility and breakage if stackage maintenance wasn’t tracking and notifying maintainers about restrictive bounds, and pushing them to fix these lest they be dropped from stackage.

            Regarding YAML: Sure it has downsides, but are you seriously of the opinion that a bespoke unspecified format like cabal is better? As far as I can tell, there is no way to compatibly deal with cabal files without binding to the one cabal library. E.g. the guix hackage importer keeps having issues where weird cabal files can’t be parsed.

            1. 2

              Regarding most of your post: fair points.

              Regarding “new-” vs “v2-”: “v2-” is the same as “new-”, and as of cabal 3.0, the “unprefixed” commands are “v2-” (but you can call the old commands as “v1-” if you need them, for now).

              Regarding YAML: I don’t like any of the general-purpose formats (json, yaml, toml, …). Dhall might be a good fit, but obviously it didn’t exist at the time and it would make a big knot out of cabal’s dependency graph.

            2. 1

              Yea I totally agree with that.

        2. 3

          I disagree. For example, “unliftio” and “unliftio-core” have very reasonable dependencies and a much simpler api than monad-control. “warp” has a nice api as well.

          1. 1

            That’s fair. I like warp which I use a lot through scotty.

        3. 8

          Regarding sum/product, I recently saw this: https://mail.haskell.org/pipermail/libraries/2020-October/030862.html

          It seems like there’s a proposal to make sum and product strict. So perhaps some time in the future Haskell will have one less warts :)

          1. 8

            Yep’, and a merge request is in the works as well, so we’re pretty much done with that point. :)

            1. 2

              This seems to be some good improvements!

              Let’s hope that other programming communities (like Rust) can use this as a learning opportunity!

              1. 0

                sum product and fold are already strict in Rust.

                1. 1

                  I meant fixing things in general.

            2. 7

              I find this quite hilarious that the matter of sum and product is brought up in this article while I’ve been working towards fixing them. :)