[HN Gopher] Notes on Project Oberon
___________________________________________________________________
Notes on Project Oberon
Author : surprisetalk
Score : 16 points
Date : 2026-03-04 15:22 UTC (7 hours ago)
(HTM) web link (sidhion.com)
(TXT) w3m dump (sidhion.com)
| Aldipower wrote:
| 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
| ofrzeta wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| titzer wrote:
| 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.
| adampunk wrote:
| 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.
| ebiederm wrote:
| 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.
| cxr wrote:
| 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>
___________________________________________________________________
(page generated 2026-03-04 23:01 UTC)