Abstraction in Elm: One Expression to Rule Them All
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
Code
Discussion
Above are two branches of a case statement inside Elm Test Runner’s update function. However, I have adjusted the code to be as concrete as it can possibly be. I have removed all abstractions, save for those coming from an external library (elm-style-animation).
This code is very direct. It tells us exactly what it does, and it tells us all of what it does in one single chunk of one single file. However, at only forty lines, it is already, in some senses, “too much to grok.” runStatus is being set to Processing, and this is perhaps mostly clear. But what is the relationship between these particular status changes and the bar color being interrupted and looped in an animation? Why is the duration of each part of each loop 660? Can I change one duration number and not the others? And what are those color values for? Why are they all different?
And this is only forty lines. What if it were six hundred? If one were completely new to this code, it would take quite a while to work through all those lines and figure out why each and every detail does what it does. We would have to run the application, observe the behavior, and try to correlate it to various parts of the expression. All of this work would be made exponentially harder by the fact that, lacking any structure, it is unclear how any one part of our single mega-function relates to any other part.
To make matters even worse, this method of perfect concreteness is highly susceptible to duplication. In only forty lines, this code already manifests numerous duplicate structures. This is a side effect of our desire to have no abstraction — we must explicitly declare each function invocation with its specific parameters.
Analysis
Pros
- The code does exactly what it says it does. There is zero ambiguity in terms of what is being executed.
Cons
- This code lacks any information as to why any part of it is the way it is. Engineer intent is highly obscure.
- Relationships between various portions of the function are unclear. As the code grows linearly, this becomes exponentially more problematic.
- Duplication is inevitable.
Continue to Abstraction in Elm: Introduce Comments.
