Evan Czaplicki - Let's be mainstream! User focused design in Elm - Curry On

> Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. I'd recommend watching this talk: [0]. Evan talks a lot about the decisions that went into the language, such as not having type classes or other advanced features. He makes a strong case for Elm not as a language-to-rule-them-all, but as a tool for the average programmer, who is more interested in building things than in learning about theory. The myriad language features in Haskell, OCaml, etc. are wonderful to those who understand them, but have not proven to be particularly effective at attracting those who aren't already interested in the languages. In that talk, he really made a strong case as to why Elm is valuable and relevant, even for someone such as myself, a functional programming nerd who loves learning about type theory, abstract algebra, and similar things. Also, I really don't think it's fair to say "The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years)." OCaml has been around for almost 20 years now, and F# for more than 10. Both have the backing of very large development teams. [0]: ▶ this video

Elm creator Evan Czaplicki can, in an elegant and pedagogical way that would feel familiar to at least developers coming from JS: ▶ this video from 24:14 until 29:39. Haskell/FP/Math purists would probably balk at the oversimplification. But introducing intimidating concepts by way of such oversimplification (without entirely missing the target) is precisely the point! Beginners just need a very rough and coarse grained overview, so they are able to gain some basic familiarity with the concept. That gives them some already-familiar conceptual knobs to hang further details on, reduces fear, and inspires curiosity to investigate further.

A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard. [1] ▶ this video

Lets be mainstream by Evan Czaplicky Designer of Elm language talks about principles he used to create language as approachable as JavaScript but as type-safe as haskell. ▶ this video

I like how mpj explains it. Monad - FunFunFunction #21 link Furthermore, the creator of Elm has a fun explanation too. Evan Czaplicki - Let's be mainstream! User focused design in Elm - Curry On ▶ this video More serious computer scientist explains monads in the following. Erik Meijer: Functional Programming link and here too link

I'm pretty keen to play with Elm, but it gives me some pause that an app like this (or the demo at link ) results in... 11k lines of Javascript. Nevertheless, these talks got me bulled up on Elm: link (Richard Feldman, collegially, on React -> Elm)</a> / ▶ this video (Evan Czaplicki on the motivation for Elm)

Evan has described a lot of the thinking behind his decisions in this talk: ▶ this video The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the first place, like type classes) because design is not finished when there is nothing more to add but when there is nothing more to remove.

elm does stay far from "now" stack (react,redux,css module,es6). But it shines in more learning and tinkering as side effect! (to some extent) community,design,rules,tools are mutiple goals when dev picking up new tooling. ▶ this video I think the real failure is not wholly technical. e.g. job,mainstream pressure <imagine ceo ask why not react?> What's important but underlooked. 1. founder of language don't hv time to add power tools into existing core language. one way or the other, you say we hv X that does same job. but actually not the same. 2. hype disappear after a while (fp hype) 3. code comparison e.g. rewrite in diff ways of prod code elm ver: link react ver: link ---result LOC point of view, react has 100 less code for button. Elm has good functional style, however distance(html, elm template) > distance(html,react). So, elm has "too much" high level built-in abstraction, which makes code reading harder. ---my take react is ok in most of cases react native is great (but you will end up writing large screen adaption, native feature for hardware X, shipping web code to native app user is ok, reverse not true). react hook is horrible (checkout some ecommerce oss, 100 warning after compile, 10+ hooks in same component, communication that not to trigger rerendering) vue has more consistency but 0 in native app direction unless you happy with doing everything in web angular was great until ppl left it to maintanance mode. tooling is very complete. (stencil,ionic) kotlin co

TypeScript won. I was watching this video by Evan Czaplicki the creator [0], and what struck me was that back then, Evan was absolutely right. He was right that in the high level, we needed a typed JS, but he was wrong in the lower level details, at least in terms of market share. TypeScript won precisely because it doesn't start off as intimidating for JS users, while others like Reason and Elm died off, but ironically TS is way more complex than either of the others in its type system. Another factor for this is that Syntax Matters™. When Gleam (language on the Erland runtime, cousin of Elixir) started out, it had a Haskell-like syntax, but this was found to be a barrier for adoption, so when the creator changed it to be more C and Rust-like, the adoption rate picked up significantly [1]. In the same vein, perhaps Elm was just too esoteric for those coming from JS. I strongly believe the reason Rust became so popular is that it's an ML in C clothing, rather than being a pure ML like OCaml. With curly braces and all, it's more accessible and then people start learning about the more functional features like maps, folds, and so on. Elm also had quite a rocky history with the BDFL not allowing other people to use the features the compiler maintainers could use, such as escape hatches, which are documented in other parts of HN. This article [2] is a particularly good overview of why some people left. [0] ▶ this video [1] link [2] link

Thank you for the feedback. Maybe this short video clip can help. Elm creator Evan Czaplicki illustrates it by way of the Monad: ▶ this video from 24:14 until 29:39. I've also updated that section of the article, to provide some justification for my wish there, including a few more illustrative backing sources.

Not necessarily. See this short clip where Elm creator Evan Czaplicki illustrates my point by way of the Monad: ▶ this video from 24:14 until 29:39.

> It would appear that you misunderstood what I said. Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailable, then you use a lower-level alternative). If that was what you meant, then I agree...and I don't think I needed to have read SICP to know that. ;) > This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. I would describe this particular issue as having been "patiently explored to death." Here are several links demonstrating this: [0] link [1] ▶ this video [2] link [3] link > Elm not facilitating the use of sufficient level of abstractions [...] I had never got the impression that the Elm community was going to fix those problems any time soon. [...] Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. This quote characterizes Elm as not having "sufficient level of abstractions" and that these are "problems" that are not being "fixed." My reference to the "abstraction wall" is also a direct quote from a previous comment. [4] All of these quotes frame personal preference as objective fact. It's like saying Java is "broken" because it does not support manual memory management, which no one seems "interested in fixing" by adding `malloc()` and `free()` to the language. Plenty of people would (rightly!) be upset if Java introduced `malloc()` and `free()`, thus breakin