> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.
I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.
We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.
It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.
Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.
There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.
> But not having an idea of what the roadmap or timeline looks like is a big deal.
The two options here are:
1) Be honest
2) Try to trick bosses
There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.
So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)
We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.
If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. [0]
This is how we've ended up with a community of people who largely don't think it's a big deal: process of elimination. Everyone who considered it a deal breaker is still using JavaScript.
I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)
> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.
I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.
We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.
It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.
Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.
There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.
> But not having an idea of what the roadmap or timeline looks like is a big deal.
The two options here are:
1) Be honest
2) Try to trick bosses
There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.
So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)
We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.
If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. [0]
This is how we've ended up with a community of people who largely don't think it's a big deal: process of elimination. Everyone who considered it a deal breaker is still using JavaScript.
I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)
[0] https://github.com/elm-lang/projects/blob/master/roadmap.md