13 ms·
Some loose thoughts: A lot of this boils down to figuring out a delegation model that works for Elm. Does the BDFL of the language really also need to be the
by tazjin 9y ago
Some loose thoughts:
A lot of this boils down to figuring out a delegation model that works for Elm.
Does the BDFL of the language really also need to be the only person maintaining core libraries? The only person maintaining project communications?
In this particular case it feels like the Elm team is afraid of "losing control" over the language.
That's often in direct contradiction with the project becoming more popular, so for a while maintainers need to choose between advocating the thing they're building and advancing it in the way Elm is currently being advanced.
Once things like [1] start appearing in the codebase you're basically asking people to fork your project and what happens after that is unknowable ...
[1]: https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72 https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...
- always_good 9y agoI've been using Elm for years now and it's always been openly admitted that core abstractions are still being decided. You can just look at the change log between versions (which are all sub-1.0) to see that. You have to be okay with that to use it in production. Else you would have used something more stable instead of decided to gamble. I think Elm is still too early to bike-shed over governance model. And people seem to think Elm is a lot farther along than it really is. Else they wouldn't have the expectations that they do. Or they wouldn't go "I don't have these issues with React." I think the social issues Elm has are just what it's going to take if Elm wants to arrive at something more compelling that just another language. If there's a continuum with BDFL on one side and design-by-committee on the other, then you're going to have issues no matter where you move the needle. The upside of the bus-factor-of-1 approach is that you have a visionary in the Hickey hammock. And the unavoidable downside is that you have to deal with the bandwidth of one person which describes a lot of the social issues. I think that anyone who is uncool with that reality chose the wrong language. And a lot of the criticism that results from that, like this: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/ https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing..., starts to reek of the hot air of entitlement, to use Rich Hickey's words.
- rtfeldman 9y ago> A lot of this boils down to figuring out a delegation model that works for Elm. I agree. This is harder than people think; we've tried some delegation models in the past that didn't go well, and we reverted back to the way things were previously. We're still trying new approaches. The next release will have a core module (Array) written and maintained by a community member (Robin H), and I predict the debugger will be the next core project to fully transition ownership from Evan to a community member. If these go well, they can be models for future delegation to community members! > you're basically asking people to fork your project and what happens after that is unknowable It's pretty predictable though - forks basically always fizzle out unless it's major contributors splitting off (as was the case with io.js), and there aren't factions like that among Elm's most prolific contributors. Turns out it's a lot of work to make something people really want to use!
- d13 9y ago> In this particular case it feels like the Elm team is afraid of "losing control" over the language. They should be.