Drastic Prelude changes imminent

[Mark Lentczner]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150130/0db12cea/attachment.html>