I think this just a standard Raspberry Pi Linux distro with an emulator for "Project Oberon 2013" preloaded.
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.
Are there any "guided" walkthroughs for someone who has never used Oberon (or any of its later versions like Bluebottle or A2) that demonstrate its most unique UI/UX aspects? Something along the lines of Russ Cox' Tour of the Acme Editor[0] but for Oberon?
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.
Really cool to see Oberon / Modula retro-tech stuff on the front 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.
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.
No, it's not. Oberon is just a generic half-assed language that is completely impractical in the real world.
It's just that Oberon is so generic that it looks literally like anything (e.g. pre-1.5 Java).
Go has several significant differences that made it far more useful:
1. Multiple return values for error handling. Its Oberon equivalent is bupkis. If you look at their examples, they just YOLO and print errors onto the console.
2. Multiple _returns_. The latest Oberon edition does not support early return from functions.
Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design. Wirth had a very clear philosophy for his language, that he followed relentlessly. If you don't like that philosophy, you won't like Oberon, but there's nothing half-assed about it.
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.
> Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design.
Nope. I stand by my statement. Oberon is half-assed.
> 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.
And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
> Many of them were implemented in various versions by students of Wirth.
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.
> 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.
??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
> 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.
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.
> And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
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.
Oberon-07 doesn't allow multiple returns, though Wirth tended to favour single return.
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.
> A decision I disagree with, but again a very explicitly motivated design choice
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".
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 like hiding little easter eggs in my novels, I added a sneaky reference to Professor Wirth and Oberon in my last novel only one person I know got the reference.
The linked pdfs on that page are wonderful. I reread Wirth's Plea for Lean Software and it still holds up remarkably well. It reminded me of Alan Kay's VPRI and the STEPS Toward the Reinvention of Programming which unfortunately ended in 2012. Oberon also doesn't seem to be actively developed anymore as far as I can tell. Are there any similar projects that are still being actively worked on?
> Oberon also doesn't seem to be actively developed anymore
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.
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
The paper archive is still up. There were various interim reports generated for STEPS. I assume there was a final report as well, but I don’t remember reading it, myself. Vpri.org still works.
What is Oberon useful for? Apparently it's not very feature rich: limited Unicode support, limited graphics support, no XML, no JSON, no HTTP. Or am I wrong?
I think this just a standard Raspberry Pi Linux distro with an emulator for "Project Oberon 2013" preloaded.
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.
Are there any "guided" walkthroughs for someone who has never used Oberon (or any of its later versions like Bluebottle or A2) that demonstrate its most unique UI/UX aspects? Something along the lines of Russ Cox' Tour of the Acme Editor[0] but for Oberon?
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.
[0]: https://www.youtube.com/watch?v=dP1xVpMPn8M
There is Wirth's 4 page guide, How to use the Oberon System
https://people.inf.ethz.ch/wirth/ProjectOberon/UsingOberon.p...
Also The Oberon Pi Quick Reference and System User Guide at this project page.
Really cool to see Oberon / Modula retro-tech stuff on the front 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.
I would say Go is C dragged halfway towards Oberon. It's essentially the core group that created and used C admitting Wirth's work was better.
They were already inspired by it for how ACME works, and one of the creators, is a former ETHZ student, with a PhD in Oberon research.
No, it's not. Oberon is just a generic half-assed language that is completely impractical in the real world.
It's just that Oberon is so generic that it looks literally like anything (e.g. pre-1.5 Java).
Go has several significant differences that made it far more useful:
1. Multiple return values for error handling. Its Oberon equivalent is bupkis. If you look at their examples, they just YOLO and print errors onto the console.
2. Multiple _returns_. The latest Oberon edition does not support early return from functions.
3. Structural polymorphism (objects automatically implement conforming interfaces).
4. Generics, and initially generic maps and slices.
5. Small neat language features like using the last component of the package path to refer to names.
Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design. Wirth had a very clear philosophy for his language, that he followed relentlessly. If you don't like that philosophy, you won't like Oberon, but there's nothing half-assed about it.
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.
thank you for a well written reply, that I did not have the patience to write.
> Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design.
Nope. I stand by my statement. Oberon is half-assed.
> 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.
And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
> Many of them were implemented in various versions by students of Wirth.
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.
> 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.
??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
> 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.
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.
> And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
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.
God's multiple returns is, from someone whose primary language is Go for now, crap.
See https://herecomesthemoon.net/2025/03/multiple-return-values-... which goes into detail.
You don't get it. Oberon doesn't allow multiple _returns_, not merely multiple return _values_.
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.
Oberon-07 doesn't allow multiple returns, though Wirth tended to favour single return.
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.
> A decision I disagree with, but again a very explicitly motivated design choice
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".
While of course Pike found inspiration in Wirth, Golang wasn't just Pike; it was Pike, Thompson, and Griesemer. Wirth was Griesemer's doctoral thesis advisor, and the thesis itself was on a parallel version of Oberon he called Oberon-V: https://eulercenter.ru/pdf/eth10277.pdf https://www.research-collection.ethz.ch/handle/20.500.11850/...
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.
> how structurally similar Oberon is to Go
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 mean the whole design of Plan 9 is basically modeled after Oberon, and of course Go came from basically the same group
If this interests you, I highly recommend Luca Boasso’s oberonc project for the JVM[1].
1. https://github.com/lboasso/oberonc
Author of oberonc here, thanks for trying it out :)
Does anyone know if there's any (free online) university courses for writing your own OS on the Pi?
I like hiding little easter eggs in my novels, I added a sneaky reference to Professor Wirth and Oberon in my last novel only one person I know got the reference.
The linked pdfs on that page are wonderful. I reread Wirth's Plea for Lean Software and it still holds up remarkably well. It reminded me of Alan Kay's VPRI and the STEPS Toward the Reinvention of Programming which unfortunately ended in 2012. Oberon also doesn't seem to be actively developed anymore as far as I can tell. Are there any similar projects that are still being actively worked on?
> Oberon also doesn't seem to be actively developed anymore as far as I can tell
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.
> Oberon also doesn't seem to be actively developed anymore
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
was there ever a post mortem on STEPS? I'd like to know what happened as the demoes and ideas they had looked awesome.
The paper archive is still up. There were various interim reports generated for STEPS. I assume there was a final report as well, but I don’t remember reading it, myself. Vpri.org still works.
Final report is here:
https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf
There is Ultibo based bare metal Oberon version too: https://github.com/MGreim/ultiboberon
There used to be an Oberon app on Apple's app store. I ran it on Intel Macs for fun. It's sad it's no longer there.
On a side note, there was also an AT&T Blit terminal emulator that also vanished.
See https://news.ycombinator.com/item?id=43883747
Interesting name, considering that the “Pi” in “Raspberry Pi” was originally “Py”, since it was originally meant to boot directly into Python.
I like this a lot... But I'd love to to see a true bare-metal port even more.
A2 used to support StrongARM bare-metal. The tools are out there.
As learning experiences, what would be the difference between picking 9front and Oberon?
DuskOS it's integrating oberon too.
https://git.sr.ht/~vdupras/duskos
What is Oberon useful for? Apparently it's not very feature rich: limited Unicode support, limited graphics support, no XML, no JSON, no HTTP. Or am I wrong?