That talk was very interesting and very telling since this was a group moving from Elm to PureScript not because they wanted more sophisticated types and more squiggles but rather almost inspite of those aspects and instead because of ecosystem issues.
Mark On Wed, Apr 26, 2017 at 2:07 AM Wojciech Piekutowski < w.piekutow...@gmail.com> wrote: > Forking is already kind of happening. Not per se, but some people decided > to stick with 0.16 and FRP. And switched to PureScript for new projects. > This still fresh talk covers such a case: > https://www.youtube.com/watch?v=9kGoaUqcq4A > > Brief summary of why they didn't use Elm for other projects > They stayed at 0.16 because of FRP. It isn't cost effective and could not > be in fact possible to port to 0.17+. They are frustrated with lack of > communication (not much info beforehand about the tectonic change between > 0.16 and 0.17 before it happened). There's no roadmap. > > I'm wondering if 0.18 TEA couldn't be just a higher level abstraction over > FRP. That way we would have simplicity for newcomers and smaller apps, but > also keep the lower level powerful machinery for advanced cases or people > who don't want/can't to follow TEA. > > Similar approach could apply to things like localStorage. Why not have a > low-level libs more or less mirroring web APIs, but later community could > build something higher level, like > https://github.com/elm-lang/persistent-cache? > > On 26 April 2017 at 05:19, Mark Hamburg <mhamburg...@gmail.com> 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 <john.orf...@gmail.com> >> 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 elm-discuss+unsubscr...@googlegroups.com. >>> >>> >>> 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 elm-discuss+unsubscr...@googlegroups.com. >> >> >> 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 elm-discuss+unsubscr...@googlegroups.com. > > > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
