Relevant comment I left on another submission here that didn't get any traction[1] that I'll shamelessly copy here since this post not only namechecks Oberon and is about abstraction, but also manages to end with some unresolved musing from the author about the potential for programs having non-plaintext source code:
> There's a really interesting approach in the Oberon system where a text file is a type called Text that's fundamental to the system. You typically interact with text files through the Texts module similar to the way you get a file pointer from fopen and nose your way through using fread in UNIX/C's stdio.h.
> One thing that's easy to miss (even when you're reading an explanation of it) is that Text is an abstract data type, and so while it may feel like you're interacting with a plain text file like on any other system, the reality is that the actual bytes on disk don't matter; as long as the Text ADT is able to support it (read: the Texts API gives you what you need), then hypothetically the file could be gzip-compressed binary serialization of XML for all it matters. (NB: It's not, though.)
> Oberon exploits this by having a "looks" subsystem in the same Texts module that's entirely orthogonal to the read (and write) operations of the textual content of the file. This means the Texts module is able to include APIs that let you adjust the color, font, and spacing of an arbitrarily selected range in any "text file"—even source code. So you can have italics, bold, etc. in your program's source, but because the compiler, like any other program, interacts with the files using the API from the Texts module, it doesn't matter that they're there, and the compiler's tokenizer is able to proceed through it all totally unaware.
> So to me it seems that we don't want abstractions when trying to study certain things about a whole system. Instead, we want to view all of its components and then build our understanding from there. Abstractions hide the things that we care about.
I disagree. My experience is that most problems require a very thorough understanding of a specific slice of a system. It is rare (again, in my experience) that solving a problem involves understanding the whole system. This becomes more true the larger and more complex the system is. Abstractions allow you to ignore the irrelevant pieces and focus on what matters.
In a well-designed (or "proper") abstraction, we can deal with it in terms of its public interface. Two things that break abstractions are bugs and performance.
If you have either of those, then abstractions can be worse.
Another thing that is bad is the wrong abstractions, or abstraction inversion (https://en.wikipedia.org/wiki/Abstraction_inversion), where a layered system hides abstractions at the bottom from layers at the top, that top layers would nevertheless like to use, and reimplement, poorly. This happens surprisingly often.
But overall, I generally think that well-designed and factored abstractions are better than no abstractions at all.
I disagree as well. Abstractions, or interfaces, define the contract between modules, and then you can reason about the system in terms of those contracts. Without the abstractions, you’d have to reason based on all the details of the whole program, which is obviously much harder. Abstractions are a form of divide and conquer.
Regarding the article’s point about diluting abstractions when new disparate features are required, a third alternative (to the two presented in the article) is often to provide alternative abstractions in parallel, each individually still focused and to-the-point, which prevents both changing and diluting the existing abstraction.
Regrading the article’s point about performance analysis, in principle you can specify performance guarantees for each abstraction. It’s more difficult to check them, but in theory a type system could even encode performance characteristics in an automatically checkable way.
I agree with this. One way that I will go further is to say that “understanding of the whole system“ is a pretty fraught phrase. One person‘s holistic understanding is another person‘s gnostic gobble-de-gook. Realistically, they are all essentially just abstractions bounded by a different stopping rule. Just because one person‘s view of the whole system does not include what the GOOGLE engineer writing the code had for breakfast does not mean that that can’t be reasonably included.
The issue I think people have is that abstractions do not announce when they are insufficient or porous. This means that an abstraction which is perfectly trustworthy without further inspection for many years can suddenly become hazardous without warning.
After reading the article I think the point stand. Not always but for example when working doing a RDBMS all the abstractions are active inhibitors and even hostile to do what should be done (easier) without all that.
And then you need to know that "no, all that IO sys call not do what you want, how yow want neither how is documented or even practiced by most" to take the most obvious case.
So, yes, this is a case where this quote is on point.
When Wirth talks about modules and abstraction I believe he was talking about what was known as the software crisis. In particular the observation that as programs size increases the number of possible interactions of program components grows quadratically.
Modules in particular and good abstractions in general make the number of interactions between components tractible.
The N^2 component interaction problem is real and it continues to cause problems.
Even with our best solutions there is room for improvement.
Last I paid attention there was a culture that had developed around the administration of CISCO routers because things that should be unrelated affecting each other is a real world problem for the administrators of those routers.
Any time something changes in siftware and something unrelated is affected this general problem is making it's appearance.
There is also a long term tension between abstractions and entire system simplicity. The wrong abstract or an abstraction poorly implemented can make things worse.
Wirth was talking about "modular programming", a term that isn't as well-known today as it once was. It's where Modula got its name, and there were entire conferences and journals that arose in response to the term's coinage. Ultimately the label "object-oriented" got a lot more mindshare, even to describe concepts that can be accurately described as modular programming and aren't terribly accurately described as object-oriented (generally lacking one or more of the necessary message-passing and "extreme late-binding" criteria required for O-O).
Oh, "you are absolutely right". It was written in Modula-2. I got it mixed up.
But related languages anyway. :-)
Edit:
Yes, I prefer the monochrome display and version too!
Still using my monochrome SM124 monitor with Steinberg Cubase 3.1. It is a work horse. Only my eyes getting worse. Not the screen!! :-D
Relevant comment I left on another submission here that didn't get any traction[1] that I'll shamelessly copy here since this post not only namechecks Oberon and is about abstraction, but also manages to end with some unresolved musing from the author about the potential for programs having non-plaintext source code:
> There's a really interesting approach in the Oberon system where a text file is a type called Text that's fundamental to the system. You typically interact with text files through the Texts module similar to the way you get a file pointer from fopen and nose your way through using fread in UNIX/C's stdio.h.
> One thing that's easy to miss (even when you're reading an explanation of it) is that Text is an abstract data type, and so while it may feel like you're interacting with a plain text file like on any other system, the reality is that the actual bytes on disk don't matter; as long as the Text ADT is able to support it (read: the Texts API gives you what you need), then hypothetically the file could be gzip-compressed binary serialization of XML for all it matters. (NB: It's not, though.)
> Oberon exploits this by having a "looks" subsystem in the same Texts module that's entirely orthogonal to the read (and write) operations of the textual content of the file. This means the Texts module is able to include APIs that let you adjust the color, font, and spacing of an arbitrarily selected range in any "text file"—even source code. So you can have italics, bold, etc. in your program's source, but because the compiler, like any other program, interacts with the files using the API from the Texts module, it doesn't matter that they're there, and the compiler's tokenizer is able to proceed through it all totally unaware.
<https://news.ycombinator.com/item?id=47231108>
> So to me it seems that we don't want abstractions when trying to study certain things about a whole system. Instead, we want to view all of its components and then build our understanding from there. Abstractions hide the things that we care about.
I disagree. My experience is that most problems require a very thorough understanding of a specific slice of a system. It is rare (again, in my experience) that solving a problem involves understanding the whole system. This becomes more true the larger and more complex the system is. Abstractions allow you to ignore the irrelevant pieces and focus on what matters.
In a well-designed (or "proper") abstraction, we can deal with it in terms of its public interface. Two things that break abstractions are bugs and performance.
If you have either of those, then abstractions can be worse.
Another thing that is bad is the wrong abstractions, or abstraction inversion (https://en.wikipedia.org/wiki/Abstraction_inversion), where a layered system hides abstractions at the bottom from layers at the top, that top layers would nevertheless like to use, and reimplement, poorly. This happens surprisingly often.
But overall, I generally think that well-designed and factored abstractions are better than no abstractions at all.
I disagree as well. Abstractions, or interfaces, define the contract between modules, and then you can reason about the system in terms of those contracts. Without the abstractions, you’d have to reason based on all the details of the whole program, which is obviously much harder. Abstractions are a form of divide and conquer.
Regarding the article’s point about diluting abstractions when new disparate features are required, a third alternative (to the two presented in the article) is often to provide alternative abstractions in parallel, each individually still focused and to-the-point, which prevents both changing and diluting the existing abstraction.
Regrading the article’s point about performance analysis, in principle you can specify performance guarantees for each abstraction. It’s more difficult to check them, but in theory a type system could even encode performance characteristics in an automatically checkable way.
I agree with this. One way that I will go further is to say that “understanding of the whole system“ is a pretty fraught phrase. One person‘s holistic understanding is another person‘s gnostic gobble-de-gook. Realistically, they are all essentially just abstractions bounded by a different stopping rule. Just because one person‘s view of the whole system does not include what the GOOGLE engineer writing the code had for breakfast does not mean that that can’t be reasonably included.
The issue I think people have is that abstractions do not announce when they are insufficient or porous. This means that an abstraction which is perfectly trustworthy without further inspection for many years can suddenly become hazardous without warning.
After reading the article I think the point stand. Not always but for example when working doing a RDBMS all the abstractions are active inhibitors and even hostile to do what should be done (easier) without all that.
And then you need to know that "no, all that IO sys call not do what you want, how yow want neither how is documented or even practiced by most" to take the most obvious case.
So, yes, this is a case where this quote is on point.
When Wirth talks about modules and abstraction I believe he was talking about what was known as the software crisis. In particular the observation that as programs size increases the number of possible interactions of program components grows quadratically.
Modules in particular and good abstractions in general make the number of interactions between components tractible.
The N^2 component interaction problem is real and it continues to cause problems.
Even with our best solutions there is room for improvement.
Last I paid attention there was a culture that had developed around the administration of CISCO routers because things that should be unrelated affecting each other is a real world problem for the administrators of those routers.
Any time something changes in siftware and something unrelated is affected this general problem is making it's appearance.
There is also a long term tension between abstractions and entire system simplicity. The wrong abstract or an abstraction poorly implemented can make things worse.
Wirth was talking about "modular programming", a term that isn't as well-known today as it once was. It's where Modula got its name, and there were entire conferences and journals that arose in response to the term's coinage. Ultimately the label "object-oriented" got a lot more mindshare, even to describe concepts that can be accurately described as modular programming and aren't terribly accurately described as object-oriented (generally lacking one or more of the necessary message-passing and "extreme late-binding" criteria required for O-O).
The game Oxyd for the Atari ST was completely written in ~Oberon~ (no, it was Modula-2). Such an addictive game.
https://www.youtube.com/watch?v=tm6ZgMKBL38
I thought it was written in Modula-2. The Megamax compiler was quite popular. Oxyd is great but for some reason I prefer the monochrome display.
Oh, "you are absolutely right". It was written in Modula-2. I got it mixed up.
But related languages anyway. :-)
Edit: Yes, I prefer the monochrome display and version too! Still using my monochrome SM124 monitor with Steinberg Cubase 3.1. It is a work horse. Only my eyes getting worse. Not the screen!! :-D
It was written in Megamax Modula-2 by Application Systems Heidelberg, a small German software company as far as I recall.