Oberon-2, a hi-performance alternative to C++ (1997)

https://folk.ntnu.no/haugwarb/Programming/Oberon/oberon_vs_cpp_II.htm

by abricq • 3 years ago

73 102 3 years ago

folk.ntnu.no

Rochus16• 3 years ago

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.

rurban2• 3 years ago

That's why you would use o2c, which can use gcc-13 or clang-14.

Though I'm convinced that this ship has sailed, with go replacing oberon

Rochus16• 3 years ago

There is even a better alternative; just use the Oberon+ toolchain (compatible with Oberon 87, Oberon-2 and Oberon-07), so you can benefit of a decent IDE with a source-level debugger and a C99 transpiler.

kristianp2• 3 years ago

Or use Modula-2, which was recently added to gcc (https://www.phoronix.com/news/Module-2-GCC-Merged).

MarcusE1W2• 3 years ago

As a bit more comfortable alternative to Oberon I would suggest Modula-3.

https://github.com/modula3/cm3

It even comes with a GUI library, which even though developed in the 90th Stil, works on x11. I find that quite fascinating :-)

bhaak5• 3 years ago

(because it only supports a fraction of the C++ features)

I'm pretty sure that both Mössenböck and Wirth would consider this a feature, not a bug.

Rochus16• 3 years ago

Neither Mössenböck nor Wirth were involved with the posted paper, and neither intended to create a "high-performance alternative to C++". The authors of the paper who made this claim are different people, who apparently didn't know C++ good enough.

mpweiher• 3 years ago

[Optimization not comparable to C++]

Hmm...considering Proebsting's Law[1], which is always shown to be too optimistic despite its pessimism[2][3], the arguments presented by DJ Bernstein[4] and the fact that Frances Allen got all the good ones in 1971 [5], etc. not sure how much this matters outside a few specialised domains.

[1] http://proebsting.cs.arizona.edu/law.html

[2] https://gwern.net/docs/cs/algorithm/2001-scott.pdf

[3] https://zeux.io/2022/01/08/on-proebstings-law/

[4] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

[5] http://venge.net/graydon/talks/CompilerTalk-2019.pdf

mhd3• 3 years ago

I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at.

And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.

pjmlp13• 3 years ago

Which makes sense in 1990's computing world, and I was a big Oberon fan.

However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up.

Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense.

Latest revisions of Active Oberon also have some kind of generics support.

ThinkBeat• 3 years ago

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....

Rochus16• 3 years ago

The operating systems written in Pascal I'm aware of (e.g. the Lisa the source code of which was published last week) used extended versions of Pascal, which e.g. had the '@' operator; actually I don't know any system of significant size which used original Pascal as specified in Jensen/Wirth's User Manual and Report; do you have references?

yjftsjthsd-h2• 3 years ago

Eh, that's fine, nobody writes OSs in standard C without compiler extensions either.

musicale9• 3 years ago

The Lisa had two operating environments written in Pascal - the standard Lisa OS/Lisa Office System, which resembled early Mac environments but supported protected memory, and the mostly text-based Lisa Workshop development environment, which resembled the UCSD p-system, but supported native compilation, assembly language, and a Lisa GUI-based text editor.

Two big extensions to standard/Wirth Pascal that enabled Pascal to work well for the Lisa and subsequent systems were units (separate compilation modules that could be imported/referenced using the USES statement) and an early version of Object Pascal known as Clascal.

I'm not sure that Pascal's evolution from Wirth Pascal to UCSD/Lisa/Turbo/etc. Pascal to Object Pascal and Delphi is something to complain about, any more than we'd complain about C evolving from K&R to C89/.../C23 and to C++ (and its various versions.) Pascal is still a capable and relatively compact language.

I think Pascal versions that lacked the @ operator and type casts could often use case variant records (relying on technically undefined behavior) to accomplish similar things.

pmontra• 3 years ago

Pascal and C where the two most used languages in the kind of software development world I was living in around 1990, hobby, university and consulting, UNIX and some Windows. I remember reading one Oberon and one Modula 2 paper. I didn't know anybody using them to build anything real. Pascal had its heyday on DOS and Windows with Turbo Pascal and Delphi. It slowly faded away because everybody started building GUIs with Visual BASIC instead, or Visual C++ for the very technical people. Then came the web and Java and PHP and the early Linux corporate adoption and by 2000 it was buried under a geological layer.

kmoser• 3 years ago

Modula-2 was definitely a niche language. Back in the late 1980s I wrote an add-on to a commercial Modula-2 library that earned me a few bucks. Literally, a few bucks. I used Logitech's Modula-2 compiler, which I don't remember being slow, but Turbo C and Turbo Pascal were far more popular, likely because of their fast compilation speed.

bhaak5• 3 years ago

I remember reading one Oberon and one Modula 2 paper. I didn't know anybody using them to build anything real.

FWIW there was a huge following for the Wirth languages on the Amiga. I don't quite know how that came about but at times it felt like the programs written with Modula-2 or Oberon were as numerous as the ones written in C or Assembler.

That was mostly for Public Domain, Freeware, and Shareware software though.

mikewarot2• 3 years ago

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.

musicale9• 3 years ago

Not entirely sure why people are downvoting your perspective. There are at least two object lineages for Pascal: one leading to Oberon and the other to Delphi.

Both to semi-obscurity, but there is a lot to like in the Pascal language family in my opinion. Personally I find the syntax to be simple and attractive. Even though I spend a lot of time writing C-style languages, I don't have any trouble reading Pascal-style syntax.

My complaints about Ada and VHDL, which seem to have Pascal-inspired syntax, are they they feel a bit verbose compared to C++ and Verilog. On the other hand, Ada supports concurrency and memory safety, and has packages for dimensional analysis of physical units, and VHDL supports pluggable implementations.

pjmlp13• 3 years ago

While uppercase keywords is a bummer, many IDEs support automatic capitalization.

One thing from Oberon linage that Turbo Pascal/Delphi/Free Pascal lack, is automatic memory management (with the exception for COM based types).

mikewarot2• 3 years ago

No garbage collection, but Strings... it handles those brilliantly, you never need to allocate them, and they are automatically reference counted, and just work, even with a gigabyte of ascii in them.

It's the best of both worlds. No GC pause, yet you can have huge strings in memory, return them from functions, all without issue.

fortran77• 3 years ago

Someday Rust will go the way of Oberon.

sheepscreek• 3 years ago

Username checks out.

Jokes aside, I’m excited about any future additions to Fortran, esp. to make it appealing to direct data science use.

speed_spread• 3 years ago

You mean there will be a Rust-2? Nice.

throwaway17_17• 3 years ago

Genuinely curious, do you mean Rust will become equivalent to Oberon in terms of developer mindshare/use in production in 2023 (i.e. very limited); or, that someone will ‘Wirth’-ify the Rust language and produce a less complex language that still allows for writing code at Rust’s level of abstraction?

mhd3• 3 years ago

There don't seem to be any Wirth's around, design-wise. We're in the Algol-68 committee's time line.

roarcher• 3 years ago

Rust daily driver here. When that happens it'll be because something obviously better came along. I look forward to that.

KMag• 3 years ago

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.

vidarh6• 3 years ago

Huge fan of Franz' work on this, his PhD thesis on it[1] is a thing of beauty for it's simple, accessible description.

Beyond that, I just wanted to add a couple of things:

It doesn't require keeping the generated datastream at the level of the AST per see. You can generate as high- or low-level data as suitable where e.g. a lower level representation requires additional computation but remains independent of hardware architectures. The key is just that what you generate should fit a tree structure. So you can do any number of optimisation steps on the tree prior to applying the semantic dictionary encoding step if you choose. The extension to e.g. serialising SSA forms was pretty natural - there was work at ETHZ on generating SSA form around the same time as well [2]

The real beauty of the method is that the encoder and decoder each generates a dictionary the same way e.g. LZW does (and the dissertation cites Welch; Lempel-Ziv style variable length dictionary entries is achieved by simply variable length encoding all integers stored), but where the encoder uses it to compress and flatten the tree, the decoder does not reconstitute the original tree, but uses it to generate machine code fragments directly, and either copy it straight into the code being generated or stores it as a template to reuse for generation of other occurrences of that dictionary element.

The compression/decompression and serialization/code-generation are one and the same, and avoiding a separate layer is a key reason why it achieved the speed it did.

[1] Code-Generation On-the-Fly: A Key to Portable Software, M. Franz (1994): https://oberoncore.ru/_media/library/franz_m.code-generation...

[2] Single-pass generation of static single-assignment form for structured languages, M. Brandis, H. Mössenböck (1994)

pjmlp13• 3 years ago

As info for others, since Oberon System 3, there is the option of AOT or JIT compile the modules, depending on the use cases.

It is done as part of the compiler settings when compiling a module, if it ends up in pure binary or abstract syntax trees format. Some flags depend on the compilation mode.

dang• 3 years ago

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)

msla2• 3 years ago

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.

kragen2• 3 years ago

in 01997 it was acceptable to them and that's why most of them did move to java, once hotspot came out if not earlier

c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c

a lot of c++ projects in the 01990s were what we think of now as java projects or c# projects (or django projects): line-of-business systems full of boilerplate and shitty architecture, not streamlined mega-optimized aaa game engines or web browsers

c++ projects today are the niche that was left over, which is, yeah, basically the cases where you can't afford gc

— ⁂ —

the appeal of wirth languages is that you get 90% of the value of a monstrosity like pl/i or c++ for about 5% of the complexity

language complexity hurts you three times: when you are learning the language, when you are choosing a compiler, and when you are debugging your code

so actually sometimes you get 200% of the value of a monstrosity like pl/i or c++

hopefully at some point someone will develop a wirthified version of rust, but i don't think wirth will do it this time

midoridensha2• 3 years ago

in 01997 it was acceptable to them c++ projects today are very different from c++ projects in the 01990s a lot of c++ projects in the 01990s

You got the year wrong with that '0' prefix. The decade you're referring to is the 11990s.

vidarh6• 3 years ago

c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c

As an example, as late as '99, my first large web application was C++, and that was not an unusual choice at the time.

pjmlp13• 3 years ago

It is acceptable to those that use Unreal C++ and C++/CLI.

Many did move to Java (or .NET), that is one of the reasons C++ is hardly seen in distributed computing stacks 20 years later, or most CNCF projects, other than existing OSes and RDMS.

Those targeting OSes like Android, or ChromeOS, hardly have an option, unless they feel like using their own OpenGL/Vulkan based GUI, and create JNI wrappers (or JS callbacks) for like 80% of the OS surface .

vidarh6• 3 years ago

It's very simple: Simplicity.

A Wirth-style compiler for a Wirth-style language can be written fairly rapidly by a single person, and the languages, compilers and runtime systems can be easily understood. The Oberon-07 language report, including the grammar, is 17 pages.

If simplicity doesn't matter to you, then this won't appeal to you, and that's fine. I mostly use Ruby these days, whose parser (in MRI anyway) is likely longer than the whole Oberon-07 language report alone (I haven't measured, but ca. Ruby 1.8.6 the parser alone was 6k lines+), so I've surrendered the simplicity, but it still stands out to me as an ideal and inspiration.

Wirth was perhaps too ascetic in his insistence on keeping the compilers minimal, but you can fine less extreme versions carried on in extensions done in the PhD dissertations of students in his group.

Nevermark• 3 years ago

Wirth was perhaps too ascetic

Maybe too ascetic in terms of getting the most adopters, but a wonderful reminder to designers of development tools that most designs are probably far more complex than they need to be, even when optimizing for non-simplicity criteria.

So not a wasted effort!

HarHarVeryFunny7• 3 years ago

It's very simple: Simplicity.

Well, simplicity in a programming language is IMO only a virtue as long as it doesn't come at the cost of too much functionality, which with Pascal it surely did.

There's a reason that of C and Pascal, C is the one that survived. It's the simplicity of Pascal that ultimately killed it, since it forced any practical implementation to heavily extend the language (Turbo Pascal, Apple's Clascal, etc). Even USCD's famous P-System extended as much as it subsetted the language. What this meant is there was in practice no Pascal standard, only these isolated ecosystems which eventually died one at a time.

In contrast to Pascal, C (which was designed only a couple of years later) was functionally complete enough, even in original K&R form, that it was implemented as a standard, and the standard endured past the lifetime of any individual implementation.

The simplicity of Pascal also came at extreme cost in terms of performance and usability. For example most non-trivial Pascal programs (certainly any use for systems programming) end up using the "variant record hack" for type casts (e.g. pointer to int). So, rather than not allow type casts, Pascal allowed it but made it have a runtime cost of load/store rather than being free. Or another example - Pascal only supported value or var (passed by reference) function parameters, so if you want to efficiently pass a record or array type you'd have to pass it as "var" to avoid being copied, even if the caller wasn't meant to modify it.

Hmm.. or how about Pascal's "simple" for loops, which took the form "for i := x to y", which means you couldn't use it for "i = 0 to (N-1)" without the cost of calculating "N-1" and would have to use a while or repeat loop for that instead at the cost of readability/maintainability.

Or how about Pascal's (variable sized) "conformant array" function parameters which the language didn't allow you to pass to another function... Or how about the fact that Pascal didn't support length-1 strings (length 0 and 2+ ok, though), since it made things "simple" by regarding 'a' as a char vs 'ab' as a string (incompatible types).

Yes, it was simple, but very poorly thought out, and practically useless unless extended.

augustk2• 3 years ago

Here is the specification for the latest version of the original Oberon language (also called Oberon-07):

http://miasap.se/obnc/oberon-report.html

kristianp2• 3 years ago

Back in the 90s when Modula 2 was that latest thing, the selling point was that it was as efficient as C (in theory), but safer. The Wirth languages were called 'bondage and discipline' languages for the safety they offered to beginning programmers. No buffer overflows, and you could specify a metres type and be assured that someone wouldn't accidentally cast an variable of type yards to it. It also offered modular programming with implementation hiding.

usrnm2• 3 years ago

Safety wasn't fashionable back then

pjmlp13• 3 years ago

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

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

Oberon-2, a hi-performance alternative to C++ (1997)

Related Stories