5 Embedded domain-specific languages
This chapter covers
- Modeling the domain
- Designing embedded domain-specific languages with ADTs
- Building multiple related languages properly organized
- Interpreting languages and making them work
Software development is a difficult job. Developers do make wrong decisions, and it happens more often than it actually should. Developers do write incorrect code, and it happens against their will most likely. Developers feel lost in complex business domains, broad and contradictory requirements, and mind-bending technologies, each of which can turn anyone into depression when something goes wrong. Nothing is perfect; nobody is a superman.
While it's acceptable to demand correctness from software, it's not so obvious why unnecessary complex abstractions can lead to bugs. One of the primary reasons is that we lose the focus of the domain we’re implementing. If we treat an abstraction as a universal hammer that we think can solve all our problems at once; we risk going far from the actual task--a working code that solves a business problem. Many abstractions and approaches are intended to make our code more correct, but correctness is mostly about meaning (the domain) rather than technique (an abstraction).