3 ms·

> As I understand it, the fundamental reason for this situation is technical. It is really difficult to enforce purity in a strict language with an FFI, because

> As I understand it, the fundamental reason for this situation is technical. It is really difficult to enforce purity in a strict language with an FFI, because the behavior of side-effecting functions would be predictable and they'd be easy to use. My understanding is that 1. FFIs are still available to NoRedInk, Evan's employer. 2. The change was partly justified as a way to manage the Elm ecosystem. In general, Evan seems to have a history of changing the language in response to changes in the ecosystem that he does not like e.g. he did not like to kinds of custom infix operators people were defining so he removed the ability to define custom infix operators. > A lot of people seem to really deeply believe that Evan owes them something, and is required to manage his project along the lines of some kind of standard 'open source' model. I think this is slightly uncharitable. While I haven't followed his activities recently, Evan spent time trying to build community around Elm. People contributed to the ecosystem based on a combination of implicit and explicit promises that the community's needs would matter, I've chatted with a few people who say Evan gave them personal assurances about long term usability. Evan benefitted from some of these contributions, in prestige, bug reports, etc. Then Evan broke almost everyone's code and was unapologetic about it. I don't think it's unreasonable to feel like some kind of social contract was broken.

foldr 5y ago
I think the revealing term here is 'implicit promise'. A lot of people seem to have very fixed expectations about how open source projects should be run, and feel that they've been betrayed if a project isn't run in that way. I don't think Evan is to blame for that, though. The bottom line is that no project that's run by one person in their free time is able to give assurances of anything over the long term. I do think that if half of Evan's critics had the experience of running a reasonably popular open source project, they'd realize how meaningless any long-term 'assurance' is. I'm not sure what you're referring to when you say that Evan broke everyone's code. I was writing Elm code as part of my day job during the 0.18-0.19 transition, and it was not particularly painful. But this is all by the by. The fundamental question is the following. How would you propose to keep Elm pure while still allowing community libraries to access the FFI?

foldr 5y ago

I think the revealing term here is 'implicit promise'. A lot of people seem to have very fixed expectations about how open source projects should be run, and feel that they've been betrayed if a project isn't run in that way. I don't think Evan is to blame for that, though. The bottom line is that no project that's run by one person in their free time is able to give assurances of anything over the long term. I do think that if half of Evan's critics had the experience of running a reasonably popular open source project, they'd realize how meaningless any long-term 'assurance' is. I'm not sure what you're referring to when you say that Evan broke everyone's code. I was writing Elm code as part of my day job during the 0.18-0.19 transition, and it was not particularly painful. But this is all by the by. The fundamental question is the following. How would you propose to keep Elm pure while still allowing community libraries to access the FFI?