Notes on Project Oberon

Aldipower

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

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.

cxr

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 >