4 ms·

These organizational breakdowns in tech communities (recently Rust,.NET, Elm) make me much more appreciative of long-running, relatively healthy communities.

nzach 5y ago
Can you elaborate on the Elm breakdown? I don't remember reading about it.
- foldr 5y ago
  There's been a longstanding issue that a lot of people are unhappy with the level of control that Evan exercises over the development of the language. On top of that, a lot of the development of the core language happens behind closed doors, which has given the impression of stagnation over the past few years. 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. In contrast, while someone certainly could release a Haskell library that made pervasive use of side-effecting functions, the resulting library would be horribly brittle and no-one would want to use it. Evan really wants Elm to be pure. To ensure it stays that way, he's banned community packages from using the Javascript FFI. This has been unpopular, but I think he's probably right that this is the only way of keeping the language pure. It comes back to the usual open source entitlement debate. 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. He doesn't see it that way.
  - nzach 5y ago
    Thanks!
  - iudqnolq 5y ago
    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.
    - azeirah 5y ago
      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.. :<
      - iudqnolq 5y ago
        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.
  - Hermitian909 5y ago
    > 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?
  - smitop 5y ago
    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/770071accf791e8171440709effe71e78a9ab37c/compiler/src/Elm/Package.hs#L85 https://github.com/elm/compiler/blob/770071accf791e817144070...
- frozenlettuce 5y ago
  some examples https://news.ycombinator.com/item?id=27808306 https://news.ycombinator.com/item?id=27808306 https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ and there's also the elm-pine issue, where an independent package manager was shunned by the core developers (note that the official package manager doesn't support basic features as repos not on Github)
oleganza 5y ago
Please don't confuse the breakdowns in specific political groups with overall community. In any realm there are 10-100s of quiet participants for each loud person who takes on some public role and tries to organize things. Enthusiastic bureaucrats often clash unless there's de-fact dictatorship that suppresses such conflicts before they create too much noise. But their problems are not representative of everyone else's work and participation.
nabla9 5y ago
Technical communities are formed around common purpose. They are not goals in themselves. Community needs only to be healthy enough to get things done. Take for example OpenBSD. Theo de Raadt may be an asshole sometimes, but he knows stuff can still steer the technology. OpenBSD is extremely opinionated even technologically, but it's really good.
- DominikD 5y ago
  This doesn't scale though, and OpenBSD - as much as I love it - is a clear example of that. Compare Theo who remains abrasive at times, and Linus, who realized that project the size of Linux cannot be handled with complete disregard for safe, inviting environment. Toxic leaders are the reason there's this idea that projects that are built on merit somehow must be ruthless and uninviting. It's really easy to e.g. confuse critique and criticism and in result give project the "avoid whenever possible" badge.

nzach 5y ago

Can you elaborate on the Elm breakdown? I don't remember reading about it.

foldr 5y ago
There's been a longstanding issue that a lot of people are unhappy with the level of control that Evan exercises over the development of the language. On top of that, a lot of the development of the core language happens behind closed doors, which has given the impression of stagnation over the past few years. 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. In contrast, while someone certainly could release a Haskell library that made pervasive use of side-effecting functions, the resulting library would be horribly brittle and no-one would want to use it. Evan really wants Elm to be pure. To ensure it stays that way, he's banned community packages from using the Javascript FFI. This has been unpopular, but I think he's probably right that this is the only way of keeping the language pure. It comes back to the usual open source entitlement debate. 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. He doesn't see it that way.
- nzach 5y ago
  Thanks!
- iudqnolq 5y ago
  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.
  - azeirah 5y ago
    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.. :<
    - iudqnolq 5y ago
      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.
- Hermitian909 5y ago
  > 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?
- smitop 5y ago
  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/770071accf791e8171440709effe71e78a9ab37c/compiler/src/Elm/Package.hs#L85 https://github.com/elm/compiler/blob/770071accf791e817144070...
frozenlettuce 5y ago
some examples https://news.ycombinator.com/item?id=27808306 https://news.ycombinator.com/item?id=27808306 https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ and there's also the elm-pine issue, where an independent package manager was shunned by the core developers (note that the official package manager doesn't support basic features as repos not on Github)

oleganza 5y ago

Please don't confuse the breakdowns in specific political groups with overall community. In any realm there are 10-100s of quiet participants for each loud person who takes on some public role and tries to organize things. Enthusiastic bureaucrats often clash unless there's de-fact dictatorship that suppresses such conflicts before they create too much noise. But their problems are not representative of everyone else's work and participation.

nabla9 5y ago

Technical communities are formed around common purpose. They are not goals in themselves. Community needs only to be healthy enough to get things done. Take for example OpenBSD. Theo de Raadt may be an asshole sometimes, but he knows stuff can still steer the technology. OpenBSD is extremely opinionated even technologically, but it's really good.

DominikD 5y ago
This doesn't scale though, and OpenBSD - as much as I love it - is a clear example of that. Compare Theo who remains abrasive at times, and Linus, who realized that project the size of Linux cannot be handled with complete disregard for safe, inviting environment. Toxic leaders are the reason there's this idea that projects that are built on merit somehow must be ruthless and uninviting. It's really easy to e.g. confuse critique and criticism and in result give project the "avoid whenever possible" badge.