6 ms·

Really cool to see Oberon / Modula retro-tech stuff on the front page. Whats somewhat interesting is how structurally similar Oberon is to Go. One could say Go

Really cool to see Oberon / Modula retro-tech stuff on the front page. Whats somewhat interesting is how structurally similar Oberon is to Go. One could say Go is Oberon dragged halfway towards C/Unix conventions (curly braces) with Go channels slapped on. Rob Pike was aware of Wirth's work, as his ACME editor (https://en.wikipedia.org/wiki/Acme_(text_editor) https://en.wikipedia.org/wiki/Acme_(text_editor) ) took inspiration from it. So either way, if there was inspiration for Go form Oberon or if there was not [a case of convergent evolution I guess in that case], it shows the strength of Wirth's thought.

deleted 1y ago
[deleted]
timbit42 1y ago
I would say Go is C dragged halfway towards Oberon. It's essentially the core group that created and used C admitting Wirth's work was better.
- pjmlp 1y ago
  They were already inspired by it for how ACME works, and one of the creators, is a former ETHZ student, with a PhD in Oberon research.
- cyberax 1y ago
  [flagged]
  - vidarh 1y ago
    Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design. Wirth had a very clear philosophy for his language, that he followed relentlessly. If you don't like that philosophy, you won't like Oberon, but there's nothing half-assed about it. With respect some of your points, the lack of support for early returns is one of those philosophical decisions, as is many of the other "missing" features. Many of them were implemented in various versions by students of Wirth. Polymorphism for Oberon was the subject of at two projects at EHTZ in the 90's, including an at the time fairly novel approaches for a runtime extensible vtable approach to polymorphism. As for your #5, to me that's one of the most horific warts I can think of in the languages that use it, but again a question of philosophy, and certainly one aspect of Go I detest. But to go back to Oberon, as a language user, I find Oberon too austere, but as an implementer, the design is beautiful in its simplicitly and how clean it is, and I wish more language implementers paid attention to Wirths work as a starting point, and paid attention to his systematic approach to language design - even if I'd prefer a result that isn't as minimalist.
    - wirrbel 1y ago
      thank you for a well written reply, that I did not have the patience to write.
    - cyberax 1y ago
      [flagged]
      - vidarh 1y ago
        > And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity. This is why I called this view grossly ignorant. No, it's not easy when you have the added constraint of producing a language that is practical enough to write an OS and applications with. Have you tried? How many such languages have you designed? Can we see the grammar? Producing a small language that is Turing complete is easy, yes. And it is also entirely uninteresting if that is all you do. Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it. > Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go. Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic. > Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH. Entirely missing the point, which is that implementations existed and that including them in the official version of the language was a conscious design choice, rather than any indication it was "half-assed". > ??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables. Yes. And? I wrote what I wrote, and what I wrote is true. Nothing I wrote talked about "the standard Oberon-2". The entire point of the Oberon work at ETHZ was that it was a teaching language, and a lot of the projects involved experimental changes to the language and compiler. To your mention of vtables, I was specifically thinking of Michael Franz' paper on Protocol Extension, that introduced a two-layer set of indirections to allow runtime extension with interfaces. Again, the point is that not including these in the standard version of Oberon was a conscious choice. A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people. Personally, I loved Franz' work on Protocol Extension to the point that my (buggy, temporarily abandoned, unfinished) prototype Ruby compiler uses his propagation method for vtable updates to allow for vtable-based dynamic method redefinition, and think it'd have been a great addition to standard Oberon, so it's not that I disagree that it could have used a more flexible way of doing OO. But I do respect Wirth's extremely focused design, even where I disagree with it. So I stand by what I wrote: To call it half-assed is grossly ignorant. > Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports. I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
  - lelanthran 1y ago
    God's multiple returns is, from someone whose primary language is Go for now, crap. See https://herecomesthemoon.net/2025/03/multiple-return-values-in-go/ https://herecomesthemoon.net/2025/03/multiple-return-values-... which goes into detail.
    - cyberax 1y ago
      You don't get it. Oberon doesn't allow multiple _returns_, not merely multiple return _values_. As in, you can't write "return val;" in the middle of a function. FWIW, I don't like explicit error handling in Go, but it's undeniably minimalistic and practical.
      - vidarh 1y ago
        Oberon-07 doesn't allow multiple returns, though Wirth tended to favour single return. In Wirth's introduction of Oberon-07, he specifically gave an example of an Oberon procedure with multiple returns, and the corresponding Oberon-07 version, where a single return at the very end is enforced and the only syntactically valid way of including a return. A decision I disagree with, but again a very explicitly motivated design choice - Oberon-07 in particular reflected years of looking largely at what Oberon could do without to achieve something that cut down complexity even further without being too limiting. It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.
        cyberax 1y ago
        > A decision I disagree with, but again a very explicitly motivated design choice As I said, he cared more about ideology. Early returns significantly improve imperative code. They are not necessary in fully functional languages, where you can easily juggle with blocks of logic, but Oberon is not such a language. > It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire. It was basically: "my way or you're expelled because I'm the emeritus professor here".
        1y ago
Rochus 1y ago
> how structurally similar Oberon is to Go There are minor similarities, mostly the fact that it is garbage collected, and also the receiver syntax Go inherited from Oberon-2 (i.e. proposed by Mössenböck, not by Wirth). Go has a completely different focus and is essentially a further development of Newsqueak, which was mostly influenced by Pascal and C.
cenamus 1y ago
I mean the whole design of Plan 9 is basically modeled after Oberon, and of course Go came from basically the same group
kragen 1y ago
While of course Pike found inspiration in Wirth, Golang wasn't just Pike; it was Pike, Thompson, and Griesemer. Wirth was Griesemer's doctoral thesis advisor, and the thesis itself was on a parallel version of Oberon he called Oberon-V: https://eulercenter.ru/pdf/eth10277.pdf https://eulercenter.ru/pdf/eth10277.pdf https://www.research-collection.ethz.ch/handle/20.500.11850/141363 https://www.research-collection.ethz.ch/handle/20.500.11850/... I have to say, though, that I think Golang is a lot more similar to Newsqueak (which Pike did before working with Griesemer) than to Oberon.

deleted 1y ago

[deleted]

timbit42 1y ago

I would say Go is C dragged halfway towards Oberon. It's essentially the core group that created and used C admitting Wirth's work was better.

pjmlp 1y ago
They were already inspired by it for how ACME works, and one of the creators, is a former ETHZ student, with a PhD in Oberon research.
cyberax 1y ago
[flagged]
- vidarh 1y ago
  Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design. Wirth had a very clear philosophy for his language, that he followed relentlessly. If you don't like that philosophy, you won't like Oberon, but there's nothing half-assed about it. With respect some of your points, the lack of support for early returns is one of those philosophical decisions, as is many of the other "missing" features. Many of them were implemented in various versions by students of Wirth. Polymorphism for Oberon was the subject of at two projects at EHTZ in the 90's, including an at the time fairly novel approaches for a runtime extensible vtable approach to polymorphism. As for your #5, to me that's one of the most horific warts I can think of in the languages that use it, but again a question of philosophy, and certainly one aspect of Go I detest. But to go back to Oberon, as a language user, I find Oberon too austere, but as an implementer, the design is beautiful in its simplicitly and how clean it is, and I wish more language implementers paid attention to Wirths work as a starting point, and paid attention to his systematic approach to language design - even if I'd prefer a result that isn't as minimalist.
  - wirrbel 1y ago
    thank you for a well written reply, that I did not have the patience to write.
  - cyberax 1y ago
    [flagged]
    - vidarh 1y ago
      > And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity. This is why I called this view grossly ignorant. No, it's not easy when you have the added constraint of producing a language that is practical enough to write an OS and applications with. Have you tried? How many such languages have you designed? Can we see the grammar? Producing a small language that is Turing complete is easy, yes. And it is also entirely uninteresting if that is all you do. Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it. > Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go. Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic. > Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH. Entirely missing the point, which is that implementations existed and that including them in the official version of the language was a conscious design choice, rather than any indication it was "half-assed". > ??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables. Yes. And? I wrote what I wrote, and what I wrote is true. Nothing I wrote talked about "the standard Oberon-2". The entire point of the Oberon work at ETHZ was that it was a teaching language, and a lot of the projects involved experimental changes to the language and compiler. To your mention of vtables, I was specifically thinking of Michael Franz' paper on Protocol Extension, that introduced a two-layer set of indirections to allow runtime extension with interfaces. Again, the point is that not including these in the standard version of Oberon was a conscious choice. A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people. Personally, I loved Franz' work on Protocol Extension to the point that my (buggy, temporarily abandoned, unfinished) prototype Ruby compiler uses his propagation method for vtable updates to allow for vtable-based dynamic method redefinition, and think it'd have been a great addition to standard Oberon, so it's not that I disagree that it could have used a more flexible way of doing OO. But I do respect Wirth's extremely focused design, even where I disagree with it. So I stand by what I wrote: To call it half-assed is grossly ignorant. > Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports. I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
- lelanthran 1y ago
  God's multiple returns is, from someone whose primary language is Go for now, crap. See https://herecomesthemoon.net/2025/03/multiple-return-values-in-go/ https://herecomesthemoon.net/2025/03/multiple-return-values-... which goes into detail.
  - cyberax 1y ago
    You don't get it. Oberon doesn't allow multiple _returns_, not merely multiple return _values_. As in, you can't write "return val;" in the middle of a function. FWIW, I don't like explicit error handling in Go, but it's undeniably minimalistic and practical.
    - vidarh 1y ago
      Oberon-07 doesn't allow multiple returns, though Wirth tended to favour single return. In Wirth's introduction of Oberon-07, he specifically gave an example of an Oberon procedure with multiple returns, and the corresponding Oberon-07 version, where a single return at the very end is enforced and the only syntactically valid way of including a return. A decision I disagree with, but again a very explicitly motivated design choice - Oberon-07 in particular reflected years of looking largely at what Oberon could do without to achieve something that cut down complexity even further without being too limiting. It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.
      - cyberax 1y ago
        > A decision I disagree with, but again a very explicitly motivated design choice As I said, he cared more about ideology. Early returns significantly improve imperative code. They are not necessary in fully functional languages, where you can easily juggle with blocks of logic, but Oberon is not such a language. > It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire. It was basically: "my way or you're expelled because I'm the emeritus professor here".
        1y ago

Rochus 1y ago

> how structurally similar Oberon is to Go There are minor similarities, mostly the fact that it is garbage collected, and also the receiver syntax Go inherited from Oberon-2 (i.e. proposed by Mössenböck, not by Wirth). Go has a completely different focus and is essentially a further development of Newsqueak, which was mostly influenced by Pascal and C.

cenamus 1y ago

I mean the whole design of Plan 9 is basically modeled after Oberon, and of course Go came from basically the same group

kragen 1y ago

While of course Pike found inspiration in Wirth, Golang wasn't just Pike; it was Pike, Thompson, and Griesemer. Wirth was Griesemer's doctoral thesis advisor, and the thesis itself was on a parallel version of Oberon he called Oberon-V: https://eulercenter.ru/pdf/eth10277.pdf https://eulercenter.ru/pdf/eth10277.pdf https://www.research-collection.ethz.ch/handle/20.500.11850/141363 https://www.research-collection.ethz.ch/handle/20.500.11850/... I have to say, though, that I think Golang is a lot more similar to Newsqueak (which Pike did before working with Griesemer) than to Oberon.