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]

> 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

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]

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