January 9, 2026
Pick your programming Pokémon
Design duality and the expression problem (2018)
Objects vs Data: Devs pick sides, ask for book recs, and meme the ‘open world’
TLDR: The post shows how choosing objects vs data changes what you can safely add—new functions or new kinds—when your code is used by others. Comments morphed into a book hunt and reignited the split between “objects” and “data,” highlighting the real-world trade-offs developers juggle.
Today’s post breaks a brainy topic into plain talk: the trade‑off between power vs properties and why choosing objects vs data changes how your code grows in the “open world.” Using a simple coordinates example (cartesian vs polar), the author shows a key dilemma: with objects you can add new kinds later, but adding new actions can break others; with data you can add new actions freely, but new kinds might break users. That tug‑of‑war is the famous expression problem, explained without scary math. Think of it like choosing a toolbox that’s great at new tools, or great at new parts—but rarely both.
Readers showed up with opinions. Some cheered “properties over power,” while others called it overthinking and begged for simple rules they can change later. The top vibe? Book fever: commenter billfruit asked, “Any recent books on design in the abstract?” and the thread spun into reading lists. Jokes flew—Team Object vs Team Data, “choose your fighter: Cartesian,” and memes about the “open world” being paid DLC. A mini language war simmered (Java structure vs Haskell data), but the mood stayed curious. Bottom line: folks want practical guidance and receipts, not just theory—and a solid bookshelf right now.
Key Points
- •The article frames abstraction design around the trade-off between power and properties, prioritizing properties for predictable systems.
- •Design context matters: system boundary constraints make stability and adherence to rules more critical than in internal code.
- •A coordinate example contrasts object-oriented (fixed interface) and data-centric (fixed schema) representations.
- •Object-oriented design allows adding new representations but makes adding new methods potentially breaking.
- •Data-centric design allows adding new functions but makes adding new variants potentially breaking, illustrating the expression problem.