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