"Oberon is a general-purpose programming language created in 1986 by Professor Niklaus Wirth and the latest member of the Wirthian family of ALGOL-like languages (Euler, Algol-W, Pascal, Modula, and Modula-2). Oberon was the result of a concentrated effort to increase the power of Modula-2, the direct successor of Pascal, and simultaneously to reduce its complexity."
This is one of things I admire about Wirth. Through most of his career, he seems to have removed more from his languages than he added. Oberon is like the end result of a serious of very careful incisions. It's austere, but it's austere for very specific reasons: What he removed, he tended to remove because he either found through extensive experience with the languages that it did not add much, or because implementing it in an obvious, efficient way was tricky.
Famously, he also strictly enforced his simplicity also on the compilers, by insisting that e.g. things like optimizations should "pay for themselves" by speeding up the compilation of the compiler itself more than the extra code in the compiler would slow it down (though it is of course worth keeping in mind that the official compilers were part of a computer science curriculum, not commercial products).
> Famously, he also strictly enforced his simplicity also on the compilers, by insisting that e.g. things like optimizations should "pay for themselves" by speeding up the compilation of the compiler itself more than the extra code in the compiler would slow it down
I thought I remembered a similar approach being recommended on the Conclusions page of the Computer Language Benchmarks Game, and it turns out it's a direct reference to Wirth [1]:
> In order to find the optimal cost/benefit ratio, Wirth used a highly intuitive metric, the origin of which is unknown to me but that may very well be Wirth's own invention. He used the compiler's self-compilation speed as a measure of the compiler's quality. Considering that Wirth's compilers were written in the languages they compiled, and that compilers are substantial and non-trivial pieces of software in their own right, this introduced a highly practical benchmark that directly contested a compiler's complexity against its performance. Under the self compilation speed benchmark, only those optimizations were allowed to be incorporated into a compiler that accelerated it by so much that the intrinsic cost of the new code addition was fully compensated.
Famously, he also strictly enforced his simplicity also
on the compilers, by insisting that e.g. things like
optimizations should "pay for themselves" by speeding up
the compilation of the compiler itself more than the extra
code in the compiler would slow it down.
This seems like a heuristic that breaks down as soon as the work a compiler does is sufficiently different from the work its output is expected to do. For instance, transforming calculations on vectors of doubles into SIMD instructions would likely never pass...
Kind of, you are forgetting the startup that ETHZ sponsored with Component Pascal and the fact that Oberon (the OS) was actively used at ETHZ IT department, not only for teaching. :)
Apparently, it didn't lead to a sustainable business model. (Well, they seem to have made it work for a surprisingly long time.) But eventually the company abandoned the product and made it available for free: http://www.oberon.ch/blackbox.html
Also, I think there is still quite an active community around BlackBox in Russia. Unfortunately, I don't speak Russian and cannot really provide any links to their forums, etc.
That has been the problem with Wirth languages, he has written on an essay that he was kind of naïve to think that people would care for quality and flock to Algol derived languages.
The Russians are quite active in all Oberon derived languages, not only CP.
That's true, but my point is that for the official compiler (as opposed to Component Pascal) the justification for being strict in terms of keeping complexity low was different than it would be for a commercial compiler:
Wirth needed to be able to explain the entirety of the compiler to students more than he needed it to generate the fastest possible code.
(That said, several of his students have written papers on adding various optimisations to the Oberon compilers, with good results)
While I am a big fan of Oberon, and Wirth ideas, I think the best design was the Active Oberon one, but Wirth had not much to do with it.
However Oberon-07 is a very good approach for a systems programming language, with GC, targeted at low end devices, pitty that other than Astrobe, it is largely ignored by the IoT hype.
I've never liked Active Oberon, because it doesn't feel like a Wirthian language anymore. It tries to be simple by adding just one concept, the "object", but it's a huge and complicated concept that conflates data, algorithm, concurrency, and synchronization. It's much more complicated than anything else in the language and it duplicates parts of the record and procedure abstractions.
I think the designers of golang followed a more Wirthian approach with goroutines and channels, because those are orthogonal extensions to the rest of the language, and they each have a single well-defined purpose.
I wasn't aware of the other improvements. Thanks! I agree that interfaces and untraced pointers / resources are good and useful.
I haven't quite decided yet on annotations. I'm assuming you mean things like {ACTIVE} and {EXCLUSIVE}? {EXCLUSIVE} is probably nice to have because you can't forget to release the lock. I'm less convinced of {ACTIVE}.
One of the interesting features of Oberon the language is that its syntax allows for very fast compilation times, to the point that on today's hardware there is little need in storing library modules' code in the form of binary objects. For example, building the Oberon compiler from its sources and the sources of the Oberon standard library (all written in Oberon) only takes a fraction of a second.
AFAICT it was one of design goals, considering the hardware. I remember how a Pascal compileron a PDP-11 would tell me "15 KB used" upon compilation. It seemed to only keep the relevant part of symbol table,plus a small work area, in RAM. Everything else went straight to disk as machine code.
The common workaround for this kind of thing for other languages was to either write to disk in between multiple passes and/or load code for one pass at a time. We still have multiple passes in many compiler toolchains in the form of compiler->assembler->linker, but there were older compilers with ridiculous numbers of passes out of sheer necessity.
E.g. here is a HN discussion about a 63 pass compiler for the IBM 1401 [1]
(There's been a resurgence in interest in multiple passes in the form of "nanopass" architectures, but today that's driven out of a desire to simplify code, whereas before it used to be out of a need to minimize memory use or even fit the code needed in memory)
But, yes, this is one of the drivers in a lot of older languages, but particularly the Wirth-ian ones, for declarations before use, etc. so that the language can be easily parsed and compiled in a single pass. The Wirth compilers typically didn't build an AST either.
CFB Software, an Australian company, exists since 1997 selling Oberon compilers for ARM Cortex-M3, Cortex-M4, Cortex-M7 Microcontrollers and Xilinx FPGA Systems.
Some time ago I applied for a job at a company that makes UAVs with combustion engines. They had Oberon on the "nice to have" list of skills they were expecting from applicants.
Oberon is more academic in nature. In the past some applications built with Oberon/F were commercially used. Oberon was one of the influences of the Go language.
It's not clear - the documentation references both "original Oberon" and Oberon 07. But the differences between the original release and Oberon 07 are very tiny, and the additions his "Eberon" [1] makes are bigger, so I think the extensions probably dominates the changes anyway.
Oberon 07 actually removed features -- like multiple return statements...
The extensions on the other hand seem pretty hefty, and I'd be worried that they change the language's character a bit too much. Some of that seems to be necessary for JavaScript interaction, though. Then again, one probably doesn't pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass.
> Then again, one probably doesn't pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass.
I am passionate about Oberon, collect all Wirth related papers and enjoyed using Native Oberon back in the day, when the OS was made available on the PCs, around 1996 or so.
He is one of my "idols" in history of computing and I even had the opportunity to meet him once, as he gave an Oberon conference at CERN.
However, I have learned many paradigms and languages since those days, to be happy just doing plain Oberon on the job.
Nowadays any JVM or .NET language is more my kind of thing for it, the only thing missing is standard AOT compilation as part of their canonical toolchains, but that is slowly being taken care of.
At least some of his ideas regarding safe OS architectures seem to live on those runtimes, and MSR work.
I read my previous post again and just wanted to make clear that this "morass" was referring specifically to the JavaScript "landscape", not the paradigms in general...
And yeah, I remember Native Oberon, too. In the mid-90s it seemed much more open about what OS was taking over. Win95 just came out, OS/2 was still an alternative (Warp), Linux was making the rounds, and then some oddballs like Oberon or QNX...
Marrying Oberon with the browse feels a bit weird, though. The ETHZ workstations were rather reductionist, and hosting that on a modern browser stack...
(For a double whammy, one could write the backend in Go, the mirror universe Oberon)
Yes, most of Wirths language revisions removes more features than they add.
I agree the extensions seem hefty to some extent, but most of them look like they should change the grammar very little. I wish he'd publish a BNF for the full thing and a diff against the original Oberon 07 BNF, to make it easier to see the full impact, though. I see he's given grammar fragments a couple of places.
In terms of semantics they do clearly deviate quite a bit from the overall philosophy of Oberon (e.g. making MAP a built in type despite the big variety of design tradeoffs people might want), but it still seems quite restrained compared to most modern languages.
"Oberon is a general-purpose programming language created in 1986 by Professor Niklaus Wirth and the latest member of the Wirthian family of ALGOL-like languages (Euler, Algol-W, Pascal, Modula, and Modula-2). Oberon was the result of a concentrated effort to increase the power of Modula-2, the direct successor of Pascal, and simultaneously to reduce its complexity."
https://en.wikipedia.org/wiki/Oberon_(programming_language)