foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges

[Casey McCann]

On Wed, May 22, 2013 at 9:18 AM,  <amindfv at gmail.com> wrote:
>> 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.