One interesting thing about at least some versions of the Oberon system is that they found that it was faster to store programs as compressed abstract syntax trees on disk and compile them at load time instead of storing them on disk as native code. This was largely due to 2 factors: (1) the ratio of disk I/O bandwidth to CPU speed on the ETH Zurich workstations and (2) Wirth-style compilers generating code very quickly (with relatively few optimizations).

Wirth's graduate student Michael Franz took this a bit further and adapted to storing Java programs as compressed SSA control flow graphs, called SafeTSA. Franz's research group modified the Jalapeno (now JikesRVM) JVM to be able to load SafeTSA files as well as regular Java class files. They found that the time to JIT code was reduced, and the performance of the generated native code was faster when using SafeTSA. The downside is that SafeTSA isn't well suited to interpretation in a HotSpot style hybrid JIT. So, program start-up time would likely suffer unless using AoT compilation. Last time I played around with A2/Bluebottle/AOS, I believe compressed syntax trees were the on-disk program format.

I never got the big appeal of Wirth languages. When they weren't just vanilla Algol derivatives, they were making a virtue out of a performance hack (enforced define-before-use to enable single-pass compilers) or relying on non-standard variants (Turbo Pascal/Delphi) to claim that uninspiring base languages were competitive.

As an aside, Oberon-2 isn't a C++ alternative because it apparently has mandatory garbage collection, which isn't acceptable to C++ programmers now (which is why they're going to Rust instead of Go) and damned well wasn't acceptable to them in 1997, else they would have moved to Java.

Well, Oberon-2 (designed and published by Hanspeter Mössenböck in 1991) was indeed closer to C++ than its predecessor Oberon 87 and 90, but definitely not a true alternative to C++ (because it only supports a fraction of the C++ features). Neither is the optimization done by the available Oberon compilers comparable to what we see in C++ compilers, not even in 1997.

Pascal is a great alternative to C. It is practical for writing operating systems. Though its use for this has declined if not vanished.

Most think of it as a "basic tinkering and learning" language, and indeed, that is probably the most common application. It does not have to be. [1]

UNIX came with C, and C became "IT".

[1] https://wiki.freepascal.org/Operating_Systems_written_in_FPC....

Turbo Pascal/Delphi/Free Pascal evolved since Pascal, and cover quite a bit of the feature set of Oberon, as far as I can tell.

The main improvement I see is the implied handling of multiple statements in an if-then-else-end. It seems like it would eliminate a lot of begin/end pairs, so I like it.

Wirth's decision to revert to Case sensitivity was a bad one.

With the exception of replacing "Uses" with "Import", it looks identical to Free Pascal/Delphi.

For screenshots of what it feels like to use an Oberon based OS, see

http://progtools.org/article.php?name=oberon&section=compile...

Related:

Oberon-2, a high performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=13734438 - Feb 2017 (2 comments)

A basic forking server in Oberon-2 - https://news.ycombinator.com/item?id=11627697 - May 2016 (36 comments)

Oberon-2, a hi-performance alternative to C++ (1996) - https://news.ycombinator.com/item?id=3361469 - Dec 2011 (18 comments)

Someday Rust will go the way of Oberon.