I don’t write a lot of Elm. I’m unlikely to consider using it on my professional projects. I don’t really use it on my side projects. I might spend a week or two every year explore the Elm ecosystem, but I don’t do anything with it too seriously.
However, whenever anyone asks me what’s something interesting to learn, I recommend reading through the introductory documentation for Elm. While using the Elm language might not be directly applicable to a developer’s job, the underlying principles behind Elm are excellent. These principles set the foundations for the code a developer should be writing each day.
I recommend that every developer read through Elm’s introductory documentations.
An Excellent Developer Experience
Elm excels in creating a productive developer experience. Ideally, a codebase should be an environment that allows developers to evolve solutions to problems. Once a developer is comfortable with a language, they should be able to spend a majority of their time thinking about the domain of the problem.
With a well-thought-out implementation in mind, translating that implementation should be seamless. Of course, there will always be roadblocks that will disrupt the flow. But, a language should do everything in its power to create a smooth implementation experience.
Elm’s excellent developer experience is based on some foundational principles. These fundamental patterns are laid out clearly in the introductory documentation. Someone new to Elm can build their understanding on the solid foundation of proper fundamentals.
I recommend developers learn Elm in order to learn the core development principles this language demonstrates. A developer can apply these principles to whatever language they are using in their day-to-day work. Elm’s usefulness extends beyond writing code with the language itself.
I’d like to highlight a few of these core principles that form the foundation of my coding experience. These principles come from the introductory documentation, so I won’t dive into deep detail for each of these principles. I just want to call your attention to a few of the principles that I find important.
First off, Elm demonstrates the functional programming paradigm. Elm was my introduction to functional programming. It helped me think in terms of functions. The functional programming paradigm can help developers think through problems differently, even when writing code in an object-oriented environment.
Functional programming has helped me think about the tradeoffs when I’m creating functions or methods with side effects. I’m mindful of parameters and their order. I think a lot about naming functions clearly. That’s because this helps the mental burden of figuring out how a series of function calls should behave.
Static Type Systems
Second, Elm highlights the necessity of a static type system for guiding refactors. One could make an argument that static-type systems aren’t strictly necessary for refactors. However, static type systems have made my developing experience so easy. I can make quick changes confidently by modifying the type system and following errors along the way. Elm emphasizes this development practice in its introductory documentation. Modeling the domain in the type system allows developers to grow the code organically.
Solution-Oriented Error Messages
Lastly, I’d like to point out Elm’s care when it comes to error messages. Rather than just telling a developer that an error has happened, Elm’s error messaging directs the developer toward a solution. This complements the aforementioned type system, giving developers a smooth refactor experience.
But this practice of good error messages goes beyond the type system. Whenever I throw an exception in any framework, I make sure to not just say what’s going wrong but try to also explain why. For example, my current project prices products across a timeline. It’s pretty common for a developer to try to look up a price and not find anything. It’s natural to think that maybe pricing data doesn’t exist for a product, but in reality, the price just might be a bit in the future. So instead of creating a generic “Not Found” message, I make sure I communicate the other possibilities to any future developer who might run into this situation.
Final Thoughts on Elm
There are many more principles in Elm, and I highly recommend anyone reading this post to go check out Elm for themselves. Elm provides an excellent opportunity for a developer to improve fundamental coding practices. Even if you’re not interested in functional programming, or even web development, Elm has something for everyone to learn. Its principles are nearly universally applicable to other development environments.
Do you have another language that demonstrates excellence in these foundational ways? I would love to hear about it in the comments below!