Object-Oriented Programming in Oberon-2 [pdf] (1994) | Hacker News Reader

Object-Oriented Programming in Oberon-2 [pdf] (1994)

ssw.jku.at

78 pointsAlexeyBrin28 comments

I happen to work in Oberon pretty much every week. At my company, we program OS for mobile robots and have been carrying Oberon code since 25 years. The code base is huge, and it works really well. It’s been under production for all these years and we know it’s robust. It’s definitely not fast, but most applications don’t require the speed offered by modern languages. That’s why it was never translated in C++ or Rust or any « better languages ».

In my daily practice, I find the following limitations to be the most challenging ones.

* No generic type : that’s extremely limiting, especially when implementing math libraries.

* The garbage collector (using the XO2 real-time OS) does not collect array of primitive types, only array of pointers are collected. Honnestly it would be much easier to not have the garbage collector.

* extremely small standard library (but this is to be expected for a niche language …).

* the only tooling that you have is the tooling that you build yourself (editor, completion, debuting, etc …)

I often wonder how many other people work in Oberon. I’d love to share with someone else than me that does !

That's impressive! Are there still any advantages in using Oberon commercially in 2023? (I use it mainly for study)

I don’t think there is any advantage to start a new code base in Oberon. The language itself is just like any OOP language, with very pronounced limitations. Typically, you’ll often have to fix problems with the compiler, or with the OS.

I guess that sometimes the risk to make a language migration (and to introduce some bugs) is higher than the performance benefits.

Which Oberon compiler do you use?

Do you work in other languages in your spare time?

Do you feel left behind working in a mainly OOP language when the industry seems to be heading towards functional programming?

You write that Oberon is definitely not fast, but that only applies to the implementation - how efficient the code is given by a compiler. I will assume you are using some port of ETH Oberon, but in the Oberon world all compilers are traditionally the most linear and only support basic optimization. So Oberon by itself has the potential to be no slower than Pascal or C if the optimizing compiler is well implemented.

About "No generic type" - in fact, such type (analog of the type "variant" from Delphi) can be emulated with an empty record, from which records with a field for a specific data type are inherited. Price for the philosophy of Wirthian simplicity. ;)

I'd like to inform you that I am an Oberon enthusiast from Ukraine and the developer of the Ofront+ project, which is a translator of the five Oberon dialects into C. The Ofront+ (my fork of Josef Templ's Ofront) supports: Oberon-1990, Oberon-2, Component Pascal, Oberon-07 and my own dialect. And we can mix all these dialects in one project. I would be glad if you find an opportunity to try it out yourself. Ofront+ exists for all popular platforms: Linux, Windows, macOS on different processors.

https://github.com/Oleg-N-Cher/OfrontPlus

Ofront+ is under active development, has a community and has already been used in a couple of commercial projects. At the same time, Ofront+ is open source and free. I provide free support and advice to Ofront+ users.

I used Component Pascal under Black Box Component Builder for developing scientific image processing and adaptive optics. The math libraries by Robert Campbell are available from Component Pascal Collection. The name of Robert's package collection is unassuming word Chill. It is the most amazing set of math, algebra, graphics, and utilities. All written in Component Pascal which can be backported to Oberon-2. You can download BlackBox from the same page. http://www.zinnamturm.eu/index.htm

As I mentioned in another comment, it was very interesting experience for what we had back then, as a full single user graphical workstation OS.

Outside of its original environment, isn't quite the same.

Thanks for sharing your experience.

Fascinating! I was skimming through TFA, wondering if anyone actually uses Oberon for real. TIL: Yes, they do.

Astrobe is still in business, selling Oberon-07 compilers.

Did you already have a look at http://oberon-lang.ch? It's a new version of Oberon, compatible with Oberon-2 and Oberon 90, with support for generic modules. It also has an IDE with syntax colouring, semantic navigation, cross-referencing and source-level debugging. Performance is close to C++ (https://github.com/rochus-keller/Oberon/blob/master/testcase...).

> No generic type

A good macroprocessor can provide a similar capability (and much more). My favorite example is to simply use an ASP-like syntax, where you could have the same language as your macro language, along with the "code inversion" brackets ("<%" in the case of ASP).

Please no. That's how CFront worked in the late 80s: one of the first c++ compilers that emitted c for classes and generics. It was slow, clumsy, and errors completely opaque. It served to get c++ implemented quickly during its early years, but things got much better when real compilers came out.

Hygienic macros integrated with a language, ok. But don't implement the language in a macroprocessor.

I am also working in Oberon, We are developing devices using compiler O7 for STM32 and also may years developing desktop applications with BlackBox Component Builder (also version of Oberon language).

PDF is thirty years old, and this is like the Third or fourth post on Oberon in the past few weeks so just wondering why the love? I mean as a study in programming languages its nice, but you cannot program real-world programs like you can with other pascal based languages like free-pascal and Delphi and if its just for teaching then it seems no more developed than Turbo pascal which is also free.

Did my training on Turbo Pascal and it was a missed opportunity IMHO but come on somebody enlighten me here.

I think Fogus was able to summarize it quite well in his "Six works of Computer Science-Fiction" blog post [0]:

"Wirth’s magnum opus is the quintessential example of Computer Science alternative-history world-building."

Note that Oberon was not only the name of a programming language, it was also the name of an innovative (at that time) operating system. It is possible to program real-world programs today in Oberon depending on the used implementation. For example oberonc [1] is a compiler targeting the JVM and allows you to leverage the JVM ecosystem by invoking Java code (or any other language that compiles to Java bytecode). For more Oberon implementations see [2]

[0] http://blog.fogus.me/2015/04/27/six-works-of-computer-scienc...

[1] https://github.com/lboasso/oberonc

[2] http://oberon07.com/compilers.xhtml

> it was also the name of an innovative (at that time) operating system

it was also an example of a complete system (from hw through os + dev tools to apps) which had been developed by only two people.

I thoroughly enjoyed Wirth's excuse for an FPGA re-implementation: "no commercial machines would talk to my favourite mouse —given to me as a parting gift from my Xerox sabbatical— so I built a workstation that would"

(He once gave a slideshow of the workstations he'd designed over the years, and although the displays got bigger, and the cpu and storage got smaller, the mouse remained the same...)

> an innovative (at that time) operating system

The UI paradigm involving Oberon's "system track" is still really interesting.

This isn't fanfare. I put some serious hours into messing around with Oberon (re-implementing the compiler like you, working on a couple emulators, working out how to bootstrap the system and build a disk image). Still, I never particularly enjoyed using Oberon, though.

About a year or so ago, though, while fumbling around with Firefox's bookmarks, I was entertaining the idea of a "universal sidebar" that would from the perspective of any app or web page be entirely separate but would still be sufficiently powerful to control any one (or all) of them. I realized I was re-imagining Wirth's system track, jotted the idea down, and then moved on. I'm still occasionally reminded of it, of course, due to the same frustrations that led to my daydreaming in the first place.

I do most of my computing with browser windows and terminal emulators snapped to either the left or right sides of the screen, anyway, so my existing workflow is entirely amenable to the imposition of parallel tracks. It's an underexplored UI concept on modern desktops. Windows Vista did have a widget engine that it first called the Sidebar and then called Desktop Gadgets, but it it was basically a clone of Konfabulator and the Mac Dashboard and not so much a supercharged window manager/app coordinator in the vein of Oberon or Plan 9 Acme, and I don't use Windows anyhow. The Browser Company is doing something sort of interesting with Arc, but it's still just an application-sidebar and not nearly powerful enough for what I want. Plus it's on the wrong side of the screen.

Imagine being in the mid-1990s, Windows 3.x is what most people use on the PC, Windows 95 is around the corner.

Here is a full workstation graphical OS, programmed in a memory safe systems programming language, with automatic memory management.

The language is compiled to native code, originally, eventually the system will evolve to a mixed AOT/JIT workflow.

The OS is heavily based on the ideas from Xerox PARC, primarly in Mesa/Cedar[0][1], and brings them into the normal PCs, specially with Native Oberon.

A mix of dynamic loading, REPL and mouse commands, gives an experience similar to Lisp Machines/Smalltalk (like in Cedar).

Basically any public symbol from a module, can be called from the shell, or via the mouse, and act upon selected text, selected window, widget or take additional input.

When modules are changed and reloaded this affects the whole OS, similar to those Xerox environments.

Rob Pike actually became quite a fan, hence with Rio and ACME in Plan 9 are heavily influenced by how Oberon (the OS works), and also carried into Inferno/Limbo afterwards.

All of this when outside Xerox PARC and ETHZ, almost everyone was discussing about writing OSes in C (with exception of Apple and Object Pascal, later C++).

The closest you would get to it today, is how Powershell alongside .NET and COM permeate Windows, and even that fails short as that is only userspace.

This is why many of us relate so much to Oberon, even if it doesn't make sense in 2023, an alternative universe of systems programming in GC based languages, coupled with a Lisp Machines/Smalltalk like experience.

[0] - https://www.computerhistory.org/revolution/input-output/14/3...

[1] - https://www.youtube.com/watch?v=z_dt7NG38V4

> Imagine being in the mid-1990s, Windows 3.x is what most people use on the PC, Windows 95 is around the corner.

Anyone recalls how slow and clunky Java applets were back then? I think we all know why Oberon was ultimately less than successful. Of course, the missing ingredient back in the 1990s was memory safety without relying on GC, what Cyclone gives you and what was further developed by Rust.

Those Java applets were interpreted, and had nothing to do with Oberon.

If you never used it, don't assume.

Oberon-2 was the first programming language that we learned in school, back in 2002. We used Pow! as IDE (http://www.fim.uni-linz.ac.at/pow/pow.htm). Good times, implementing sorting algorithms, Turing machines, and various backtracking algorithms. And ofc playing GTA 2 when the teacher wasn't looking.

Author of this (Hanspeter Mössenböck) works on GraalVM.

His research students used to.

Recently I saw a book of his on .NET, is he still involved in GraalVM?

(1994)

It's amazing how readable the code in that book is compared to C++, Java or even Rust.

Some non-idiomatic Python may come close in readability, but not in type-safety, of course.

Decades on, Wirth and Mössenböck are still an inspiration against bloatware.

It's just a different style of syntax, preferring written-out keywords to symbols (including the use of BEGIN and END as opposed to symbolic delimiters) and also using uppercase keywords to avoid them clashing with program identifiers. It was motivated historically by the highly restricted character sets (sometimes not even including lowercase) featured on some early computers. This is why COBOL goes as far as letting you write, e.g. DIVIDE x INTO y GIVING z. Nonetheless it does tend to be a tiny bit more readable for novices, at least when dealing with shorter program snippets, of the sort that might be common in intro programming books. The story changes as programs get larger, where being able to skim more code at a glance means that terser syntax is favored. (Of course, this is only true up to a point; you can also have languages like Perl or APL, which are both terse and quite difficult to parse.)

> Decades on, Wirth and Mössenböck are still an inspiration against bloatware.

I was working on an Android app today, it boggles the mind how complex and huge Android studio is. 100+ MB, just to download a particular version of gradle. And the number of menu options when you right-click on a selection of code, for example.

Reply on news.ycombinator.com