> Abstraction in general is usually said to be something which helps readers understand code without delving into the details.
I agree with this. And to me, this means a good abstraction is necessary to be ambiguous. For example, number is an abstraction. But a type that is int32 is not an abstraction. In fact, we are not using a meta-layer that allow ambiguity is the reason that most abstractions force readers to be concerned with details in order to understand code.
Math abstractions are good and rigorous. That is because math is never concerned with reality. As soon as you deal with reality, math is ambiguous from start to end. For example, what is one? Math throw away all the physical details, that is what allows it to be useful -- one can understand math without ever concerned with physical details.
The current popular programming language are not suitable for abstractions. Our natural language are good for abstractions. But I think we probably can have something in-between, like what we come up with math.
Abstraction is about the core idea without distracting details. Your core idea is likely to either have a finite bound (if the core idea includes bound) or have no bound (if your core idea is just about number). `int32` have the detail of signedness, minimum and maximum bound, underflow and overflow behaviors. Those are distracting details. And those are precise details. Thus, it is not a abstraction at all. It's like a specific 3-lb hammer, is that an abstraction of your hammer?
But an int32 is an abstraction over even lower details: alignment, endianness, and all of the compiler and hardware implementations of signedness, boundedness, and overflow behaviors.
There are multiple layers of abstraction. int32 is just one layer lower than you're used to.
It's not the right abstraction you are making. I assume here we are discussing abstrations above the base programming language level, such as structured vs spaghetti code.
I don't think that's a good assumption. The article above is talking about all abstractions, those built into the programming language, those not part of the programming language, and even those that span multiple programming languages.
I agree with this. And to me, this means a good abstraction is necessary to be ambiguous. For example, number is an abstraction. But a type that is int32 is not an abstraction. In fact, we are not using a meta-layer that allow ambiguity is the reason that most abstractions force readers to be concerned with details in order to understand code.
Math abstractions are good and rigorous. That is because math is never concerned with reality. As soon as you deal with reality, math is ambiguous from start to end. For example, what is one? Math throw away all the physical details, that is what allows it to be useful -- one can understand math without ever concerned with physical details.
The current popular programming language are not suitable for abstractions. Our natural language are good for abstractions. But I think we probably can have something in-between, like what we come up with math.