Drastic Prelude changes imminent

[davean]

On Sat, Jan 31, 2015 at 1: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.
>

It is very painful the prelude isn't more generalized. Its the first thing
that bit me learning Haskell and its pained me the entire time I've used it.


> 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.
>

Personally, I want a language thats good to use. That means constant
improvement. My life gets better by far more then it costs me to update
some code in fairly trivial ways when the language or libraries change. In
fact, Haskell makes updates easy. Why should we instead build up the need
to replace the language with a new one, how is that better? We can have
constant gradual improvement, or force an entire change of language. I for
one will take a constant improvement every time.


> 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.
>

I think they're exactly who not to take our queues from. I think they're
the perfect example of how to make bad software and I really don't want to
be them.


> "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.
>

Alternative we must do it to keep advancing.


> If we make a change like this, we've just told the world to wait another
> 10 years before considering Haskell.
>

Or told people who should consider Haskell. Perhaps that is good.

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.
>

And we shouldn't have it. Its good we don't have it. Its why I'm here
frankly. The constant drive for improvement is how its solve the problems
that make it worth coding in. Lets instead of being adopted have the best
language possible and the most pleasant time programming in it. Lets not
tear our hair out because someone made a bad decision in the 1980s and now
we're stuck with it. I've done that. It was terrible. The world doesn't
need another language that makes that mistake.

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