Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
The upshot of this e-mail is a strong collective -2 from us both on particular proposal, and a general call for much more caution when it comes to breaking changes that are not critically important. Thank you for articulating what are also my misgivings. -1 from me also.
On a historical note `return` used to be called `unit`. Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com
-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. 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. -- Johan
Hi all, Johan Tibell wrote: On 10/03/2015 09:00 AM, Johan Tibell wrote:
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.
Well said. That is also a major concern of Graham and myself. And it is not just people considering adopting Haskell who are being annoyed, but also long-standing members of the community. Just to give one data point, Graham tells me that the latest revision of Richard Bird's Haskell book was broken with respect to the latest changes before it had had a chance to hit the shops. The changes that broke the book may well have been essential. But such breakage is clearly annoying to many people, including those who have bought a recently updated book only to find that it does not quite work. We really need to be careful to not break things unless absolutely necessary. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
Henrik Nilsson
Hi all,
Johan Tibell wrote:
On 10/03/2015 09:00 AM, Johan Tibell wrote:
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.
Well said. That is also a major concern of Graham and myself. And it is not just people considering adopting Haskell who are being annoyed, but also long-standing members of the community.
That includes me. I have various pieces of software that I have written in Haskell over the years, and having fiddle with them pretty much every time there is a new release of ghc is very irritating. Obviously I don’t bother to recompile most of them every time, because one of the advantages of programming in Haskell is that I make fewer mistakes: so the code works and has done for years, but when I want to add a new feature or compensate for some change in the environment, what should be a 10 minute job ends up taking ages. -1 on the proposal. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
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
Perhaps introducing the change now, but extending the transition period until the next major breakage would bring the best of both worlds? Best regards, Marcin Mrotek
participants (6)
-
Dominic Steinitz -
Henrik Nilsson -
Ivan Perez -
Johan Tibell -
Jon Fairbairn -
Marcin Mrotek