Drastic Prelude changes imminent

[Gershom B]

Hiya Mark.

Your note was pretty passionate, so I hope you’ll forgive me if mine is a bit strongly worded as well. There’s a phenomenon, especially on the internet, where people don’t make arguments of the form “I don’t like” or “I don’t want” or even “I think” but instead of “Personally, I’m fine with X, but I can see how see how _others_ could…”.  I tend to think of this argument as a form of ‘concern trolling’ even though I know that is an overloaded term that maybe has too many other connotations.

In any case, I have seen a lot of this form of argumentation in the Foldable/Traversable discussions. “I understand this stuff perfectly well, but I can see how  a beginner could…”. “I of course can fix up my libraries in an afternoon, but I can see how this would cause trouble for others…”. “Patching my codebase to handle the change isn’t bad, but I can see how others who might want to adopt Haskell could…”

So what’s the problem here? Bluntly, if somebody has an objection, we have a chance of convincing them. If imaginary rhetorical strawmen in somebody’s head have an objection, we don’t have a chance of convincing them, or even having a proper dialogue with them, because nobody can speak to these imaginary people outside of the person that is imagining them.

In this case, I know that you have a tremendous amount more industry experience than me, and in fact than many others of us, but I nonetheless think you’re engaging in a form of this advocacy on the part of invented parties. Let me explain why. In the course of writing “industrial Haskell” I have discovered that one of the _first_ things that many Haskell shops do is to settle on a standardized, “custom” import list for their stuff. Often, this list omits the partial functions from the import of Prelude. Sometimes, it is packaged up as a convenience module, sometimes it is just a chunk of import statements. These imports include chunks of Prelude, chunks of Base, and often, chunks of whatever homegrown “enterprise glue” utilities that a given shop has come to rely on — logging, parsing, configuration, sometimes communication, etc. So what affect does a change in Prelude have in such systems? Often, much less than if there were not such standards. And furthermore, if you’re using a custom convenience module anyway, you have a mechanism for managing the impact of changes in Prelude in a fairly modular way.

I’m not saying every “Industrial Haskell” shop now does something like this — but honestly, those that don’t should, and this is the sort of thing that, as industrial Haskell adoption grows, will clearly get adopted as a “best practice.” On top of this, industrial shops, unlike library authors, have a much stronger set of controls on the environment they expect their code to work in. You can set a companywide standard for a version of GHC, and cutover to new versions on a controlled schedule of your choice, in a coordinated fashion. You can lock down package version numbers strongly and migrate them all at once. Etc. Again, even though some shops may not do this uniformly, it is certainly a best practice with many benefits, even absent any changes in the Prelude. And its implementation again strongly mitigates the effects of such changes.

In any case, let’s not set our sights too high. It may be that “the 80%” of large shops won’t adopt Haskell anytime soon. Frankly, I don’t think that Prelude instability will be the reason why. How many developers at how many shops have heard of Haskell and take it seriously as more than a curiosity regardless? How many, even when they hear about Google or Facebook adoption say, “Ah so it is a fancy language for big problems faced on the bleeding edge. Me? I’m just writing some typical stuff, who cares?”

Let’s have some proportion. For all our adoption, for Haskell to become even a “2%” language across industry would be a few orders of magnitude growth from where we are now. As far as I know, no other language with our current user base has felt the need to lock things down so tightly at this point on the growth curve. If, at this stage in its career, Java can get lambdas, that almost seems a constructive disproof in itself of the “widely used things shouldn’t evolve” principle you seem to be describing.

From my standpoint, the ironic thing is that we have endured far more seriously and wide-ragingly breaking changes over the course of prior GHC releases for years, but they have not generated this much heat because they have _looked_ innocuous. So we finally have a core libraries committee that is tasked with trying to make changes in a smooth way. And the changes here proposed are _very_ smooth! But now, of course, the care that was taken to make sure everything works cleanly and smoothly itself has now generated backlash, because it makes the surface area of this change _look_ larger.

Honestly? The Prelude is just the set of stuff in scope by default. If the entire prelude consisted of one function that drew an ASCII fish and nothing else, I could live with that. My main inclination here is to trust the core libraries committee to do its job, and to see what benefits that brings over time, rather than killing off this entire direction of work before it even has a chance to begin to prove itself.

Cheers,
Gershom

On January 31, 2015 at 1:19:18 AM, Mark Lentczner (mark.lentczner at gmail.com) wrote:
> I'm sorry for being so behind the times, and now have to write this at this
> stage...
>  
> BBP deeply saddens me. While I understand the desire for a more generalized
> Prelude (surely this is one of the seven stages of Haskell, along with
> "need to write a Monad tutorial"....), I don't think the ends come anywhere
> close to justifying the means.
>  
> I realize I'm often (always?) the voice of stodginess. But I'll tell where
> I'm coming from: I want to get people to adopt Haskell for serious software
> development. But that means I have get them to buy into an ecosystem and
> for them to do so they need to feel it will be stable on the order decades.
> They need to feel that before they're going to be willing to invest in the
> tooling, the process development, and committing their work to Haskell.
>  
> In 1990 most shops wouldn't ship software in C++ because none of us trusted
> the compilers, or that language (already C++ 2.0) wouldn't change in ways
> that would be unpredictable and negatively affect our work. It took almost
> another decade. In 2005 many places still wouldn't ship things using STL.
> It takes a long time for people to trust that an ecosystem has stabilized.
>  
> "Burning Bridges". The name says it all. We cannot do this. We have to look
> well beyond how a change like this affects compiling a bunch of code form
> stackage... We have to think beyond the discussions on our mailing lists...
> Think of the text books, the corse syllabuses, the in-house trainings,
> think of work flow and deployment processes.. think of vast amounts of code
> we can't see... We cannot undermine the Prelude and Data.List that they are
> all built on.
>  
> If we make a change like this, we've just told the world to wait another 10
> years before considering Haskell.
>  
>  
> The sadder thing is that I don't think the proposal really adds much to
> Haskell:
>  
> The value of generalizing the list functions greatly over estimated: There
> have been alternate, more generalized Preludes for ages... and I don't see
> much use of them. Sure, they require some futzing with imports to use - but
> that isn't that high of a bar, and yet clearly their value rarely merits it
> in people's minds. Maybe I don't write the most clever code (code golf
> excepted), but I rarely pine for a more generalized length. Or for all to
> work over Foldable... etc.
>  
> For the few times when I need something like Foldable I don't see what the
> issue is with importing qualified and using prefixes. People here seem to
> feel that a "F." is somehow an ugly wart on their code... but that is just
> the way it is with most software: You need a lot of things in scope, you
> use namespaces of one sort or another.
>  
>  
> There's also a whole issue of commitment to forward and backward
> compatibility that we as a community don't yet have. Littering our code
> with CPP is not really acceptable. And all production code insists on clean
> compilation with -Wall, so we can't be spewing warnings. Or for that matter
> playing tricks with import orders. This stuff is tricky and hard... no
> doubt, but it is the price of a bid at adoption.
>  
>  
> All in all, what saddens me here is that this whole episode, like the
> similar one around roles and 7.8, is indicative that on the whole, we as a
> community, are not ready to hunker down and work toward making Haskell a
> solid tool for software development. We are, instead, too fascinated with
> making it more perfect.
>  
> - Mark
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>