Oberon Pi
pascal.hansotten.com
pascal.hansotten.com
>> I think this just a standard Raspberry Pi Linux distro with an emulator for "Project Oberon 2013" preloaded.
No, it's the standard Oberon 2013 with nontrivial changes made to the UI, to make it significantly easier to learn and use than Oberon 2013. Oberon Pi runs as an app on the standard Raspberry Pi OS, using the standard Oberon RISC emulator written in C.
>> Are there any "guided" walkthroughs for someone who has never used Oberon
Yes. The Oberon Pi System User Guide was specifically written to address this learning gap in the existing Oberon doc universe (though it is specific to Oberon Pi). Note that the system user guide is included in the Oberon Pi release as an integrated help document.
>> limited Unicode support, limited graphics support, no XML, no JSON, no HTTP.
Oberon is a historical software system which predates all these features – to judge it by contemporary software standards is ahistorical.
>> Go has several significant differences that made it far more useful >> I'd love to to see a true bare-metal port
Because Oberon is historical, upgrading it to compete with contemporary software entirely misses the point. But teaching Oberon in computer science education would be entirely apposite, for the same reasons as teaching algebra and geometry.
Oberon has a tortured version history, so it takes a bit to explain what "Project Oberon 2013" is, but it's basically representative of Oberon in a very early stage of development.
This version was originally described by Wirth in his 1992 book "Project Oberon: The Design of an Operating System, a Compiler and a Computer". After his retirement he prepared a new edition, which came to be known as "Project Oberon 2013". For this edition he switched out the "computer" part -- the original used the now extremely obscure NS32000 CPU, the new edition used a custom RISC architecture implemented on an FPGA. But otherwise than this "implementation detail", the system was unchanged.
(And of course, given the FPGA source code, it's easy to build an emulator.)
But if you try this and it feels primitive -- it is. Later versions of Oberon got much fancier.
Oberon seems fascinating and I would like to eventually play around with it in an emulator, but any resources that show how it's being used (as opposed to a description of its design like in Wirth's book for example) would be appreciated.
https://people.inf.ethz.ch/wirth/ProjectOberon/UsingOberon.p...
Also The Oberon Pi Quick Reference and System User Guide at this project page.
Whats somewhat interesting is how structurally similar Oberon is to Go. One could say Go is Oberon dragged halfway towards C/Unix conventions (curly braces) with Go channels slapped on.
Rob Pike was aware of Wirth's work, as his ACME editor (https://en.wikipedia.org/wiki/Acme_(text_editor) ) took inspiration from it.
So either way, if there was inspiration for Go form Oberon or if there was not [a case of convergent evolution I guess in that case], it shows the strength of Wirth's thought.
With respect some of your points, the lack of support for early returns is one of those philosophical decisions, as is many of the other "missing" features.
Many of them were implemented in various versions by students of Wirth. Polymorphism for Oberon was the subject of at two projects at EHTZ in the 90's, including an at the time fairly novel approaches for a runtime extensible vtable approach to polymorphism.
As for your #5, to me that's one of the most horific warts I can think of in the languages that use it, but again a question of philosophy, and certainly one aspect of Go I detest.
But to go back to Oberon, as a language user, I find Oberon too austere, but as an implementer, the design is beautiful in its simplicitly and how clean it is, and I wish more language implementers paid attention to Wirths work as a starting point, and paid attention to his systematic approach to language design - even if I'd prefer a result that isn't as minimalist.
This is why I called this view grossly ignorant. No, it's not easy when you have the added constraint of producing a language that is practical enough to write an OS and applications with. Have you tried? How many such languages have you designed? Can we see the grammar?
Producing a small language that is Turing complete is easy, yes. And it is also entirely uninteresting if that is all you do.
Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it.
> Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic.
> Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH.
Entirely missing the point, which is that implementations existed and that including them in the official version of the language was a conscious design choice, rather than any indication it was "half-assed".
> ??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
Yes. And? I wrote what I wrote, and what I wrote is true. Nothing I wrote talked about "the standard Oberon-2". The entire point of the Oberon work at ETHZ was that it was a teaching language, and a lot of the projects involved experimental changes to the language and compiler.
To your mention of vtables, I was specifically thinking of Michael Franz' paper on Protocol Extension, that introduced a two-layer set of indirections to allow runtime extension with interfaces.
Again, the point is that not including these in the standard version of Oberon was a conscious choice.
A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people.
Personally, I loved Franz' work on Protocol Extension to the point that my (buggy, temporarily abandoned, unfinished) prototype Ruby compiler uses his propagation method for vtable updates to allow for vtable-based dynamic method redefinition, and think it'd have been a great addition to standard Oberon, so it's not that I disagree that it could have used a more flexible way of doing OO.
But I do respect Wirth's extremely focused design, even where I disagree with it.
So I stand by what I wrote: To call it half-assed is grossly ignorant.
> Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports.
I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
I actually did, as a part of my CS course. My compiler had COM support (hey, it was late 90-s!) with IUnknown and IDispatch, optional static typing, and interface-based polymorphism. I could use it to compile the code for DOS, Windows, and Netware (don't ask). So yeah, I know exactly what is needed to design a compiler that can be used to write an OS.
It is not hard at all. And I did not know about Oberon at that time.
> Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it.
Oberon is an utter failure, in everything it touched. It failed in academia, it failed in industry, it failed everywhere. Despite being forced onto students in the ETH.
> Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic.
I though that Go was practically Oberon?!?
> A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people.
Yeah? What culmination? What has Oberon achieved? Where are the masterpieces in Oberon? It's been 30 years since its original edition and the only major university that touched it was the ETH.
All the code I've seen in Oberon is just gross. Look at the Bluebottle/A2 source code, it's just terrible. No coherent error handling, poor structure, lots of unnecessary nesting in the source code, etc. You can even open something like UHCI USB implementation and compare it with Linux drivers.
> I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
When why did you mention it?
It's not hard at all when you cut off the design constraint that it should be minimal. You keep taking shortcuts and argue against positions that are very different from the positions I have taken, and I can't tell whether you're doing so on purpose or if you just fail to understand what it is I've written.
> Oberon is an utter failure, in everything it touched. It failed in academia, it failed in industry, it failed everywhere. Despite being forced onto students in the ETH.
Even if we were to postulate that you are right, this is another strawman that has nothing to do with your initial claim it was "half-assed".
(And most people should dream of having a "failure" that has provided as much inspiration to people as Oberon, as most people never will)
> I though that Go was practically Oberon?!?
You can have that discussion with someone who actually thinks that. I have not claimed that, nor would I. Go goes very significantly against Wirth's design ideals in many ways.
> Yeah? What culmination?
Do you not understand basic English sentence structure? "It" in the sentence you quoted refers to Oberon. In other words Oberon is the culmination.
> What has Oberon achieved? Where are the masterpieces in Oberon? It's been 30 years since its original edition and the only major university that touched it was the ETH.
Strawman. The claim you made that I objected to was the ignorant opinion that it was "half-assed", not that it was commercially successful or otherwise widespread. You seem incapable of actually defending the claim of yours I disagreed with, and keep trying to set up new strawmen with every new comment.
> All the code I've seen in Oberon is just gross. Look at the Bluebottle/A2 source code, it's just terrible.
Bluebottle/A2 has nothing to do with Wirth - it was developed after he retired -, so another strawman that says nothing about whether the design of Oberon the language was "half-assed".
Like a lot of your other complaints here, it seems to come down to you conflating the design of the language with what others have or have not done with it and/or conflating success with the quality of the design.
> When why did you mention it?
I haven't once argued against package prefixes. Read what I responded to again, and try not to assume I've claimed things I haven't. I objected to defaulting to using the last element of the package path.
See https://herecomesthemoon.net/2025/03/multiple-return-values-... which goes into detail.
As in, you can't write "return val;" in the middle of a function.
FWIW, I don't like explicit error handling in Go, but it's undeniably minimalistic and practical.
In Wirth's introduction of Oberon-07, he specifically gave an example of an Oberon procedure with multiple returns, and the corresponding Oberon-07 version, where a single return at the very end is enforced and the only syntactically valid way of including a return.
A decision I disagree with, but again a very explicitly motivated design choice - Oberon-07 in particular reflected years of looking largely at what Oberon could do without to achieve something that cut down complexity even further without being too limiting.
It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.
As I said, he cared more about ideology. Early returns significantly improve imperative code. They are not necessary in fully functional languages, where you can easily juggle with blocks of logic, but Oberon is not such a language.
> It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.
It was basically: "my way or you're expelled because I'm the emeritus professor here".
His views on it are as much or little ideology as your views on it are. They are rooted in a view of design you clearly don't share. That's fine.
With respect to early returns, I disagree with him too, but I understead why he dislikes them - they do affect reasoning about a piece of code, and Wirth cared deeply about the ability to reason about the code more than about convenience.
You may not agree with that choice, but it's an entirely valid choice.
> It was basically: "my way or you're expelled because I'm the emeritus professor here".
That's extreme hyperbole, and just suggests you haven't read much of ETHZ's research output, which is full of dissertations and papers doing things Wirth didn't want in the standard Oberon. Including plenty of works he was the adviser for.
And given that Oberon-07 wasn't released until nearly a decade after he retired, it's also nonsense.
No. The practice of writing code has clearly shown that early returns lead to better structured code. It's not even disputable anymore.
> they do affect reasoning about a piece of code, and Wirth cared deeply about the ability to reason about the code more than about convenience.
Then he should have looked at functional languages, rather than missing the point of them completely.
> That's extreme hyperbole, and just suggests you haven't read much of ETHZ's research output, which is full of dissertations and papers doing things Wirth didn't want in the standard Oberon. Including plenty of works he was the adviser for.
OK. What are the superstar Oberon projects that are used by a large number of people? Can you name ANY? I don't know any, and I know unfortunately a lot about Oberon and its cult members.
I am familiar with ETH research, and I actually employ an ETH professor, and an alumnus. I don't think I've seen any mentions of Oberon in their highest rated recent ETH research.
What is "better structured" is subjective. So, yes, it is very much disputable, however much you'd like it to not be. I happen to agree that it leads to better structured code, but I'm not arrogant enough to presume this to be an objective view, because the difference is very minor and is also largerly affected by coding style.
> Then he should have looked at functional languages, rather than missing the point of them completely.
Having looked plenty at functional language, the complexity of compilation of functional languages that are fast enough to be practical is vastly higher, and compilation complexity was a major aspect of his philosophy of what made a good language.
I'm all for making cautious tradeoffs to make developer experience nicer, but if you think he missed the point of them, you don't understand his philosophy on simplicity.
Again, it's fine to disagree with him about it, but a core part of the philosophy behind Oberon was to whittle the language down to what could demonstrably be implemented in a very simple but efficient way.
So again, when you call it "half-assed" while again and again demonstrating that you're ignoring the very extensive amount of thinking that went into the choices made, it makes it clear my initial assessment was right.
> OK. What are the superstar Oberon projects that are used by a large number of people? Can you name ANY? I don't know any, and I know unfortunately a lot about Oberon and its cult members.
Strawman. I've not suggested there are any "superstar Oberon projects that are used by a large number of people", so this has zero relevance to any of the things I've argued. You've either entirely missed the point of the sentence you quoted, or have run out of arguments.
> I am familiar with ETH research, and I actually employ an ETH professor, and an alumnus. I don't think I've seen any mentions of Oberon in their highest rated recent ETH research.
Which again has zero relevance to the sentence you quoted, which was in response to your ludicrous suggestion that 'It was basically: "my way or you're expelled because I'm the emeritus professor here"' in response to my statement about admiring Wirths approach to language design, after you went on about early returns - a feature Wirth introduced into Oberon-07 which he designed after retiring.
The projects I referenced happened in the 90's, while he was still at ETHZ. If you are familiar with the ETH research during the era, you'd be aware of a long range of PhD dissertations and technical reports that provided alternative feature sets for Oberon, as per what I argued above to show that the design of standard Oberon was concious choices to keep it minimal rather than some lack of effort. Wirth was an examiner for Franz' 1994 dissertation on JIT'ing Oberon code, for example.
You keep moving goalposts, and bringing up strawmen, because your initial claim that it was "half-assed" is entirely unsupportable.
While I share that opinion, I recognise that it is, in fact, an opinion.
> It's not even disputable anymore.
For it to not even be disputable anymore you need a mountain of overwhelming evidence in the form of peer-reviewed double-blind studies. IIRC, there's maybe 2 papers that have very weak and never-reproduced evidence for early returns leading to better code in terms of cyclometric comlexity (not even "better structured", which is pretty subjective).
There are minor similarities, mostly the fact that it is garbage collected, and also the receiver syntax Go inherited from Oberon-2 (i.e. proposed by Mössenböck, not by Wirth). Go has a completely different focus and is essentially a further development of Newsqueak, which was mostly influenced by Pascal and C.
I have to say, though, that I think Golang is a lot more similar to Newsqueak (which Pike did before working with Griesemer) than to Oberon.
See https://github.com/rochus-keller/Oberon, and derived languages such as https://github.com/rochus-keller/Luon or https://github.com/rochus-keller/Micron, which inherit the "spirit of Oberon", but specialize for other use-cases than the original.
That's pretty much it, for maybe 10+ years now. There was a successor project BlueBottle with some promise, but it did not deliver. Later it was renamed to A2. Surprisingly, it did not help.
https://en.wikipedia.org/wiki/A2_(operating_system)
IMO the authors of BB/A2 bet heavily on XML/Java hype, and were trying to make Oberon more like Java. The result was something without much internal consistency and not very usable.
Not being able to use a major browser and not having the resources to write one from scratch did not help either.
Then some of the major figures of this project left. And that was it.
There are some hobbyists and some small businesses which use it for niche projects and that is all
On a side note, there was also an AT&T Blit terminal emulator that also vanished.
A2 used to support StrongARM bare-metal. The tools are out there.
https://github.com/bztsrc/raspi3-tutorial/
Or this, which builds on it?
I wonder if there's some lectures to follow as well, on this topic.