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.
I'm not sure that your description of generalization coincides with the idea of modeling abstraction from TFA. Modeling abstraction is "about identifying what should leak and leveraging it". Generalization is about making something cover more cases. The technique to achieve these things can overlap of course, but the intention/goal is different.
> abstraction is "about identifying what should leak and leveraging it"
vs
> Abstraction hides unnecessary detail.
Sounds like these ways of describing abstraction are in agreement with one another to me.
If you hide what’s unnecessary you’re left only with the things you think should leak. And you think they should be left unhidden so that you can use them for something, so to leverage them.
> 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.
> 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.
It is two different flavours. One is about interconnecting things, and the other is what you interconnect. What TFA called modelling abstraction seems to be the primitive ideas that goes in building more complex systems (which it calls Modularity Abstraction). Something like a String is not a primitive, but rather a combination of the idea of Character and List are. Just like you can go from a disk (a pure array of bytes) to a file system (in the unix world, a tree with nodes of metadata). The primitive here are Array (existing) and Tree (target) and with them you build a modular system (The file systems) that transform ones into another.
So yes, both are abstractions, one is about identifying primitives, and the other is about combining them.
I think it goes to show how different notions of "compression" can be (that word gets thrown a lot nowadays because of AI). Humans like simplicity for sure, but there can be different use cases for the simplicity
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
Yes. The followup blogpost makes this more concrete over an example:
https://muratbuffalo.blogspot.com/2026/08/composition-and-mo...
The rely-guarantee reasoning we used in this post is where the two abstractions meet and become a joint constraint. The modularity abstraction is the boundary: we split the specs into private versus interface variables, hiding produced from the consumer and consumed from the producer. The modeling abstraction is the Env actions. E.g., EnvPut is not an API for the producer, it is a reduction of the producer: the minimal behavioral skeleton of the entire producer relevant to the consumer's property.
> [ Note that his list is all about modularity abstraction: TCP (hide IP), string libraries (hide character arrays), file systems (hide spinning disks), virtual memory / flat address space (hide MMU and paging), SQL (hide query plans), NFS / SMB (hide the network), C++ string classes (hide char*). ] Modularity abstraction aspires to hide the interleavings and present operations as if they were atomic.
I wouldn't go with that. Most of the listed abstraction here is about building a new model on top of the old for new capabilities. They don't bother to hide them, merely use them for new purposes.
Like TCP using IP for interconnection, but adding transport stability on top. IP is still fairly visible, but in an axiomatic way. Same with string libraries which mostly add new operations but the nature of being a list of characters is still present.
A better example of abstraction for hiding are libraries where the public interface hide the nature of implementation (things like POSIX). This aligns more with the modeling abstraction, where you extract a minimalistic version of the system. Incomplete for implementation, but enough for interfacing.
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.
vs
> Abstraction hides unnecessary detail.
Sounds like these ways of describing abstraction are in agreement with one another to me.
If you hide what’s unnecessary you’re left only with the things you think should leak. And you think they should be left unhidden so that you can use them for something, so to leverage them.
> 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.
It is two different flavours. One is about interconnecting things, and the other is what you interconnect. What TFA called modelling abstraction seems to be the primitive ideas that goes in building more complex systems (which it calls Modularity Abstraction). Something like a String is not a primitive, but rather a combination of the idea of Character and List are. Just like you can go from a disk (a pure array of bytes) to a file system (in the unix world, a tree with nodes of metadata). The primitive here are Array (existing) and Tree (target) and with them you build a modular system (The file systems) that transform ones into another.
So yes, both are abstractions, one is about identifying primitives, and the other is about combining them.
https://muratbuffalo.blogspot.com/2026/08/composition-and-mo... The rely-guarantee reasoning we used in this post is where the two abstractions meet and become a joint constraint. The modularity abstraction is the boundary: we split the specs into private versus interface variables, hiding produced from the consumer and consumed from the producer. The modeling abstraction is the Env actions. E.g., EnvPut is not an API for the producer, it is a reduction of the producer: the minimal behavioral skeleton of the entire producer relevant to the consumer's property.
I wouldn't go with that. Most of the listed abstraction here is about building a new model on top of the old for new capabilities. They don't bother to hide them, merely use them for new purposes.
Like TCP using IP for interconnection, but adding transport stability on top. IP is still fairly visible, but in an axiomatic way. Same with string libraries which mostly add new operations but the nature of being a list of characters is still present.
A better example of abstraction for hiding are libraries where the public interface hide the nature of implementation (things like POSIX). This aligns more with the modeling abstraction, where you extract a minimalistic version of the system. Incomplete for implementation, but enough for interfacing.