<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 31, 2015 at 1:18 AM, Mark Lentczner <span dir="ltr"><<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm sorry for being so behind the times, and now have to write this at this stage...<div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.</div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.</div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>"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.</div></div></blockquote><div><br></div><div>Alternative we must do it to keep advancing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If we make a change like this, we've just told the world to wait another 10 years before considering Haskell.</div></div></blockquote><div><br></div><div>Or told people who should consider Haskell. Perhaps that is good.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The sadder thing is that I don't think the proposal really adds much to Haskell:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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. </div></div></blockquote></div></div></div>