Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Ivan Perez]

On 03/10/15 09:00, johan.tibell at gmail.com (Johan Tibell) wrote:
> -1 from me as well.
>
> I don't find the proposal convincing.
>
> Cons:
>   * Major breakages to existing code (which needs to be updated), docs (many
> of which can't be updated), and future code (coding with ifdefs is error
> prone).
>
> Pros:
>   * A feeling of cleanliness.
Completely agree.

-1 for us too.

Breaking changes are a major problem for us:

- At Keera Studios we are maintaining a bunch of legacy libraries 
internally (some of which we
are releasing back via github), for all platforms.

- Also, GHC's Android backend is currently based on 7.8, and don't have 
the manpower to maintain it.

> I think there's an implicit argument being made here, that if we let time
> go towards infinity every breaking change is eventually paid off, no matter
> how small the gain. Time doesn't go to infinity for us. Haskell currently
> has a window of opportunity for being adopted and bringing more functional
> programmers to the world. This window isn't very big, perhaps a couple of
> years to a decade. If we make programming in Haskell annoying by
> continuously breaking anything, people will lose interest in Haskell and
> move on to other languages.
In general, regarding how these changes are being introduced:

Time runs fast for us, and our company sits in this window of 
opportunity that Johan mentions.

While we understand that changes are necessary, and that this kind of 
change benefits from spread adoption to test the community's response 
quickly, the decision process that is currently taking place leads to a 
form of continuous releases that breaks libraries very often. This costs 
us a time that we simply do not have.

We currently deploy Haskell worldwide. Even if our audience is 
relatively small in numbers, it is geographically spread. Frequent 
backwards-incompatible changes require huge amounts of testing if we 
want to do things right. Testing, in our market, without access to your 
client's terminal, is expensive.

We prefer to invest time once, fix legacy code once, test it once and 
know it's set and working for 3-5 years at least. We have users who have 
been running updates of the same Haskell software for 4 years straight 
now, without ever hitting a runtime bug. We see consider that not our 
success, but Haskell's. We'd like to keep it that way.

Ivan