The wasted potential of Haskell: Language & Compiler

Links
1

This quite resonates with me at the moment, so I’m interested to hear other’s opinions.

A common insult hurled at Haskell is that it’s a “committee language”.

My take is that this was not the case initially. Sure, it was made by a bunch of people and written as a standard, but in my opinion these were passionate people working as a team on an exciting project. Certainly not what we usually have in mind by a “committee”.

It definitely turned into a committee language over time as we were trying to be “stable” and “responsible” and just tacked on stuff onto the language without introducing many breaking changes.

Instead of new standards we just have new extension collections which are mostly syntactic in nature, or we bend over backwards to an insane degree to try and fit anything new in a backwards compatible way, like dependent types.

Btw. I’m not trying to critique HF and their efforts as I think they do provide great value to the community, but it seems like the current mentality of “stability” will only cause Haskell to “fail responsibly” in the end (instead of avoiding success, at all cost).

Perhaps introducing some turmoil into the ecosystem might be beneficial long term. And honestly, I never quite understood the obsession with backwards compatibility in a strongly typed language such as Haskell. Especially today with LLMs (to play the devils advocate) I really don’t see any problem with regularly updating the GHC or dependencies for large code bases.

3 Likes
2

The video is more rage bait (which he basically admits at the beginning) than constructive criticism.

7 Likes
3

It still highlights quite a few important issues. And while it’s opinionated I think it’s very unfair to dismiss it as rage bait.

4

He implies the designers of Haskell are stupid at various points. I also find his arguments often very shallow. I could try to point out the nuances, but it would take me a lot more work, and it wouldn’t be as fun to watch/read.

7 Likes
5

I didn’t take it as such. It’s also implied that these decisions make sense one after another. But I’m more interested in the general sentiment this video carries. I’ve clearly stated my observations about the language development and future.

6

There are a few misconceptions and dubious claims here. I don’t intend to watch the video after Jaro’s review, but this is my response to the claims in the post:

Haskell has a good reputation as a committee language, not a bad one. I have never seen “committee language” “hurled” at Haskell as an insult. On the contrary, many point to Haskell as a successful example of “design by committee”:

  • Real World Haskell: “Many people are rightfully suspicious of ‘design by committee,’ but the output of the Haskell committee is a beautiful example of the best work a committee can do.”

  • Rabkin & Katz, Socio-PLT: “Committees sometimes produce good designs – indeed, the designs of Algol-60 and Haskell are routinely lauded.”

  • Hacker News: “Haskell was a success story of design by committee.”

  • /r/haskell: “Design by Committee: I often hear that Haskell is an exception to the rule.”

It’s not true that new extensions are “mostly syntactic in nature”. Here are some recent ones that have a purpose significantly beyond their syntax:

The Haskell Foundation (HF) has nothing to do per se with the design of the language. The GHC steering committee is responsible for the language as implemented by GHC, which is de facto the language “standard”.

It’s not fair to say that we “bend over backwards to an insane degree” to maintain backwards compatibility. In fact, going back just a few years ago shows how bad the instability problem was. Today we take stability more seriously, and that’s a good thing.

  • Moritz Angermann: “I fail to understand how we can require code level migration for each release.”

  • Julian Ospald: “This difference is very stark and should serve as a reference point when discussing diverging goals in our community.”

  • Andrew Lelechenko: “Things however change when you are at the receiving end. At some point it does not matter how well motivated was the change or how many papers and committees support it. Enough is enough.”

  • Moritz Angermann: “continuously breaking the compiler causes massive costs to users when upgrading for no obvious value other than ‘staying current’”.

  • Enes Bayram: “these packages resist GHC upgrades due to very minor problems.”

  • Julian Ospald: “9.6 has some pretty severe breakages”.

  • Haskell Foundation Stability Working Group: “there is a real appetite for movement from practitioners on some notion of stability.”

  • State of Haskell Survey 2022: 35% (360 respondents) said upgrading their Haskell compiler had broken their code in the previous year.

  • Simon Peyton Jones: industrial users “complain, quite legitimately actually, that things change too fast and that we just broken their code again and it’s too much work for them to fix.”

17 Likes
7

We must move in very different circles and read very different threads. As I’ve noted in the beginning, I too think it was the success, but outside the Haskell circle and more CS focused circles, this is a very common “critique” thrown around and people are parroting it. My thought is that over the past few years it has indeed started going down the “bad design by the committee” path.

I don’t want to be dismissive, but I don’t think quoting stuff from a:

  1. book about Haskell
  2. paper from 2012 which may have reflected opinion at that time in the academia
  3. random comment from YC, a response to which immediately proves my point
  4. a 7 year old thread on a sub-reddit dedicated to Haskell

is objective proof of anything (and neither is my claim, but it feels much more align with what I’ve personally observed).

Perhaps I wasn’t clear by what I mean by this. I’ve meant that instead of a new coherent language standard / version, there is just e.g. GHC2024 extension pack with IMO mostly syntactic improvements that just allow us to do stuff we’ve been able to do before, but with more convenience.

As for the mentioned extensions, for the lack of a better word, I’d say they are again, mostly syntactic improvements, but perhaps you had different interpretation of what this means so I’ll try to paint a picture of what I mean:

  1. ExplicitLevelImports: This can be resolved with a qualified import at the moment so it is, in my book, a “syntactic” improvement, albeit a necessary one for ergonomic dependent types use.
  2. ImplicitStagePersistence: Again, “syntactic” quality of life improvement that allows us to use TL identifiers within TH sparing us a few keystrokes.
  3. NamedDefaults: Not really a “syntactic” improvement, but something that enables a defaulting mechanism for custom types.
  4. RequiredTypeArguments: I’d also classify this as syntactic as it doesn’t really introduce new capabilities, just a nicer syntax for what we already could do, e.g. Proxy. Although it’s definitely a nice for QOL.
  5. TypeAbstractions: This again is to me nothing new, and just a nicer syntax for binding type variables.
  6. TypeData: Again, a nice “restriction” of what we already had. Essentially promoted data types with removed value level interpretation.
  7. DeepSubsumption: An extension that enables old behavior

Just note that I’m not disparaging these extensions. Every single one has it’s uses and effort was put into them. I’m just trying to say that nothing particularly new was introduced into the language. And some, like RequiredTypeArguments, TypeAbstractions, and TypeData will ultimately lead to dependent types which is something I would consider actual advancement of the language.

Now that I think about it, “ergonomic” is the word I was looking for instead of “syntactic”.

By this I didn’t mean on the GHC stability, or the standard library level. I’ve meant the language level. There are no improvements to the language that introduce backwards incompatible changes.

Language extensions are “opt-in”, there’s no drive to say e.g. “dudes, we need to really go and re-do the module system from the ground up”. While we have the linear types frontend, the base package is pretty much useless with linear types, and again I have to “opt-in” into the linear-base.

Anyway, I think there’s no “vision” for the future. Just very incremental improvements that try to “patch” some inconveniences.

8

The only language circle I move in is Haskell’s, so I would certainly have missed the criticism if it was levelled at Haskell in the community of another language. It would be an easy criticism to make, however, if Haskellers were not around to respond.

Please share quotations, otherwise your claim is not particularly understandable nor actionable.

Seems reasonable. Could you move the discussion forwards by suggesting a possible change to the language that is beyond the ergonomic but is somehow stymied by the workings of the GHC steering committee?

There certainly have been. One relatively recent one one which caused a lot of pain was the change to shallow subsumption with no way to go back to the old behaviour (until DeepSubsumption was introduced).

I don’t really follow. Where do you expect this vision to come from? Plenty of people have their vision for Haskell and they’re busy putting it into practice, both at the language and the library level. They are constrained to some degree by the recent consensus that existing code shouldn’t be broken too much, but probably to a greater degree by the simple costs of getting hard things done. But certainly if someone had a radical idea to dramatically improve Haskell, yet it would break a small number of existing users, I would expect that idea to make it through committee review, assuming that person was willing to put in the work to advocate for the idea and justify its benefits.

Perhaps you have a vision for Haskell and you’re disappointed that Haskell isn’t moving that direction? Well then, great, but you have to publish your idea and build consensus around it! Please do.

7 Likes
9

It is often the go to beating stick (along with “academic language”) in popular programming related podcasts by “real engineers” who “deliver”. I can go and find some of those, but since you’ve just concluded you won’t watch the linked video I kind of don’t see the point.

Anyway, my point was that it indeed was a success, but now it’s starting to suffer from the issues usually associated with committee based languages.

The committee?

I very much like linear and dependent types, but I think they suffer because of the “responsible” conduct that’s become the norm. In this case I’d expect the “GHC steering committee” to say “let’s do some major breakage and commit to this” instead of choosing the slow death approach by perpetually testing the waters through tacked on extensions that will get harder and harder to maintain as the time goes on.

The current situation reminds me of the “self-organized criticality” where Haskell will be largely abandoned.

10

It’s up to you, of course. I can’t guarantee how I’ll respond to any particular person’s postings here, but I certainly can’t see you making a convincing case without explicit examples.

Ah, you may have misunderstood the role of the GHC steering committee. It is nothing like that of the committee which designed the language in the early days. It is an organisation which votes on which changes can be made to the language which GHC implements, it does not per se design or propose such changes. If you want a change to GHC you propose it to the committee. Then ultimately they vote to accept or reject the proposal. See the committee README for more information.

Ah no, it’s on you to persuade the committee that that would be a good idea. If your argument is compelling enough, you will succeed! They are rational people. You’ll have to do the legwork though. Please do. Your vision sounds exciting.

4 Likes
11

No. You are constantly misunderstanding my point. As I’ve said earlier, Haskell was a successful “designed by committee” language because as you yourself say, the early committee is nothing like the committee nowadays.

This stuff where “reasonable” people vote is exactly the problem. They will always vote on the “reasonable” and “stable” stuff that no-one can really argue against, and no-one will be able to blame them if it ultimately fails.

It also induces self censorship in anyone who wants to make a proposal making them settle for a “reasonable” approach instead of total overhaul of certain features as they want their proposal to be accepted by the “reasonable” committee.

In ideal world, committee would say e.g. “we are initiating the effort to do a complete overhaul of the module system that will break backwards compatibility, please join us in this effort”.

This I think is much needed approach to motivate people to dedicate their time on contributing, as they have the power to focus effort of many people, instead of making an individual lead the initiative and try to convince a bunch of “reasonable” people to do a certain thing.

1 Like
12

Perhaps. I shall endeavour to do so, but can you help by illustrating what you mean in a way that makes it easier for me, perhaps including providing examples?

It’s not just “nothing like” it. It isn’t it, at all! It’s a different body for a different purpose. The GHC steering committee is not “the committee”. The most recent incarnation of a committee for a similar purpose as the original committee is the Haskell Prime committee. You might want to look into the history of that effort.

Can you bring some evidence to support this claim? For example, proposals that were brought that should have been accepted but that were rejected? Historically you’ll probably find they accepted all sorts of proposals that caused existing code to break, yet that didn’t somehow make Haskell a more popular language. In fact I think it had the opposite effect.

That’s not something the GHC steering committee does. It’s simply not in its remit, like it’s not in the remit of the Haskell Foundation board or the Haskell.org committee or the Core Libraries Committee or the Rust steering committee or the United States House Committees on Armed Services. None of those committees are for the purpose of initiating the definition of a new version of the Haskell language.

Now, any of them could do that, in principle (for some it would be more surprising if they did so than for others). But why would they? The people who joined those committees didn’t join them to do that. They joined them to do something else.

If you want to say “it’s a shame that people in the Haskell community haven’t spontaneously formed a committee to develop a new backwards-incompatible language version with all the goodies that I want in it, and spent their political capital bringing it into existence” then that’s fair enough, and I can sympathise. I think it’s a shame too.

But many people (including myself) are already busy using Haskell as it is for getting a lot of stuff done, and are both too busy to try to define a new language version and finding that what already exists in Haskell suits our purposes.

If you want to use your time, energy, political capital and perhaps even cash to form and contribute to such a committee please do. I’m not being snarky or sarcastic: I would love to see it! The effort of people freely giving those things to the benefit of the community is the only reason we have the ecosystem we have.

I’m even willing to share with you how I’d go about doing such a thing, if you’re interested.

3 Likes
13

I think it’s a good thing that people can try out extensions and move their programming forward without everyone having to use features that aren’t necessarily fully stable. I hope that with the extension editions, we can start to use these feature sets to a greater extent, and they become standard use.

I’ll say in favour of what Tom’s saying: committees don’t have ideas, people have ideas. It’s easier to put together a wishlist of a what you want in your new language than to radically revamp your language that thousands use daily; but incremental changes and improvements (which are breaking changes!) help get us towards that future.

I, myself, am shepherding such a breaking change that will improve the language for the better: Monad and Monoid Canonicity: Removing Methods `return` and `mappend` · Issue #328 · haskell/core-libraries-committee · GitHub. Unlike Go, or Rust, or many other languages however, we do not have nearly the same amount of resources. Many folks are volunteers, and those that aren’t still have a limited amount of time to tease out bugs and improve performance instead of dreaming up new and interesting ways to break backwards compatibility.

3 Likes
14

I don’t know how to talk with you anymore. You just seem to want to avoid the core of the argument, which is that the current system is relying on individuals with a vision, instead of a governing body with a vision. And the individuals with a vision have to appear appealing to the committee for their proposal to be accepted, which ultimately lead to “safe” choices that cause slow decay overall.

And you also keep deflecting to stuff like “oh, but this body is not for this or that” while, again, avoiding the core argument that I want a certain type of body to exist, and that the current stuff that we have is exactly what is commonly recognized as the “bad committee” as opposed to the body that initially created Haskell.

It also seems like you think I’m proposing this body should do the work of implementing stuff itself, while I was proposing they only “advertise” the initiative and create permission structure where people do not have to be reserved abut such major changes.

15

It feels like people are simply not reading what’s being said. These small improvements certainly have great value, and I’m not against that, but there’s only so much you can do with such incremental changes.

There has to be an occasional cleanup and consolidation of features “blessed” by the governing body, otherwise what you get is a duck-taped frankenstein monster.

16

From my point of view you seem to be doing fine! Sorry if that is not how you experience it. I shall endeavour to do my best to understand what you’re saying, but I can’t guarantee I will succeed.

Not at all. I have no intention of avoiding anything. It hasn’t been completely clear to me what your argument is, but it’s becoming clearer, I believe. Let’s see.

Yes, I think that’s true. To show my cards up front: I’m pretty skeptical that “a governing body with a vision” is a plausible concept. I think individuals (or maybe small groups) can have a vision, and governing bodies are the conduits through which a vision can be turned into reality.

I agree.

I disagree. I don’t think there’s anything standing in the way of someone submitting a good proposal for a radical change to GHC and getting it through the steering committee, except that fact that radical changes disrupt the lives of many Haskell users, including those (perhaps especially those) working in industry.

The steering committee is the body ultimately responsible for placing a high bar on such proposals and if the committee didn’t exist the high bar may not be there. But if the committee didn’t exist the problem would just shift elsewhere, for example to many industrial users simply leaving Haskell.

Now, if someone or some group comes to the steering committee with a radical proposal that would cause breakage to existing code but nonetheless the proposers can convince the committee that the change is broadly beneficial overall to a wide range of stakeholders then the committee will accept it. Why not?

I just don’t believe there’s a fundamental impediment on radical change as a result of the operations of the steering committee. I think the impediment comes from many GHC users not wanting radical change! That’s a quite different issue.

[OK, well it shouldn’t be, because it’s not the same thing at all. I don’t think a “committee language” or “design by committee” typically means a language which is governed by a steering committee like GHC’s but rather one in which each committee member is trying to push their own special interest to the detriment of the quality of the design. I think that’s a minor terminological point, so I’ll try not to labour it further. If you or anyone else wants to call it a “committee language”, go ahead. I don’t care about the nomenclature. I think it has no bearing on the analysis of the situation.]

Aha! Now we’re getting somewhere. You want a certain type of body to exist. How should it come into existence?
Do you agree with me that it takes some work to bring such a thing into existence? Who will do that work? You, or others? Or maybe you disagree with me, and think it takes no work to bring such a thing into existence. I think it would drive the conversation forward if you could explain your point of view on this issue.

To be clear, no, I don’t think that.

Seems a fine thing for a body to do. But how do you propose they “create permission structure”? I guess to do that the body would have to be composed of people that are broadly trusted and recognised as authorities in the Haskell world. Are you saying they should be willing to volunteer their time, energy and political capital on the project? Maybe they should! But could you justify that further?

Now, if you want to say “the current setup we have with the GHC steering committee is leading to sub-optimal outcomes for GHC, Haskell, and the ecosystem” that’s a valid thing to say, but it needs careful analysis. You might want to refer to important proposals that would have been very beneficial but were held up in the review process. You might also want to claim “chilling effects” whereby the very prospect of steering committee review stops someone from even thinking about, let alone working on, a proposal.

But the onus is on you to provide such an analysis, taking into account the history of the body, why it was set up, the work that went into promoting the concept of language stability and the reasons behind that. If you can do that, great, but linking a podcast by a “real engineer” who “delivers” won’t cut it, because the people who typically have trust and authority in the Haskell world are also examples of such, with limited time, and have to choose carefully what they spend their time on.

In good faith: if you do want to do that, great! I’m sure it would be helpful. I’m willing to help you, particularly to help you understand more of the history around the push for more stability in the Haskell world (“real engineers” who “deliver” generally prefer stability). I think it would be useful for the community.

Alternatively, you might have an idea for a breaking change to the language whose benefits would outweigh the costs its imposes in breakage. Great! I’m also willing to help introduce you to the GHC proposal process so you can try to turn you idea into a real proposal. I can’t guarantee your proposal will succeed, but I can guarantee that if it doesn’t you’ll have gained some invaluable knowledge for participating in debates like this in the future!

If you don’t want to do that, that’s fine. But don’t be surprised if things don’t magically change in your favour for free.

Thanks for your work on this! It’s an important part of modernising the language. This is a good case in point because the change itself is tiny but it is a lot of work to do the necessary stability analysis and submit all the required patches. It takes a long time to get that kind of thing done (which I think is essentially the kind of thing that @mastarija is objecting to).

3 Likes
17

For me, the existence of all of the language extensions and the extension collections like “GHC2024” is evidence itself that there’s a need and a desire for a more comprehensive overhaul of the language. I think the linked video also illustrates one pain point where every time I use type classes I have to increase a bunch of little language extensions, each of which is just a “patch” on top of a previous patch, each one introducing a little bit more syntax stuff and it’s own little rules.

To me it is a common sense that such direction is unsustainable long term, and the “governing” structures that exist are exactly the structures that will stabilize thing short term, but cause decay long term.

You seem to disagree and you think there’s no fundamental problem with the way things are. This essentially boils down to who has better perception of reality, otherwise I think we are both capable of fairly logical reasoning.

All I can say is that I recognize these “structures” from experience, and I (think) know where they lead. They are also very much universally recognized in the society. You seem to like citations, so here are a few interesting (hand picked artisanal:) references:

I believe these more formally explore widely recognized detrimental social structures. The only thing that’s left is whether Haskell community has setup such structures or not. And the only proof I have is “just look at it”. I don’t think I can prove that to you in any better way.

I agree, but such endeavor requires a lot of energy to push through, and people will simply turn their attention to other things if there’s too much friction. This also happens even with simple contributions to GHC because the whole setup to even start contributing is really annoying due to a lot of “tacked-on” code that accumulated over the years. And this is why there aren’t many people willing to work on GHC IMO.

1 Like
18

We got linear types relatively recently (cosmically speaking). and dependent types are slowly but surely on their way. doesn’t feel like a language frozen in time to me.

3 Likes
19

both these features require changes to Core iirc (which is the secret sauce of Haskell - it’s a production grade language that takes a detour in System F on its way to becoming machine code. This is a big reason linear/dependent types can be layered on.)

1 Like
20

Doesn’t feel like you’ve read the argument. I’ve clearly stated these two as things are actual progress, but even in those cases we bend over backwards as to not disturb backwards compatibility. This IMO will result in a lot of clunkiness and more complications down the road.