4 ms·
The big difference here is the cost: > In the particular example of (/=), there isn’t even any cost. There are ~50 packages that define (/=), and the solution
by Zababa 5y ago
The big difference here is the cost:
> In the particular example of (/=), there isn’t even any cost. There are ~50 packages that define (/=), and the solution is just to delete those definitions. Yes, it’s churn, but I personally am willing to send a patch to each package. If you’re the maintainer of such a package, email me and I’ll just go fix it for you.
The author also developped a semi-automatic tool for this migration: https://reasonablypolymorphic.com/blog/comby/ https://reasonablypolymorphic.com/blog/comby/. While as some people said, breakage is breakage, having a very easy migration path helps with that.
However, there's one point that isn't talked about here: code that doesn't get update often. Lots of small changes like that can be very annoying for code like that, but I don't see a good solution here (except to never deprecate anything).
- eyelidlessness 5y agoTo be clear, this is the part that sounds like Python 3 to me: > Since we’re just about to break things, might I again suggest we add Foldable1, and clean up Prelude? If breakage is breakage (it is), we might as well take advantage of it and do as much cleanup as possible. This is an excellent opportunity. The status-quo is for all of us to argue about it every week, with half the people saying “these are bad circumstances and we should fix them,” with the other half saying “yes, they are bad circumstances, but breakage is worse.” > But given that we now have breakage, let’s make the most of it. I don’t know how costly that larger scope is. Maybe it’s similarly low to this one change?