No offense to the coder, but I would have preferred the name elm to have stayed in my memory as an text-based email client.
The language is alright.
Road to Elm 1.0
131–140 of 192 posts
Re: Road to Elm 1.0
#132We had some big Elm proponents who were trying hard to convince the company to use Elm, including doing proof of concept buildouts in Elm. Then the 0.18 to 0.19 Elm drama happened: The core team restricted the ability for users to do any native JavaScript interop, which broke every Elm app that needed any functionality that wasn’t in the core library. It split the Elm fans into two groups: Those who were upset that t…
It's amazing that business would tolerate paying staff to build products on one person's prototype hobby language.
It's going to be hard to explain to future generations that the demand for computer-speakers was once such that sometimes they could even decide the language in which they spoke to the computer, and that really was a big deal back then because computers couldn't just switch back and forth like they can today.
Re: Road to Elm 1.0
#133Earlier quoted context omitted.
what?
In Elm 0.19, they removed the ability for third party packages to provide native bindings for JavaScript APIs that the language or its official packages didn't yet support.[0] The only alternative proposed by Evan is to use ports, which are about as ergonomic as calling a function in a web worker. [0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826
there is also web components (best way to do a "copy this to clipboard" button in my experience) and secret back door synchronous FFI through overloading the Object prototype. In all cases the communication is gated through decoders/encoders that can fail; you can only pass serialized data across the boundary from JS to Elm.
Re: Road to Elm 1.0
#134Any insight on comparing Elm to Yew? I once wrote a frontend webapp with Elm. And with backend server in Clojure, it made as much sense as Elm five years ago, right? :) For the past two years I've instead used Yew, a rust crate for building UIs. It can look like react or like Elm, it's up to you for how you yew s it ;0) My latest app uses The Elm Architecture in Yew. It has been fantastic. I think the biggest benefit…
I don't know about Yew but I've been using Iced 0.14 which is also a Rust crate inspired by the Elm architecture. It seems like Yew is specifically geared towards web applications, which I suppose is in some ways closer to the original Elm project.
What is your app? Is it intended for personal use, or commercial?
Re: Road to Elm 1.0
#135I think Evan's pointing at something, and everyone's looking at the finger. I don't think this is really about Elm at all, but the preparation for Acadia.
In his talk, Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8, he does reveal a peek at what he's been working on for the past seven years: a query language with functional ideas applied to them.
He points at the boundaries in web apps that typically destroys type information: - language storage - storage wire
What if we could preserve the type information across these boundaries? What would that buy us? One answer he had was easier migrations. They'd just be a type diff, rather than hand-written SQL.
So I think the right question is, can we infer what Acadia is going to be like given the changes he's shipping with Elm? What does incremental compilation give query languages?
Re: Road to Elm 1.0
#136> ... and others are more visible features like equatable and hashable types. I love Elm, and I love the community, but I feel a little gaslit here.
say more! Is it that it has typeclasses but they're closed?
It is that even without an open typeclass system, these specific typeclasses have been a common request for a long while.
I have worked at a few elm places, there is always a dict-for-everything dependency or local implementation.
Re: Road to Elm 1.0
#137Earlier quoted context omitted.
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossib…
This really overstates the problem and situation. Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop. But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port. It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference,…
I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it.
And the problem isn't just that sync interop was removed. That would've been fine. It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong.
Breakage is totally fine, I never expected anything different from Elm. But community-killing permanent core feature removal is a bit much, is it not?
I luckily never invested too deeply into the ecosystem so there wasn't a lot dor me to "learn", but it sure ruined any chances of me - and with me I bet a lot of other people - ever looking at an Elm 1.0 or Elm++, and considering the valuable insights gained from TEA that really is a shame.
Re: Road to Elm 1.0
#138I think Evan's pointing at something, and everyone's looking at the finger. I don't think this is really about Elm at all, but the preparation for Acadia. In his talk, Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8 , he does reveal a peek at what he's been working on for the past seven years: a query language with functional ideas applied to them. He points at the boundaries in web app…
> I don't think this is really about Elm at all, but the preparation for Arcadia.
Considering Elm's history, why should anyone trust that Arcadia won't work out the same?
No matter how good his ideas are, if Arcadia doesn't have a more future-proof community-focused development model nobody will adopt it. At best it'll end up being "the project that inspired XYZ".
Evan might think it is about the Next Big Thing, and he might even be right, but after Elm will the world care enough to listen?
Re: Road to Elm 1.0
#139No offense to the coder, but I would have preferred the name elm to have stayed in my memory as an text-based email client. The language is alright.
Thank you for another check on my bingo card.
Re: Road to Elm 1.0
#140Is it me, the code examples look awful to read?
it's an ML family language. If you're not used to them they can be a trip.