I wonder if elm is actually complete. I have the feeling that it did actually most of everything it wanted to be, didn’t it ? I think the nature of elm as a DSL and not a general web language makes it so that it is kind of complete. I can’t really imagine how it could organically evolve anymore as a programming language. What do you think ?
2 Likes
Elm is happy to be what it is for the foreseeable future but it has higher ambitions.
As far as I can tell, one of them is to compile to something other than JS. wasm has been discussed.
Another ambition would be to become a concurrent language. You can read about it here.
3 Likes
How could wasm change Elm as a Language ? I think it would still be pretty much the same as we know it today. The same completeness as today 
- just … complete
I guess you are right. My thinking around the answers were more related to what Elm allows now and what Elm could allow in the future.
If you are talking strictly about syntax, my guess is that the language not going to change anytime soon.
2 Likes
I think this is an interesting question and it comes down to what you count as “Elm”.
Elm as a language
If you count Elm as a language (i.e. syntax + operational semantics), then I think you are mostly right. I can think of a few minor warts that could be improved.
These are:
- Tracking whether
==can be applied in the type system, so we can deliver on the no-runtime exceptions (except stack overflows). - The built-in type variables are kind-a ugly.
compappendreally? - The built-in WebGL stuff is probably not sufficiently future-proof, given that WebGL2 and WebGPU are a thing.
Elm as a compiler
I think there is always another performance improvement to make, another platform to compile to, etc. This is probably just going to be a somewhat endless task.
I think a cool thing that could still be done on the compiler side would be some further work into SSR, code splitting and Web Workers.
Elm as a platform
Since only `elm/` and `elm-expolorations/` packages can execute kernel code, I hope there will be more expansion made to the web platform.
Namely and in rough order of my own personal priorities:
- Better handling of SVG APIs, especially precise event handling.
- I18n APIs. Formatting numbers, dates, currencies and lists in the users correct locale is still somewhat of a tricky problem in modern day Elm and certainly downloading the necessary data files from the server is not as efficient as it could be.
- Media APIs.
- Web Workers and off-thread computation. Especially if we can make a decent stab at having types that don’t need to serialise.
9 Likes
I agree with the compiler being something ever lasting. So then at the end there remains the question of Elm as a language and it’s possibilities for broadening access to web api. Maybe wasm allows it so that Elm implements its own API’s rather than masking the existing ones. Would that even make sense ?
And also the question remains, if Elm as a language is complete, why don’t make a first official stable release, known as “1.0”. If nothing will change language wise, what is holding it back to present itself as stable?
Maybe that every single package on package.elm-lang.org needs to be updated to say that it’s compatible with 1.0.0 (even if there are no changes).
1 Like
Personally I think that would be pretty good. In fact I wish there was say a four-yearly cycle of a reset, where all the abandoned forks, accidentally published packages, packages where someone was doing a screencast on how to publish a package and all the other cruft would disappear.
5 Likes
Effort? Return on Investment? Additional expectations from 1.0 release? Polish?
Even if language part is stable, we won’t release other parts separately. Package management? Debugger? Documentation format?
@evancz is always working on some stuff, maybe it’s on the verge of materialising. Or not.
Elm website recently got a facelift.
Perhaps 1.0 is already on its way.
I can’t understand, what do you mean concretely?
A programming language can always be declared to be complete at any time, so in a certain sense your question could always be answered by “yes.” But if your question is something along the lines of “what are hypothetical additional tweaks or changes to the Elm language that would ever make sense at this point” I can think of tons!
Here’s a list. Keep in mind that these are “hypothetical” and I’m not endorsing any of these (unlike my proposal for extensible variants a while back). Some of these are actually in conflict with one another if you think hard about them! Others have a lot of latent issues and tradeoffs that are hard to navigate. However, I do think they illustrate that should Evan choose to do so, there’s still a lot of room for the Elm language to change and grow while staying within the bounds of its original mission.
Filing away rough edges
There’s a bunch of things about Elm right now that have small issues one way or another that another language release could fix. @gampleman has already covered a few of them, but just to reiterate:
- Really fixing duplicate fields in record types. The underlying type system that Elm is built on allows for duplicate record fields. Elm tries hard to fight this (if you write duplicate record field names in a record literal you’ll get an error), but it’s not consistent about this. You can still crash the compiler or write code that Elm’s type system shouldn’t allow with duplicate field names. This corner case just needs a bit of thought when it comes to Elm’s semantics (it’s not terribly hard to fix, just needs to be decided one way or the other).
- Rethinking whether we really need built-in type variables or whether we can do away altogether with any last vestiges of type classes.
- Allowing custom types in various data structures (dictionaries, sets, and the like).
- Either update WebGL support, think about how to expand the built-in treatment of WebGL to other kinds of languages, or excise WebGL altogether.
- Rethinking implicit record constructors and type safety: right now a lot of “pipeline” libraries such as
elm-json-decode-pipelinerely on the implicit ordering of parameters in atype aliasto generate a custom record constructor. This is fragile in the face of various refactorings and renamings that might change that order. Is there any way to make this more robust? - Thinking hard about concurrency (the off-thread stuff @gampleman alluded to as well as the link that @pdamoc shared).
- Thinking hard about parallelism: Elm right now only ever uses one physical core. Can/should that change? How would you indicate to Elm that you would like to use more than one core?
Revisiting Haskell-esque decisions Elm made in the past
Early on in its history Elm was much more influenced by Haskell then it is now. With the benefit of hindsight and more divergence from Haskell, it’s worth going back and seeing whether a lot of things that Elm has inherited from Haskell still make sense.
- Is currying by default really worth it? It seems like an additional barrier for newcomers to the language to have to learn about (both currying by default and partial application) and also imposes a certain order to function arguments to try to make them ergonomic when using
|>. Perhaps a solution like what Scala or Clojure has, where you use some symbol such as_to create an anonymous function would get you the best of all worlds, e.g.add 2 _ === \x -> add 2 x, and allow any argument in a function to be “subbed out” while using|>. - Is there a better way to abstract over function arity than the current solution which forces you to either give up nice error messages with the equivalent of Haskell’s
apfunction or use a limited set offunctionNfamililes of functions?
Making a good developer experience even better
Elm thinks hard about DX, but DX is a never ending journey that can be greatly lifted up by changes in the language itself.
- Elm’s compiler goes out of its way to make error messages nice and on the whole library authors also try to design with compiler error messages in mind. However, sometimes a library API just doesn’t generate intuitive compiler error messages, or the error message could be so much better if there was library specific information that the library author could include (e.g.
hey you're using function foo, which doesn't work here, but function bar does, does that work for you?). Is there some mechanism that Elm the language could provide for code authors to augment or change the default compiler message? Languages such as Haskell and Scala use various type level and implicit argument mechanisms respectively to achieve this that probably are not consistent with the rest of Elm’s language design. Can Elm forge its own path here? - One of the early demos that got a lot of developers excited about Elm was its time-traveling debugger. Over time, that feature has waxed and waned in popularity and support. Can Elm revitalize this? Maybe Elm the language can dive deep into type-safe code hot-swapping support (right now things like
elm-liveexist, but they have various limitations on how e.g. changes to the model can be hot swapped). Languages such as Erlang have thought hard about this and offer various language level features to deal with this and maybe Elm can too (it’s uniquely situated because of its FP nature and full control over its included framework) and provide a strong answer to what hot-swapping with a static type system looks like. Imagine a time traveling debugger, but you can directly edit and persist changes to your model as well as play the debugger backwards and forwards all programmatically with Elm! Think Smalltalk or Common Lisp.
Thinking hard about multi-platform support
Elm tries hard to insert boundaries between itself and Javascript, but were Elm to really try to go and e.g. support iOS or Android natively, there still would need to be a good of deal attention paid to various language level details.
- Interop: Right now Elm has, in addition to ports, the ability to use custom elements for interop on the web. Would something analogous exist for other platforms? If so, do you now have platform-specific code? If not do you do away with the ability to use custom elements, even for the web?
- Multi-platform code: In the same vein, you can easily imagine other things that require various platform-level tweaks, even if Elm itself tries to be platform-agnostic (e.g. some code that generates CSS under the hood for the web probably wants to do something else on mobile). Does Elm try to support platform-specific code separation?
- Moving the entire visualization library into Elm itself: maybe Elm fully embraces something like
elm-uiand tries to push a completely platform agnostic visualization tool instead of allowing users to ever construct HTML or CSS. - Thinking hard about non-visual frontends. Frontends aren’t always visual! Interfaces for the blind are frontends as well! Can Elm the language be tweaked to also support this use case in a web-agnostic way? Whereas visualizations are static things, audio is inherently dynamic: you can’t play a single note forever, you need to have dynamically changing vocalization. That is while animation is optional for a graphical interface (and is also a bit challenging to do well in Elm at the moment), it’s mandatory for an audio interface. Can/should Elm be tweaked to support this?
And tons more! I could totally see Elm staying the way it is, but I could also see so many additions, subtractions, and unification of different features that would probably keep it “Elm”-ish.
17 Likes
Is any project ever complete? 
Maybe it’s just me, but I can never seems to arrive at those fabled shores 
2 Likes
Very inspiring ! We will see how this journey will continue, exciting
How about Don Knuth’s TeX and METAFONT? In 1990 he stopped development, saying he would
make no further changes except to correct extremely serious bugs.
He wanted TeX, like print, to be archival. If there are similar ambitions for web pages, a similar conclusion might arise.
Most recently Don Knuth made such changes in 2008, 2014, and 2021 (an arithmetic progression) and now TeX is a version number 3.141592653 (converging to pi, and to be made pi when Knuth dies). In 1990 he wrote
I strongly believe that an unchanging system has great value, even though it is axiomatic that any complex system can be improved.
Therefore I believe that it is unwise to make further “improvements” to the systems called TeX and METAFONT.
Let us regard these systems as fixed points, which should give the same results 100 years from now that they produce today.
For more details Don Knuth’s articles in TUGBoat 1990 (PDF) and TUGBoat 2021 (PDF).
5 Likes
I’m not super serious in making that claim - it’s the tendency to not set clear goals I’m admitting to 
it’s fun to grow ideas without too strict boundaries (or any, for that matter).
In that spirit, I suppose Elm is built around goals abstract enough that it’ll have to change over time? Is delightful webapps the same in 10 years?
I’ve definitely built smaller projects with very well-defined goals that had clear “I’m done now” milestones 
I’m gonna read all about this - thanks for sharing 
Browser APIs are evolving and we’re getting new ones. Elm prohibits easy interoperability and thus needs to update with new browser features. It’s already lagging behind for example with internationalization.
It might be useful here to distinguish between Elm the language and Elm the framework/platform/ecosystem. As noted, the web continues to evolve. If Elm were to be used places other than the web, the APIs might look similar but probably not identical. Right now, Elm the language and its approach to interfacing with the browser are pretty tightly intertwined, but it seems possible to tease them apart. Assuming, of course, that Evan wanted to do that. On the other hand, if Elm’s mission is to be a tool for writing browser apps, then there is no need for such a separation of the language from this particular use case.
Side note on Elm and JavaScript: While Elm tries to keep itself at least somewhat at arm’s length from JavaScript, its record types more or less assume hash-table-based records in some form since writing something like rec.x merely establishes that rec needs to have a field named x somewhere. One could probably map this to runtimes for protocol-based languages but it seems like a pretty big stretch. More likely, one would do something like use fixed field layout for the concrete record type and include a pointer to the hash map translating field names to offsets. That said, a non-JavaScript Elm runtime could easily bury this implementation from view.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.