Notes on Project Oberon
sidhion.com
sidhion.com
> 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.
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.
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.
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.
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.
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.
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.
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