Discussion
Notes on Project Oberon
Aldipower: The game Oxyd for the Atari ST was completely written in Oberon. Such an addictive game.https://www.youtube.com/watch?v=tm6ZgMKBL38
ofrzeta: 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.
Aldipower: 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
ch_123: > 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.
layer8: 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.
mamcx: 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.
cxr: Apropos 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>
