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 :)
