7 ms·

Oberon 07 compiler – written in JavaScript and translates to JavaScript

75 points by colinprince 10y ago

vidarh 10y ago
The page says it's written in Oberon "with extensions", and compiled to Javascript, not written in javascript. (not a criticism, by the way - to me that makes it more interesting...)
erikpukinskis 10y ago
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.
  - 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...
yazan94 10y ago
Are lesser known languages such as Oberon really commercially used? Or are they more academic in nature?
- eterps 10y ago
  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.
- pjmlp 10y ago
  Yes they are used commercially. CFB Software, an Australian company, exists since 1997 selling Oberon compilers for ARM Cortex-M3, Cortex-M4, Cortex-M7 Microcontrollers and Xilinx FPGA Systems. http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm Systems programming language with GC support, running on tiny device boards.
- donquichotte 10y ago
  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.
Koshkin 10y ago
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.
- pjmlp 10y ago
  That is actually common to all Mesa descendants, not only Oberon.
- nine_k 10y ago
  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.
  - vidarh 10y ago
    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. [1] https://news.ycombinator.com/item?id=9289070 https://news.ycombinator.com/item?id=9289070
tomcam 10y ago
Wonderful! Syntax feels very much like Oberon. But I couldn't find which version of Oberon it extends.
- vidarh 10y ago
  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. [1] https://github.com/vladfolts/oberonjs/wiki/Eberon https://github.com/vladfolts/oberonjs/wiki/Eberon
  - mhd 10y ago
    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.
    - vidarh 10y ago
      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.
    - pjmlp 10y ago
      > 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.

75 points by colinprince 10y ago

The page says it's written in Oberon "with extensions", and compiled to Javascript, not written in javascript. (not a criticism, by the way - to me that makes it more interesting...)

erikpukinskis 10y ago

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

yazan94 10y ago

Are lesser known languages such as Oberon really commercially used? Or are they more academic in nature?

eterps 10y ago
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.
pjmlp 10y ago
Yes they are used commercially. CFB Software, an Australian company, exists since 1997 selling Oberon compilers for ARM Cortex-M3, Cortex-M4, Cortex-M7 Microcontrollers and Xilinx FPGA Systems. http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm Systems programming language with GC support, running on tiny device boards.
donquichotte 10y ago
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.

Koshkin 10y ago

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.

pjmlp 10y ago
That is actually common to all Mesa descendants, not only Oberon.
nine_k 10y ago
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.
- vidarh 10y ago
  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. [1] https://news.ycombinator.com/item?id=9289070 https://news.ycombinator.com/item?id=9289070

tomcam 10y ago

Wonderful! Syntax feels very much like Oberon. But I couldn't find which version of Oberon it extends.

vidarh 10y ago
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. [1] https://github.com/vladfolts/oberonjs/wiki/Eberon https://github.com/vladfolts/oberonjs/wiki/Eberon
- mhd 10y ago
  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.
  - vidarh 10y ago
    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.
  - pjmlp 10y ago
    > 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.