Modula-2 and Oberon (2007) [pdf] | Hacker News Reader

Modula-2 and Oberon (2007) [pdf]

citeseerx.ist.psu.edu

59 pointsJtsummers51 comments

My unpopular opinion. Here's Wirth's words: "The programming language Oberon was the result of a concentrated effort to increase the power of Modula-2 and simultaneously to reduce its complexity."

He kept on "reducing complexity" while re-building what is essentially the same, rather primitive, language. ANd he kept throwing the baby out with the bathwater.

One of the Oberons had three different loop constructs, and only one of those could be terminated early. Because reasons. Then a newer Oberon reduced the number of loop constructs, but also removed the ability to terminate them early. Then a newer Oberon... ad infinitum.

And you can see it in all the langage variants he built: he insisted that the core of the language be small at the expense of usefulness to the point of uselessness. And purely irrational academic fixation (such as function vs. procedure or the aforementioned loops).

Was he instrumental in creating a good teaching language, and one of the first good high-level languages (Modula/Pascal)? Yes. Did he do anything noteworthy after that? I honestly doubt it as he was pursuing this idree fixe of a "small language where you can remove nothing more".

I'm also upset at Niklaus Wirth because how he sensationalized Dijkstra's article "A Case Against the Goto Statement" by taking the liberty to change its title to "Goto Statement Considered Harmful", causing a lifelong disproportionate stigma against goto and relevant programming constructs like switch/case, break, continue, etc. Dijkstra had never intended to take such a purist stance against Goto. I also mention this in my book Street Coder.

Not Knuth. Dijkstra.

You're right edited it now, thanks!

? That was Edsger Dijkstra's article, if I recall correctly.

The standard joke is "Europeans refer to him by reference, as Nicklaus Wirth, and Americans - by value, as Nickel's Worth."

Yes my bad. Edited, thanks!

It was Dijkstra's article, but he submitted it with the title "A case against the Go To statement". Wirth was the journal editor and he choose to rename it to "Go To statement considered harmful".

Knuth ties into this because he published a response "Structured Programming with go to Statements", examining many situations where goto statements are hard to avoid in the standard structured programming paradigm.

GGP had originally referred to the author of the article as Knuth, GP (and I) both replied correcting that. GGP comment has since been edited.

Yes, I'd meant Dijkstra where I said Knuth despite that Knuth might still be relevant. I got this right in the book, no worries. :)

From the opening paragraph of Edsger W. Dijkstra's letter to the CACM editor:

More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code).

"Harmful" seems to me a perfectly appropriate characterization of the words "disastrous" and "abolished". If anything, it tones them down.

Similarly, "A case against" is way more toned down than "harmful." I agree that the opening statement is a strong stance and fits to the new title, but the article mostly focuses on proliferation of goto as a generic flow-control construct rather than exceptional such as using it as a "defer"-like construct in C where there's no alternative. I still think Wirth's edits hid the nuances in the article and helped fostering a strongly opionated dogma against goto by gifting a slogan to the masses.

I wasn't convinced of Oberon; to me, MODULA-2 was great, and that's where things ought to have ended. And in terms of impact, his main accomplishment is clearly Pascal (and indeed, thanks for that!).

However, I do believe his aspiration to make things simpler is genuine. Occasionally, he may have gone beyond the 'sweet spot', but as an academic, this way of tinkering and trying out different things is something that is second nature. I admire that he wrote a language, compiler, OS and - later - also designed the hardware of his own workstation. That's the kind of teacher you want: "look, how easy it all is!".

His compiler book, which can be read in a day, remains a marvel of clarity and brevity.

Here is a modern version which supports all loops of Oberon and Oberon-2; it also has generic modules and a kind of exceptions, and it is still quite small and simple: https://oberon-lang.github.io/

For me the best Oberon is Active Oberon, although I am quite certain Wirth would see that differently.

> He kept on "reducing complexity" while re-building what is essentially the same, rather primitive, language. ANd he kept throwing the baby out with the bathwater.

What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime.

As far as I know it's also the only system currently in existence that fullfills that promise.

Just the language part of Oberon is not optimal for running on the regular personal computer systems we used or are currently using. But AFAIK that was never its purpose either.

I'm attempting one at github.com/civboot/fngi. Let me just say... It ain't easy, and Oberon is a huge inspiration for what's possible.

Exactly. ... and not just within one lifetime — within a few years!

> What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) ... the only system currently in existence that fullfills that promise.

Well, Unix including the C programming language were essentially implemented by two guys (Thompson und Ritchie); at least in the beginning Unix was small enough to "be understood in its entirety by a single human being within one lifetime". The same applies to Linux (implemented by only one guy in the beginning). Also the Oberon System (written by Wirth and Gutknecht) became bigger and more complex during the years it was used at ETH; barely anyone has full detail knowledge of e.g. the whole Oberon System V4. We can assume that if the Oberon System had been more successful, it would have shared the fate of original Unix and Linux, and became too big to be understood in its entierty by a single person.

  You are not expected to understand this.

That even works with much smaller code bases; I remember staring at half a page of image processing code for a week.

I think the main problem is that Nicolas was like a practical PL researcher and don't think he believe was the guy to build a actual practical PL.

So, more like "take inspiration from me, and see how simplicity can be done".

More that he's a practical computer architect, producing h/w as well as s/w, and there's no sense complicating one very specific part of that —the PL toolchain— if it doesn't help build the systems he wants to build.

Lot's of excellent critiques and comments in this thread.

Wirth has spent most of his life in an academic environment which have shaped his opinions on teaching programming. He believes strongly that teaching programming is most effective when students can grasp the entirety of a small language.

Below are a few quotes from Wirth taken from a 2018 interview. I find myself agreeing with his opinions:

On designing a programming language:

"...a language designer picks ideas from others, facilities, features, and has the task of putting them into a coherent whole, into a framework. And that is less easy than people might think, because you want to have as much power in the language as possible, yet a compact structure and compact syntax. And that you can get I think only through experience with language design."

On teaching a first programming language

"..as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key. In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in. That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge."

On further development of Oberon:

"The incentive came from colleagues mentioning that they had learned very, very much from my book called Project Oberon, which is one of the very few describe a full system and its development in detail. That’s something in computer science that is wrong. People learn to write before they have learned reading."

> Yes. Did he do anything noteworthy after that? I honestly doubt it

Worth’s contributions may not seem significant to some, today, because he did make this contributions; championing simplicity and portability. In a lot of ways we stand on his shoulders. Anyone who feels shorted or that they don’t get their nickels worth should also read about the Oberon System which was a complete computer with peripherals and a ui.

The web is getting hugged, I uploaded the PDF here: https://archive.org/details/Modula-2-and-Oberon

If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM. There are other several Oberon implementations for different platforms listed here[1]

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

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

Fun fact: You can run Oberon OS on the Oberon RISC chip (emulated in JS) in your web browser from here: http://schierlm.github.io/OberonEmulator/

Golang is the modern Oberon.

Golang is not an OS. Golang doesn't fit in 12kib of source code. I could go on.

Depends on what extent an unikernel is an OS.

https://www.withsecure.com/en/solutions/innovative-security-...

Go has all the same features as Oberon has, in regards to systems programming, it is a matter of anyone finding it worthwhile to actually design a graphical OS with it.

I will conceed it lacks a very important one from Oberon, proper dynamic loading. Also the plugin packages are mostly abandoned across several releases.

However in this day and age, probably it would make more sense to do the dynamic loading capabilities of Oberon commands available via OS IPC instead.

> Go has all the same features as Oberon has

Go is missing both two new features Wirth introduced in Oberon compared to Modula (see section 5.2 of the referenced HOPL paper): type extension (i.e. inheritance) and type inclusion (no implicit coercion in Golang at all).

Taking a closer look there are only few similarities between Oberon and Go; both are garbage collected; Go uses the same separate receiver syntax element in method declarations as Oberon-2; and there is an intersection of keywords and also := appears, but the semantics are rather different.

You get similar workflows via interfaces, delegation and now generics to help reduce the boilerplate.

COM has done just great during the last 30 years without class inheritance.

I didn't say that the "Go way" was bad; just that there are few similarities. Certain things you can do in Oberon you cannot do in Go and vice versa. Personally I prefer Oberon+ over both Go and previous Oberons; if I didn't need to maintain backward compatibility with Oberon/-2/-07 I would remove type inclusion from Oberon+ and require explicit casts like Go; Wirth also removed type inclusion from Oberon-07, but he (unfortunately) also removed all numeric types but INTEGER, REAL and BYTE (but left some unfortunate implicit casts).

From that point of view yes, I do agree.

Although I still think Active Oberon is the best descendant from original Oberon, I am not a fan of the minimalist design Wirth persued afterwards.

In any case, Oberon's best days are behind it, hence why I would rather see some Go inspired approach to those ideas, even if I am not a big fan of Go's design.

> In any case, Oberon's best days are behind it

Maybe if you insist that parallel processing is part of the language (which you likely do if you prefer Active Oberon). Personally I think this can be well delegated to libraries to keep the language simple. Oberon+ doesn't use dedicated syntax even for exception handling; also "green" or regular threads, and channels and the like can well be covered by libraries or FFI. I'm neither a fan of Go's design, but with the ongoing work on Oberon+ I'm confident that its best days are yet to come.

The whole point of Oberon was the Smalltalk like experience, or to be more precise Mesa/Cedar like experience.

So to offer a bare bones language in 2022 without an OS that is at least at the same level of Blue Bottle, let alone what consumers expect from a modern OS is really not attainable.

It remains a nice language to look at as language nerd, and at the end of the day, pick something else when delivering software into production with the expectations that Swift, C#, Kotlin and so on can fulfill.

> The whole point of Oberon was the Smalltalk ... Mesa/Cedar like experience.

That's not even true if you mean the Oberon OS.

The idea - as described in the referenced HOPL paper - was the focus on the essentials of a language, which from my point of view is still a very valid goal, as you can see by just looking at the success of Go.

Swift, C#, Kotlin are at the other extreme of the spectrum, not too far away from modern C++ or Ada, where the language designers seem to want to integrate everything that anyone could ever want. That makes about as much sense as everyone today thinking they have to drive an SUV, and leave the bicycles or other economical means of transport as "a nice thing to look at" for the "transportation nerds".

It is definitly true for Oberon OS System 3.

Oberon-07 isn't it.

References?

References to what?

Worth's quest to reduce Oberon's usability to a language without the libraries and related OS infrastructure that made it interesting to use in first place?

References for your claim that "The whole point of Oberon was the Smalltalk ... Mesa/Cedar like experience." and "It is definitly true for Oberon OS System 3." I was at ETH until 1993 (and then again from 2000 to 2005 for my PhD) and have other information directly from the sources.

So now I have to find a magic paragraph, which as it seems won't change your mind anyway, because "I was there Luke", why bother life is too short.

No magic, just facts, Luke; don't search too long; look at the introductory sections of "Project Oberon, The Design of an Operating System and Compiler" (ACM 1992), "The Oberon Companion, A Guide to Using and Programming Oberon System 3" (vdf 1998), and Gutknecht, J (1994): Oberon System 3: Vision of a Future Software Technology, Springer, Software.

Thanks for proving me right it would be a waste of time.

See, this could have been a healthy discussion about Oberon, instead it went sour.

Learning is never a waste of time.

I don't think I have the breadth of your knowledge, so I would really love any thoughts you had on the language/OS I'm creating, github.com/civboot/fngi.

It's partly inspired from Oberon (although I started it without knowing about Oberon), but I'm still working my way through the book and language as I develop my own. I'm sure it's going to a decade+ project to have something valuable, but I'm hungry for any feedback I can get at this early stage.

Oberon language and Oberon OS are two distinct entities and given the context of this post it's obvious that I was talking about Oberon the language. Whether you like Go or not, it's the closest modern production language to Oberon and derived very much from it, so my point stands.

Ah, you're speaking of just the language. I've actually read a bit of the Oberon book and had no idea Golang was inspired by it. Good to know, since I consider both an inspiration for my own projects!

Golang is the admission by the creators of B, C, Unix, and Plan-9, that Wirth was right.

This is a rather bold claim given that the most obvious influence was the method syntax of Oberon-2 (designed by H.P. Mössenböck, the PhD supervisor of R. Griesemer), and besides that there are only some superficial similarities between Oberon and Go. See https://news.ycombinator.com/item?id=32303837.

Yes, I believe Robert Griesemer one of the three brains behind Golang is Wirths student.

Reply on news.ycombinator.com