By Artyom Kazak aka @availablegreen
January 9, 2021
🧱 This post is written in Brick — a platform for writing pretty public notes, which I co-founded. Using Brick has significantly increased how much I write. If you try it out, I'd love to hear feedback on Twitter or at artyom@brick.do.
I have already talked about all of this on Twitter, but here is a summary write-up.
My working hypothesis right now is that Haskell should be split into "Haskell" and "Boring Haskell".
Note that I am proposing something more radical than what is usually meant by "Boring Haskell". Eventually I want the languages to diverge completely — with a forked compiler, ecosystem, subreddits, etc.
Let me elaborate.
Haskell was created as a single language for a) research, b) teaching, and c) production. (See Haskell Report, "Goals".)
I think this goal should be narrowed down.
In particular, and to make the disagreement as evident as possible, I see a lot of people pushing for "increasing Haskell's adoption in the industry". I don't think it's a particularly worthwhile goal.
In my opinion, Haskell brings the most value as a testbed for figuring out how to marry advanced type systems and "production" — I don't think there are other languages that achieve this goal as well as Haskell does, and this is the irreplaceable bit about Haskell. By focusing on this specific goal, perhaps we would make progress there faster.
I think the other good bits about Haskell are not irreplaceable at all:
Interestingly, "bring advanced type systems into production" is not a goal that I care about personally. However, I suspect it's important enough that keeping it going would be worth it, and Haskell is a big player on this scene, and so keeping Haskell going is worth it.
This is the assumption I rest my thinking on — that we should optimize for "marrying research with production" above all else. Why exactly would splitting Haskell help us focus on this goal?
As Evgeny Poberezkin pointed out, there are three camps in the Haskell community. The camps can be summarized as "production + maintainability", "production + correctness", and "research". His comment is worth reading in full:
There seems to be a split in the community into two (or even three) camps:
- the first is led by @snoyberg, that has a very strong focus on [Haskell] being a reliable tool for production code, and I should say I am using the stack (not just the "stack") it advocates - Reader pattern, unliftio (but not rio), etc. But to me this camp is taking it way too far - almost nobody came to Haskell with the desire to write "boring Haskell", many people I know chose Haskell because it allows to express type invariants in a wider range of scenarios than other languages. The top values for this camp are "reliability" and "approachability" - that is, be able to write production code that is highly maintainable by a wider group of engineers thanks to its approachability.
- the second group is a growing number of commercial users who care much less about "approachability", and much more about "rigor" - they have very high expectations of the correctness and reliability of the software systems they develop, and do rigorous modelling in types. Galois would be a prime example, but there is also a growing number of financial and communication sector companies who have very high expectations about software reliability that can be only achieved via type-driven / algebra-driven design approaches. For these users a wider range of scenarios expressible as type invariants helps them achieve their goals better.
- the third group is "research" - a strong focus on Haskell being a research playground for advanced type systems, and you, Simon, etc. seem to be here. This camp is super important, but unless it will see creating commercial and society value as a very important priority it risks losing industry support from both camps.
In a nutshell, I am worried that the first camp might win.
If it wins, the second and third camps might disperse. This is why I would like "Boring Haskell" to appear. Not because I myself want Boring Haskell, but because the first camp — including me — would flock away.
(I hoped Eta would become Boring Haskell, and thought being JVM-only was a brilliant move, but Eta seems to be dead.)
The camp that needs a good, teachable, reliable production tool, would probably have an easier life with Boring Haskell. A shared understanding of "we are making a language for such-and-such purposes" would make it easier to decide on new language features. As the simplest example — perhaps various quality-of-life tweaks like -XTrailingCommas would not be discussed to death for a year.
The camp that does research would also probably have an easier life with all the Boring Haskell folks leaving. Examples:
This leaves the middle camp — and they are essential, because without them the "production + correctness" equation would devolve into "correctness". If the first camp leaves, the overall effort put into GHC and the boring bits of the ecosystem will likely decrease. If it decreases too much, the middle camp might not be able to afford using Haskell anymore.
This is the biggest reason I am not sure splitting Haskell is a good idea after all. But there are other reasons, too:
Overall I'm not sure one way or another. But I'd like to see someone try anyway.
I don't think so.
Having different communities, in general, is an effective way to explore a bigger chunk of the design space that would be possible to explore with a single community — if only because different communities have different norms/paradigms/values.
You can possibly explore a chunk of the design space faster if you have more people on board (and even that is questionable!). However, at some point the boost you get from the community size will plateau out. You can't ever explore the full design space if you only adhere to a single set of values, and that's why we need competing sets of values.
One of Scala's goals seems to be researching how to marry functional and object-oriented programming. Some people are not interested in that.
See also: the top of Edward Kmett's head.
I haven't used either F# or OCaml. However, here are my guesses:
I don't know. This would very much depend on who actually kickstarts Boring Haskell.
Probably, we'll get a lot of stuff from Michael Snoyman's "Haskell: The Bad Parts" series: part 1, part 2, part 3.
A bunch of GHC warnings might become default and/or turn into errors.
I actually don't expect anything radical to happen at first; likely, the languages will start diverging with time as the compiler teams prioritize differently and/or different things will get funded. Growing apart organically is much easier than being bold and throwing features out immediately.
It's so, so, so nice to be using something that aligns with your goals. If Boring Haskell happened, I would probably wait a year (just to see whether it dies or not) and then start using it even if it only makes minimal changes.
I think that when your community is significantly volunteer-driven, the abundance of features might actually hurt the ecosystem — and commercial development relies on the maturity of the ecosystem. That is, I suspect that a) a smaller community with more narrow goals will produce a better ecosystem, and b) limiting the ways in which things can get done will also result in a better ecosystem.
Example: Haskell has N different ways to write a type-safe SQL library (with generics, with type-level schema declarations, with GADTs, with Template Haskell, etc). Correspondingly, we have N half-baked SQL libraries instead of a few good ones. I suspect that this is partly because writing a new proof-of-concept library is more fun than contributing to an existing one.
And, in turn, having N libraries probably means that there are fewer tutorials covering each library. Which makes using them harder.
As long as this kind of fun will remain an option, it will keep distracting people. By somewhat dialing the fun down, we might be able to change the output of the (volunteer-driven) community.
(Example: I don't know the Rust ecosystem enough, but it looks to me that their situation with SQL libraries is much better — everybody just seems to use Diesel. While in the Haskell land we have Beam, Persistent+Esqueleto, Opaleye, Squeal, Selda, and no clear winner among those.)
(Update: I am told that Esqueleto significantly improved in v3.4, so perhaps we do have a good DB library in Haskell after all. I haven't checked it myself yet.)
Counterexample: there is already a chunk of the Haskell community that tries to adhere to Haskell 98. Their share is probably decreasing, though.
If there was a community norm that "not using features beyond [latest standard] in production is a good and desirable thing", this would effectively limit the features. You might say "why don't we institute this norm" then, but I don't think you can institute such a norm in the existing community, not without bringing some kind of benefit to them — e.g. an alternative to GHC that is faster but supports fewer features.
This would also de-facto split the community, even if the compiler remains "Haskell".
If there is a norm to use the [latest standard] and nothing beyond that, there could very well emerge a single library that all adherents of the [latest standard] are using.
And, even if it had no documentation at all, it would likely still have enough third-party tutorials to blow e.g. Beam documentation out of the water.
I haven't mentioned Snoyman anywhere, have I.
This said: Snoyman himself doesn't prevent advanced features from happening, sure. Does the whole "boring production" chunk of the community prevent them from happening? This is more debatable.
-XLinearTypes?-XLinearTypes must not unduly increase" and "There must be no degradation in runtime performance of GHC-compiled programs" were hard conditions put on the authors of the linear types proposal; so -XLinearTypes was merged into GHC 9.0 with major omissions, but at least error messages remained free of mention of linear types.Thanks to u/nuptions for the formulation.
I think you have missed the point.
I am not interested in growing Haskell's use in industry, among hobbyists, or in research. As I have explained in part I, my interest is in researching how to marry advanced language features with production — this goal is not helped when a large chunk of the community doesn't care about achieving it.