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

[John Lato]

First off, I generally agree with Mark's comments.  That said, I think a
discussion of when breaking changes are adopted can (and should!) run in
parallel with any breaking proposals currently under consideration.

Aside from that, how does one run a build over all Hackage?  I saw this
very question last week, but didn't see any useful responses.  I know
others have done so.  Surely there's already a framework set up to do this,
yes?  Even if it is just shell scripts in a github repo?

John L.


On Wed, May 22, 2013 at 1:12 PM, Mark Lentczner <mark.lentczner at gmail.com>wrote:

> Ay yi yi!
>
> A few thoughts on all of this:
>
> 1) Rather than guessing how much will or won't break - would some please
> just run this change (F/T in Prelude) over Hackage and do some analysis and
> stats? Sure, it doesn't represent all code - but it's a good start.
>
> 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.
>
> 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.
>
> I think we'd be better served by "chunking" this stuff up over several
> years - and releasing it in well defined sets.
>
> 4) My reaction to the "monomorphism helps newbies" argument is always the
> same: Well then, let's just fix the error messages!
>
> - Mark
> 
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130522/c7a47270/attachment.htm>