Spotting similarities betwen the appearance of the Oberon System and Plan 9, or Oberon syntax bits that were used in later languages, is left as an exercise for the reader.
swiftcoder 11 hours ago [-]
I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem
MisterTea 6 hours ago [-]
I am surprised the top comment on an HN post is someone asking what Oberon is (especially someone who have programmer in their name.) Oberon is not only a programming language, but an entire software and hardware computing system built from the ground up to be as minimal as possible by famed computer scientist Niklaus Wirth. Simple RISC CPU, Oberon compiler, OS And Windowing system. The windowing system was famously copied by Rob Pike's Acme text editor on Plan 9.
I'm quite familiar with Project Oberon as a professor who studies operating systems and programming languages, but even though this is Hacker News where many of us are familiar with the project, I'm not surprised that there are also many readers who are not familiar with it, since Oberon does not have the userbase of much more popular programming languages and operating systems, and it's not even covered in many undergraduate courses on those topics. Most undergraduate OS courses are Unix-focused, centering on either Linux, Minix, or xv6. The Oberon OS is certainly not Unix. Programming languages and compiler courses tend to vary, but I haven't seen one that uses Oberon.
MisterTea 4 hours ago [-]
I am not a CS student nor have I had a "programming job." I just enjoy computing which leads me to explore the different design philosophies so I read and tinker. Currently I am learning Ada, itself based on Wirth's Pascal so I am on a bit of a Wirthian kick.
justin66 35 minutes ago [-]
Remember that people who familiarize themselves with computing history are neither "crushing it" nor doing anything else evocative of advertising for energy drinks. Study of computing history is therefore something to be avoided.
swiftcoder 5 hours ago [-]
I mean, in all fairness, I wasn't even born when Oberon started development
nxpnsv 4 hours ago [-]
It's not just you. I started coding in the 80s. Never heard of Oberon.
shrubble 6 hours ago [-]
A picture of the running system is the first thing you see at the link.
On the screen is (readable to me at least) the first page of the paper "Oberon Language Report" showing N. Wirth as the author.
In the Introduction to the on-screen document it says, "Oberon is a general-purpose programming language that evolved from Modula-2."
Pasting a Wikipedia link or saying "just ask an LLM" only helps out the one instance of someone not knowing. I did the same thing as the OP you're replying to. They're right - a brief summary in the readme would be a near zero-effort permanent fix to people who stumble on your project and dont know what Oberon is.
luismedel 5 hours ago [-]
Honest question. Where does one stop clarifying things?
wk_end 4 hours ago [-]
One of the basic principles of communication is that you have a mental model of the person you're communicating with and are phrasing what you want them to understand in terms that you think they'll understand. So whenever you're writing something - anything - you should be writing with a target audience in mind, and stop explaining right around the point where you believe that your target audience doesn't need further explanation.
Of course it's normal for there to be a disconnect between your assumptions about your target audience and reality. In a real conversation this happens all the time and it's no big deal. When something's written and especially when it's printed it can be a bit more of a problem, so maybe better to err on the side of over-explaining. Also a good reason to have editors and proofreaders. But I'm rambling a bit.
In this case, the link was posted to HN by the author, so the author might have had "average HN reader" in mind. Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich I personally wouldn't expect someone - even someone in tech - to know about it.
luismedel 4 hours ago [-]
Exactly. I knew what the link was about and didn't study at ETH Zurich. I (mistakenly?) think Oberon is that kind of "roots knowledge" shared between all of us, like Lisp or Forth. That's why I asked when one should stop clarifying things. Maybe some people need to know what a compiler os, or a VM, or a windowing system, or ...whatever.
What I mean is that having so much info at the toe of our tips, comments like "you should put a link about what this thing is" are needless.
wk_end 3 hours ago [-]
> I (mistakenly?) think Oberon is that kind of "roots knowledge" shared between all of us, like Lisp or Forth.
Yes, I think that's a mistake. Lisp and Forth saw widespread commercial use, were hugely influential, and directly begat many other languages. While I'd expect most folks on here to be familiar with Pascal - you could say those same things about it - and maybe even know who Wirth is, Oberon basically saw no commercial use whatsoever and even in academia was basically only used at the school it came from. There's no real comparison.
fhars 2 hours ago [-]
Yes, you are likely confusing Oberon with Pascal. That is the Wirth language people usually have heard about. They may also have heard about Modula 2, but assuming that is stretching it. I was already interested in computers at the time, but I still only remember Oberon as that even bigger failure than Modula.
swiftcoder 4 hours ago [-]
The problem with this is that there are so many branches of tech from 40 years ago that any one person is unlikely to be familiar with all of them.
I'm plenty familiar with the whole Modula 3 -> NextSTEP branch of this little tree, but the Oberon branch isn't something I've run into before.
nothinkjustai 3 hours ago [-]
Sorry, can you explain what ETH Zurich is? I’m not familiar with that term.
homarp 3 hours ago [-]
it is an Ethereum fork, named after Jan Zurich (a cousin of the famous Chief Niklaus Emil Wirth). Jan Zurich discovered a little moon on Uranus, and named it Blaise
It’s also worth noting that Jan (who strictly uses the pronouns var / val) belongs to one of the most historically marginalized groups in modern tech: One-Pass Compiler Enthusiasts. They were repeatedly ostracized by the bloated LLVM cabal for stating that any build process taking longer than 50 milliseconds is a toxic social construct. The ETH fork was actually meant to fund a decentralized safe space where nobody is ever forced to use a borrow checker.
wk_end 2 hours ago [-]
I assume you're just trolling to make a rhetorical point (apologies if not!), but FWIW:
ETH Zurich is one of the most well-regarded technical schools in the world, and arguably the most well-regarded technical school in Europe. It has many famous alumni, including Albert Einstein. I think it's fair to expect most people in tech to be familiar with the big schools in the field, even the ones in Europe, though maybe that's giving too much credit to Americans.
But maybe it's also worth pointing out some other principles of communication: ETH Zurich wasn't really the main topic of my comment, and it's OK if readers don't catch every reference; communication is invariably lossy, and as long as general meaning is conveyed that's OK! Also, given the context (the sentence "Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich...") even if the reader hadn't heard of ETH Zurich it could be reasonably inferred that ETH Zurich is an academic institution, probably in Zurich, where Oberon was successful. Part of writing is trusting that the reader is a rational person who understands how (the) language and the world work, otherwise communication becomes impossible.
Some associated ideas in the philosophy of language might be the "cooperative principle", the "principle of humanity", and the "principle of charity". I'll frankly make a muddle of trying to explain them in detail, and this reply is already too long and too snarky, so in this case I'd ask the interested reader to consult Wikipedia, the Stanford Encyclopedia of Philosophy, etc.
Rochus 3 hours ago [-]
[dead]
spijdar 1 days ago [-]
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.
Rochus 1 days ago [-]
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.
foruhar 1 days ago [-]
Smalltalk too was originally a full OS running on bare metal back in the Xerox Alto days (1972-ish).
Rochus 1 days ago [-]
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.
EffCompute 1 days ago [-]
It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems.
While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.
Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?
Rochus 1 days ago [-]
I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance was roughly equivalent to that of GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O...). The C++ type system is also pretty strict, and on the other hand it's possible and even unavoidable in the Oberon system 3 to do pointer arithmetics and other things common in C behind the compiler's back (via the SYSTEM module features which are not even type safe). So the original Oberon syntax and semantics is likely not on the sweet spot of systems programming. With my Micron (i.e. Micro Oberon, see https://github.com/rochus-keller/micron/) language currently in development I try for one part to get closer to C in terms of features and performance, but with stricter type safety, and on the other hand it also supports high-level applications e.g. with a garbage collector; the availabiltiy of features is controlled via language levels which are selected on module level. This design can be regarded as a consequence of many years of studying/working with Wirth languages and the Oberon system.
vidarh 24 hours ago [-]
There was a couple of PhD theses at ETH Zurich in the 90s on optimizations for Oberon, as well as SSA support. I haven't looked at your language yet, but depending on how advanced your compiler is, and how similar to Oberon, they might be worth looking up.
Rochus 23 hours ago [-]
I'm only aware of Brandis’s thesis who did optimizations on a subset of Oberon for the PPC architecture. There was also a JIT compiler, but not particularly optimized. OP2 was the prevalent compiler and continued to be extended and used for AOS, and it wasn't optimizing. To really assess whether a given language can achieve higher performance than other languages due to its special design features, we should actually implement it on the same optimizing infrastructure as the other languages (e.g. LLVM) so that both implementations have the same chance to get out the maximum possible benefit. Otherwise there are always alternative explanations for performance differences.
vidarh 21 hours ago [-]
It might have been Brandis' thesis I was primarily thinking about. Of the PhD theses at EHTz on Oberon, I'm also a big fan of Michael Franz' thesis on Semantic Dictionary Encoding, but that only touched on optimization potential as a sidenote. I'm certain there was at least one other paper on optimization, but it might not have been a PhD thesis...
I get the motivation for wanting to use LLVM, but personally I don't like it (and have the luxury of ignoring it since I only do compilers as a hobby...) and prefer to aim for self-hosting whenever I work on a language. But LLVM is of course a perfectly fine choice if your goal doesn't include self-hosting - you get a lot for free.
Rochus 21 hours ago [-]
I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex or time-consuming (and ultimately, you’re still dependent on binutils). However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement.
guenthert 10 hours ago [-]
> However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement.
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
Rochus 10 hours ago [-]
> I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
That's exactly the question we would hope to answer with such an experiment. Given that your language received sufficient investments to implement an optimal LLVM adaptation (as C did), we would then expect your language to be significantly faster on a benchmark heavily depending on matrix multiplication. If not, this would mean that the optimizer can get away with any language and the specific language design features have little impact on performance (and we can use them without performance worries).
EffCompute 3 hours ago [-]
[dead]
gobdovan 12 hours ago [-]
When you call LLVM IR a design failure, do you mean its semantic model (e.g., memory/UB), or its role as a cross-language contract? Is there a specific IR propert that prevents clean mapping from Oberon?
Rochus 10 hours ago [-]
Several historical design choices within the IR itself have created immense complexity, leading to unsound optimizations and severe compile-time bloat. It's not high-level enough so you e.g. don't have to care about ABI details, and it's not low-level enought to actually take care of those ABI details in a decent way. And it's a continuous moving target. You cannot implement something which then continus to work.
pjmlp 7 hours ago [-]
To be fair they also kind of share that opinion, hence why MLIR came to be, first only for AI, nowadays for everything, even C is going to get its own MLIR (ongoing effort).
fuck_google 16 hours ago [-]
[dead]
girvo 22 hours ago [-]
Is anyone attempting to implement Oberon on LLVM IR? Sounds like a fun project
Rochus 21 hours ago [-]
Threre are at least two projects I'm aware of, but I don't think they are ready yet to make serious measurements or to make optimal use of LLVM (just too big and complex for most people).
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.
cmrdporcupine 22 hours ago [-]
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.
pjmlp 12 hours ago [-]
This is great, especially being System 3, given the nice user experience Oberon eventually morphed into.
In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language.
I prefer the path taken down by Active Oberon, however that doesn't seem to also get that much love nowadays, and is much more complex to explore than System 3.
For those that not know it, it already had something like OLE (inspired by how Xerox PARC did it with Cedar), an AOT/JIT compilation system (with slim binaries for portability), and everything on a memory safe systems language.
Rochus 9 hours ago [-]
Thanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
pjmlp 9 hours ago [-]
Sure, but that in the end is what matters with memory safe systems languages, reduction of attack surface and easy to spot when safety is being disabled.
Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
Rochus 9 hours ago [-]
There are better alternatives than assembly. The Oberon approach would already benefit if low-level code no longer operates behind the compiler's back and instead supports full type checking. My new Micron language provides this.
pjmlp 7 hours ago [-]
Sure, in theory we could do NEWP style, where everything needed for lowlevel is provided as intrisics, and Assembly isn't even available.
However this doesn't seem to be a solution that many are keen on going through.
How is Micro doing it?
Rochus 6 hours ago [-]
There is actually no good reason why the SYSTEM features use LONGINT instead of typed pointers. C at least has type support, even if the compiler ignores it for many situations.
Micron is doing well; the language definition has matured; it now even supports Go interfaces from level 2 onwards (i.e. even for plain records before level 3 adds dynamic memory).
The primary goal of Micron is not safety, but to make a better C, Pascal and Oberon, adding some features which turned out to be very useful in C++, but without the complexity. The compiler now has an x86 and ARMv7 backend with debug support. RV32 support is on the horizon. And there is a C99 transpiler if need be.
musicale 21 hours ago [-]
Does Oberon still require capitalized keywords? That always seemed to be emphasizing the wrong thing:
However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords.
It is a non problem, like discussion of parentheses or white space in programming languages that require them.
tengwar2 8 hours ago [-]
Does the editor in this environment do automatic capitalisation?
I have to say that when I used Modula-2, editors were very simple and banging away on the shift key or caps lock was a real irritation.
pjmlp 7 hours ago [-]
Not directly if I remember correctly, but there are OS formatting tools.
Windows IDE tooling for Modula-2, or using something like XEmacs/Emacs or Brief.
butterisgood 22 hours ago [-]
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!
Rochus 21 hours ago [-]
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.
eterps 1 days ago [-]
This is great! I remember running System 3 on a 386 back when MS-DOS was king.
Rochus 1 days ago [-]
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/).
anta40 13 hours ago [-]
Cool. Is macOS (Apple Silicon) also supported?
If not, well there's another reason to have a Linux VM ready :)
Rochus 10 hours ago [-]
Technically yes, but since Apple locked down their OS completely, you might have to compile the tools yourself on your machine so the OS allows them to start at all.
rootbear 4 hours ago [-]
Will this image also work on the 3B+? I have a spare one of those that I can try this out on.
1 days ago [-]
chinabot 22 hours ago [-]
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.
Rochus 22 hours ago [-]
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.
rcarmo 23 hours ago [-]
This is lovely. And I bet it is very fast on that hardware, all things considered.
Rochus 22 hours ago [-]
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.
ike____________ 1 days ago [-]
Thank you, I've never heard of the Oberon os before.
Rochus 1 days ago [-]
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).
tomcam 1 days ago [-]
So good to see Oberon this accessible! Mad props!
alterom 1 days ago [-]
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
cyberax 1 days ago [-]
> 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).
jhbadger 23 hours ago [-]
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.
imtringued 8 hours ago [-]
This unnecessarily creates the need for mutable variables in every function when in practical code bases 95%+ of variables programmers define are immutable and are only mutable because the programming language forces mutability by default. Mutable variables make local reasoning harder since you have to inspect all write locations to understand the impact of any given line of code.
cyberax 22 hours ago [-]
The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling.
Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically.
In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the 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.
And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.
Rochus 21 hours ago [-]
It all boils down to the fact that ideas should be viewed as tools rather than dogmas, and famous people are neither infallible nor prophets simply because they had a few good ideas.
rbanffy 11 hours ago [-]
> Every ambient condition that you need to track adds mental load
Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
cyberax 10 minutes ago [-]
"Limit" how? I suggest looking at any real code in Oberon that has to deal with the real world.
E.g. a USB driver.
Rochus 1 days ago [-]
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 ;-)
cyberax 22 hours ago [-]
"Traced back" is fine. We can trace back the size of the Shuttle's boosters to the width of the roads in the Roman Empire.
Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.
Rochus 21 hours ago [-]
Well, a lot of ideas (and I mean really a lot) from the sixties are still very relevant today, and indeed, there are also problems discovered in the sixties still waiting for a solution. We don't have to live in the past, but many "new" things aren't actually new, or are not better just because they are new.
cyberax 14 hours ago [-]
Of course. Problems that existed in 60-s were very real. And structured programming was an improvement over messy gotos.
At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability.
And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.
tengwar2 8 hours ago [-]
The story about "the width of the backsides of two Roman horses" is just a myth. Which should be obvious if you look at the many different railway gauges in use. You can trace it back to 19C standardisation, and argue over whether Brunel's 7'¼" was better than standard gauge, or if we should all have converted to 3m Breitspurbahn, but that's a different question.
cyberax 1 hours ago [-]
The thing is, it's not a _total_ myth. All the widespread standard railway gauges are very close to each other, within about 20 cm.
pjmlp 12 hours ago [-]
Apparently a school of though widely embraced by Go scholars, nowadays resposible for our cloud infrastructure.
cyberax 1 hours ago [-]
Go added multiple returns for error/exception handling. It's a solution, just not a pretty one.
In comparison, Oberon has... nothing. If you check the source code of Oberon OS for something like USB, a lot of code is either YOLO or a mess of nested blocks.
alex38928392 10 hours ago [-]
[dead]
zephyrwhimsy 18 hours ago [-]
[dead]
zephyrwhimsy 1 days ago [-]
[dead]
devcraft_ai 11 hours ago [-]
[dead]
Rendered at 19:38:48 GMT+0000 (Coordinated Universal Time) with Vercel.
The Oberon language and the Oberon System were featured in Byte Magazine several times, most notably in Dick Pountain's articles:
https://vintageapple.org/byte/pdf/199103_Byte_Magazine_Vol_1... https://vintageapple.org/byte/pdf/199305_Byte_Magazine_Vol_1... https://vintageapple.org/byte/pdf/199501_Byte_Magazine_Vol_2...
Spotting similarities betwen the appearance of the Oberon System and Plan 9, or Oberon syntax bits that were used in later languages, is left as an exercise for the reader.
https://projectoberon.net/
On the screen is (readable to me at least) the first page of the paper "Oberon Language Report" showing N. Wirth as the author.
In the Introduction to the on-screen document it says, "Oberon is a general-purpose programming language that evolved from Modula-2."
Of course it's normal for there to be a disconnect between your assumptions about your target audience and reality. In a real conversation this happens all the time and it's no big deal. When something's written and especially when it's printed it can be a bit more of a problem, so maybe better to err on the side of over-explaining. Also a good reason to have editors and proofreaders. But I'm rambling a bit.
In this case, the link was posted to HN by the author, so the author might have had "average HN reader" in mind. Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich I personally wouldn't expect someone - even someone in tech - to know about it.
What I mean is that having so much info at the toe of our tips, comments like "you should put a link about what this thing is" are needless.
Yes, I think that's a mistake. Lisp and Forth saw widespread commercial use, were hugely influential, and directly begat many other languages. While I'd expect most folks on here to be familiar with Pascal - you could say those same things about it - and maybe even know who Wirth is, Oberon basically saw no commercial use whatsoever and even in academia was basically only used at the school it came from. There's no real comparison.
I'm plenty familiar with the whole Modula 3 -> NextSTEP branch of this little tree, but the Oberon branch isn't something I've run into before.
see timeline on https://ethereum.org/ethereum-forks/
ETH Zurich is one of the most well-regarded technical schools in the world, and arguably the most well-regarded technical school in Europe. It has many famous alumni, including Albert Einstein. I think it's fair to expect most people in tech to be familiar with the big schools in the field, even the ones in Europe, though maybe that's giving too much credit to Americans.
But maybe it's also worth pointing out some other principles of communication: ETH Zurich wasn't really the main topic of my comment, and it's OK if readers don't catch every reference; communication is invariably lossy, and as long as general meaning is conveyed that's OK! Also, given the context (the sentence "Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich...") even if the reader hadn't heard of ETH Zurich it could be reasonably inferred that ETH Zurich is an academic institution, probably in Zurich, where Oberon was successful. Part of writing is trusting that the reader is a rational person who understands how (the) language and the world work, otherwise communication becomes impossible.
Some associated ideas in the philosophy of language might be the "cooperative principle", the "principle of humanity", and the "principle of charity". I'll frankly make a muddle of trying to explain them in detail, and this reply is already too long and too snarky, so in this case I'd ask the interested reader to consult Wikipedia, the Stanford Encyclopedia of Philosophy, etc.
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.
While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.
Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?
I get the motivation for wanting to use LLVM, but personally I don't like it (and have the luxury of ignoring it since I only do compilers as a hobby...) and prefer to aim for self-hosting whenever I work on a language. But LLVM is of course a perfectly fine choice if your goal doesn't include self-hosting - you get a lot for free.
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
That's exactly the question we would hope to answer with such an experiment. Given that your language received sufficient investments to implement an optimal LLVM adaptation (as C did), we would then expect your language to be significantly faster on a benchmark heavily depending on matrix multiplication. If not, this would mean that the optimizer can get away with any language and the specific language design features have little impact on performance (and we can use them without performance worries).
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'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.
In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language.
I prefer the path taken down by Active Oberon, however that doesn't seem to also get that much love nowadays, and is much more complex to explore than System 3.
For those that not know it, it already had something like OLE (inspired by how Xerox PARC did it with Cedar), an AOT/JIT compilation system (with slim binaries for portability), and everything on a memory safe systems language.
Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
However this doesn't seem to be a solution that many are keen on going through.
How is Micro doing it?
Micron is doing well; the language definition has matured; it now even supports Go interfaces from level 2 onwards (i.e. even for plain records before level 3 adds dynamic memory). The primary goal of Micron is not safety, but to make a better C, Pascal and Oberon, adding some features which turned out to be very useful in C++, but without the complexity. The compiler now has an x86 and ARMv7 backend with debug support. RV32 support is on the horizon. And there is a C99 transpiler if need be.
However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords.
It is a non problem, like discussion of parentheses or white space in programming languages that require them.
I have to say that when I used Modula-2, editors were very simple and banging away on the shift key or caps lock was a real irritation.
Windows IDE tooling for Modula-2, or using something like XEmacs/Emacs or Brief.
Great Stuff!
If not, well there's another reason to have a Linux VM ready :)
Thanks to your work, that's about to change.
Thank you times a thousand <3
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).
Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically.
In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the 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.
And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.
Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
E.g. a USB driver.
Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.
At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability.
And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.
In comparison, Oberon has... nothing. If you check the source code of Oberon OS for something like USB, a lot of code is either YOLO or a mess of nested blocks.