23 comments

[ 3.1 ms ] story [ 51.8 ms ] thread
Oberon was my first programming language, taught by Jürg Gutknecht himself. One week, our home assignmend was "write your own file system". At first, I thought that would be impossible to do in such a short time. However, it turned out to be not that hard thanks to the clean and simple design of the Oberon operating system.
I only heard from fellow students about it.

Some of them changed universities explicitly because programming was taught with Oberon. They don't wanted to waste time with a language that wouldn't give them a good job after university.

At the university where I did my first degree, we learned Java, C/C++ and PHP. Back in the days I thought this was a good thing, because I could use this knowledge directly at work.

But at the second university I got an introduction to SmallTalk, which blew my mind. Now I know the value of looking into alternative programming languages once in a while.

I got to learn it while at university in Lisbon, when looking into stuff for compiler design.

As I refer on a sibling post, it opened my mind to systems programming with GC enabled languages, specially interesting when one thinks how the desktop computers looked in the mid-90's.

A decade later I got to enjoy a talk from Niklaus and Jürg at CERN, but Oberon was already on the way out.

It was a great OS and language.

For me it opened my mind to what is possible with a GC enabled systems programming language and made me delve into Modula-3, Oberon derivatives and its precursor Mesa/Cedar at Xerox PARC.

Unfortunately all of those not touched by it, still don't believe in GC enabled systems programming languages.

At least a little bit of its soul now lives on as Go.

Even if I dislike some of its design decisions, it would be nice to see someone redo Oberon in Go (it just needs a bare metal runtime like Oberon's KERNEL).

I think some of the concepts of Oberon have been implemented in Plan 9.

Whenever Oberon is mentioned, I want to recommend the book "The School of Niklaus Wirth: The Art of Simplicity" (I think this even contains a variant of the linked article).

I would consider that more in regards to Inferno and Limbo, than pure Plan9.
> For me it opened my mind to what is possible with a GC enabled systems programming language and made me delve into Modula-3

Also, if you like Modula-3, you'll probably love Nim.

It's also a GC-enabled systems programming language (someone even redid the OSdev minimal kernel in Nim), and the official FAQ lists Modula-3 as its top influence (in practice, it feels like Modula-3 semantics mapped to Python syntax).

Thanks for the hint, I know Nim.

However I have came lately to the realisation that .NET and the JVM worlds already take too much of my time to look elsewhere.

Due to my interest in programming languages I still keep on reading about new developments, but at the end of the day what matters is what my employer cares about.

In short, Russ Cox started doing that (an OS in go which was probably not Oberon) and then moved on to other toys when a bit field didn't work out. I read the words, but didn't quite understand them. Can anyone help with the reference.

There is an OS called Clive written in a modified go. http://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

Does anyone know of an image of the oberon system that one could run on qemu, virtualbox or something similar?

I understand it was a complete system from scratch including the hardware but I think I saw somewhere that the OS/Compiler/Tools were ported to other architectures.

For the curious, it's possible to download a 'Native Oberon' image from the website[1] and run it under VirtualBox. It's interesting to see how things might have turned out and also it's astonishing how quickly it boots up. The influence on Plan9's acme (I think it's that way around) is clear.

[1]:http://www.oberon.ethz.ch/

Looks like the archive is offline .. haven't been able to find another source, alas. :(
Sorry a bit late replying (been on vacation!) Try: ftp://ftp.ethoberon.ethz.ch/ETHOberon/
One thing that really says a lot about Wirth's philosophy is that in the most recent revision (2007?) he actually removed a rather common feature from the language (multiple returns!).
> He used the compiler’s self-compilation speed as a measure of the compiler’s quality.

Heh that's an interesting idea. Go could do that now that it is written in go.

It's a measure of the compiler's quality, and also of the language specification complexity.
Can someone compare Oberon against Genera, beyond the obvious implementation language and hardware?
Could anyone give a base/guidance on how one would start comparing/explaining the similarities/differences between Oberon and Smalltalk?