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.
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.
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?
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.
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.
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 :)
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.
> 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
Interesting name, considering that the “Pi” in “Raspberry Pi” was originally “Py”, since it was originally meant to boot directly into Python.
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?
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.
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
See https://news.ycombinator.com/item?id=43883747
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