Since it is a common question in such statements, let us ask it directly here: why create a new website instead of working to incrementally update haskell.org? In the opinion of the team behind haskell-lang.org, the tooling story and general ecosystem infrastructure for the Haskell community has accumulated enough baggage that a clean break is the best use of everybody's time. We intend to streamline the on-boarding process for new developers, move away from infrastructure that is showing its age, and embrace newer approaches to facilitate open collaboration. Similar decisions have already been made in creating the Stack build tool and Stackage.
Exactly. At this point I really wish the FP complete people would just fork GHC and get it over with. They've been such a huge problem in the haskell community, just divide it up already.
A huge problem? Could you give an example of the sort of problem they are causing?
Maybe I am out of the loop but from my perspective as a hobby coder FP complete (particularly snoyberg) has done nothing but put out extremely useful code. Most notable of which stack which is (going to be) the defacto standard for deploying Haskell applications.
Yup. Stack was born out of our internal build tool "fpbuild". We found that having a good build tool was crucial to our productivity. Stack was created to better satisfy our own needs, and we shared it with the community so that they can also benefit from it and help make it better.
When someone's consistently had good contributions and discussion, we've granted them maintainer level privileges. Certainly quite a lot of stack's development and maintenance is done by FP Complete folks. However, our intention is to make the project as open to contribution and feedback as possible.
You can't deny there's pattern emerging of reinventing existing Haskell infrastructure under the pretense to "move away from infrastructure that is showing its age" rather than help improving the existing one
Moreover, this new tooling/services are operated and maintained by FPC employees which, quite conveniently, moves control away from the community board to FP Complete which by design has commercial interests at its heart.
I'm not saying FP Complete is doing evil things right now but this creeping shift of powers into the hands of a commercial entity is making me uneasy.
I've set up a few things using Stack, but as far as I can see there's nothing that would stop me just downloading the intended versions of GHC and the various needed packages from Hackage if Stack went away tomorrow.
Are other projects more tightly integrated in some way, such that backing out in the event of catastrophic failure of the Stack ecosystem would be unreasonably or prohibitively difficult?
Stack is a perfect example. The people involved have been the ones artificially creating the problem by refusing to follow established community standards (the package versioning policy), then they release a tool to "solve" the problem they created, all while spewing FUD about cabal and the actual haskell developers and community.
It's not just people at FP Complete `et al` who were frustrated with cabal-install. Cabal-hell was the number one problem with using Haskell for commercial projects, as a majority of people responded who took part in a FP Complete Haskell organized survey (this was before stack was officially released), https://www.fpcomplete.com/blog/2015/05/thousand-user-haskel.... I wrote that survey, if you want to discuss methodology I would be happy to. Anecdotally, after contacting by email most of the respondents, very few complained of a fragmentation the community by virtue of stack being released. We could argue all day over about arguments on reddit, but data suggests otherwise.
FP Complete is a commercial consulting firm now targeting life science companies. We use Haskell because we believe it is the best modern language for robust high-performance software. It is not our goal to own the Haskell ecosystem. It is our goal to promote Haskell use and to develop reliable tooling. Do people feel the same way about continuum analytics for releasing Anaconda and special versions of numpy?
That doesn't address what I said at all. People were not frustrated with cabal-install, they were frustrated with package installation errors, and blamed cabal-install and "cabal hell" (despite the vast majority of errors having nothing to do with cabal hell). But the actual problem is widely used packages written by FP complete people deliberately refusing to follow the PvP. Yesod was the biggest example, everyone complained about how impossible it was to install. We did not need a curated set of packages and a backwards package installation tool to solve that problem, we needed the yesod devs to follow the rules.
This is exactly what I mean. You create a problem, spread FUD about the problem, then "solve" the problem by conveniently trying to move everyone to your separate ecosystem and tooling.
This totally rewrites history. The idea of scrapping upper bounds was introduced by Brian O'Sullivan https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... whereupon it was adopted by yesod as you can see by comparing http://hackage.haskell.org/package/yesod-1.1.0 (before bos's verdict) and http://hackage.haskell.org/package/yesod-1.1.0.1 (after bos's verdict). If you study the cabal file for yesod 1.1.0 you will see that the method it employed then was extreme restriction of constraints. I don't use stack all that much, and certainly disapprove of omitting upper bounds, but the truth is, it was a chamber of horrors to get really large complex builds to work in those days. pandoc and yesod in particular were really hopeless, and one was constantly explaining to beginners how to get these things to work. Now these problems don't arise; if you are building something that will require 50 libraries to be installed, of course you use stack.
I would avoid any speculation into malicious and/or manipulative actions. Personally, I think PVP is a beautiful idea, but fails in practice. Even if you were correct in asserting that Yesod devs were intentionally polluting the waters by refusing to supply upper version bounds, such a fragile system clearly shouldn't be the tool of choice for Haskell. BTW, none of my issues with cabal stemmed from FP Complete packages. It was a widespread problem, and it's not spreading FUD to be outspoken about it.
People like you really raise the level of name calling to a whole new level. It's open source, people are free to choose what tool they wish to use, develop which tool they wish, and recommend which tools they wish. Believe me, FP Complete is not makings tons of profit in an attempt to convert everyone to Stackage.
It is absolutely spreading FUD to convince new users that simple problems they have are "cabal hell" and are best solved by switching to stack. And being open source does not make anything I said "name calling".
You sound like you have never tried to install any sizable haskell package ever... Cabal-hell was a very real problem, and an inordinate amount of time was spent by package maintainers to help people installing their packages, even on the IRC #haskell channel, cabal-hell questions would very frequently pop-up. Also, you FUD about Yesod is not true at all, they followed the PVP closely up until 1.1.0, as another commenter mentioned. Even with the PVP, you would basically have to nuke your cabal packages, or, when sandboxes finally came in cabal, you could use them.
Stack completely removes some very real problems with building packages.
Honestly, having read all your comments in this thread, you seem to be either a troll, or someone who clearly has no idea of the history of haskell tooling....
> It is FP Complete, a corporation attempting to subvert the haskell community for their financial benefit.
There are much, _much_ better and easier ways to make money than what you are suggesting.
The idea that they would produce and give away these tools that fix real problems (whether you want to believe it or not) just to somehow down the line subvert the Haskell community to financially benefit is just _absurd_. If this were a larger programming community I could possibly believe it, but Haskell? Which is mostly used by hobbyist? Come on.
Have they ever refused to merge a PR because they want you to pay for it? What evidence do you have for this _at all_?
>There are much, _much_ better and easier ways to make money than what you are suggesting.
So? By that logic FP complete would not exist. Yet they clearly do. Try emailing them, they are in fact real. Whether you think haskell is too small or not, the fact is they exist to make money on haskell.
>The idea that they would produce and give away these tools that fix real problems
The tool does not fix real problems. It avoids a real problem, which the authors of the tool created in the first place. The problem does not exist if packages use upper version bounds. They refuse to, and then release a tool to move people to a curated subset of packages and versions instead, bypassing the problem they've imposed on everyone in the first place.
>just to somehow down the line subvert the Haskell community to financially benefit is just _absurd_
It is not down the line, or somehow. It is right now, exactly as described.
>If this were a larger programming community I could possibly believe it, but Haskell?
Again, that logic makes no sense.
>Have they ever refused to merge a PR because they want you to pay for it?
What does that have to do with anything? How is taking control of haskell related to refusing to merge PRs without payment?
>What evidence do you have for this _at all_?
I explained it quite clearly. Your response is to say nothing that has happened counts because "it is haskell".
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.
>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.
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.
You should read up on the PvP before you comment on something you clearly don't understand well yet (unless you're knowingly misrepresenting the facts and using hyperbole on purpose in the interest of spreading FUD).
>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.
> > 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/...
"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.
> See, for instance, the following from someone with no connection to FP Complete that I'm aware of
You may be interested to know that Carter (the guy you're quoting) knows better today, and has even become a Hackage Trustee whose mission is more or less to uphold those very PVP upper bounds ;-)
Amusing, but orthogonal to my point, which was that the move away from parts of the PVP was motivated by real concerns, and moreover that the comment above was specifically an obvious reference to concerns that had been voiced during that time.
I am not arguing that the move away from the PVP was correct - I was uncertain at the time and I remain uncertain.
The concerns you're talking about here were primarily deficiencies in tooling, not an inherent problem with the PVP. Many of those deficiencies have been fixed (for example, --allow-newer) or there is work in progress that will fix them (cabal new-build, cabal.project files, etc).
Yes, people make mistakes. He no longer favors that approach, as he learned how bad it is. The difference is that FPC employees still continue to push it even when they know the problems.
You seem to miss my point. I am not arguing that the move away from upper bounds was correct - I was uncertain at the time and I remain uncertain.
My point was that the comment above was specifically an obvious reference to concerns that had been voiced during that time (and speculation as to why they might have been less relevant to you) - far from an "absurd non-sequitur."
>My point was that the comment above was specifically an obvious reference to concerns that had been voiced during that time
I am aware of that. And again, that in no way contradicts or discredits what I said. Which was that FP complete employees consistently do this. I never said they were the only people who do it. I never said they were the first people to do it. I said they do it. I really do not understand where the confusion is coming from.
You keep acting as if the only claim you've made in this entire discussion was that FP Complete employees do not include upper bounds. It's certainly not the case that anything we've been discussing has bearing on that. But that's not an honest characterization of your comments in this thread.
> The tool does not fix real problems. It avoids a real problem, which the authors of the tool created in the first place. The problem does not exist if packages use upper version bounds.
The implicit assertion in the following comments (which I found painfully clear, but maybe you genuinely missed it - surely we read from different contexts) was: Even if the tooling only solves a problem introduced by particular practices, it can be a "real problem" if those practices address a real problem themselves.
You are responding to a strawman, and still trying to pretend it has something to do with me. What I said is what I said, and is what I meant. What you wish I meant has nothing to do with me.
I am responding to what you wrote. I quoted it. If I am misunderstanding it, please explain how.
Or you know what, don't. I'm growing convinced that you're not engaging in good faith anywhere in this thread. And if this is going to be regular practice, please GTFO of the Haskell community.
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?
The question is historical. I think you can't have been making your immense industrial build in the years immediately preceding `Wed Aug 15 14:54:44 UTC 2012` when `yesod` signed on to Brian O'Sullivan's plan of omitting upper bounds throughout Hackage (a plan which on your view must itself have arisen from O'Sullivan's madness and incompetence or vested interest in a non-existent FPComplete that he never had anything to do with, since there was of course no problem at all, it was just a fiction he cooked up). `yesod`s 2012 act of compliance was on your view calculated by FPComplete (founded 2013) to take over Haskell by means of a then non-existent `stack` tool (2015). On that day, the installation of `yesod`, a perfectly innocent web-related library, required the installation of 145 distinct Hackage packages, as you can verify with a couple of commands. The previous record was held by the pandoc executable which in the form it took on that same fateful day (pandoc-1.9.4.2) required the installation of only 47 distinct packages. Yet in the previous years unlimited amounts of ink had been spilt on the pandoc list and #haskell explaining what was going wrong when pandoc users tried to build the newest version with the feature they had prayed for. With `yesod` things were now completely out of control. This had nothing whatsoever to do with `yesod` or anything else being in itself broken. `yesod` presumably did actually need e.g. `x509-validation` and `aeson-pretty`. Other packages went over to the plan announced by O'Sullivan too, though most of them reverted. --All of this, on your view, was part of a hostile take-over plan by the non-existent FPComplete. You are by the way of course benefitting from stackage in ways you are not recognizing, though, like me, you are not a regular stack user. It is very familiar that before stackage, there was much less coherence among the Hackage libraries. Things were best about one month after a new ghc was released.
I don't understand why you keep bringing up bos's question. How does one person wondering aloud if PVP is good or not make anything I've said inaccurate? As the bulk of your post is responding to a strawman you created, I'll allow you to provide the voice for it yourself.
It's clear that you weren't around then and don't have the historical knowledge necessary to have a view about this. This isn't stopping you from spreading absurd libels.
It is "clear" to you, because that is what you want to believe. You have no basis for that belief, it is incorrect and silly, but it makes you feel good because you think it allows you to dismiss what I said.
It is completely irrelevant to my argument. My argument is "FP complete employees do X". Saying "so do some other people" changes nothing, it is completely and totally irrelevant. "The sky is blue." "Well so are my slippers! HAHA I devastated your argument!".
That wasn't your argument at all. I know and constantly affirmed that many people do and have removed upper bounds, and that I myself oppose it. Your 'argument' is the absurd falsification that this practice was introduced to sell BSD3 software that appeared 3 years after the practice was introduced, by a company that appeared over a year after the practice was introduced. What you are doing is unconscionable and destructive.
>Your 'argument' is the absurd falsification that this practice was introduced to sell BSD3 software that appeared 3 years after the practice was introduced
I said nothing even remotely like that. Lying about what other people say is not constructive.
> The people involved have been the ones artificially creating the problem by refusing to follow established community standards (the package versioning policy)
and
> The tool does not fix real problems. It avoids a real problem, which the authors of the tool created in the first place. The problem does not exist if packages use upper version bounds. They refuse to, and then release a tool to move people to a curated subset of packages and versions instead, bypassing the problem they've imposed on everyone in the first place.
-- in fact they are no different from e.g. bos and amazonka and many many others; it's a view, we oppose it.
> then they release a tool to "solve" the problem they created, all while spewing FUD about cabal and the actual haskell developers and community.
Again it is demonstrable that they didn't create any problem. And they don't say anything against cabal that thousands of others didn't say. And on and on through your whole chain of nonsense.
Just give it up. They have a view we reject. The solution is to continue to argue against it .. keeping in mind that what we are asking for is torture to maintain even where you are dealing with only 10 external dependencies. It happens that I have just spent basically all morning dealing with dependency problems with four or five pipes-related libraries which keep rigorous upper bounds. Frankly it's unimaginable what yesod or amazonka would have to go through basically every morning with 10-20 times as many other-people's libraries to keep track of. There needs to be some automated way of doing it.
Your entire reply contains nothing of relevance to anything I have said. I do not see any way you can reasonably be just confused. It appears as though you are very deliberately dishonest. Please stop.
It's more subtle than that. Sure, Stack is OSS and all that. But Stack's developers have a vision of their own how Stack and Stackage (and by extension the Haskell ecosystem) are supposed to work. They may even make Stack rely on services controlled/hosted exclusively by FPC rather than a neutral entity. And they will reject feature-requests or PRs which don't fit their agenda rather than because you didn't pay them enough. As long as Stack doesn't add any essential functionality over Cabal which would make a package unbuildable with plain Cabal we're good.
Sure, I could fork Stack and implement features I consider important. But how do I get my Stack fork advertized on haskell-lang.org to reach as many people as possible?
You're implying everyone's equal. But the fact is that the haskell-lang.org team is made up almost exclusively high-profile Haskell developers who everybody knows already, including backing from a commercial entity which can promote it via their company site, as well as a book author who can promote haskell-lang.org via his new book. So while anybody could just do what the haskell-lang.org team did, it wouldn't have the same impact/effectiveness without a comparable endorsement.
So, some of the most high-profile Haskellers who have created vast amounts of Haskell software and documentation have started a new initiative and you, you're ... complaining?
I think the assertion is that these particular people have a privileged position primarily because of their high quality contributions to the community, and the argument is that this is fairly appropriate.
Since it is a common question in such statements, let us ask it directly here: why create a new website instead of working to incrementally update haskell.org? In the opinion of the team behind haskell-lang.org, the tooling story and general ecosystem infrastructure for the Haskell community has accumulated enough baggage that a clean break is the best use of everybody's time. We intend to streamline the on-boarding process for new developers, move away from infrastructure that is showing its age, and embrace newer approaches to facilitate open collaboration. Similar decisions have already been made in creating the Stack build tool and Stackage.