On Wed, May 22, 2013 at 9:18 AM,
2) That there are so many Prelude replacements... and that none of them are worth it enough to induce people to add the two lines of code it takes to use 'em.... tells me that they don't have enough value.
Other reasons are a) not widely known - no Haskell book mentions them, and b) introduction of another package dependency (a major concern for me personally)
For the last year or two I've been doing exactly this--adding the two lines of code in every module to import my own alternate Prelude, which has many of the changes which are obviously a good idea (replacing monomorphic functions with generalized versions, re-exporting Applicative and Monoid, &c.) and a few which are obviously a bad idea (re-exporting the entirety of Control.Lens). It's not very polished and not really intended for anything but my own use, but saves me a great deal of annoyance. If that was all there was to it I'd be content leaving the official Prelude to stagnate, crushed under the weight of mailing list arguments as unending as they are unproductive. Some things simply aren't reasonable to fix by way of using a different Prelude-like module. Replacing standard type classes outright causes massive interoperability headaches with everyone else's code (and in some cases makes things nearly unusable due to the limitations of the defaulting mechanism), but I can't just add the Applicative constraint and remove fail to fix the existing Monad class. Alternate Preludes will always be either superficial or unusably incompatible.
3) Stability is very important to adoption of a language. People are very influenced by their first impressions of a system. We seem perilously close to "death by continuous little paper cuts" here: I saw the catch debacle snag tons of people and projects in tiny hiccups. If you were a newcomer to Haskell (experienced engineer or no) and you ran into this, I bet it was a turn off.
In generaly I'm against the constant evolution of Haskell. Revising the language every year (or even every two), and revising the core libraries and modules and Prelude piecemeal seem to me like recipes for avoiding success. Now that functional programming is gaining some notice in the wider engineering world, now would be the time to have the most stable, most "always just works", most reliable language of the lot. That probably means stability trumps warts. Not forever, but it means avoiding a constant stream of hiccups.
This is a valid concern, but I can easily imagine the rationale of "functional programming is gaining popularity - don't scare people away now" preventing us from making changes for several years.
No, it's not. It might be a valid concern if more than a meager handful of warts had actually been fixed in the past decade, but the world you easily imagine turns out to be the one we already inhabit. The status quo, just so we're all clear on this, is to leave the major warts in place indefinitely due to inane bikeshedding and vague, mostly-unspecified concerns about being disruptive, while fixing just enough small warts to ensure that every piece of old code breaks anyway unless someone manually makes the (usually simple) changes necessary. Utterly fantastic. The Haskell ecosystem as a whole--including GHC itself, ironically--evolves far more rapidly than the core libraries (or the language standard) do. Widely-used packages make breaking changes and bump the version number and--somehow!--life goes on. This creates predictable amounts of angst and chronic strife concerning Cabal, but not a great deal more complaints about things changing at all, which leads me to conclude that the quantity of opposition to breaking changes is not a function of either the quantity of changing or the quantity of breaking involved. Suggestions that the changes which are currently not being done should be done more slowly really ought to be accompanied by a suggested time table and plan for implementing the changes, if intended as anything other than a motion to continue postponing all improvements indefinitely.
A "continuous improvement" model of small changes we all adapt to could be less daunting to beginners.
Also, the case has been made for beginners, but what about "intermediates"? Trying other data structures will be much less foreign if they've been raised on Foldable and Traversable.
I'll say it again: Design for people using the language, not for people learning it, if you want them to continue doing the former when done with the latter. - C.