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.
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.
IF disaster THEN abort;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.
If not, well there's another reason to have a Linux VM ready :)
Great Stuff!
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.
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.