4 ms·

I don't think you read the Interfaces section properly. Rob is not claiming go invented interfaces. If you want to level such a charge that he is rewriting his

I don't think you read the Interfaces section properly. Rob is not claiming go invented interfaces. If you want to level such a charge that he is rewriting history, you need to take special care yourself in representing his views accurately.

dwattttt 3y ago
I came away with the impression they were saying they'd invented interfaces, so I reread it: > That idea was exciting for us, and the possibility that this could become a foundational programming construct was intoxicating. Talking about interfaces as an idea that could become a foundational programming construct definitely sounds like they're saying they invented it.
- twic 3y ago
  In his defence, their interfaces do work somewhat differently to Java's, because they don't need to be explicitly implemented. I don't know if that matters enough to make them a novel invention, though.
  - deleted 3y ago
    [deleted]
  - za3faran 3y ago
    Java's interfaces are nominal. What you're describing is called structural interfaces, and they exist in other languages like Scala.
  - shakow 3y ago
    > I don't know if that matters enough to make them a novel invention, though. That's called structural typing, which is at least as old as OCaml, i.e. 25+ y.o.
  - moomin 3y ago
    Yes, they work the same way as Modula-3's did in 1988. Still not exactly innovation.
- PH95VuimJjqBqy 3y ago
  go's version of interfaces is fairly unique, if you read that as them inventing interfaces you misread. If you read it as them having a unique twist on interfaces they felt was powerful, then you read it correctly. It never even occurred to me that someone would suggest they're claiming to have invented interfaces, mostly because obviously they didn't.
  - dwattttt 3y ago
    I was careful to try read what was said; the language might be a bit loose because it's a transcript of a live talk. That said, the example they gave, and their motivating problem of the qsort API in C don't show anything about using nominal interfaces, and instead look like a normal use of interfaces, combined with language about being wowed of how powerful they could be.
    - PH95VuimJjqBqy 3y ago
      The text is recreated below: > It's clear that interfaces are, with concurrency, a distinguishing idea in Go. They are Go's answer to objected-oriented design, in the original, behavior-focused style, despite a continuing push by newcomers to make structs carry that load. > Making interfaces dynamic, with no need to announce ahead of time which types implement them, bothered some early critics, and still irritates a few, but it's important to the style of programming that Go fostered. Much of the standard library is built upon their foundation, and broader subjects such as testing and managing dependencies rely heavily on their generous, "all are welcome" nature. > I feel that interfaces are one of the best-designed things in Go. > Other than a few early conversations about whether data should be included in their definition, they arrived fully formed on literally the first day of discussions. > And there is a story to tell there. > On that famous first day in Robert's and my office, we asked the question of what to do about polymorphism. Ken and I knew from C that qsort could serve as a difficult test case, so the three of us started to talk about how our embryonic language could implement a type-safe sort routine. > Robert and I came up with the same idea pretty much simultaneously: using methods on types to provide the operations that sort needed. That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away. > That's something that is not often not acknowledged: Go's sort is implemented as a function that operates on an interface. This is not the style of object-oriented programming most people were familiar with, but it's a very powerful idea. > That idea was exciting for us, and the possibility that this could become a foundational > programming construct was intoxicating. When Russ joined, he soon pointed out how I/O would fit beautifully into this idea, and the library took place rapidly, based in large part on the three famous interfaces: empty, Writer, and Reader, holding an average of two thirds of a method each. Those tiny methods are idiomatic to Go, and ubiquitous. > _THE WAY INTERFACES WORKED became not only a distinguishing feature of Go, they became the way we thought about libraries, and generality, and composition. It was heady stuff. emphasis at the end there is mine. how the hell _anyone_ reads that and comes away with the idea that they're claiming they invented the idea of interfaces is beyond me. my only guess here is that many people are not familiar with the sort problem they're describing. very famously, C++'s sort is more performant than C's sort because C uses a void pointer and C++ uses templates. The extra type information allows C++ to optimize the sort in a way that C cannot, so while C is generally more performant than C++ in a lot of ways, this is one particular area where C++ shines. So it's no surprise that Rob Pike, et al, paid close attention to sort as something to improve over C and the way to do that is having more type information available (C++ very clearly has shown this).
throwawaymaths 3y ago
It sounded like it to me. I kept thinking didn't java have interfaces to prevent multiple inheritance? All go did was replace all inheritance with interfaces
- moomin 3y ago
  Which I’m pretty sure CLU did first (honestly, I’m pretty sure nearly every good idea was in CLU first).

dwattttt 3y ago

I came away with the impression they were saying they'd invented interfaces, so I reread it: > That idea was exciting for us, and the possibility that this could become a foundational programming construct was intoxicating. Talking about interfaces as an idea that could become a foundational programming construct definitely sounds like they're saying they invented it.

twic 3y ago
In his defence, their interfaces do work somewhat differently to Java's, because they don't need to be explicitly implemented. I don't know if that matters enough to make them a novel invention, though.
- deleted 3y ago
  [deleted]
- za3faran 3y ago
  Java's interfaces are nominal. What you're describing is called structural interfaces, and they exist in other languages like Scala.
- shakow 3y ago
  > I don't know if that matters enough to make them a novel invention, though. That's called structural typing, which is at least as old as OCaml, i.e. 25+ y.o.
- moomin 3y ago
  Yes, they work the same way as Modula-3's did in 1988. Still not exactly innovation.
PH95VuimJjqBqy 3y ago
go's version of interfaces is fairly unique, if you read that as them inventing interfaces you misread. If you read it as them having a unique twist on interfaces they felt was powerful, then you read it correctly. It never even occurred to me that someone would suggest they're claiming to have invented interfaces, mostly because obviously they didn't.
- dwattttt 3y ago
  I was careful to try read what was said; the language might be a bit loose because it's a transcript of a live talk. That said, the example they gave, and their motivating problem of the qsort API in C don't show anything about using nominal interfaces, and instead look like a normal use of interfaces, combined with language about being wowed of how powerful they could be.
  - PH95VuimJjqBqy 3y ago
    The text is recreated below: > It's clear that interfaces are, with concurrency, a distinguishing idea in Go. They are Go's answer to objected-oriented design, in the original, behavior-focused style, despite a continuing push by newcomers to make structs carry that load. > Making interfaces dynamic, with no need to announce ahead of time which types implement them, bothered some early critics, and still irritates a few, but it's important to the style of programming that Go fostered. Much of the standard library is built upon their foundation, and broader subjects such as testing and managing dependencies rely heavily on their generous, "all are welcome" nature. > I feel that interfaces are one of the best-designed things in Go. > Other than a few early conversations about whether data should be included in their definition, they arrived fully formed on literally the first day of discussions. > And there is a story to tell there. > On that famous first day in Robert's and my office, we asked the question of what to do about polymorphism. Ken and I knew from C that qsort could serve as a difficult test case, so the three of us started to talk about how our embryonic language could implement a type-safe sort routine. > Robert and I came up with the same idea pretty much simultaneously: using methods on types to provide the operations that sort needed. That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away. > That's something that is not often not acknowledged: Go's sort is implemented as a function that operates on an interface. This is not the style of object-oriented programming most people were familiar with, but it's a very powerful idea. > That idea was exciting for us, and the possibility that this could become a foundational > programming construct was intoxicating. When Russ joined, he soon pointed out how I/O would fit beautifully into this idea, and the library took place rapidly, based in large part on the three famous interfaces: empty, Writer, and Reader, holding an average of two thirds of a method each. Those tiny methods are idiomatic to Go, and ubiquitous. > _THE WAY INTERFACES WORKED became not only a distinguishing feature of Go, they became the way we thought about libraries, and generality, and composition. It was heady stuff. emphasis at the end there is mine. how the hell _anyone_ reads that and comes away with the idea that they're claiming they invented the idea of interfaces is beyond me. my only guess here is that many people are not familiar with the sort problem they're describing. very famously, C++'s sort is more performant than C's sort because C uses a void pointer and C++ uses templates. The extra type information allows C++ to optimize the sort in a way that C cannot, so while C is generally more performant than C++ in a lot of ways, this is one particular area where C++ shines. So it's no surprise that Rob Pike, et al, paid close attention to sort as something to improve over C and the way to do that is having more type information available (C++ very clearly has shown this).

throwawaymaths 3y ago

It sounded like it to me. I kept thinking didn't java have interfaces to prevent multiple inheritance? All go did was replace all inheritance with interfaces

moomin 3y ago
Which I’m pretty sure CLU did first (honestly, I’m pretty sure nearly every good idea was in CLU first).