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.
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
0.16 and 0.17 before it happened). There's no roadmap.
FRP. That way we would have simplicity for newcomers and smaller apps, but
who don't want/can't to follow TEA.
Similar approach could apply to things like localStorage. Why not have a
Post by John OrfordThis will evolve, but see above, the constraint is that Elm remains
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
Post by John OrfordMy 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.
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
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
For more options, visit https://groups.google.com/d/optout.
"Elm Discuss" group.
For more options, visit https://groups.google.com/d/optout.