Abstraction in Elm: Introduction
Table of Contents
- Introduction
- One Expression to Rule Them All
- Introduce Comments
- Introduce Local Functions
- Utility-Based Modularization
- Domain-Based Modularization
- Wrappers and Generics for Everything
- Conclusion
Why Should We Care about Abstraction in Elm?
One of the largest challenges facing the Elm community today is creating an environment where React, Angular, and Vue engineers feel comfortable trying Elm, both as a language and a framework, while at the same time coercing them away from the “component-based design” abstraction pattern that React, Angular, and Vue have taught them. While necessary in order to work with those frameworks, it’s an unnecessary impediment when working with Elm.
The heavy push to discourage reliance on the component abstraction pattern is a good one, but it has also, in my opinion, led to some questionable conclusions. Notable examples would be Evan Czaplicki’s recommendation in “The Life of a File” that engineers not think about abstraction in Elm until a file is six-hundred lines long. I have also witnessed numerous instances in Elm Slack of community members discouraging abstraction outright, even making claims to the effect that “all abstraction obscures clarity.”
In this series, I will show that abstraction is not necessarily bad. Its effect on our code can vary enormously depending on the context and manner of its application. To demonstrate this, I will take two branches of an Elm case statement and take them from their most concrete state possible to their most abstract state possible, and I’ll talk about the effects that each of the changes has.
I will show that the phrase “all abstraction obscures clarity” is only half-true. Abstraction does decrease clarity of details (what our code actually does), but it also increases clarity of intent (why our code does what it does). Our goal when coding should be neither to maximize clarity of detail nor clarity of intent, for both strategies are fraught with significant drawbacks. We should instead optimize for clarity of relationships by using abstraction to draw meaningful partitions between various portions of our application. This can only be achieved if we correctly balance concreteness and abstraction when building our software.
Continue to Abstraction in Elm: One Expression to Rule Them All.
