Hacker News Reader

> 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.

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?

The compiler literally checks what GitHub org originated the package. If you fork a package that uses FFI, it won't work unless you remove the check from the compiler or use a hacky workaround to trick the compiler: https://github.com/elm/compiler/blob/770071accf791e817144070...

Evan also wants to prevent people from making packages that solve certain types of problems so that he'll be able to make a better package in the future without needing to worry people might not want to switch because of backwards compatibility. I think that's entirely his right, but I'm skeptical it'll work.

Clojure and Common Lisp managed to have super stable community-built libraries. I'm not entirely sure what contributed to this (ie did this happen because of a stable core? Did this happen because lisps are somehow naturally conducive to stable extension?) but it's possible to have this happen without preventing community built-libraries.. :<

My impression is that Evan thinks a stable community built library that he doesn't like the feel of would ruin his language, so he'd rather have an unstable library he controls (because he doesn't have the bandwidth for everything). If this eventually leads to lots of stable great libraries written by Evan that would be nice, but until then it doesn't seem worth investing in. Here's what the author of a parsing library had to say

> Of all the changes in 0.19, this is the one that most hurt my code: I have parser combinator library, and used just two custom operators, for the very reasons that Evan points out in at the top.

> Now I learn that elm/parser can, and does, define two operators for parsing, for the same reasons my library had done so. There are indeed times when custom embedded languages with custom operators are worth the mental effort on the programming staff. Parsing is one of them, which Evan acknowledges, and indeed uses in elm/parser.

> However, it is not realistic to assume that elm/parser will become the only parsing package we ever need. For one, it only works on String. Parsing over byte arrays is quite common, (and what mine did). Even if elm/parse had been parameterized on the stream type - there are still differing implementation and functionality tradeoffs in parsers (backtracking, error tracking, error recovery, etc..) that make different parser libraries useful even they support the same stream type.

Thanks!