|
Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever). I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I conceded to the current limitations of the language and did things the Elm way, accepting that sometimes things are bit boilerplatey and cumbersome. Now my second large Elm project is currently in its first round of QA, and the difference to similar projects in Angular or React is striking. There are no (and I mean ZERO) runtime errors that have popped up during testing. When QA find a bug, its instantly clear exactly where in the codebase the problem is, and usually simple to fix. So far most serious issues have ended up ultimately being consequences of a poor choice of design/modelling that, when fixed, has ended up in a higher quality overall codebase. Yes, things could be better, and I'm sure they eventually will be. We would all like the kind of abstractions you talk about in your article, but in my real-life experience it turns out that you don't need them to write powerful and high quality code. And hey, when these kinds of abstractions do arrive I'll just refactor my code, and know that the compiler will tell me when its done. Imagine doing that in Javascript. |
That's unlikely, it is not the direction Evan wants to take, and so far the language has gone the opposite direction on purpose and by design.
> And hey, when these kinds of abstractions do arrive
Which they probably won't. Realise that the Elm platform is written in Haskell, Evan knows about these features, he could have used them and he very specifically avoided doing so. If you want these abstraction-building tools you'll be much better off looking at e.g. PureScript rather than wait for Elm to add them.