Learning from the "No /= in Eq" debate

#22

What I’m indeed surprised about is that this discussion happened wrt the No /= in Eq proposal and not in the Dependent Haskell one.

From how I read the discussion, people want clarity, so they can manage their expectations. That may (for some) mean they will leave the community. Others will set different priorities (e.g. won’t update their libraries all the time). Some may even consider a fork of GHC, who knows.

I think the important point is not to try to keep everyone in the same boat, but be up-front about where things are heading and allow people to do their own thing, without dramatic incidents.

Even if part of the community decides to go a different route in some aspects… that doesn’t mean there can’t be useful synergy. And this clarity may in fact reduce friction, even if it contributes a little bit to increased fragmentation.

As an example: if everyone understood that base primary concern is backwards compat, many users of it would stop trying to push large changes into it and alternative preludes would maybe become even more common. That’s fine. That’s open-source dynamics. But there must be a path forward, so people don’t waste their time due to confusion in priorities.

7 Likes
#23

I’m currently reading it and found it fits perfectly our current situation, even though it was written before the notion of open source software even existed (1990). It is very well written and illuminating, as it covers examples and models of collective governance from a number of disciplines. Highly recommended :slight_smile:

#24

Now that you’ve mentioned it:

2.6 Was Haskell a joke?

The first edition of the Haskell Report was published on April 1, 1990.

Alright, would an updated Haskell standard do? After all:

  • lots of decisions are involved, and
  • some level of “mutual agreement” is achieved.

The CLC could then use both of these to guide its decisions going forward.

#25

If we consider the whole paragraph from Being lazy with class, sec. 3.7 :

The fact that Haskell has, thus far, managed the tension between these two strands of development is perhaps due to an accidental virtue: Haskell has not become too successful. The trouble with runaway success, such as that of Java, is that you get too many users, and the language becomes bogged down in standards, user groups, and legacy issues. In contrast, the Haskell community is
small enough, and agile enough, that it usually not only absorbs language changes but positively welcomes them: it’s like throwing red meat to hyenas.

My interpretation of the zeitgeist is that we are facing those growing pains. It’s not that the “hyenas want alka-seltzer” (good one btw), but simply that times have changed, and new animals roam the savannah.

Haskell is definitely not as big as Java, but I’m guessing it has a much larger (and diverse) user base than in 2007 (when Being lazy with class was published), and indeed we are facing complex social and political dynamics, and hard economical calls to make.

@atravers In 2021 we are “stuck” with a single Haskell compiler and core libraries environment; Hugs is no longer in development and the various research compilers (UHC , etc.) cannot keep up with the pace at which new research is merged into GHC. On the industrial side, valiant efforts like Eta have been bogged by the same problem; forking means duplication of much effort.

The most vocal negative feedback on the /= proposal concerns time (and therefore money) : “Why should updating dependencies break my code?”.

I completely agree with @hasufell : GHC and the core libraries must make (in-)stability expectations as explicit (and motivated) as possible going forward.

1 Like
#26

Apart from being a textbook example of bikeshedding, the two are different because hopefully (and as far as I can pick up from the current writeups) dependent types will be opt-in instead of a forced change, whatever that means.

1 Like
#27

Yes, I agree too. My personal view (I am not speaking for the HF here) is that

  • A distinctive and valuable feature of Haskell is that it does grow and change, even at the cost of some backward-incompatibility.
  • We should strive to minimise the costs of such changes by strategies such as
    • Providing ample warning
    • Giving opportunity for many voices to be heard; perhaps there are unanticipated costs that might change the judgement balance.
    • Offering mitigation strategies and workarounds; perhaps introduce changes in several steps (e.g. warnings first, before the change itself)
    • Avoiding gratuitous back-incompat (e.g. “change for change’s sake”)

It’s not a black-and-white thing, obviously. But most production languages err strongly towards 100% back-compat, and Haskell is (historically at least) different to that. For me personally, a principle is that I’d like Haskell to “make sense” when viewed as a whole with no history; rather than to enshrine in perpetuity a series of historically-driven mutually-inconsistent choices.

It might help if the HF (in consultation with the community) framed some general principles to guide the GHC steering committee, CLC, and others, and to help avoid the unpleasant surprises that arise from mis-matched expectations.

9 Likes
#28

Because that’s the price of “floating” Haskell (no fixed standard).

These days, the closest a developer can get to a fixed standard of the language is to keep and tend to their own private copy (or copies!) of GHC for as long as possible: one with the necessary features for their own programs - a “mini-fork” of sorts. That makes for a lot of duplicated work - much of which can be avoided with a fixed standard.

But fixed standards also have their price, and if the fate of Haskell 2020 is any guide then the Haskell community now considers that too expensive. So Haskell is left “floating” and now subject to change, depending on how well the argument is made for said change, leaving us to deal with ongoing breakage or ongoing (and duplicated) maintenance of mini-forks - or both D-:

GHC and the core libraries must make (in-)stability expectations as explicit (and motivated) as possible going forward.

How would this help? Some users would still complain, it just won’t be when their old code no longer compiles - they’ll just petition for the breaking change to not happen. That leaves two options:

  • try to write a tool which can update old code, or
  • endure the complaints e.g. about Haskell “being a toy”.

Haskell-to-Haskell translators? That seems almost as complicated as writing an all-new compiler! Maybe therapy for the disappointed is the simplest option…

#29
  • A distinctive and valuable feature of Haskell is that it does grow and change, even at the cost of some backward-incompatibility.

…case in point: the banishing of the monomorphism restriction - presumably no-one wants that part of the language back!

It might help if the HF (in consultation with the community) framed some general principles to guide the GHC steering committee, CLC, and others, and to help avoid the unpleasant surprises that arise from mis-matched expectations.

…in the absence of an encompassing language standard to refer to, this could be an workable alternative, provided “discussions” don’t continue on indefinitely. At some point, decisions must be taken - no level of “guidance” (or bureaucracy) changes this basic fact.

#30

I’ve written a thing , looking forward to all feedback :

#31

I want to talk a bit about what I think about this topic.

So, what do I think about this topic?

I think this topic should be considered in social, historical and even teleological context. It is not merely that some people want one thing (say, nice core libraries) and others want another (say, timeless learning materials). There is a reason why people want this or that — this reason is what matters. And people can be wrong about what is best for them.

So, what do people want?

The problem is that it is impossible to have both.

The standard solution to this problem is to clarify the purpose. This is mentioned in this comment. But what if there are several purposes? There is a proposal to split the ecosystem.

How should we evaluate these possibilities?

  • There is a local way. «This is good for me, therefore I am going to support it.» We ask everyone to evaluate a local optimum and then vote to either pick one or take a weighted average. This is what I think was happening so far. Everyone pulling the blanket their way.

  • There is a global way. «Amplify Haskell’s impact on humanity.» This is the mission statement of the Haskell Foundation. But the Haskell Foundation does not have the authority to decide upon socially divisive problems. So, we are still stuck at the average between local optima.

Can we pursue the global way as a community?

It seems that we should account for several aspects of the problem. My picture is like this:

  • There is a space-time continuum. Space is the landscape of society, time is cultural change. (To be concrete, take the relative adoption of Haskell in various markets as dimensions and vary it over time.)
  • Haskell is drawing a curve in this continuum. The aim of this curve is either a clearly stated purpose, or an unwritten average determined by historical accident.
  • There is no option for the curve to have no aim. Since it is mostly smooth, it has a tangent vector along most of its length.

This can also be said in terms of enterprise management. There are customer segments and Haskell can strive to offer value to some but not all of the possible segments. The outcome is that either Haskell has a big market share overall (many opportunities for paid employment, many well-supported libraries) or a small market share overall (few opportunities for paid employment, few well-supported libraries).

So, goals we pursue → vector of cultural change → overall market share → good things.

The current situation is that Haskell has about 3% market share and no growth to speak of.

How can these numbers be improved?

  • This is not a question of technical expertise, but of business administration.
  • This is not a question of keeping the work of maintainers easy. Maybe we can instead make it harder but better paid. Then more people will be able to afford to do it.
  • Haskell Foundation is not going to make hard decisions for us. There is no management for Haskell.

The only way forward I can see is for the community to organize itself. And not around technical expertise, but around social, enterprise and strategic expertise. Splitting hairs like whether /= should be a method is a waste of everyone’s time. There is bigger fish to fry.

This of course involves redistribution of power. Currently those most able to split hairs hold all the power. I do not see this working. We need someone to look outside the Haskell bubble, someone to crunch the numbers (like say these dream metrics), someone to talk about big changes (like say splitting the ecosystem — see above).

The first step is to re-frame the discourse to account for social, historical and even teleological context. That is what I think, anyway.

Thanks!

#32

One of the goals of creating the HF is to have a body that can make hard decisions. We have no power of enforcement, but we do hope to point ourselves to hard problems and make hard decisions, informed by the community and by data collection.

As one of the chief hair-splitters: I agree. It’s one of the reasons I support the HF and am thrilled to work with people paid to make business decisions around the future of Haskell.

4 Likes