Design duality and the expression problem (2018)

Summary

Part of what I hope to accomplish with this series is to make more concrete the nebulous notion of “trade-offs” that gets brought up any time program design comes up. So far I have brought up what I think are two of the most important ideas: The most fundamental trade-off in abstraction design is power vs properties. And we humans seem to have a common bias towards more power, when getting the right properties is almost always more important. Adding a property limits power, though. Get comfortable with the idea! :) The most fundamental piece of context is whether we’re designing on a system boundary. Most “rules” apply on a system boundary, where the code can’t be fixed later because it’d break external users. Outside of system boundaries, you can always fix mistakes later, so “small, simple, clear, direct” can outweigh adherence to rules. I’ve also mentioned that part of my thesis is that our languages don’t do us any favors because they routinely do not fully embrace both objects and data distinctly. (If you want to bring up certain languages, you’ll probably find mention of them in that post, and stay tuned for future posts!) I’m going to make more than a few justifications for this over time, but today will be the first big one. A simple example I’m going to pick something deliberately simple to start with, to make sure we all understand what’s going on. Here’s representing coordinates, where there’s two representations we want to support: polar and cartesian. We can make two different choices about how to represent this type: as an object or as data. As an object, with slightly condensed Java-like notation: interface Coord { float distance(); } class Cartesian implements Coord { private float x, y; public float distance() { return sqrt(x*x + y*y); } } class Polar implements Coord { private float angle, dist; public float distance() { return dist; } } Or, as data, with Haskell-like notation: data Coord = Cartesian { x :: Float, y :: Float } | Polar { angle :: Fl...