4 ms·

> Probably [hello NIGHTMARE !]. Who wants that? Nobody wants that. I don't really care if you want that. Everyone should know that that's just the way slices w

> Probably [hello NIGHTMARE !]. Who wants that? Nobody wants that. I don't really care if you want that. Everyone should know that that's just the way slices work. Nothing more nothing less. I really don't give a damn about that, i just know how slices behave, because I learned the language. That's what you should do when you are programming with it (professionally)

terminalbraid 1y ago
If you're fine with that then you should be upset by the subsequent example, because by your own definition "that's just not the way slices work".
- 813ac4312b25c 1y ago
  I am fine with the subsequent example, too. If you read up about slices, then that's how they are defined and how they work. I am not judging, I am just using the language as it is presented to me. For anyone interested, this article explains the fundamentals very well, imo: https://go.dev/blog/slices-intro https://go.dev/blog/slices-intro
  - terminalbraid 1y ago
    Then you seem to be fine with inconsistent ownership and a behavioral dependence on the underlying data rather than the structure. You really don't see why people would point a definition that changes underneath you out as a bad definition? They're not arguing the documentation is wrong.
    - assbuttbuttass 1y ago
      The definition is perfectly consistent. append is in-place if there's enough capacity (and the programmer can check this directly with cap() if they want), and otherwise it allocates a new backing array.
      - terminalbraid 1y ago
        Yes, it's consistent and complicated and non-intuitive. "Consistent" is necessary but not sufficient for "good".
    - deleted 1y ago
      [deleted]
    - rustandmore 1y ago
      Ownership is perfectly consistent. `append` always returns a new slice value `func append(slice []Type, elems ...Type) []Type` The only correct way to use append is something like `sl = append(sl, 1, 2, 3)` `sl` is now a new slice value, as `append` always returns a new slice value. You must now pass the new slice value back to the user, and the user must use the new slice value. The user must not use the old slice value. It's trivial to fix the "bug" in the article, once you actually understand what a slice value is: https://go.dev/play/p/JRMV_IuXcZ6 https://go.dev/play/p/JRMV_IuXcZ6 A slice is not the underlying array, and the underlying array is not the slice. A slice is just a box with 3 numbers.
thomashabets2 1y ago
Yup. If you code in Go then you should know that. Just like every PHP coder should know that the ternary operator associativity is backwards compared to every other language. If you code in a language, then you should know what's bad about that language. That doesn't make those aspects not bad.
- theodorejb 1y ago
  Note that since PHP 8.0 the ternary operator is non-associative, and attempting to nest it without explicit parenthesis produces a hard error.
skitter 1y ago
The author obviously knows that too, otherwise they wouldn't have written about it. All of these issues are just how the language works, and that's the problem.
lawn 1y ago
> because I learned the language If that's your argument then there are no bad design decisions for any language.

terminalbraid 1y ago

If you're fine with that then you should be upset by the subsequent example, because by your own definition "that's just not the way slices work".

813ac4312b25c 1y ago
I am fine with the subsequent example, too. If you read up about slices, then that's how they are defined and how they work. I am not judging, I am just using the language as it is presented to me. For anyone interested, this article explains the fundamentals very well, imo: https://go.dev/blog/slices-intro https://go.dev/blog/slices-intro
- terminalbraid 1y ago
  Then you seem to be fine with inconsistent ownership and a behavioral dependence on the underlying data rather than the structure. You really don't see why people would point a definition that changes underneath you out as a bad definition? They're not arguing the documentation is wrong.
  - assbuttbuttass 1y ago
    The definition is perfectly consistent. append is in-place if there's enough capacity (and the programmer can check this directly with cap() if they want), and otherwise it allocates a new backing array.
    - terminalbraid 1y ago
      Yes, it's consistent and complicated and non-intuitive. "Consistent" is necessary but not sufficient for "good".
  - deleted 1y ago
    [deleted]
  - rustandmore 1y ago
    Ownership is perfectly consistent. `append` always returns a new slice value `func append(slice []Type, elems ...Type) []Type` The only correct way to use append is something like `sl = append(sl, 1, 2, 3)` `sl` is now a new slice value, as `append` always returns a new slice value. You must now pass the new slice value back to the user, and the user must use the new slice value. The user must not use the old slice value. It's trivial to fix the "bug" in the article, once you actually understand what a slice value is: https://go.dev/play/p/JRMV_IuXcZ6 https://go.dev/play/p/JRMV_IuXcZ6 A slice is not the underlying array, and the underlying array is not the slice. A slice is just a box with 3 numbers.

thomashabets2 1y ago

Yup. If you code in Go then you should know that. Just like every PHP coder should know that the ternary operator associativity is backwards compared to every other language. If you code in a language, then you should know what's bad about that language. That doesn't make those aspects not bad.

theodorejb 1y ago
Note that since PHP 8.0 the ternary operator is non-associative, and attempting to nest it without explicit parenthesis produces a hard error.

skitter 1y ago

The author obviously knows that too, otherwise they wouldn't have written about it. All of these issues are just how the language works, and that's the problem.

lawn 1y ago

> because I learned the language If that's your argument then there are no bad design decisions for any language.