6 ms·

> The Go programming language is not only partly inspired by Wirth's work There are very little similarities between Go and Wirth's languages. R. Griesemer's d

by Rochus 3y ago

> The Go programming language is not only partly inspired by Wirth's work There are very little similarities between Go and Wirth's languages. R. Griesemer's doctoral supervisor was H. Mössenböck, not N. Wirth.

rob74 3y ago
You don't have to take my word for it, here's a graph from the Go Programming Language book: https://www.oreilly.com/api/v2/epubs/9780134190570/files/graphics/influences.png https://www.oreilly.com/api/v2/epubs/9780134190570/files/gra... The most visible Pascal-family influence is the variable declaration syntax ("i int" instead of "int i" as in C et al).
- Rochus 3y ago
  Unfortunately, this graph is at least misleading, if not wrong. The middle path is overly prominent; the detour to Object Oberon (probably so that Griesemer's name is represented) is amusing. Actually there should be a direct line from Newsqueak to Go. Aleph's brief intermezzo is mostly historically relevant for Go, not technically. The path from C should actually point primarily to Newsqueak (in addition to Pascal). Technically, there would be a very thick arrow from Newsqueak to Go, a slightly less thick from C to Go, and a very thin one from Oberon-2 and a few other languages. But as a highly simplified representation of the languages and people directly and indirectly involved and the chronological sequence, the graph is ok.
  - kragen 3y ago
    it's true that golang is basically newsqueak with structural interface types, but newsqueak is pretty obviously strongly pascal-influenced. i agree that newsqueak shows significant c influence, but in most of the ways that c and pascal differ, it follows pascal. and it seems unavoidable that griesemer spending his grad school at wirth's school hacking on wirth's language oberon would have influenced the taste he applied to golang
    - Rochus 3y ago
      In case you're interested I'm looking for feedback for my Oberon concurrency proposal: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md https://github.com/oberon-lang/oberon-lang.github.io/blob/ma...
      - kragen 3y ago
        i'll take a look! but i don't know much about oberon, though i have the book
        Rochus 3y ago
        Great, thanks! There are books online for free, e.g. https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf and https://ssw.jku.at/Research/Books/Oberon2.pdf https://ssw.jku.at/Research/Books/Oberon2.pdf Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/ https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-condition-variables-using-Go-channels-only/answer/Rochus-Keller https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity. Feel free to comment here or e.g. in https://news.ycombinator.com/item?id=38903351 https://news.ycombinator.com/item?id=38903351 or in https://github.com/rochus-keller/Oberon/discussions/45 https://github.com/rochus-keller/Oberon/discussions/45.
        kragen 3y ago
        sorry for the delay i don't know that much about concurrency in general, so take this with a grain of salt i feel like monitors are potentially an improvement over bare locks, but they tend to perform poorly in manycore settings and are still vulnerable to deadlock, perhaps more so due to their implicit nature. (i see that you point this out with respect to java, and also that it doesn't really have monitors.) fundamentally, blocking synchronization of any kind is incompatible with modularity you misspelled brinch (rip) there are lots of versions of actors, and the most influential one effectively didn't have any concurrency at all, so it's important to disambiguate in the text that you're talking about the one in agha's 01985 dissertation, which is also very influential. also your footnote says it's from "1986"; is that a different document by agha with the same title? objects with their own threads (like concurrent actors or like processes in csp or erlang) are not the same thing as monitors, contrary to your assertion in the 'concurrency in oberon' section. there is a well-known duality between message passing between threads and control passing between monitors, but the mechanisms have quite different ergonomics and common failure modes it's surprising that in a discussion that surveys original-modula, modula-2, csp, erlang, active oberon, c, c++, concurrent pascal, object pascal, superpascal, joyce, newsqueak, old squeak, alef, limbo, golang, java, and ada, you didn't mention javascript at all. in browsers and node, javascript's concurrency model was originally that of original oberon — each event handler runs to completion in succession — which strongly suggests that the concurrency facilities it has added more recently might be worth a look. those are python-like async/await, sometimes caricatured as 'colored functions', and web workers. also it might be worthwhile to at least mention the π-calculus my uninformed viewpoint is that js, erlang, haskell with its stm, and (non-async!) rust are the languages with the most promising approaches to the concurrency problem. all four of them work hard to be safe (unlike the entire rest of the js language), though i think their concurrency safety guarantees are all to some degree fragile. except maybe haskell, which i haven't tried your reference [31] https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... doesn't purport to show that no single concurrency construct is adequate, as you claim, or even that communication channels are inadequate; rather, it argues that the implementation in golang of that concept is inadequate, because golang implements them inefficiently, because it can't garbage-collect processes, because there are some design errors, and that because golang also offers other concurrency constructs (as you propose for oberon+), it's hard to avoid concurrency bugs. though certainly not conclusive evidence, this runs strongly against the conclusion you are using it to argue for also your bibliography incorrectly abbreviates 'per brinch hansen' as 'hansen, p. b.' rather than 'brinch hansen, p.' a few times i hope this is helpful, and i'm glad to see you're exploring how to solve this problem! feel free to copy or excerpt my comments elsewhere if you think it would be useful
  - rob74 3y ago
    Here's the accompanying text from The Go Programming Language for that line in the graph: > One major stream of influence comes from languages by Niklaus Wirth, beginning with Pascal. Modula-2 inspired the package concept, Oberon eliminated the distinction between module interface files and module implementation files. Oberon-2 influenced the syntax for packages, imports, and declarations, and Object Oberon provided the syntax for method declarations. So mostly packages and syntax - not the most exciting stuff, but the package concept contributes to enabling Go's compilation speed, so it shouldn't be disregarded. Ok, you can still argue that many or most of the C/Pascal-family influences were already present in Newsqueak (I'm only familiar with Pascal, C and Go, so I can't judge that), but I think it's understandable that they wanted to have the language the book is about at the focal point of the graph, and not one of its less successful and more obscure ancestors.
    - Rochus 3y ago
      Thanks, I have the book. The major influence had Pascal on Newsqueak. I don't see any specific similarity between Modula-2 and Go. There are other languages which are at least as close or even closer. The last sentence is even wrong. Object Oberon is a completely different language in terms of OO. Go uses the receiver syntax of Oberon-2, which is a completely different concept than in Object Oberon.
wirrbel 3y ago
Look at this document by Mössenböck https://www.astrobe.com/CPIde/CP-Lang.pdf https://www.astrobe.com/CPIde/CP-Lang.pdf on Component Pascal, which is essentally a modified Oberon 2 (Wirth language) > Except for some minor points, Component Pascal is a superset of Oberon-2. Compared to Oberon-2, it provides several clarifications and improvements. The similarities are hard to overlook, replace curly braces by BEGIN / END Pascal style syntax and you are more than halfway there. Of course Go has added features that were not present in Oberon / Component pascal, the implicit interfaces come to my mind, Go channels also. But inherently its a Wirthian language. Also Griesemer is not the only Oberon connection of Go. Rob Pike has studied the Oberon system when developing the ACME editor for Plan 9 (Source: https://wiki.c2.com/?OberonOperatingSystem https://wiki.c2.com/?OberonOperatingSystem). I honestly think Oberon didn't get named, because at the time of launching Go, the Pascal / C conflict was a lot more present in the memories of people so there was nothing to gain from pointing out these roots. It is not uncommon for programming languages to not talk about their roots during launch due to politics (Java for example traces its object-oriented roots to https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk a typed Smalltalk descendant, but was advertised as a cleaned-up C++).
- Rochus 3y ago
  I don't see what this all has to do with Component Pascal (the language report is not by Mössenböck, but by Pfister et al., btw.). You should instead have a look at the Newsqueak publications. There are more similarities of Go with Algol than with Oberon. Newsqueak reused a few features of Pascal, some of which are still present in Go. The Acme editor has similarities with the original, text based Oberon system user interface, which unfortunately shares the name with the language, but is not the same thing. The user interface of the Oberon system again looks like a stripped down version of the Cedar environment developed at PARC (where Wirth had his sabbatical). The object model of Java directly traces back to Simula 67, not to Smalltalk or its descendants (see e.g. https://www.youtube.com/watch?v=ccRtIdlTqlU&t=2444 https://www.youtube.com/watch?v=ccRtIdlTqlU&t=2444).
pjmlp 3y ago
R. Griesemer's thesis was based on creating a Oberon dialect.
- Rochus 3y ago
  He implemented Oberon-V for the Cray YMP vector computer.
  - pjmlp 3y ago
    From where I am standing, Oberon-V is a Oberon dialect.
    - Rochus 3y ago
      I assume that's why it is also called "Oberon" ;-) But this fact doesn't make Go more similar to Oberon.
      - pjmlp 3y ago
        It makes from the sense Robert Griesemer decided to influence Go's design based on his ETHZ experience while working in Oberon ecosystem.
        Rochus 3y ago
        Maybe he contributed the receiver syntax to Go, we can only assume. But anyway it's not that much Oberon in Go, much less than pop culture assumes. By the end of the day, the two languages mostly share the concept of static typing (with Go even stricter than Oberon), modularity and garbage collection; otherwise they have a different focus (concurrency in Go, type extension and minimalism in Oberon).
        pjmlp 3y ago
        Only if consider the Oberon from 1987 and nothing else in the Oberon ecosystem. Nothing else in the ETHZ group doing Oberon related research counts from that point of view, if it didn't had the touch of Niklaus Wirth himself adding lines to the compiler.

by Rochus 3y ago

rob74 3y ago

You don't have to take my word for it, here's a graph from the Go Programming Language book: https://www.oreilly.com/api/v2/epubs/9780134190570/files/graphics/influences.png https://www.oreilly.com/api/v2/epubs/9780134190570/files/gra... The most visible Pascal-family influence is the variable declaration syntax ("i int" instead of "int i" as in C et al).

Rochus 3y ago
Unfortunately, this graph is at least misleading, if not wrong. The middle path is overly prominent; the detour to Object Oberon (probably so that Griesemer's name is represented) is amusing. Actually there should be a direct line from Newsqueak to Go. Aleph's brief intermezzo is mostly historically relevant for Go, not technically. The path from C should actually point primarily to Newsqueak (in addition to Pascal). Technically, there would be a very thick arrow from Newsqueak to Go, a slightly less thick from C to Go, and a very thin one from Oberon-2 and a few other languages. But as a highly simplified representation of the languages and people directly and indirectly involved and the chronological sequence, the graph is ok.
- kragen 3y ago
  it's true that golang is basically newsqueak with structural interface types, but newsqueak is pretty obviously strongly pascal-influenced. i agree that newsqueak shows significant c influence, but in most of the ways that c and pascal differ, it follows pascal. and it seems unavoidable that griesemer spending his grad school at wirth's school hacking on wirth's language oberon would have influenced the taste he applied to golang
  - Rochus 3y ago
    In case you're interested I'm looking for feedback for my Oberon concurrency proposal: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md https://github.com/oberon-lang/oberon-lang.github.io/blob/ma...
    - kragen 3y ago
      i'll take a look! but i don't know much about oberon, though i have the book
      - Rochus 3y ago
        Great, thanks! There are books online for free, e.g. https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf and https://ssw.jku.at/Research/Books/Oberon2.pdf https://ssw.jku.at/Research/Books/Oberon2.pdf Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/ https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-condition-variables-using-Go-channels-only/answer/Rochus-Keller https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity. Feel free to comment here or e.g. in https://news.ycombinator.com/item?id=38903351 https://news.ycombinator.com/item?id=38903351 or in https://github.com/rochus-keller/Oberon/discussions/45 https://github.com/rochus-keller/Oberon/discussions/45.
        kragen 3y ago
        sorry for the delay i don't know that much about concurrency in general, so take this with a grain of salt i feel like monitors are potentially an improvement over bare locks, but they tend to perform poorly in manycore settings and are still vulnerable to deadlock, perhaps more so due to their implicit nature. (i see that you point this out with respect to java, and also that it doesn't really have monitors.) fundamentally, blocking synchronization of any kind is incompatible with modularity you misspelled brinch (rip) there are lots of versions of actors, and the most influential one effectively didn't have any concurrency at all, so it's important to disambiguate in the text that you're talking about the one in agha's 01985 dissertation, which is also very influential. also your footnote says it's from "1986"; is that a different document by agha with the same title? objects with their own threads (like concurrent actors or like processes in csp or erlang) are not the same thing as monitors, contrary to your assertion in the 'concurrency in oberon' section. there is a well-known duality between message passing between threads and control passing between monitors, but the mechanisms have quite different ergonomics and common failure modes it's surprising that in a discussion that surveys original-modula, modula-2, csp, erlang, active oberon, c, c++, concurrent pascal, object pascal, superpascal, joyce, newsqueak, old squeak, alef, limbo, golang, java, and ada, you didn't mention javascript at all. in browsers and node, javascript's concurrency model was originally that of original oberon — each event handler runs to completion in succession — which strongly suggests that the concurrency facilities it has added more recently might be worth a look. those are python-like async/await, sometimes caricatured as 'colored functions', and web workers. also it might be worthwhile to at least mention the π-calculus my uninformed viewpoint is that js, erlang, haskell with its stm, and (non-async!) rust are the languages with the most promising approaches to the concurrency problem. all four of them work hard to be safe (unlike the entire rest of the js language), though i think their concurrency safety guarantees are all to some degree fragile. except maybe haskell, which i haven't tried your reference [31] https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... doesn't purport to show that no single concurrency construct is adequate, as you claim, or even that communication channels are inadequate; rather, it argues that the implementation in golang of that concept is inadequate, because golang implements them inefficiently, because it can't garbage-collect processes, because there are some design errors, and that because golang also offers other concurrency constructs (as you propose for oberon+), it's hard to avoid concurrency bugs. though certainly not conclusive evidence, this runs strongly against the conclusion you are using it to argue for also your bibliography incorrectly abbreviates 'per brinch hansen' as 'hansen, p. b.' rather than 'brinch hansen, p.' a few times i hope this is helpful, and i'm glad to see you're exploring how to solve this problem! feel free to copy or excerpt my comments elsewhere if you think it would be useful
- rob74 3y ago
  Here's the accompanying text from The Go Programming Language for that line in the graph: > One major stream of influence comes from languages by Niklaus Wirth, beginning with Pascal. Modula-2 inspired the package concept, Oberon eliminated the distinction between module interface files and module implementation files. Oberon-2 influenced the syntax for packages, imports, and declarations, and Object Oberon provided the syntax for method declarations. So mostly packages and syntax - not the most exciting stuff, but the package concept contributes to enabling Go's compilation speed, so it shouldn't be disregarded. Ok, you can still argue that many or most of the C/Pascal-family influences were already present in Newsqueak (I'm only familiar with Pascal, C and Go, so I can't judge that), but I think it's understandable that they wanted to have the language the book is about at the focal point of the graph, and not one of its less successful and more obscure ancestors.
  - Rochus 3y ago
    Thanks, I have the book. The major influence had Pascal on Newsqueak. I don't see any specific similarity between Modula-2 and Go. There are other languages which are at least as close or even closer. The last sentence is even wrong. Object Oberon is a completely different language in terms of OO. Go uses the receiver syntax of Oberon-2, which is a completely different concept than in Object Oberon.

wirrbel 3y ago

Look at this document by Mössenböck https://www.astrobe.com/CPIde/CP-Lang.pdf https://www.astrobe.com/CPIde/CP-Lang.pdf on Component Pascal, which is essentally a modified Oberon 2 (Wirth language) > Except for some minor points, Component Pascal is a superset of Oberon-2. Compared to Oberon-2, it provides several clarifications and improvements. The similarities are hard to overlook, replace curly braces by BEGIN / END Pascal style syntax and you are more than halfway there. Of course Go has added features that were not present in Oberon / Component pascal, the implicit interfaces come to my mind, Go channels also. But inherently its a Wirthian language. Also Griesemer is not the only Oberon connection of Go. Rob Pike has studied the Oberon system when developing the ACME editor for Plan 9 (Source: https://wiki.c2.com/?OberonOperatingSystem https://wiki.c2.com/?OberonOperatingSystem). I honestly think Oberon didn't get named, because at the time of launching Go, the Pascal / C conflict was a lot more present in the memories of people so there was nothing to gain from pointing out these roots. It is not uncommon for programming languages to not talk about their roots during launch due to politics (Java for example traces its object-oriented roots to https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk a typed Smalltalk descendant, but was advertised as a cleaned-up C++).

Rochus 3y ago
I don't see what this all has to do with Component Pascal (the language report is not by Mössenböck, but by Pfister et al., btw.). You should instead have a look at the Newsqueak publications. There are more similarities of Go with Algol than with Oberon. Newsqueak reused a few features of Pascal, some of which are still present in Go. The Acme editor has similarities with the original, text based Oberon system user interface, which unfortunately shares the name with the language, but is not the same thing. The user interface of the Oberon system again looks like a stripped down version of the Cedar environment developed at PARC (where Wirth had his sabbatical). The object model of Java directly traces back to Simula 67, not to Smalltalk or its descendants (see e.g. https://www.youtube.com/watch?v=ccRtIdlTqlU&t=2444 https://www.youtube.com/watch?v=ccRtIdlTqlU&t=2444).

pjmlp 3y ago

R. Griesemer's thesis was based on creating a Oberon dialect.

Rochus 3y ago
He implemented Oberon-V for the Cray YMP vector computer.
- pjmlp 3y ago
  From where I am standing, Oberon-V is a Oberon dialect.
  - Rochus 3y ago
    I assume that's why it is also called "Oberon" ;-) But this fact doesn't make Go more similar to Oberon.
    - pjmlp 3y ago
      It makes from the sense Robert Griesemer decided to influence Go's design based on his ETHZ experience while working in Oberon ecosystem.
      - Rochus 3y ago
        Maybe he contributed the receiver syntax to Go, we can only assume. But anyway it's not that much Oberon in Go, much less than pop culture assumes. By the end of the day, the two languages mostly share the concept of static typing (with Go even stricter than Oberon), modularity and garbage collection; otherwise they have a different focus (concurrency in Go, type extension and minimalism in Oberon).
        pjmlp 3y ago
        Only if consider the Oberon from 1987 and nothing else in the Oberon ecosystem. Nothing else in the ETHZ group doing Oberon related research counts from that point of view, if it didn't had the touch of Niklaus Wirth himself adding lines to the compiler.