FWIW, I've tried to use stack twice and came back to cabal-install. There's also that I enable split-objects in ~/.cabal/config (not available in Stack) and often use GHC on platforms where there's no Stack-provided GHC available. That said, avoiding the compatibility problem of dependencies via curated package sets (Stackage) is a nice idea. However, Duncan's nix-local-build work makes the problems void from what I can tell, and Ed's Backpack work will improve the situation even more. Though, curated sets are still a nice idea regardless.
I'm not a Haskell greybeard, just a light user, but despite the improvements via FPComplete's output, at least some of it feels NIH and unnecessarily polarizes the community. For instance, reusing Shake in Cabal(-install) and getting nix-local-build and Backpack production ready look like improvements that will be beneficial for a longer time, rather than splitting the community with a different build/package structure (stack).
I mean, dividing the already small Haskell community doesn't make sense to me. If Gershom doesn't play fair with the management of www.haskell.org, this should be raised officially and fixed, because haskell.org is not a one man project and there's a team around it.
There is absolutely no truth to the assertion that the haskell.org management
hasn't played fair or listened and responded to suggestions from the
community. These allegations are FUD spread by people who can't seem to be
bothered by the realities of large organizations balancing many competing concerns.
As near as I can tell these allegations are primarily referring to a pull request by
Michael Snoyman [1] that completely removed four existing sections from the
haskell.org download page and replaced them with a link to a tool only a few
months old written mostly by Michael and others at FP Complete. I think any
reasonable person would agree that a pull request like this to a language's
official website is completely ridiculous and should definitely not be
accepted. In fact, Gershom & co have proven very reasonable because they did
eventually add stack to the downloads page [2] after it had more time to
mature and became more widely used.
Furthermore, Chris Done (an employee of FP Complete who is also associated
with this new website) made the underhanded move of revoking his permission [3] for haskell.org to use the
web design that he contributed under a BSD license [4].
These are just two examples of a pattern of what I think is pretty lousy behavior on the part of
key players in FP Complete that should be taken into account when listening to
their rhetoric.
Regarding their point about /r/haskell being full of flamewars, from what I've
seen the only flamewars there are ones involving the above mentioned people from FP Complete and they are usually the ones doing the flaming.
I've used Haskell, but not to the point that I've needed anything like cabal or stack, so maybe I'm not qualified to speak on this.
But this whole thing is just so silly. The real value in Haskell, to me, seems to be for learning functional programming, since it forces you to use that paradigm. Beyond that, it's just a hobby language. There's nothing wrong with that, but it's not worthy of this East Coast/West Coast hip hop-esque schism.
Like seriously, the only recent disagreement that led to a major project splitting in half that I can think of is what happened with HTML5. Something as critical to the computing world as HTML is a lot more worth fighting about than Haskell. I feel like new versions of the C++ standard, even when there are big changes, don't have people as up in arms as they are over this.
> The real value in Haskell, to me, seems to be for learning functional programming, since it forces you to use that paradigm. Beyond that, it's just a hobby language.
It's not a bad thing, but I think like you said in the beginning of your post, you aren't qualified to speak on this. Haskell is a very powerful and capable language, and you've basically called it a toy.
It's good you've played around with the language, but to say you've built nothing substantial in Haskell and go on to say it's just a hobby language is like me saying I played around with Python and decided its only value is learning the imperative paradigm.
> The real value in Haskell, to me, seems to be for learning functional programming, since it forces you to use that paradigm. Beyond that, it's just a hobby language. There's nothing wrong with that, but it's not worthy of this East Coast/West Coast hip hop-esque schism.
I categorically disagree. Your comment states that Haskell is both good for learning functional programming and bad because Haskell forces you to use the functional programming paradigm (aside: it doesn't).
There is also a distinct lack of compassion for those that use Haskell in their jobs or have in the past.
> so maybe I'm not qualified to speak on this.
Then how do you so quickly move to "Haskell is just a hobby language"?
It's a hobby language to you, sure, but to many others, it's what they use to earn a living, it's what their companies are built upon, just like any other major language out there. I don't see your point.
Wow, this is awful. It seems like there are a lot of immature people on both sides of this nonsense. If any of them are reading this: you're making your ecosystem look bad. Settle your differences privately and present a unified front.
I don't think it's awful and immature for different people to have strong opinions on the future of Haskell. There have been honest attempts on all sides to work these problems out. The current haskell.org reflects some of this, as the download page has both Stack and Haskell Platform.
If they cannot work it out there is nothing to be feared by them parting ways. As a community-driven ecosystem, that's the only choice the community members have. Users have no right to expect anything else from such an ecosystem. If users want something clean and tidy, they need to go use something driven by a corporate overlord.
The difference between haskell.org and haskell-lang.org, the new subreddit and IRC channel, the cat fights between the designer and haskell.org, and so on.
It's a bit broader than discussing the site, if you accept what they have announced. The subreddit (and twitter feed, etc.) will be "open to all to discuss the contents of the website, and more broadly how to make Haskell as welcoming a language, community, and ecosystem as can be managed." That second part implies a wider mandate.
I haven't really followed it that much, but there absolutely is a debate, and at least some of the people involved are feeling some real acrimony. Here's snoyberg, one of the people behind the new website: https://www.reddit.com/r/haskell/comments/4l3y9f/store_a_new...
It's not mine either, but I don't read it like that. It makes sense that they would encourage people to get involved. I mostly see mentions of aging tools which, I believe, is true (I'm not a hardcore practitioner, just a curious Haskeller on my spare time).
I guess I'd like to see more in details what they are planning to do.
English is my mother tongue, and this just reads like an invitation to the community. "Lively discussions" is sometimes a euphemism for a heated debate but I didnt get that feeling from this
I just assumed it was intended to be about Haskell in general, since the first post was "Young developers like Discourse and Slack, not IRC", not very website specific.
Maybe haskell_lang_org would have been a clearer name.
Because /r/haskell has become a place of constant flamewars. We need a clean break. A new subreddit provides a fresh start allowing to mold a new community based on better principles. Everyone who wants to be part of the new community is invited to join the new Haskell movement. Troublemaker will hopefully stay behind
Are we reading the same r/Haskell? I've never seen anything more than minor disagreements - any trolling gets down voted into oblivion, beginner questions are always answered constructively with usually more information than was originally requested.
I usually head straight to the comments, often before reading the articles to see what additional information has been added to the conversation.
I note that several of the names in the announcement are often front and centre of anything that could be flamewars - the rest of the community is very civil. This is really disappointing to see this sort of public division in the community, with as far as I can see no good reason.
For starters just recently FP Complete open-sourced a new cool high-performance serialization library. Then a few people started giving Michael shit for no reason. See https://www.reddit.com/user/snoyberg?after=t1_d3ncybv
Are you talking about the "store" discussion? Michael seems to have brought some of that upon himself. He entered that discussion in a fairly abrasive way [1], and based on his replies, he didn't seem very motivated to foster a more positive discussion (or to just walk away from the trolls).
Are you mgsloan on reddit? Nobody said anything about snoyberg at all until he showed up and started shitting on everyone like usual. All I said was that FP complete is setting a bad example by actively refusing to follow established community guidelines (PvP).
No, it isn't. I don't use HN much, just taking a look at this conversation. I shouldn't even respond to this comment considering its tone. You should keep in mind that this was in discussion of a new serialization library, not the PVP.
I actually had to create this new account because I forgot my password and my old account (probably mgsloan) doesn't have an email address associated.
> All I said was that FP complete is setting a bad example by actively refusing to follow established community guidelines (PvP).
We do follow the important parts of the PvP. Personally, I consider the 3rd section of the PvP a failed experiment. It just doesn't work well, and the maintainer / hackage trustee overhead is too damn high. My theory is that the folks who are adamant about the PvP are either damn tenacious and dedicated (hvr, dcoutts, etc), or people who don't deal with projects with many dependencies and custom packages.
So, yes, we are willing to dump tradition when the tradition is nonsense. I think that Haskellers ought to understand this very well - tradition should be questioned - particularly when it is a major pain point.
When there is great value in doing so, we are questioning some traditions and doing our own thing. This attitude appears to be ruffling the feathers of the vocal minority.
> It just doesn't work well, and the maintainer / hackage trustee overhead is too damn high.
The trustee overhead is only too damn high if people start leaving off upper bounds more frequently. We're tweaking and adding features into `cabal-install` to encourage proper PVP bounds when uploading to Hackage.
On the other hand, Stack unfortunately undoes this by having harming defaults here.
So, to put this bluntly, by having bad defaults, Stack is actively contributing to overload Hackage Trustees.
> My theory is that the folks who are adamant about the PvP are either damn tenacious and dedicated (hvr, dcoutts, etc), or people who don't deal with projects with many dependencies and custom packages.
The whole PVP debate really boils down to one simple question. Do you believe that a properly functioning dependency solver is important for the community? If you answer yes, then I think it's pretty straightforward to get from there to the conclusion that version bounds are necessary. And by the contrapositive, if you are arguing against upper bounds, then you are actually arguing against the usefulness of a solver. If you answer no, then we should debate the merits of having a solver.
Would it be possible to do this more like GNU configure does? The software specifies what it needs, and the system looks for a version that works. How about check the Haskell code automatically to see what functions it uses? If I'm using `text`, and all I use from that package is `pack`, `unpack`, and `cons`, I shouldn't have to specify bounds.
The Cabal way of doing this--specifying version bounds--creates a big maintenance burden. And even then, it does not always work.
So yes, I would question the merits of having a solver that checks some version numbers that developers manually put in. That said, I lack the know-how or resources to come up with anything new, so I'm stuck using curation or a solver. Using someone else's curation winds up being much less work for me than using a solver, so that's what I do.
> Would it be possible to do this more like GNU configure does? The software specifies what it needs, and the system looks for a version that works. How about check the Haskell code automatically to see what functions it uses?
This gets often suggested every time the version bounds topic comes up (to some degree, that's the direction backpack is going btw). But unfortunately this does not work:
Because what this argument ignores is that you get a similar problem you have with duck-typing on a different level: You assume that the same name & type-signature provides the same semantics. However, the types usually leave too much degree of freedom to provide a proper contract. And you have to find a way to encode that contract.
The best-bang-for-buck way we currently have to encode this contract is... well... the PVP! Version numbers announce the contract, while version bounds define which contract you rely on.
Unless we have a better way to solve this, there's no alternative to the PVP. Unfortunately, so far I have not heard any workable solution from PVP complainers. So that's that.
> Using someone else's curation winds up being much less work for me than using a solver, so that's what I do.
:-(
So basically, you value your time more than the time of us Hackage Trustees, who now have to fix the mess you're leaving behind on Hackage. That's like justifying littering because that's less work, since there's public services anyway which pick up the garbage you leave behind.
If you have the time to write software, package it up, write tests, package it up, and upload to Hackage, then is it really asked too much to go that extra mile and follow the PVP to not waste our time?
dcoutts said it would not be appropriate to change Hackage to require upper bounds on software.
It would be quite simple to change Hackage so that any upload would require upper bounds restricted only to package versions that already exist. Why has no such change been made? If I were in your situation I would not be spending time on menial work when a simple program could prevent that work.
If such a change were made I would happily stop uploading to Hackage altogether. That no such change has been made suggests there is insufficient support for your position.
I have not wasted any trustee's time, as all my software works and I keep it working or mark it deprecated. That said, I do not want trustees to fix my stuff. I have no desire to waste anyone's time.
The only reason I upload to Hackage is to get stuff into Stackage. I would fully support a way to get stuff into Stackage that skips Hackage. I think it would reduce a lot of this friction. However I can understand why Stackage has no such method: Hackage allows no upper bounds. This suggests that people value a large unfragmented Hackage more than they value required upper bounds.
Of course I have no role in telling you how to spend your time, but if I were you I would stop fixing software that does not play by your preferred rules.
> That said, I do not want trustees to fix my stuff.
As soon as you upload stuff to Hackage, it enters the work-queue for Hackage Trustees. That's because the Hackage Trustees' mission is to make sure that Hackage remains in a healthy state. Which, by the way, wouldn't be needed in the first place, if everyone played voluntarily by what you call "your preferred rules", i.e. the PVP. Luckily, in many cases it's just an oversight, and in thoses cases people are actually grateful for the heads-up.
Consequently, the only way to keep Hackage Trustees from messing with your stuff is to refrain from uploading to Hackage.
> I would fully support a way to get stuff into Stackage that skips Hackage. I think it would reduce a lot of this friction.
That's actually an intriguing idea and to be honest I am surprised that Stackage hasn't implemented something to this end already. After all, Stackage curators keep busy fighting against overly strict version bounds, while Hackage trustees are busy fighting against inaccurately lax version bounds... this is quite yin-and-yang-esque ;-)
> Consequently, the only way to keep Hackage Trustees from messing with your stuff is to refrain from uploading to Hackage.
I don't mind if the Hackage Trustees mess with my stuff. It's released under a free license; anyone can do whatever she wants to it. But this is not work that I am foisting on anyone else. They are voluntarily doing it.
> Which, by the way, wouldn't be needed in the first place, if everyone played voluntarily by what you call "your preferred rules", i.e. the PVP.
If the Hackage Trustees think the PVP is so important, they should change Hackage so that uploads must conform to it.
Also, the litter analogy does not hold up because littering is a crime. People with your viewpoint apparently lack the clout to make non-PVP bounds a "crime".
The illegality of littering reflects a political consensus that littering is undesirable.
Since non-PVP uploads are allowed despite the technical ease of banning them, this reflects the fact that the PVP purists do not have a consensus backing their view.
I think the political consensus arose because of a recognition of certain attributes of littering, which would not go away simply because the political consensus moved. There was a time before littering was illegal.
Exactly. There is no agreement in the Haskell community that lack of strict adherence to PVP bounds has negative attributes. Because there is no such agreement, Hackage does not enforce PVP compliance.
But using that to reason about "wrongness" still seems backwards.
"This is bad in a way similar to how littering is bad, therefore it should be discouraged (and maybe banned) like littering is discouraged and banned." is a perfectly reasonable form of argument. "But it's not banned like littering is banned!" is not a good objection.
It is, of course, possible that it's not actually bad like littering is bad, or that other concerns genuinely override... but that doesn't make this particular objection appropriate.
I understand why this is confusing though, since the HN link goes to an annoucements page which mentions the new subreddit prominently), but the homepage for haskell-lang.org does not.
What? Apart from Sibi Prabakaran who I've never heard of (maybe I only know them by their handle?), everybody else in the list is a high profile, highly-respected member of the community. As far as I can tell from being on /r/haskell during the whole day every day. What kind of trouble did they cause?
There used to be a time when blog posts were written about how toxic the Haskell community is to beginners by people who had encountered abusive behaviour from Chris Allen whilst trying to learn. He had a long history of such behaviour on Twitter.
The arguments being characterized as "flamewars" almost exclusively involve Snoyman, and often include others of the FP complete "take over haskell" task force listed.
I spent a fair bit of time trying to figure that one out. Thanks for clearing that up here and on Reddit that Rabble_of_one isn't /u/Mob_of_one on Reddit. Also thanks for learnhaskell! It helped me a lot when I was first learning :)
I still don't understand why new subreddit or IRC channel are necessary. They could be used strictly to talk about the new site, but it seems they will be targeted to all things Haskell, exactly like the existing places.
Otherwise I'm all for some form of competition and moving things forwards, so props for the initiative.
I got the impression on #haskell-lang that the current occupants think the channel is about the new website. But with a channel name like that it definitely sounds like a channel devoted to Haskell discussion...and thus may become one.
We already have #haskell, #haskell-overflow (sometimes even #haskell-overflow-overflow :P) and #haskell-beginners. I don't think there's a need for further IRC channels for language discussion. The current Haskell IRC community is beautiful and the least toxic and splintered of any I've ever been to.
Good to see that the Haskell community is looking for ways to be more accessible to newcomers. I'm not very familiar with Haskell, but I have long heard that the Haskell community wasn't interested in popularity. Has there been a shift in their thinking?
The Haskell motto is "avoid success at all costs", usually clarified to "avoid 'success at all costs'".
In other words, "success" (popularity, widespread use in industry, teaching, etc.) is not a justification for "costs" such as limiting expressiveness, making things less safe, restricting research possibilities, etc. Haskell would prefer to be powerful, safe, efficient, obscure and niche; rather than popular, industry-standard, widely-known, highly compatible, unsafe, insecure, inefficient and restricted (besides, we have loads of languages of this sort!).
Crippling the language to make things easier for new users is not an option. However, there are many ways the language could be made easier without impacting any core values. For example, there are long-standing issues with strings, records, error messages, dependency handling, etc. which people are working on.
Also, for those who do want to learn Haskell, I've found the community to be very welcoming and tolerant of newbies. Just ignore some of the more math-heavy blog posts (for now, at least), or your head might explode :P
Thanks for the reply! I've heard that motto before and didn't understand it until now. Makes perfect sense.
To your point about making Haskell easier for newbies without impacting the core values... Rust is a great example of that. Rust can be difficult to learn, but the Rust community does a great job of explaining (and re-explaining in many cases) Rust's approach to newcomers. This is especially true when Rust handles a problem in a way that may be counter-intuitive to the inexperienced.
> Rust can be difficult to learn, but the Rust community does a great job of explaining (and re-explaining in many cases) Rust's approach to newcomers.
Whilst communicating why and how things work is certainly important (all of the Haskell monad tutorials come to mind!), I was actually refering to cases where "Haskell's approach" is known to be bad.
No. This is not the community's doing. It is FP Complete, a corporation attempting to subvert the haskell community for their financial benefit. The purpose of this site is to make newcomers think the FP complete tools are the tools to use, rather than the official ones.
You do understand that comments like this are actually building their case for problems in the community right? I've read several of your comments on this page, and you're the only one making accusations without any evidence, and turning this into a flame war. If you don't like stack, don't use it.
I'm not a big fan of this whole community splitting action, but to think that it's been undertaken as a coup d'état to take control of the community by a commercial entity is verging on tinfoil hat territory.
And you know what? Stack is a fantastic tool for newcomers, we use it exclusively for our commercial Haskell projects and it's changed our development practices for the better by a long way. Something that built today I can be sure will build in a year without changes - cabal has never been able to guarantee that. I'm really glad someone has put in the huge amount of effort to make a better Haskell build tool, it's been far too long coming.
No, this whole "any negative response to our hostile actions justifies our hostile actions" nonsense doesn't fly. It is begging the question. And you are spreading FUD again. Cabal absolutely is able to guarantee that, and always has. All you do is exactly what stack is doing, pin yourself to a specific version of your dependencies.
So who's behind C? C++? Haskell has a language standard and has historically had competing implementations. None of them is "official", nor is any of the infrastructure.
It is in no sense the "official" outlet for GHC. It's an outlet that promoted other people's work, and anyone else is welcome to make a new outlet of their own.
a year later you will be reminded of the rather spectacular struggles that preceded the ghc-centrism of haskell.org . The change was closely associated with the appearance of the haskell platform, and the arguments very similar to those concerning stack and stackage. If you want paranoid theories of corrupt commercial motives in that case, I can produce several incompatible ones for you to choose among.
The former is now virtually uncompilable (and was never complete), Hugs is officially unmaintained, nhc hasn't seen a release since 2010 so is not under new development.
While there was discussion over this, it doesn't at all resemble the set of arguments more recently.
I won't bother to look it up, since it's not important and we probably agree on basically everything, but there were in my memory quite a few tempests in teapots about this sort of thing. It wasn't that there were other working compilers the overt ghc-centrism was dissing; the dispute was more about the desirability of distinguishing the Haskell language from the ghc implementation which pained some. No one doubted that the ghc was the going one, especially once hugs became unmaintained. Among the arguments for overt ghc-centrism were ... that it was confusing to users not to make it obvious that effectively Haskell=ghc. Similarly it was confusing to users ... that there was not something more like a system of standard libraries like those 'blessed' by the Platform. "For commercial adoption we need a clear path through all this stuff, we need clarification, blessing and decision" was one view. I remember people who were disturbed that some Haskell platform pages had you clicking an icon reading "Download Haskell" - meaning the ghc+ Haskell platform. I'd have to hunt for an example but see http://code.galois.com/darcs/haskell-platform/download-websi... for something not quite like that. For someone like dons the fastidiousness that would balk at a "Download Haskell" icon that meant "download ghc+blessed libraries" was ridiculous (rightly, I think, for the time). (Maybe they thought it should yield a pdf of the Haskell Report ...) There were actually quite a few similarities in the arguments, the difference was that no one poisoned the wells in their favor of their side by making up imaginary corrupt commercial motives. The difference was between people with a certain view of how industrial adoption was to be advanced, and a different more language-centric view. There is on reflection quite a bit of similarity between dons and Snoyman
It isn't "ghc-centrism". None of the other compilers exist any more. If you don't have any idea what you are talking about, don't create an account just to come post nonsense.
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.
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.
Well, at least one motivation for launching a new site is so that https://haskell-lang.org/get-started is a much more streamlined way to onboard users than the existing https://www.haskell.org/downloads Unfortunately, the presentation of how to start new users is somewhat political because there is disagreement if new users should just get stated on Stack, or see all of the options.
A new website I understand. If one wants a radically different model of community participation than what the standard haskell site presents, by far the best and easiest thing for everybody is to just do it, and see what happens. The original can conservatively hang around, the new one can be trialed, if the new one is successful perhaps the original adapts or is even replaced. (IIRC, the maintainers of haskell.org have stated they don't have a lot of time to advance the backend and make significant changes.) That all makes sense to me.
No one on /r/haskell seems to know who Rabble_of_One is who has been posting here. I believe the assertions that none of the involved parties would hesitate to speak out under their established names, because they have not hesitated in the past to take strong positions.
Is there a general consensus to move beyond hackage? I thought your work on backpack was still ongoing and bridging the usability gap between cabal and stack, no?
Well, if you are a user using Stack, packages which are not in the LTS have to be added manually. So in a Stack universe, treating LTS as the universe of packages is not unreasonable.
I don't think either Stack users or Cabal users think Hackage should go away; in particular if you're a library author, the way into the LTS is to publish something to Hackage and then ask Stackage to take it.
As for Backpack, it doesn't really have much to do with the philosophy difference between Cabal and Stack. But I have, as necessary refactoring for implementing Backpack, been working on improving cabal-install, including the Nix-local builds feature which is supposed to make Cabal's usability story much better.
I think it's fair to say that haskell.org is the "official" website that has the involvement and implicit backing of the old-timers. Also the GHC compiler is hosted on haskell.org. haskell-lang.org is the upstart. Whether it will last is an open question.
I have no idea either. The new site was never discussed once on the list ( https://groups.google.com/forum/#!forum/commercialhaskell ) nor does there seem to be anything in the CHG charter that would let it as a group do anything at all, such as making a collective decision to sponsor a site.
I'm not a Haskell greybeard, just a light user, but despite the improvements via FPComplete's output, at least some of it feels NIH and unnecessarily polarizes the community. For instance, reusing Shake in Cabal(-install) and getting nix-local-build and Backpack production ready look like improvements that will be beneficial for a longer time, rather than splitting the community with a different build/package structure (stack).
I mean, dividing the already small Haskell community doesn't make sense to me. If Gershom doesn't play fair with the management of www.haskell.org, this should be raised officially and fixed, because haskell.org is not a one man project and there's a team around it.