4 ms·

"The most important change introduced into Strongtalk is the move from structural to declaration based subtyping. This change was made because: Structural type

"The most important change introduced into Strongtalk is the move from structural to declaration based subtyping. This change was made because: Structural type descriptors do not express programmer intent, and are difficult to read. Error messages produced by structural checking are poorly localized and very hard to understand. This is especially true in a large system with lots of internal cross references like Smalltalk." Word. Yet fast-forward 30-ish years and structural typing is sold as a feature again. I swear Golang is doing so much backwards that it's starting to look intentional, like a Google-sponsored LOLCODE.

skybrian 9y ago
If you want to apply these claims to Go interfaces, you should actually make the case for it by showing that it's an issue in Go programs. This is just snark.
- oso2k 9y ago
  Don't knock snark. It's perfectly valid way to challenge and traces its history to early computer science. It's why you fear goto. It's why I exploit it.
  - enugu 9y ago
    Nowadays, it has become pervasive on social media, and lost value as everyone uses it. It acts as a rhetorical device which can disguise the poor quality of of the argument.
    - andreasgonewild 9y ago
      The word to keep in mind here is 'can', or I would say 'may'. The increasing tendency of crying wolf at anything you don't like by squeezing it into a category where it can't rock the boat anymore is not really helping us move forward collectively.
    - oso2k 9y ago
      I would say, if it's Millenial Style Snark (gawd I hate to brand all millennials that way but they do tend to sound like the younger halo/gta 5/etc playing crowd) where they say something stupid like "Tests or STFU" or "callbacks or GTFO", yeah, that's tiresome. It's the kind of tone I saw occasionally in early nodejs discussions. I wouldn't call that snark, however. So I agree with your last statement. Snark to me implies a wit or cleverness as well as defiance and challenge. This is why it worked for Dijkstra. The brevity of the messages above are just a show of a lack of ability or desire to communicate and clearly express an idea. The above are just unnecessarily verbally abusive. They incite a negative response before the person even has had a chance to process other meanings of the message.
      - andreasgonewild 9y ago
        I sure hope turning the whole thing into a personality-attack was worth it for you. Do you ever consider the harm you do as you desperately fight to prevent alternate views from affecting your reality? Not to mention that it's a loosing game in the long run. Brevity is a virtue; and Golang has very little of it.
  - andreasgonewild 9y ago
    Thing is, I'm not afraid of goto. This is more like random keywords behaving like goto in certain contexts.
- andreasgonewild 9y ago
  I have enough scars from complex Golang-applications; I'm just wrapping up a port of a 5kloc Golang-codebase to C++ and one of the things that struck me is how much declaring intentions and having them checked by the compiler helps. It's not that easy to prove decreased readability, it's more a gut-feeling of additional effort being required to keep track of everything. It's an issue I've found in any language that favors structural sub-typing, it's just that Golang is pretty exceptional at bragging about about it. What saves Golang in my opinion is the possibility of declaring types in hierarchies, which solves some of the problems; but you still have the issue where random types are part of a hierarchy without any hints in the code except for which methods are implemented.
  - skybrian 9y ago
    Okay, that's better. I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method. The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable. Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters. So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.
    - andreasgonewild 9y ago
      Don't get me started on down-your-throat, manual error-handling; imports tied to repositories and opaque, mandatory N*M-threading; the outright hostility to features like flexible locking. Or the overly draconian package reference rules which turns any non-trivial software into a packaging-puzzle. There is plenty more LOLCODE-worthy contraptions in there... Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.
wtetzner 9y ago
> I swear Golang is doing so much backwards that it's starting to look intentional, like a Google-sponsored LOLCODE. I pretty much agree with this. However, I think structural types can be very useful (though as row types, not subtyping). But I think you do still need a way to specify nominal types. Something like OCaml's abstract types on top of a language with row-typed records would give you the best of both worlds.

skybrian 9y ago

If you want to apply these claims to Go interfaces, you should actually make the case for it by showing that it's an issue in Go programs. This is just snark.

oso2k 9y ago
Don't knock snark. It's perfectly valid way to challenge and traces its history to early computer science. It's why you fear goto. It's why I exploit it.
- enugu 9y ago
  Nowadays, it has become pervasive on social media, and lost value as everyone uses it. It acts as a rhetorical device which can disguise the poor quality of of the argument.
  - andreasgonewild 9y ago
    The word to keep in mind here is 'can', or I would say 'may'. The increasing tendency of crying wolf at anything you don't like by squeezing it into a category where it can't rock the boat anymore is not really helping us move forward collectively.
  - oso2k 9y ago
    I would say, if it's Millenial Style Snark (gawd I hate to brand all millennials that way but they do tend to sound like the younger halo/gta 5/etc playing crowd) where they say something stupid like "Tests or STFU" or "callbacks or GTFO", yeah, that's tiresome. It's the kind of tone I saw occasionally in early nodejs discussions. I wouldn't call that snark, however. So I agree with your last statement. Snark to me implies a wit or cleverness as well as defiance and challenge. This is why it worked for Dijkstra. The brevity of the messages above are just a show of a lack of ability or desire to communicate and clearly express an idea. The above are just unnecessarily verbally abusive. They incite a negative response before the person even has had a chance to process other meanings of the message.
    - andreasgonewild 9y ago
      I sure hope turning the whole thing into a personality-attack was worth it for you. Do you ever consider the harm you do as you desperately fight to prevent alternate views from affecting your reality? Not to mention that it's a loosing game in the long run. Brevity is a virtue; and Golang has very little of it.
- andreasgonewild 9y ago
  Thing is, I'm not afraid of goto. This is more like random keywords behaving like goto in certain contexts.
andreasgonewild 9y ago
I have enough scars from complex Golang-applications; I'm just wrapping up a port of a 5kloc Golang-codebase to C++ and one of the things that struck me is how much declaring intentions and having them checked by the compiler helps. It's not that easy to prove decreased readability, it's more a gut-feeling of additional effort being required to keep track of everything. It's an issue I've found in any language that favors structural sub-typing, it's just that Golang is pretty exceptional at bragging about about it. What saves Golang in my opinion is the possibility of declaring types in hierarchies, which solves some of the problems; but you still have the issue where random types are part of a hierarchy without any hints in the code except for which methods are implemented.
- skybrian 9y ago
  Okay, that's better. I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method. The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable. Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters. So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.
  - andreasgonewild 9y ago
    Don't get me started on down-your-throat, manual error-handling; imports tied to repositories and opaque, mandatory N*M-threading; the outright hostility to features like flexible locking. Or the overly draconian package reference rules which turns any non-trivial software into a packaging-puzzle. There is plenty more LOLCODE-worthy contraptions in there... Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.

wtetzner 9y ago

> I swear Golang is doing so much backwards that it's starting to look intentional, like a Google-sponsored LOLCODE. I pretty much agree with this. However, I think structural types can be very useful (though as row types, not subtyping). But I think you do still need a way to specify nominal types. Something like OCaml's abstract types on top of a language with row-typed records would give you the best of both worlds.