3 ms·

What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list

What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list of names? Surely that's a basic task that programming languages should be able to to do.

suprfsat 4y ago
well the comment says it's faster to use the built-in string comparison operators ==, <, >, and so on. the reason it's faster is because the function is intentionally slow, but
ori_b 4y ago
Sort only uses '<'.
travisby 4y ago
Based on https://go-review.googlesource.com/c/go/+/3012?tab=comments https://go-review.googlesource.com/c/go/+/3012?tab=comments , it sounds like they were originally focusing on _clearer_. (I interpret that) rsc considers the native binary operators to be clearer than a function with the name `Compare`. Honestly, I'd expect people to use `==` as well over `strings.Compare`. `==` _does_ work for strings, but I believe `[]byte` would try comparing memory addresses which is why the `bytes.Compare` version exists and is optimized (some assembly version, probably costly to maintain per arch?).
- quelltext 4y ago
  The native binary operators aren't a three way compare though. The author seems to assume nobody needs a three way compare, which I feel is assuming a bit too much. In particular because it is there because someone is using/needing it already. Basically their comment actually says that everyone who does need a three way compare should just re-implement what they wrote there (and maybe they'll make sure everyone's code is optimized later). Sounds pretty bizarre to me to discourage code reuse. And if three way compares are a pattern they want to discourage in the first place it should be elaborated on in documentation.
- throwawayabcdef 4y ago
  https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f97ba43ae36df215a5 https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... I interpret this as replacing a strange but more optimal call to the runtime with a straight forward but less fast stdlib implementation. rsc's comment seems more like a todo note than and ideological stance (to me at least). Something like: "I removed this weird fast way to do this that was breaking stuff b/c of linker things and replaced it with some straightforward code that's slower. If we want this to be more optimal in the future we can fix it at the compiler level.". But I'm just reading into it. Someone should ask him and tell him to explain himself :) It's been 8 years. What have you been doing?

suprfsat 4y ago

well the comment says it's faster to use the built-in string comparison operators ==, <, >, and so on. the reason it's faster is because the function is intentionally slow, but

ori_b 4y ago

Sort only uses '<'.

travisby 4y ago

Based on https://go-review.googlesource.com/c/go/+/3012?tab=comments https://go-review.googlesource.com/c/go/+/3012?tab=comments , it sounds like they were originally focusing on _clearer_. (I interpret that) rsc considers the native binary operators to be clearer than a function with the name `Compare`. Honestly, I'd expect people to use `==` as well over `strings.Compare`. `==` _does_ work for strings, but I believe `[]byte` would try comparing memory addresses which is why the `bytes.Compare` version exists and is optimized (some assembly version, probably costly to maintain per arch?).

quelltext 4y ago
The native binary operators aren't a three way compare though. The author seems to assume nobody needs a three way compare, which I feel is assuming a bit too much. In particular because it is there because someone is using/needing it already. Basically their comment actually says that everyone who does need a three way compare should just re-implement what they wrote there (and maybe they'll make sure everyone's code is optimized later). Sounds pretty bizarre to me to discourage code reuse. And if three way compares are a pattern they want to discourage in the first place it should be elaborated on in documentation.
throwawayabcdef 4y ago
https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f97ba43ae36df215a5 https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... I interpret this as replacing a strange but more optimal call to the runtime with a straight forward but less fast stdlib implementation. rsc's comment seems more like a todo note than and ideological stance (to me at least). Something like: "I removed this weird fast way to do this that was breaking stuff b/c of linker things and replaced it with some straightforward code that's slower. If we want this to be more optimal in the future we can fix it at the compiler level.". But I'm just reading into it. Someone should ask him and tell him to explain himself :) It's been 8 years. What have you been doing?