New haskell-lang.org
haskell-lang.org
haskell-lang.org
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.
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.
[1] https://github.com/haskell-infra/hl/pull/130/files
[2] https://www.haskell.org/downloads
[3] https://mail.haskell.org/pipermail/haskell-community/2016-Ap...
https://www.reddit.com/r/haskell/comments/3lax6y/discussion_...
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.
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.
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"?
I read it like there should be a problem to solve, but english isn't my mother tongue.
I guess I'd like to see more in details what they are planning to do.
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.
Are we talking about different /r/haskells here? I'm not seeing it.
"Disagreement" is not "a flamewar". Wouldn't even call it "constant disagreement", either.
Do you have an example "flamewar" you can show us?
It's worse these days. "We need a safe zones!"
Like stating the "old" community is based on worse principles ?
No, it most certainly has not.
>Troublemaker will hopefully stay behind
Three of the people involved in this would be lumped into the "troublemaker" group in any objective measure.
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.
I visit there every day and I have no idea what flame wars you are talking about.
[1] https://www.reddit.com/r/haskell/comments/4l3y9f/store_a_new...
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.
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.
:-(
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?
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.
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 ;-)
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.
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.
"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.
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.
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.
Well, that's a very bold theory...
Source: https://www.reddit.com/r/haskell/comments/4ghznv/improved_hp...
Note that the community page on haskell-lang.org still links to /r/haskell: https://haskell-lang.org/community
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.
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.
Otherwise I'm all for some form of competition and moving things forwards, so props for the initiative.
[0] https://mail.haskell.org/pipermail/haskell-community/2016-Ap...
It may appear so because haskell-lang started off haskell.org's content. You can look at http://github.com/haskell-lang/haskell-lang/commits/master to see the work that went into evolving haskell-lang away from haskell.org
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.
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
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.
Here's a great example from r/Rust where a new Rust user trashes traits and the Result type: https://www.reddit.com/r/rust/comments/4rev26/why_is_rust_ma...
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.
For example:
http://www.alexeyshmalko.com/2015/haskell-string-types
What makes them "official"?
https://web.archive.org/web/20050728010349/http://www.haskel...
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.
https://web.archive.org/web/20090129200859/http://haskell.or...
which immediately lists implementations and compare it to
https://web.archive.org/web/20100402011002/http://www.haskel...
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'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.
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.
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.
Imagine if each companies (using haskell commercially) start to act like that...
FP complete isn't misbehaving, but they're putting themselves in a position to do a lot of damage if they did.
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.
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.
It's open source and the bug reports and feature requests merged in seem to indicate the aims have been making building Haskell projects easier.
I don't see indications of vetos in favor of FP complete that hurt the Haskell community.
I use it constantly, and like it, but let's not pretend there isn't a shift in power and influence as a result.
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?
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?
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.
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.
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....
You sound like you have never read what I posted and decided a strawman was better than replying to what I actually said.
>Cabal-hell was a very real problem
Nobody suggested otherwise. Tricking people into thinking normal errors are "cabal hell" does not mean cabal hell didn't exist.
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_?
Attribution?
And frankly, couldn't you fork stack?
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".
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.
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.
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.
> 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.
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 ;-)
I am not arguing that the move away from the PVP was correct - I was uncertain at the time and I remain uncertain.
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.
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."
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 said (https://news.ycombinator.com/item?id=12058419):
> 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.
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.
I am engaging in good faith, as I have always done. I have done so under this same name, here, on r/haskell, on haskell-cafe and haskell-beginners, on #haskell, and in person.
I said that if you are engaged in bad faith, and if you will persist in doing so, you need to GTFO. I stand by that statement.
That you perceive yourself to be acting in good faith and me to be acting otherwise does not make it hypocrisy.
If you are intending to engage in good faith, please observe that - at the very least - we seem to be having a bad time successfully communicating in this format. Perhaps we can try some other medium? If you're in the bay area, I'll buy you a beer (or social equivalent).
That is very hard to believe consider the amount of dishonest rhetoric on display.
>I said that if you are engaged in bad faith, and if you will persist in doing so, you need to GTFO
You did not. You said if I continue I need to GTFO. I am not engaging in bad faith, I am being honest and clear, and you are respond with ridiculous strawman attacks.
>If you're in the bay area, I'll buy you a beer (or social equivalent).
I'm in a very different bay area than the one I assume you refer to. I do not see any reason why text is a problem. You simply need to read the words I write and respond to that, rather than read then, make up an imaginary version of me, give that imaginary version of me a bunch of other opinions you don't like, and then respond to those.
If we wish to litigate this, please point out a single instance of dishonest rhetoric from me. Be very specific about how it is dishonest. Bear in mind that there may have been genuine misunderstanding by either of us, and we were probably neither as clear as we thought ourselves to be.
I said,
> 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.
As I wrote it, the (now italicized) "this" was definitely meant to refer to the just mentioned "not engaging in good faith", not to your behavior whatever it may be. This was less clear than I'd meant it to be, although I still think my intended interpretation is favored.
And plenty of non FP Complete employees do this. What's your point?
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.
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?
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.
It's the rest of the fragmentation that doesn't.
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.
$ whois haskell-lang.org | grep ' Name:'
Domain Name: HASKELL-LANG.ORG
Registrant Name: FP Complete Corporation
Admin Name: FP Complete Corporation
Tech Name: FP Complete Corporation
$ whois haskell.org | grep ' Name:'
Domain Name: HASKELL.ORG
Registrant Name: YaleUniversityComputer Science Department Haskell Group
Admin Name: Galois Hostmaster
Tech Name: Galois HostmasterI'm not sure what stating CHG sponsors the new site means.