6 ms·

The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yours

The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yourself. You don't need a function call. I guess this is for stylistic reasons, but I don't know why anyone would feel strongly about doing it one way or the other.

quelltext 4y ago
Yes, I mentioned that that's basically what it says. But why would you tell people to actively duplicate code? It's like "I don't get what this type of function does and have to look it up all the time, better to have everyone inline this so it's clearer". To be fair, I agree that seeing bad examples of its use shown by one of the other folks here, some could have been avoided by them being forced to inline, but funnily those examples still exist despite the desires of the function author. Nothing was achieved here.
- barsonme 4y ago
  I think manual three-way comparisons are very clear. But so is strings.Compare. For better or worse, copying code is a pretty normal thing to do in Go. See "A little copying is better than a little dependency." [0] [0]: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s&themeRefresh=1 https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s&themeRef...
  - codeflo 4y ago
    I even somewhat agree with that principle, but it don’t think it applies to using the standard library, which is (a) not little and (b) not a new dependency you add to the project. If that’s the justification to keep an implementation bad on purpose (which I’m not sure is the actual intention, but is at least that’s what the referenced comment claims), then I’m not even sure I speak the same language as the people who made that decision.
- somekyle2 4y ago
  This is a part of Go's rather odd perspective that I appreciate. I've worked in codebases with library helpers for everything that mostly served to turn two clear lines into a function call. Once such functions exist, folks feel obligated to use them; after all, why duplicate code? So now, what would've been a couple dozen lines of self-contained straightforward code has 3 imports and 5 functions you need to be familiar with to understand it. It also makes compilation more expensive. I'm not saying library functions are bad or anything like that, but there's value to keeping the typical vocabulary of code small, of not adding new dependencies to solve trivial problems. Especially in a standard library that is widely used and you expect to be maintained for years. Providing functions that solve problems that are impossible or tricky in the language is important; providing `Plus(a, b int) int` that wraps `+` makes the library worse. I think there's a good argument for providing Compare() and Abs() and other fairly trivial functions even if it is perhaps less effort to not use them in most cases, but for a stdlib I can appreciate the logic of leaving out what isn't providing clear value.
  - xmprt 4y ago
    I would understand that if the method was left out. But in this case, a strings.Compare method is provided but the implementation says not to use it. That's the worst of both worlds. The stdlib still has this extra method and users will feel obligated to use it because it exists but the method is inefficient.
    - echlebek 4y ago
      The standard library can't ever remove anything because of the Go compatibility promise, and a certain percentage of it is mistakes. Once some functionality is later realized to be poor or incorrect, and the design prevents fixing it, there is not much that can be done other than telling people not to use it anymore. What you refer to as the worst of both worlds is unfortunately inevitable, but at least it's in service of a greater goal. edit: clarity
      - pjmlp 4y ago
        That is what happens when they refuse to adopt a deprecation process, even Java, .NET, C and C++ with their high regard for backwards compatibility do have such processes, and have removed features from standard library and languages.
- masto 4y ago
  I seem to recall one of go’s creators snapped back at a similar question about code duplication with “what’s the matter, are your fingers broken?” I think that sums up the philosophy, though maybe not as well as “Nothing was achieved here”, which I would like to translate into Latin and get on some stickers.
  - verisimilitudes 4y ago
    - MobiusHorizons 4y ago
      How much do you know about the authors of go? It is objectively untrue that they don’t understand computers. Maybe just maybe, people with decades of software experience might understand that the weak link in software is the editor not the author, and are optimizing for different priorities than you have. But mostly I wanna to say avoid assuming someone else doesn’t understand something because they didn’t do what you would do. You should always figures out what they were trying to do first.
    - doctor_eval 4y ago
      Such a bizarre comment for a language designed - by the creator of Unix no less - to work well with tools and to be easily parsed. High likelihood it was posted from a Unix device too.
    - dang 4y ago
      Since we've asked you many times to stop posting flamebait and you're still doing it, I've banned the account. It's not what this site is for, and it destroys what it is for. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
barsonme 4y ago
Go doesn't have many features of other languages. There are several competing goals, including keeping the language small, not hiding complexity, etc. Manually writing the three-way comparison fits in with these goals. If slices were comparable then I'd wager that bytes.Compare would not exist.
- saghm 4y ago
  What sticks out to me is the part saying "the compiler should be changed". It's weird enough that this isn't even a doc comment but a comment inside the function (making it harder for people using the function to notice), but even as someone who thinks the passive voice is often unfairly maligned, the phrasing immediately brings to mind the question "who should change the compiler?" Is the Go standard library not maintained by the same group of people as the compiler, or is this comment just a doubly obfuscated "TODO"?
  - yencabulator 4y ago
    It's not a TODO yet, it 's a note that says if you think this would be a good idea, do that instead. It's a potential TODO-to-be, waiting for the need.
    - saghm 4y ago
      Is that better? That would mean that they have a method in their API that they don't think anyone should use but haven't deprecated it or documented it that way and have no plans to do anything about it.
      - yencabulator 4y ago
        strings.Compare is mostly used in trivial demonstration programs, and is there because bytes.Compare is there. It makes https://pkg.go.dev/sort#Find https://pkg.go.dev/sort#Find documentation simpler. Deprecating strings.Compare would make sort documentation worse. Real code tends to not be that trivial, and that's why real code most likely shouldn't be using strings.Compare.
zenexer 4y ago
I don’t think that’s true. I believe they want you to explicitly define how you want you compare strings. Comparing Unicode strings isn’t as straightforward as comparing individual bytes or code points. For example, there are multiple Unicode strings that will yield the character “ï”. If you use a naïve comparison function, you can’t be sure that it will behave as expected when it encounters the word “naïve”.
- donatj 4y ago
  You’re looking for Collator.CompareString https://pkg.go.dev/golang.org/x/text/collate#Collator.CompareString https://pkg.go.dev/golang.org/x/text/collate#Collator.Compar...
- sltkr 4y ago
  > I believe they want you to explicitly define how you want you compare strings. If that were true, they wouldn't have made strings comparable in the first place, and they wouldn't recommend that callers inline the implementation (they'd recommend calling some locale-dependent function instead). An explicit comparison like "naïve" == "naïve" or "naïve" < "naïve" isn't any more clear about how the comparison is performed than Compare("naïve", "naïve") would be.

quelltext 4y ago

Yes, I mentioned that that's basically what it says. But why would you tell people to actively duplicate code? It's like "I don't get what this type of function does and have to look it up all the time, better to have everyone inline this so it's clearer". To be fair, I agree that seeing bad examples of its use shown by one of the other folks here, some could have been avoided by them being forced to inline, but funnily those examples still exist despite the desires of the function author. Nothing was achieved here.

barsonme 4y ago
I think manual three-way comparisons are very clear. But so is strings.Compare. For better or worse, copying code is a pretty normal thing to do in Go. See "A little copying is better than a little dependency." [0] [0]: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s&themeRefresh=1 https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s&themeRef...
- codeflo 4y ago
  I even somewhat agree with that principle, but it don’t think it applies to using the standard library, which is (a) not little and (b) not a new dependency you add to the project. If that’s the justification to keep an implementation bad on purpose (which I’m not sure is the actual intention, but is at least that’s what the referenced comment claims), then I’m not even sure I speak the same language as the people who made that decision.
somekyle2 4y ago
This is a part of Go's rather odd perspective that I appreciate. I've worked in codebases with library helpers for everything that mostly served to turn two clear lines into a function call. Once such functions exist, folks feel obligated to use them; after all, why duplicate code? So now, what would've been a couple dozen lines of self-contained straightforward code has 3 imports and 5 functions you need to be familiar with to understand it. It also makes compilation more expensive. I'm not saying library functions are bad or anything like that, but there's value to keeping the typical vocabulary of code small, of not adding new dependencies to solve trivial problems. Especially in a standard library that is widely used and you expect to be maintained for years. Providing functions that solve problems that are impossible or tricky in the language is important; providing `Plus(a, b int) int` that wraps `+` makes the library worse. I think there's a good argument for providing Compare() and Abs() and other fairly trivial functions even if it is perhaps less effort to not use them in most cases, but for a stdlib I can appreciate the logic of leaving out what isn't providing clear value.
- xmprt 4y ago
  I would understand that if the method was left out. But in this case, a strings.Compare method is provided but the implementation says not to use it. That's the worst of both worlds. The stdlib still has this extra method and users will feel obligated to use it because it exists but the method is inefficient.
  - echlebek 4y ago
    The standard library can't ever remove anything because of the Go compatibility promise, and a certain percentage of it is mistakes. Once some functionality is later realized to be poor or incorrect, and the design prevents fixing it, there is not much that can be done other than telling people not to use it anymore. What you refer to as the worst of both worlds is unfortunately inevitable, but at least it's in service of a greater goal. edit: clarity
    - pjmlp 4y ago
      That is what happens when they refuse to adopt a deprecation process, even Java, .NET, C and C++ with their high regard for backwards compatibility do have such processes, and have removed features from standard library and languages.
masto 4y ago
I seem to recall one of go’s creators snapped back at a similar question about code duplication with “what’s the matter, are your fingers broken?” I think that sums up the philosophy, though maybe not as well as “Nothing was achieved here”, which I would like to translate into Latin and get on some stickers.
- verisimilitudes 4y ago
  - MobiusHorizons 4y ago
    How much do you know about the authors of go? It is objectively untrue that they don’t understand computers. Maybe just maybe, people with decades of software experience might understand that the weak link in software is the editor not the author, and are optimizing for different priorities than you have. But mostly I wanna to say avoid assuming someone else doesn’t understand something because they didn’t do what you would do. You should always figures out what they were trying to do first.
  - doctor_eval 4y ago
    Such a bizarre comment for a language designed - by the creator of Unix no less - to work well with tools and to be easily parsed. High likelihood it was posted from a Unix device too.
  - dang 4y ago
    Since we've asked you many times to stop posting flamebait and you're still doing it, I've banned the account. It's not what this site is for, and it destroys what it is for. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

barsonme 4y ago

Go doesn't have many features of other languages. There are several competing goals, including keeping the language small, not hiding complexity, etc. Manually writing the three-way comparison fits in with these goals. If slices were comparable then I'd wager that bytes.Compare would not exist.

saghm 4y ago
What sticks out to me is the part saying "the compiler should be changed". It's weird enough that this isn't even a doc comment but a comment inside the function (making it harder for people using the function to notice), but even as someone who thinks the passive voice is often unfairly maligned, the phrasing immediately brings to mind the question "who should change the compiler?" Is the Go standard library not maintained by the same group of people as the compiler, or is this comment just a doubly obfuscated "TODO"?
- yencabulator 4y ago
  It's not a TODO yet, it 's a note that says if you think this would be a good idea, do that instead. It's a potential TODO-to-be, waiting for the need.
  - saghm 4y ago
    Is that better? That would mean that they have a method in their API that they don't think anyone should use but haven't deprecated it or documented it that way and have no plans to do anything about it.
    - yencabulator 4y ago
      strings.Compare is mostly used in trivial demonstration programs, and is there because bytes.Compare is there. It makes https://pkg.go.dev/sort#Find https://pkg.go.dev/sort#Find documentation simpler. Deprecating strings.Compare would make sort documentation worse. Real code tends to not be that trivial, and that's why real code most likely shouldn't be using strings.Compare.

zenexer 4y ago

I don’t think that’s true. I believe they want you to explicitly define how you want you compare strings. Comparing Unicode strings isn’t as straightforward as comparing individual bytes or code points. For example, there are multiple Unicode strings that will yield the character “ï”. If you use a naïve comparison function, you can’t be sure that it will behave as expected when it encounters the word “naïve”.

donatj 4y ago
You’re looking for Collator.CompareString https://pkg.go.dev/golang.org/x/text/collate#Collator.CompareString https://pkg.go.dev/golang.org/x/text/collate#Collator.Compar...
sltkr 4y ago
> I believe they want you to explicitly define how you want you compare strings. If that were true, they wouldn't have made strings comparable in the first place, and they wouldn't recommend that callers inline the implementation (they'd recommend calling some locale-dependent function instead). An explicit comparison like "naïve" == "naïve" or "naïve" < "naïve" isn't any more clear about how the comparison is performed than Compare("naïve", "naïve") would be.