On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins wrote:

The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually *costs* me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether.

So I'll rephrase a question I asked earlier that never got an answer: if I'm developing a commercial project based on ghc and some ecosystem, what would possibly cause me to change either the ghc version or any part of the ecosystem every other quarter? Or ever, for that matter? I've never worked on a commercial project that changed anything major mid-project, no matter what language it was using. As far as I'm concerned, one of the major features of stack is that it handles project-specific ecostystems cleanly and transparently.

On Tue, Oct 20, 2015 at 2:24 PM Ivan Perez wrote:

On 20/10/15 19:47, Mike Meyer wrote:

On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins wrote:

...

The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually *costs* me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether.

So I'll rephrase a question I asked earlier that never got an answer: if I'm developing a commercial project based on ghc and some ecosystem, what would possibly cause me to change either the ghc version or any part of the ecosystem every other quarter? Or ever, for that matter?

I don't know about them, I can tell you my personal experience.

If GHC and all libraries were perfect and free from bugs and ultimately optimized, then you'd be right: there would be no reason to change.

But if you ever hit a bug in GHC or a library which was fixed in a future version, or if you want an improvement made to it, you may have to update the compiler.

Library creators/maintainers do not always maintain their libraries compatible with very old/very new versions of the compiler. In an ecosystem like ours, with 3 versions of the compiler in use simultaneously, each with different language features and base APIs changed, compatibility requires a lot of work.

This problem is transitive: if you depend on (a new version of a library that depends on)* a new version of base or a new language feature, you'll may have to update GHC. If you do not have the resources to backport those fixes and improvements, you'll be forced to update. In large projects you are likely to use hundreds of auxiliary libraries, so this is very likely to happen.

I recently had to do this for one library because I could only compile it with a newer version of GHC. This project had 30K lines of Haskell split in dozens of libraries and a few commercial projects in production. It meant fixing, recompiling, packaging and testing everything again, which takes days and it's not unattended work :( It could easily happen again if I depend on anything that stops compiling with this version of GHC because someone considers it "outdated" or does not have the resources to maintain two versions of his/her library.

Does that more or less answer your question?

Not really. IIUC, your fundamental complaint is that the cost of tracking changes to the Haskell ecosystem outweighs any potential gains from using Haskell. But the choices that lead you to needing to track those changes don't make sense to me. For instance, you talk about compatibility requiring a lot of work, which I presume means between projects. Yes, having to swap out ecosystems and tool sets when you change projects can be a PITA, but even maintaining the environment by hand is less work than trying to keep all your projects compatible across multiple environments. So why do that? Especially when you have tools like virtual environments and stack to take away the pain of multiple environments? And yes, if some part of the ecosystem has a bug you have to get fixed and an update will get the fix, that's one option. But it also comes with a cost, in that you need to verify that it didn't introduce any new bugs while fixing the old one. Plus, dealing with possible changes in the API. And as you note, if that forces you to update some other part of the ecosystem, all that work is transitive to those other parts. It indeed adds up to a lot of work. Enough that I have to question that it's less work than backporting a fix, or even developing a new one from scratch. Over a couple of decades of building commercial projects in the P languages, when faced with the alternatives you outlined here, updating anything major was never the choice if more than one person was actively writing code. Even with a language that put a priority on not breaking old code in order to minimize the cost of doing that update. Maybe there's something I'm missing about Haskell that makes fixing somebody else's code take a lot more resources than it does in other languages. In which case that, not the changing ecosystem, is the argument against Haskell.

7.10 cost me an hour on a 60k loc project. Aeson 0.10 (<3 you Bryan, but this was brutal) cost me a couple days on a 2k loc project and I'm still not totally satisfied with how things have settled yet. Going to concur with Greg here. On Tue, Oct 20, 2015 at 4:01 PM, Greg Weber wrote:

stack and Travis CI make it easy for library authors to make sure their libraries work across multiple versions of GHC. For users, it makes it easier to install the newest version of GHC.

I have to say that I think very few people are choosing not to use Haskell because there are breaking changes to the language.

In fact, this problem didn't register as a major concern in FPComplete's survey https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey

If anything new releases with improvements (breaking or not) get people excited about using Haskell. When people talk about stability, they are generally thinking about whether the platform is buggy, and whether they can get a stack trace when there is a bug, not about upgrade cycles. For new users, upgrade cycles tend to be an afterthought.

The burden is placed on open-source library authors like Johan and myself. In general we would like to spend our time on things that produce new value and minimize spending time keeping things working how they are now. If you don't even believe the change prompting this work tax is a useful one, I can definitely see how it would be demoralizing. In my case I can say that for the last GHC release, members of the community that started using the pre-release contributed a lot of patches for the upgrades, so it actually did not bother me too much. On the other hand, aeson's latest release with unnecessary and undocumented breaking changes created hours of work for me for absolutely no reason. https://github.com/bos/aeson/pull/288

On Tue, Oct 20, 2015 at 12:24 PM, Ivan Perez wrote:

...

On 20/10/15 19:47, Mike Meyer wrote:

On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins wrote:

...

The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually *costs* me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether.

So I'll rephrase a question I asked earlier that never got an answer: if I'm developing a commercial project based on ghc and some ecosystem, what would possibly cause me to change either the ghc version or any part of the ecosystem every other quarter? Or ever, for that matter?

I don't know about them, I can tell you my personal experience.

If GHC and all libraries were perfect and free from bugs and ultimately optimized, then you'd be right: there would be no reason to change.

But if you ever hit a bug in GHC or a library which was fixed in a future version, or if you want an improvement made to it, you may have to update the compiler.

Library creators/maintainers do not always maintain their libraries compatible with very old/very new versions of the compiler. In an ecosystem like ours, with 3 versions of the compiler in use simultaneously, each with different language features and base APIs changed, compatibility requires a lot of work.

This problem is transitive: if you depend on (a new version of a library that depends on)* a new version of base or a new language feature, you'll may have to update GHC. If you do not have the resources to backport those fixes and improvements, you'll be forced to update. In large projects you are likely to use hundreds of auxiliary libraries, so this is very likely to happen.

I recently had to do this for one library because I could only compile it with a newer version of GHC. This project had 30K lines of Haskell split in dozens of libraries and a few commercial projects in production. It meant fixing, recompiling, packaging and testing everything again, which takes days and it's not unattended work :( It could easily happen again if I depend on anything that stops compiling with this version of GHC because someone considers it "outdated" or does not have the resources to maintain two versions of his/her library.

Does that more or less answer your question?

Cheers

Ivan

PS. I do not use stack yet. So, I remain ignorant about that. I see how it could help in some cases, but not this one.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

On 20/10/15 19:35, Gregory Collins wrote:

On Tue, Oct 20, 2015 at 7:45 AM, Jeremy mailto:voldermort@hotmail.com> wrote:

I'm interested in why you think recent changes are making Haskell a less viable alternative to mainstream languages.

[...] Of course, these hypothetical productivity benefits are extremely difficult to quantify (and Lord knows, we've tried), but that's not at all true for the "con" arguments:

* how many Haskell programmers are there in industry? If I lose my local expert who is trying to push us to use this thing, can I hire another? * how many lines of code are written in Haskell globally vs other languages? * how much tooling will I have available to help me if I choose Haskell vs. a "safer" technology like Java, Python, or Go? * how many open source libraries will I have available to me to handle common tasks, and what is their quality? * how likely am I to encounter bugs in the compiler or base libraries?

We actually get these questions from potential clients *all the time* (in particular, everyone asks 1 and 3). I don't always have a convincing answer.

The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually *costs* me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether. Not even that. Learning and some tooling costs can be amortized over time, but a regular and frequent cost tied to upgrades in the ecosystem may be really hard to estimate in advance. This makes profit, viability and deadlines, mid-term and long-term, really hard to estimate and fulfill. (I've also tried, and often failed.)

If clients (supervisors, project managers, <your company>) have *any* doubts that using the language may be cost-effective, they won't go for it. Cheers Ivan

On Tue, 20 Oct 2015, Jeremy wrote:

I'm interested in why you think recent changes are making Haskell a less viable alternative to mainstream languages. My experience is the opposite - beginners frequently ask "why is x not a superclass of y?" and "why does function a seem to be the same as b?", and are horrified to be told that it's for historical reasons (y existed before x, a existed before the more general b, etc.).

I would not explain it this way, not even to myself.

This is a big anti-climax for someone coming from a "mainstream" language, where type classes are all in the expected logical hierarchy, and functions/types always have the most general constraints possible.

The most general type would be: f :: Anything a => a and programs would read like f (f (f a) (f b)). I don't think that the Traversable and Foldable functions in Prelude are the most general ones - what about using Arrow class instead of functions? If we always try to get the most general functions into Prelude we will get constant change but certainly not progress. The more general the types become the more type annotations you will need and the more mental type inference the reader of a program must perform. Prelude would tend to depend on the newest type extensions.

On Wed, Nov 4, 2015 at 9:37 PM, John Wiegley wrote:

In the last round, delegates from each country who make the final decision by majority. In the case of Haskell, our "countries" might be different: Academia, Industry, Hobbyists, etc. These delegates are supposed to represent the will of their constituents, but can vote however they wish.

The trouble with this would be that the split in the community does not seem to be between e.g. the interests of academia and industry but between conversative people in academia and the industry and those who are more open to language changes in both groups. I suspect the divide isn't even close to the same on most questions either so a representative system might be tricky to implement. Maybe if some form of grouping of people in the community is necessary it should be made along the lines of the groups we saw mentioned in recent FTP discussions: authors of printed books, new Haskell users coming from other languages and new Haskell users learning it without prior experience, Haskell teachers, maintainers of libraries spanning many GHC versions, users writing new code without backwards compatibility concerns, those interested in using only one of the existing Haskell standards without language extensions and those interested in using the latest extensions available,... Perhaps in future discussions a focus should be on identifying and grouping the users affected by each change and each user should be encouraged to vote +1, 0 or -1 for each of the groups they are a part of separately, explaining how they arrived at their final vote themselves. Matthias Hörmann

Hi all, I agree with Joachim Breitner. I've worked with a number of groups with various approaches to collaborative decision making (not just just those called "voting"); and imo the recent upset has nothing to do with the "voting" procedure. I'm not saying we shouldn't consider changes to how we make decisions, just that if/when we do so we should do so for its own sake. The problem isn't with "voting" because, as mentioned repeatedly, we've taken a wide sample of the community and found overwhelming support for the changes. Given the margin of support, choosing other approaches to counting up the size of that margin are unlikely to alter the ordering of "for > against". Given the margin of support, the only thing which could invert that ordering is if we took specific individuals (e.g., those who've publicly "resigned") and considered them to be dictators. Thus, unless the actual proposal is to make those individuals dictators, their opposition is insufficient to counter the support from the rest of the community. No matter how much we dislike the outcomes we got, changing the process of decision making wouldn't've allowed us to avoid those outcomes (again, unless we decided to make certain specific individuals into dictators). The real problem is the growing divide in the community between the "liberals" vs the "conservatives". We could define these groups as those who're willing to break things vs want more stability, or as those who embrace polymorphism vs those who want to minimize mental type inference, or a few other ways I'm sure. How exactly we define the groups doesn't much matter imo; the point is: there are two groups which are growing ever more divergent from one another. Changing how we make decisions isn't going to reconcile these two groups; so long as the groups are widely divergent, any decisions made will upset one or the other. So the real issue at hand is to address the following two questions: (1) how can we reconcile the two groups, reducing the distance between them so as to reduce conflict? (2) supposing the groups cannot be (sufficiently) reconciled, how do we proceed? -- Live well, ~wren

On November 6, 2015 at 10:49:14 PM, wren romano (wren@community.haskell.org) wrote:

Hi all,

The real problem is the growing divide in the community between the "liberals" vs the "conservatives". We could define these groups as those who're willing to break things vs want more stability, or as those who embrace polymorphism vs those who want to minimize mental type inference, or a few other ways I'm sure. How exactly we define the groups doesn't much matter imo; the point is: there are two groups which are growing ever more divergent from one another. 

I think that a “two groups” model of the disputes we’ve had lately simplifies too much, and in fact runs the risk of tending to force a bunch of varying motives and concerns into only two buckets, which I worry will increase the contentiousness of discussions rather help to moderate things. Valuing stability for teaching purposes is very different than valuing stability from the standpoint of a library maintainer, for example. And valuing monomorphic definitions of some things is not the same as valuing monomorphic definitions of other things — or opposing design compromises made in the name of performance, etc. The FTP, while a step forward in many ways, made compromises that opened it up to criticism from many standpoints — from the correctness standpoint it did strange things to the List module — from the backwards compatibility standpoint it did not provide perfect backwards compat (especially with warnings taken into account) — from the performance standpoint it turns out to have introduced at least one unanticipated regression. So no matter your concern, there is somewhere where it did not hit all the marks perfectly. However, this is for the most part because it sought to _mainly_ cover all those marks — so there is a _decent_ correctness story, and a _decent_ backwards compat story, and a _pretty good_ performance story, etc. But by that token, I hesitate to lump those who had concerns or opposition around the FTP into any particular camp. What I think we can try to ask from people is that they evaluate each proposal, to the extent possible, on _its own merits_ and not as part of any camp they might imagine they are in regarding a long term alignment over “fast” or “slow” or “no” library evolution, or the like. Even if we can’t get 100% consensus (and of course we won’t be able to), a continuing dialog where everyone tries to hear everyone else’s concerns and we try to make sure everyone is comfortable with the direction forward should still be the _goal_. Ideally, we will have less voting and not more, because ideally proposals that we move forward with will have a wide base of support across the board. In my mind, the way to do that is to treat each new library proposal case-by-case and go in willing to hear all sides, rather than prejudging what people’s take may be, why they might have such a take, etc. Cheers, Gershom

...

...

...

...

Gershom B writes:

Even if we can’t get 100% consensus (and of course we won’t be able to), a continuing dialog where everyone tries to hear everyone else’s concerns and we try to make sure everyone is comfortable with the direction forward should still be the _goal_. Ideally, we will have less voting and not more, because ideally proposals that we move forward with will have a wide base of support across the board. In my mind, the way to do that is to treat each new library proposal case-by-case and go in willing to hear all sides, rather than prejudging what people’s take may be, why they might have such a take, etc.

I very much agree, Gershom. John

On 2015-11-11 at 11:41:56 +0100, Malcolm Wallace wrote:

But I particularly want us to get away from the idea that those who oppose any particular proposed change, tend to be against language changes in general. It is simply not the case, for any of the recent disputed proposals. [...] People who disagree with recent proposals do so with specific technical and sociological arguments.

Could you enumerate the "recent disputed proposals"? It's a bit unclear to me right now which ones are considered in that set. Are all proposals derived from the (real) Burning Bridges (Meta-)Proposal https://mail.haskell.org/pipermail/libraries/2013-May/020046.html contained in that "recent disputed proposals" set? Were there any non-disputed proposals recently?