4 ms·

Well, Oberon-2 (designed and published by Hanspeter Mössenböck in 1991) was indeed closer to C++ than its predecessor Oberon 87 and 90, but definitely not a tru

by Rochus 4y ago

Well, Oberon-2 (designed and published by Hanspeter Mössenböck in 1991) was indeed closer to C++ than its predecessor Oberon 87 and 90, but definitely not a true alternative to C++ (because it only supports a fraction of the C++ features). Neither is the optimization done by the available Oberon compilers comparable to what we see in C++ compilers, not even in 1997.

rurban 4y ago
That's why you would use o2c, which can use gcc-13 or clang-14. Though I'm convinced that this ship has sailed, with go replacing oberon
- Rochus 4y ago
  There is even a better alternative; just use the Oberon+ toolchain (compatible with Oberon 87, Oberon-2 and Oberon-07), so you can benefit of a decent IDE with a source-level debugger and a C99 transpiler.
- kristianp 4y ago
  Or use Modula-2, which was recently added to gcc (https://www.phoronix.com/news/Module-2-GCC-Merged https://www.phoronix.com/news/Module-2-GCC-Merged).
  - rurban 4y ago
    When we can use Oberon, there is no need for Modula-2. Oberon is by far simpler and superior. Just enum and records might be missing from the default Oberon.
    - mannschott 4y ago
      Enumerations and subranges (in style of Modula-2 and Pascal) are missing from Oberon, but Records are present subject to type extension in the style of structs in Go. In Oberon(-1), we used (pointers to) procedures in record fields as methods when programming in an object-oriented style. Oberon-2 added methods which dispatch dynamically based on type of receiver. These were "type bound procedures". You'll find this idea echoed in Go as well.
- MarcusE1W 4y ago
  As a bit more comfortable alternative to Oberon I would suggest Modula-3. https://github.com/modula3/cm3 https://github.com/modula3/cm3 It even comes with a GUI library, which even though developed in the 90th Stil, works on x11. I find that quite fascinating :-)
bhaak 4y ago
> (because it only supports a fraction of the C++ features) I'm pretty sure that both Mössenböck and Wirth would consider this a feature, not a bug.
- Rochus 4y ago
  Neither Mössenböck nor Wirth were involved with the posted paper, and neither intended to create a "high-performance alternative to C++". The authors of the paper who made this claim are different people, who apparently didn't know C++ good enough.
  - bhaak 4y ago
    The title of the article is quite clickbaity. Neither is the performance of Oberon-2 discussed nor how it compares to C++. But you are wrong if you think that Oberon-2 wasn't considered a competitor to C++. I'd say 1997 was early enough that it wasn't obvious yet that Java would snatch up such a big part of C++'s market share. Wirth has always been very critical of software bloat and C++ is an abomination in programming language design. They certainly didn't set out to make an alternative to C++ but a good language that was an improvement over Oberon.
    - Rochus 4y ago
      C++ was never a role model, neither for Oberon nor for Oberon-2. Wirth was always opposed to C++ and Mössenböck worked in his group. The official goal for Oberon-2 was "to make object-oriented proramming easier without sacrifiicing the conceptual simplicity of Oberon" (from ETH INF Report 160, 1991). Wirth himself was involved when Apple designed Clascal and Object Pascal, and even though you see a different solution to OO in both Oberon and Oberon-2; the latter introduced the receiver syntax for its type-bound procedures, which you can also find in Go (not surprisingly since Mössenböck was the PhD supervisor of Griesemer).
mpweiher 4y ago
> [Optimization not comparable to C++] Hmm...considering Proebsting's Law[1], which is always shown to be too optimistic despite its pessimism[2][3], the arguments presented by DJ Bernstein[4] and the fact that Frances Allen got all the good ones in 1971 [5], etc. not sure how much this matters outside a few specialised domains. [1] http://proebsting.cs.arizona.edu/law.html http://proebsting.cs.arizona.edu/law.html [2] https://gwern.net/docs/cs/algorithm/2001-scott.pdf https://gwern.net/docs/cs/algorithm/2001-scott.pdf [3] https://zeux.io/2022/01/08/on-proebstings-law/ https://zeux.io/2022/01/08/on-proebstings-law/ [4] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf [5] http://venge.net/graydon/talks/CompilerTalk-2019.pdf http://venge.net/graydon/talks/CompilerTalk-2019.pdf
mhd 4y ago
I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at. And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.
- pjmlp 4y ago
  Which makes sense in 1990's computing world, and I was a big Oberon fan. However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up. Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense. Latest revisions of Active Oberon also have some kind of generics support.

by Rochus 4y ago

rurban 4y ago

That's why you would use o2c, which can use gcc-13 or clang-14. Though I'm convinced that this ship has sailed, with go replacing oberon

Rochus 4y ago
There is even a better alternative; just use the Oberon+ toolchain (compatible with Oberon 87, Oberon-2 and Oberon-07), so you can benefit of a decent IDE with a source-level debugger and a C99 transpiler.
kristianp 4y ago
Or use Modula-2, which was recently added to gcc (https://www.phoronix.com/news/Module-2-GCC-Merged https://www.phoronix.com/news/Module-2-GCC-Merged).
- rurban 4y ago
  When we can use Oberon, there is no need for Modula-2. Oberon is by far simpler and superior. Just enum and records might be missing from the default Oberon.
  - mannschott 4y ago
    Enumerations and subranges (in style of Modula-2 and Pascal) are missing from Oberon, but Records are present subject to type extension in the style of structs in Go. In Oberon(-1), we used (pointers to) procedures in record fields as methods when programming in an object-oriented style. Oberon-2 added methods which dispatch dynamically based on type of receiver. These were "type bound procedures". You'll find this idea echoed in Go as well.
MarcusE1W 4y ago
As a bit more comfortable alternative to Oberon I would suggest Modula-3. https://github.com/modula3/cm3 https://github.com/modula3/cm3 It even comes with a GUI library, which even though developed in the 90th Stil, works on x11. I find that quite fascinating :-)

bhaak 4y ago

> (because it only supports a fraction of the C++ features) I'm pretty sure that both Mössenböck and Wirth would consider this a feature, not a bug.

Rochus 4y ago
Neither Mössenböck nor Wirth were involved with the posted paper, and neither intended to create a "high-performance alternative to C++". The authors of the paper who made this claim are different people, who apparently didn't know C++ good enough.
- bhaak 4y ago
  The title of the article is quite clickbaity. Neither is the performance of Oberon-2 discussed nor how it compares to C++. But you are wrong if you think that Oberon-2 wasn't considered a competitor to C++. I'd say 1997 was early enough that it wasn't obvious yet that Java would snatch up such a big part of C++'s market share. Wirth has always been very critical of software bloat and C++ is an abomination in programming language design. They certainly didn't set out to make an alternative to C++ but a good language that was an improvement over Oberon.
  - Rochus 4y ago
    C++ was never a role model, neither for Oberon nor for Oberon-2. Wirth was always opposed to C++ and Mössenböck worked in his group. The official goal for Oberon-2 was "to make object-oriented proramming easier without sacrifiicing the conceptual simplicity of Oberon" (from ETH INF Report 160, 1991). Wirth himself was involved when Apple designed Clascal and Object Pascal, and even though you see a different solution to OO in both Oberon and Oberon-2; the latter introduced the receiver syntax for its type-bound procedures, which you can also find in Go (not surprisingly since Mössenböck was the PhD supervisor of Griesemer).

mpweiher 4y ago

> [Optimization not comparable to C++] Hmm...considering Proebsting's Law[1], which is always shown to be too optimistic despite its pessimism[2][3], the arguments presented by DJ Bernstein[4] and the fact that Frances Allen got all the good ones in 1971 [5], etc. not sure how much this matters outside a few specialised domains. [1] http://proebsting.cs.arizona.edu/law.html http://proebsting.cs.arizona.edu/law.html [2] https://gwern.net/docs/cs/algorithm/2001-scott.pdf https://gwern.net/docs/cs/algorithm/2001-scott.pdf [3] https://zeux.io/2022/01/08/on-proebstings-law/ https://zeux.io/2022/01/08/on-proebstings-law/ [4] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf [5] http://venge.net/graydon/talks/CompilerTalk-2019.pdf http://venge.net/graydon/talks/CompilerTalk-2019.pdf

mhd 4y ago

I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at. And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.

pjmlp 4y ago
Which makes sense in 1990's computing world, and I was a big Oberon fan. However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up. Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense. Latest revisions of Active Oberon also have some kind of generics support.