Oh, this is something I'm going to have to try. Excellent work!
I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a managed runtime like Java or dot net, and the Inferno OS, where it can both run hosted or "natively". Whenever I've skimmed the wikipedia or web pages I've been a bit confused.
Thanks. In contrast to Smalltalk or Lisp, Oberon is originally a native language, and the Oberon System originally was conceived as the native operating system of the Ceres computer used for teaching in the nineties at ETH Zurich. So there is no image as in Lisp or Smalltalk. Oberon lives on today in the form of various dialects and derivatives (such as my Oberon+ or Micron languages, see https://github.com/rochus-keller/oberon and https://github.com/rochus-keller/micron). There are indeed Oberon implementations which run on Java or ECMA 335 runtimes, which is possible due to the very restricted pointer handling and memory management of Oberon.
The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.
I often think this style of UI -- tiled text windows but with mouse and graphics interaction (similar to emacs actually) -- is what we should be using for the coding agents we're all using now.
I'd like to be able to dock panels of information, live-edit pieces of code instead of just "accept? Y/N", have side interactions, have real scroll bars and proper clipboards, even a live REPL alongside.
Instead we get Claude Code's janky "60fps TUI" full of bugs and barely interactive.
Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/). I even implemented an IDE which I used for the development (see https://github.com/rochus-keller/activeoberon/).
Thanks. The A2 Fox compiler actually has an ARM backend, so I would be surprised if nobody has migrated it to the Raspi yet. The 2003 version of AOS/Bluebottle (not A2) is on my list of interesting sytems, particularly because it supports multicore hardware.
Cool, tell me whether it worked. Unfortunately my mini HDMI adapter is broken and I have to wait for the new to arrive. But I already soldered the headers to the UART pins and observed the system start which looked as it should.
The system is up extremenly fast (compared to Linux), but then it takes pretty long to find the USB hub and the keyboard/mouse. Maybe I can still speed this up.
Oberon is both a programming language and an operating system used mostly for teaching, much like e.g. xv6 or xinu. Similar to the latter, Wirth has written text books about the system, some of which can be downloaded for free (see https://projectoberon.net/ for the PDF links).
> I still hope to see the world where Oberon is the future (and present) of OS and programming language design
I see you're into horror stories.
Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s.
Like not allowing multiple returns (not multiple return _values_ but multiple returns).
There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always in the service of making code easier to read, even if it makes it slightly harder to write.
Show me significant concepts implemented in today's languages which cannot directly be traced back to "things that were important in 1960-s" or seventies ;-)
Oh, this is something I'm going to have to try. Excellent work!
I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a managed runtime like Java or dot net, and the Inferno OS, where it can both run hosted or "natively". Whenever I've skimmed the wikipedia or web pages I've been a bit confused.
Thanks. In contrast to Smalltalk or Lisp, Oberon is originally a native language, and the Oberon System originally was conceived as the native operating system of the Ceres computer used for teaching in the nineties at ETH Zurich. So there is no image as in Lisp or Smalltalk. Oberon lives on today in the form of various dialects and derivatives (such as my Oberon+ or Micron languages, see https://github.com/rochus-keller/oberon and https://github.com/rochus-keller/micron). There are indeed Oberon implementations which run on Java or ECMA 335 runtimes, which is possible due to the very restricted pointer handling and memory management of Oberon.
Smalltalk too was originally a full OS running on bare metal back in the Xerox Alto days (1972-ish).
The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.
9 replies →
The Oberon user interface inspired Acme on Plan 9.
Oberon is a very nice, fun and cozy system and environment for programming. I lived in it for a few months back around 2010 and it was a joy.
I often think this style of UI -- tiled text windows but with mouse and graphics interaction (similar to emacs actually) -- is what we should be using for the coding agents we're all using now.
I'd like to be able to dock panels of information, live-edit pieces of code instead of just "accept? Y/N", have side interactions, have real scroll bars and proper clipboards, even a live REPL alongside.
Instead we get Claude Code's janky "60fps TUI" full of bugs and barely interactive.
This is great! I remember running System 3 on a 386 back when MS-DOS was king.
Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/). I even implemented an IDE which I used for the development (see https://github.com/rochus-keller/activeoberon/).
Have always been fond of Oberon! I would love to have A2/ActiveOberon/BlueBottle or whatever the name of the day is on a small native machine as well.
Great Stuff!
Thanks. The A2 Fox compiler actually has an ARM backend, so I would be surprised if nobody has migrated it to the Raspi yet. The 2003 version of AOS/Bluebottle (not A2) is on my list of interesting sytems, particularly because it supports multicore hardware.
Does Oberon still require capitalized keywords? That always seemed to be emphasizing the wrong thing:
Yes, the original Oberon (which the system is based on) has upper-case keywords (and some other orthodoxies). If you are looking for something more modern, go to https://github.com/rochus-keller/oberon, https://github.com/rochus-keller/luon or https://github.com/rochus-keller/micron.
I'm going to try and give it a go on a zero2 I have lying around. Thanks, this is exactly what I come to hacker news for.
Cool, tell me whether it worked. Unfortunately my mini HDMI adapter is broken and I have to wait for the new to arrive. But I already soldered the headers to the UART pins and observed the system start which looked as it should.
This is lovely. And I bet it is very fast on that hardware, all things considered.
The system is up extremenly fast (compared to Linux), but then it takes pretty long to find the USB hub and the keyboard/mouse. Maybe I can still speed this up.
Thank you, I've never heard of the Oberon os before.
Oberon is both a programming language and an operating system used mostly for teaching, much like e.g. xv6 or xinu. Similar to the latter, Wirth has written text books about the system, some of which can be downloaded for free (see https://projectoberon.net/ for the PDF links).
So good to see Oberon this accessible! Mad props!
I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it.
Thanks to your work, that's about to change.
Thank you times a thousand <3
> I still hope to see the world where Oberon is the future (and present) of OS and programming language design
I see you're into horror stories.
Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s.
Like not allowing multiple returns (not multiple return _values_ but multiple returns).
There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always in the service of making code easier to read, even if it makes it slightly harder to write.
2 replies →
Show me significant concepts implemented in today's languages which cannot directly be traced back to "things that were important in 1960-s" or seventies ;-)
2 replies →
[dead]
[dead]