I agree with a lot of this. I.e. 1) Long standing bugs are indefensible (although interestingly not complained about by Duane). Community contributions should be encouraged
2) Communication. Thing is, Evan is a good communicator. Perhaps a weekly or monthly blogpost would be prudent 3) Vapourware. Par for the course 4) Eco system. 1.0 cannot come quick enough On Wed 26. Apr 2017 at 11:19, Mark Hamburg <[email protected]> wrote: > This will evolve, but see above, the constraint is that Elm remains >> reliable... > > > Which the lack of attention to bug fixes undermines. How long were there > warnings that arrays had problems? How long has Elm sometimes generated bad > code for cyclic definitions leading to runtime crashes? The speed blog post > regarding Elm talks up using Html.Lazy and to do that effectively in some > cases you need Html.map. Guess what, use them in the "wrong" way and you > can get type system violations leading to runtime errors. > > Tight control over the core is something that many language designers have > maintained and it leads to clarity. (At the large language end of the > spectrum, this has helped C# be a better language than Java despite > starting as a Java knock off.) But everything within that tight bound of > control then also becomes an area of responsibility or the technical > ecosystem suffers. > > An ecosystem that had looked vibrant and innovative a year ago now looks > increasingly buggy and stagnant. We're coming up on the one year > anniversary of the Elm 0.17 release in which FRP was removed, effects > managers introduced with a plan that they would cover the web APIs, and a > new guide to Elm was introduced. The guide long contained promises of > material that was coming soon though now it just seems those promises have > been deleted rather than fulfilled. The effects manager ecosystem appears > to have been abandoned in that nothing new seems to have come to the > community in ages. Evan started a manager for local storage but hasn't seen > it as worthwhile to finish it leaving people using ports with a range of > frustrations (see other threads). Phoenix was cited as an example of where > effects managers could be useful but there is no blessed Phoenix effects > manager. If you took the velocity of the last nine months and projected it > forward, it's hard to make it look promising. People want to help. They > want to write and share code to expand what Elm can do, but the evidence > suggest that there is a lot of pushback against that right now — > particularly when it comes to getting code approved for distribution > through the standard package manager. > > The lack of effects manager build out also reflects a sense that the > direction Elm development moves in is capricious. When 0.17 was released, > there was a strong message around this being the architecture for the > future of Elm and a suggestion that it wasn't going to take that much to > get coverage of the standard web API. That appeared to be the plan of > record to the extent that there was one. Binary data has been a hot topic > for quite a while and the HTTP libraries give nods toward adding support > but haven't actually done so. Now, it seems Evan is working on providing > ways to download less code or download code incrementally when delivering > web apps. That's definitely nice. Smaller is better. But to the extent that > there were hints toward a roadmap, this hadn't been on it. > > This is what leads to people being worried or frustrated. This is what > leads to them leaving. There will always be churn. There will always be > people who are unhappy because of the strictures of pure functional > programming or who are unhappy because Elm isn't Haskell. But this thread > started with an active member of the community — as opposed to someone who > just came by to kick the tires — deciding that the ecosystem just wasn't > viable as a place to invest anymore. Maybe this is just a one off. But > maybe it's symptomatic. As web technologies — of which Elm clearly > positions itself as one — demonstrate it doesn't take much to tilt from > being the hot new thing to being the thing that everyone has heard that > people have gotten burned by and one best stay away. > > What you are hearing is frustration and fear. When people talk about > forks, I doubt that it is because they really want to fork Elm. Most of us > recognize that language development is hard. But people are trying to > figure out a backup plan. > > As I've said, some people want very specific extensions to the language > and those just don't seem likely to happen. As a language, Elm seems to be > focused on being a strongly-typed, pure functional language that avoids the > complexities of Haskell. That's laudable. (I'm the sort of caveman that > prefers C to C++.) But for the ecosystem, if I look at other successful > languages, it feels like Evan needs to make clear where the boundary lies > for what he wants absolute control over, needs to make a commitment to > making the material inside that boundary as strong as possible, and needs > to figure out how to be supportive of active development outside of that > boundary. Those actions would allow people to make decisions based on facts > rather than hopes and/or fears. It would allow more people to decide up > front whether the Elm ecosystem is where they want to be and if it results > in some people not coming in then it also results in fewer people leaving > noisily or throwing around talk of forks to address issues that don't seem > to be being addressed. > > Short of that, it would be great if the features called out on > elm-lang.org got more attention. There are only four of them. Semantic > versioning is essentially done and while JavaScript performance could > probably be better, the benchmarks are doing well. But anytime the > implementation can generate a runtime exception — other than stack > overflows from halting problem issues — this is a failure of brand promise. > And when people are banging their heads against JavaScript interop issues > and leaving the ecosystem because of it, that makes the promises in that > regard seem particularly hollow. > > People are worried and frustrated. > > Mark > > On Tue, Apr 25, 2017 at 7:17 PM, John Orford <[email protected]> > wrote: > >> My 2c on above... >> >> 1) web components - once they're a standard they will be a must. >> >> Perhaps they feel like a necessity now (I am sold) but they're still in a >> flux, browsers support bits and pieces, some things haven't been finalised >> yet. >> >> Angular / Reacts / Vue's ad hoc implementations for their own >> implementations are fine, but you get bitten when they have breaking >> updates (Ng 1 -> 2 etc...). >> >> Best to stick with the W3C when it appears. >> >> 2) Community / priority setting / BDFL >> >> Elm is unique, it doesn't try to do everything well. Evan obviously has >> his priorities and other things go by the way side. This is a strategy, and >> this is how Elm will be effective. >> >> It's right there on the home page: >> >> > A delightful language for reliable webapps >> >> From my POV, Elm is almost success already, in that it has a goal, >> clearly advertises it and is almost there. Roll on 1.0! >> >> 3) JS interop >> >> This will evolve, but see above, the constraint is that Elm remains >> reliable... >> > -- >> > You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
