4 ms·

You keep repeating the claim that `stack` exists in order to solve a problem deliberately created by the FPComplete crowd. This is frankly a really disturbing l

You keep repeating the claim that `stack` exists in order to solve a problem deliberately created by the FPComplete crowd. This is frankly a really disturbing lie that has nothing to do with reality or the actual order of events. The theory that upper bounds should be eliminated - which was, I think, no good - is demonstrably independent of the FPComplete people. The theory of extreme restriction of bounds, the theory of eliminating upper bounds, and the existence of stack, stackage and so on are founded on real and genuine problems that arose with the appearance of immense builds like pandoc and especially yesod. I didn't particularly care for the stack business when it came along, but this is because I understood `cabal-install` pretty well, and still prefer it, but more importantly because I wasn't engaged in professional development that involved the co-operation of e.g. 100 Haskell packages - though I did spend countless hours helping new users get around the build problems with yesod and the like. It just is a fact that `cabal-install` was not ready for the existence of the phenomenon of the immense industrial Haskell build.

MustardTiger 10y ago
>The theory that upper bounds should be eliminated - which was, I think, no good - is demonstrably independent of the FPComplete people. No, it is not. Every FP complete employee does this. All of their packages are missing upper bounds. They actively promote not using upper bounds, writing blog posts and reddit comments telling people to violate the PVP. Just because they are not the only ones who do it, does not mean it is "independent" of them. They do it without fail, and they promote doing it to others. >It just is a fact that `cabal-install` was not ready for the existence of the phenomenon of the immense industrial Haskell build. That is not a fact, it is a fiction. Cabal-install did and still does work fantastically for our immense industrial haskell builds. Just broken packages like yesod were problems. And they were not problems with cabal-install, they were problems with people not understanding the consequences of no upper bounds, and expecting things that can not be possible to "just work". Stack did not solve this problem in any way, it simply bypassed it by restricting the set of packages to one curated set of versions.
- massysett 10y ago
  So you maintain immense industrial Haskell builds, presumably for pay. Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. Yesod is not broken. It builds just fine using a sane build tool. Yesod does not become broken because you insist on using a tool that crafts arbitrary build plans.
  - MustardTiger 10y ago
    >Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. I have no idea how you came up with that absurd non-sequitur. >Yesod is not broken. It builds just fine using a sane build tool. Yesod does not become broken because you insist on using a tool that crafts arbitrary build plans. Nothing in that is accurate at all. There is nothing arbitrary about a cabal build plan.
    - massysett 10y ago
      Since Yesod builds just fine, explain how it is "broken"?
      - HaskellMuppet 10y ago
        The fallacy of that argument is assuming that tool X being able to build artifact Y means that X is "sane". The only thing this says is that tool X is able to build Y, nothing more and nothing less. For instance, I could easily implement a tool which is only capable to build `yesod`, and only `yesod`. Would that be a "sane" build-tool?
    - dllthomas 10y ago
      > > Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. > I have no idea how you came up with that absurd non-sequitur. You can dispute the accuracy, but "the PVP as written puts too much burden on maintainers" was a part of the justification at the time for removing upper bounds. See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102894.html https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... "As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach!" It was not a non-sequitur, but an objection to your assertion that there was no problem with the PVP.

MustardTiger 10y ago

>The theory that upper bounds should be eliminated - which was, I think, no good - is demonstrably independent of the FPComplete people. No, it is not. Every FP complete employee does this. All of their packages are missing upper bounds. They actively promote not using upper bounds, writing blog posts and reddit comments telling people to violate the PVP. Just because they are not the only ones who do it, does not mean it is "independent" of them. They do it without fail, and they promote doing it to others. >It just is a fact that `cabal-install` was not ready for the existence of the phenomenon of the immense industrial Haskell build. That is not a fact, it is a fiction. Cabal-install did and still does work fantastically for our immense industrial haskell builds. Just broken packages like yesod were problems. And they were not problems with cabal-install, they were problems with people not understanding the consequences of no upper bounds, and expecting things that can not be possible to "just work". Stack did not solve this problem in any way, it simply bypassed it by restricting the set of packages to one curated set of versions.

massysett 10y ago
So you maintain immense industrial Haskell builds, presumably for pay. Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. Yesod is not broken. It builds just fine using a sane build tool. Yesod does not become broken because you insist on using a tool that crafts arbitrary build plans.
- MustardTiger 10y ago
  >Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. I have no idea how you came up with that absurd non-sequitur. >Yesod is not broken. It builds just fine using a sane build tool. Yesod does not become broken because you insist on using a tool that crafts arbitrary build plans. Nothing in that is accurate at all. There is nothing arbitrary about a cabal build plan.
  - massysett 10y ago
    Since Yesod builds just fine, explain how it is "broken"?
    - HaskellMuppet 10y ago
      The fallacy of that argument is assuming that tool X being able to build artifact Y means that X is "sane". The only thing this says is that tool X is able to build Y, nothing more and nothing less. For instance, I could easily implement a tool which is only capable to build `yesod`, and only `yesod`. Would that be a "sane" build-tool?
  - dllthomas 10y ago
    > > Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. > I have no idea how you came up with that absurd non-sequitur. You can dispute the accuracy, but "the PVP as written puts too much burden on maintainers" was a part of the justification at the time for removing upper bounds. See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102894.html https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... "As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach!" It was not a non-sequitur, but an objection to your assertion that there was no problem with the PVP.