Elm design philosophy

https://www.youtube.com/watch?v=oYk8CKH7OhE

Evan Czaplicki (the creator of Elm) talks about its design philosophy. I wanted to know whether Elm will get type classes, and while he says its on the todolist, he is not sure of the best way to implement it. Given his outlook towards productivity with languages, he thinks it's better to wait and see. Specifically, his answer to "why no type classes" is "(they're going to happen someday, but) when you release a feature is also a feature".

Evan sounds like a brain who cares about (and is capable of) pragmatic language design without getting bogged down in (unnecessary) abstract hypotheticals. I'd love to understand this philosophy before I build any language.

I'd #recommend this to anyone who wants a fantastic first Programming language or anyone who's fatigued from Making websites in Javascript land.

The talk outlines how he plans to increase Elm's language adoption through:

• Gradual learning
  • Haskell, OCaml and other functional languages might be more maintainable when you finally understand them, but as a beginner it takes so long to get something workable in them (regardless of your problem domain) that not many people survive that activation energy filter.
  • You should design the language itself so that features can be introduced incrementally (minimal handwaving). Think about how long it took before you understood public class HelloWorld { public static void main(String[] args) {} }. This ties in with how Incremental understanding is the best learning method.
• Communication
  • What's the point of having a better programming language if you can't convey the benefits to people? You wouldn't help someone solve addition by teaching them group theory (first), and we shouldn't try and sell functional programming by talking about state monads or purity. Use direct and specific language for problems people have ("stateless function" > "pure function", "easily refactored" versus "easier to reason about").
• Culture
  • Meetups should be targeted at popular goals. "Build side-scrolling game in a day" is more applicable than "side-effect free game development".
  • Style should be unambiguous and enforced with the compiler. Languages may not be inherently hard to read, but have common styles that are hard to read. Eliminate this problem at the outset.
  • Make it easy for people to build cool things. Someone built a time-travel debugger for Elm just by messing around with the package guide. Have online playgrounds to get started.
• Usage driven design
  • Start with simpler features and see the real-world limitations before you add more complex ones. Complex (aka "powerful") features lead you to miss great solutions with simpler features. Elm's Json library approach wouldn't have been found if type classes were added in the beginning. The Elm Architecture (TEA), which has since been adopted by many languages, would never have emerged if static signals had been included immediately.
• Unique tooling
  • Because of Elm's purity, tools can be built with a small team that could never be built for other languages. The time-travel debugger is the most obvious example. Automatic semver enforcement is another; major changes are automatically detectable in changes to public function type signatures, which means it should be impossible to break software from a third-party patch (and it's much easier to understand what changed).
  • Friendly error messages. This is one of my key takeaways. It's all well and good to say that type checkers help you catch errors at build time, but if they don't guide you towards a solution, it's like troubleshooting your toxic stonewalling partner who doesn't tell you what's wrong, but only says "fine".
  • Isolation of side-effects and state changes means aggressive optimisation can happen. Elm will likely be faster and lighter than all other JS libraries forever as a result.