System design's two abstractions: hiding vs. reducing
The Two Abstractions of System Design: Hide or Reduce
A distributed systems researcher unpacks a contradiction: computer scientists are trained in abstraction, yet modeling with TLA+ demands a different skill. He distinguishes modularity abstraction—encapsulation that hides internals—from modeling abstraction, which reduces a system to its minimal behavioral skeleton. Using examples like Lamport clocks, consensus, and MapReduce, he shows how modeling exposes concurrency to prove invariants and maximize safe parallelism, while modularity hides it for ease of use.
Modularity abstraction hides concurrency. Modeling abstraction exposes it.
- BoiledCabbage
I've generally heard the two concepts discussed as abstraction vs generalization.
Abstraction hides unnecessary detail. Generalization finds/surfaces commonality among items.
> oop - What's the difference between abstraction and generalization? - Stack Overflow - https://stackoverflow.com/questions/19291776/whats-the-diffe...
Creating a procedure/method is a form of abstraction. Allowing it to accept parameters is a form of generalization (by allowing it to be used for a number of similar inputs).
Simply creating an integer data type is a very simple form of generalization. Allowing operations to work against generically against any integer.
- danparsonson
> Modularity abstraction aspires to hide the interleavings and present operations as if they were atomic. Its goal is to make the module easy to use, but in doing so it forgoes exposing concurrency or efficiency opportunities.
> In stark contrast, the modeling abstraction is about identifying what should leak and leveraging it! It exposes the fine-grained actions and orderings, and proves that invariants hold despite the interleavings. The payoff for this work is to harvest the maximum safe concurrency from the system.
I guess I don't understand the argument here because those just sound like two different flavours of the same custard to me; the difference is just the balance of work you're doing on each side of the interface, and that decision depends on use cases specific to the project.
This feels more like it's making a point about system design? Abstraction is abstraction - you can apply it at different levels within a project, and a big part of building skills in software development is in learning to zoom in and out and nail the abstraction at each stage, but ultimately you're doing the same thing over and over. I don't personally think we need categories of it.
- thekaranchawla
my takeaway was modularity abstraction (as the author describes it) hides implementation and modeling abstraction reduces the system to the min. behavioral state required to preserve your invariants