4 ms·

For anyone who doesn't know what Oberon is: "Oberon is a general-purpose programming language created in 1986 by Professor Niklaus Wirth and the latest member

For anyone who doesn't know what Oberon is: "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) https://en.wikipedia.org/wiki/Oberon_(programming_language)

vidarh 10y ago
> 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).
- pjmlp 10y ago
  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. :)
  - vidarh 10y ago
    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)
    - pjmlp 10y ago
      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_don_t_know 10y ago
        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.
        pjmlp 10y ago
        Actually it adds more than just that and that is not really what I find more interesting on it. Rather the support for interfaces, annotations and most importantly untraced references. If you read the papers related to Oberon design, specially EthOS, not having support for untraced references was considered a pain point. It is also something that Cedar, Modula-2+ and Modula-3 also supported. As for the "object" and the duplication between records and objects, I agree with you.
        i_don_t_know 10y ago
        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}.
  - i_don_t_know 10y ago
    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 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.
    - pjmlp 10y ago
      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. http://oberoncore.ru/ http://oberoncore.ru/ http://www.inr.ac.ru/~blackbox/ http://www.inr.ac.ru/~blackbox/ http://www.inr.ac.ru/~info21/ http://www.inr.ac.ru/~info21/
- stirner 10y ago
  > 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. [1] https://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html#ultimate-benchmark https://benchmarksgame.alioth.debian.org/dont-jump-to-conclu...
  - igouy 10y ago
    It's from the "Oberon - The Overlooked Jewel" chapter by Michael Franz, in The School of Niklaus Wirth, "The Art of Simplicity". http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7173&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90....
- al2o3cr 10y ago
  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...

vidarh 10y ago

> 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).

pjmlp 10y ago
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. :)
- vidarh 10y ago
  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)
  - pjmlp 10y ago
    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_don_t_know 10y ago
      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.
      - pjmlp 10y ago
        Actually it adds more than just that and that is not really what I find more interesting on it. Rather the support for interfaces, annotations and most importantly untraced references. If you read the papers related to Oberon design, specially EthOS, not having support for untraced references was considered a pain point. It is also something that Cedar, Modula-2+ and Modula-3 also supported. As for the "object" and the duplication between records and objects, I agree with you.
        i_don_t_know 10y ago
        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}.
- i_don_t_know 10y ago
  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 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.
  - pjmlp 10y ago
    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. http://oberoncore.ru/ http://oberoncore.ru/ http://www.inr.ac.ru/~blackbox/ http://www.inr.ac.ru/~blackbox/ http://www.inr.ac.ru/~info21/ http://www.inr.ac.ru/~info21/
stirner 10y ago
> 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. [1] https://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html#ultimate-benchmark https://benchmarksgame.alioth.debian.org/dont-jump-to-conclu...
- igouy 10y ago
  It's from the "Oberon - The Overlooked Jewel" chapter by Michael Franz, in The School of Niklaus Wirth, "The Art of Simplicity". http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7173&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90....
al2o3cr 10y ago
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...