5 ms·

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.

by enneff 11y ago

junke 11y ago
And that's exactly why I am not convinced that Go is as maintainable as often claimed. 30 seconds for you, but how many hours for the poor souls who will come after you and ask: should I change this copy too or is it a separate case? It reminds me of this: http://typicalprogrammer.com/abject-oriented/ http://typicalprogrammer.com/abject-oriented/
- enneff 11y ago
  This thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.
  - junke 11y ago
    The thread was more about mattlondon's problem with sorting according to the same key in different structs. I used of modified version of this example[0] to illustrate what I think is his problem[1]: you can sort circles and planet by radius, and probably many other things in the original case, but you are required to copy-paste the definitions. I can understand that instantiating templates by hand is not so bad. But once it is written, maintaining the code is not so obvious for someone not acquainted with it. Did I introduce a bug or not in the code? Not easy to tell without context. [0] http://stackoverflow.com/a/28999886/124319 http://stackoverflow.com/a/28999886/124319 [1] https://play.golang.org/p/Dq0AJjkhhr https://play.golang.org/p/Dq0AJjkhhr
    - jhalderman 11y ago
      Why not write an interface for getting the radius and a radius sorter for sorting on that interface? I made a modified version of your code to illustrate. https://play.golang.org/p/Ya7tUhDnO2 https://play.golang.org/p/Ya7tUhDnO2 *edited a typo
      - junke 11y ago
        Thanks a lot for your example. I would certainly take this approach and I am happy that you took the time to write it. I feel a little sorry for you because I put a trap for the parent poster in the original code. I wrote "a[j] < a[i]". You "fixed" it while refactoring, which would be the good thing to do if I made a typo. If however I really wanted to sort circles differently from planets, then you made an error while refactoring what looked like copy-pasta but wasn't. My original point was that when you "have" to copy-paste, you cannot clearly see what is or isn't part of the copy and what is new. You found a way to rewrite the code without much copy- pasting, and I am happy to see that. Still, in other places where code duplication arise, there could be similar problems from a maintenance point of view.
    - NateDad 11y ago
      It's 3 lines of code the most newbie of newbies could understand... if this is the biggest problem I have in my day to day programming, I'll be happy. Is it mildly annoying to type out those three lines? Sure. You know what's a lot more annoying? Basically everything else in programming.
      - junke 11y ago
        The problem with code duplication is not about being lazy, or having to type. I love typing. When you dive into a codebase full of vaguely similar yet different blocks, it starts being more than mildly annoying to understand the intent of the code and make the correct change.
        NateDad 11y ago
        nobutseriously... type userList []*User func (u userList) Len() int { return len(u) } func (u userList) Swap(i, j int) { u[i], u[j] = u[j], u[i] } func (u userList) Less(i, j int) bool { return u[i].Name() < u[j].Name() } What change would you ever need to make to this code that would be at all difficult? The first two methods on userList are never ever ever going to change. The only thing you could possibly want to change is how to sort inside the Less method... and that code would be the exact same code you'd have to change no matter what language you're in. You still have to define the sort one way or another for non-trivial types. So, yes, it's some extra typing... but saying that it makes maintenance harder is just plain wrong.
        junke 11y ago
        Not all duplication is bad in all cases. It is more a factor of quality, not a direct, causal relationship. See for example this review of publications about code duplication: http://eprints.eemcs.utwente.nl/15314/01/ewic_ea09_s4paper2.pdf http://eprints.eemcs.utwente.nl/15314/01/ewic_ea09_s4paper2.....
        NateDad 11y ago
iopq 11y ago
commit c270f19d456e862aeb559098fa32d36fbc5329a0 Date: Wed Apr 13 04:57:46 2016 -0700 fixing level selection again commit dae018e4f76db0e9da810b4560d6c8e1c7029048 Date: Mon Apr 11 07:06:47 2016 -0700 fixing level selection for hint case commit a754bcd0d09ab1e357ae28c8f06baf65d879878f Date: Sat Apr 9 02:33:14 2016 -0700 forgot to fix the level selection in the move case
golergka 11y ago
Maintenance.
parenthephobia 11y ago
What if I'd done that 20 times around my code-base and then later I discover there's an off-by-one error in the original code that's maybe been inherited into all 20 copies? If I could actually reuse code properly I'd only have to fix it once. Without effective code reuse, I have to hunt down the copies, each of which may have slight modifications to make them better fit their use case (and might be hard to grep for as a result), figure out whether or not the bug exists in that copy (and whether it can actually be triggered), and fix it there. The description of inheritance in http://typicalprogrammer.com/abject-oriented/ http://typicalprogrammer.com/abject-oriented/ seems relevant here. (Edit: Derp, junke got there way before me!)
takeda 11y ago
Then one day you find a bug in your code and now will have to find all copies of it and to make things worse someone else modified some of the copies so now not all of them are identical.

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.

by enneff 11y ago

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.

junke 11y ago

And that's exactly why I am not convinced that Go is as maintainable as often claimed. 30 seconds for you, but how many hours for the poor souls who will come after you and ask: should I change this copy too or is it a separate case? It reminds me of this: http://typicalprogrammer.com/abject-oriented/ http://typicalprogrammer.com/abject-oriented/

enneff 11y ago
This thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.
- junke 11y ago
  The thread was more about mattlondon's problem with sorting according to the same key in different structs. I used of modified version of this example[0] to illustrate what I think is his problem[1]: you can sort circles and planet by radius, and probably many other things in the original case, but you are required to copy-paste the definitions. I can understand that instantiating templates by hand is not so bad. But once it is written, maintaining the code is not so obvious for someone not acquainted with it. Did I introduce a bug or not in the code? Not easy to tell without context. [0] http://stackoverflow.com/a/28999886/124319 http://stackoverflow.com/a/28999886/124319 [1] https://play.golang.org/p/Dq0AJjkhhr https://play.golang.org/p/Dq0AJjkhhr
  - jhalderman 11y ago
    Why not write an interface for getting the radius and a radius sorter for sorting on that interface? I made a modified version of your code to illustrate. https://play.golang.org/p/Ya7tUhDnO2 https://play.golang.org/p/Ya7tUhDnO2 *edited a typo
    - junke 11y ago
      Thanks a lot for your example. I would certainly take this approach and I am happy that you took the time to write it. I feel a little sorry for you because I put a trap for the parent poster in the original code. I wrote "a[j] < a[i]". You "fixed" it while refactoring, which would be the good thing to do if I made a typo. If however I really wanted to sort circles differently from planets, then you made an error while refactoring what looked like copy-pasta but wasn't. My original point was that when you "have" to copy-paste, you cannot clearly see what is or isn't part of the copy and what is new. You found a way to rewrite the code without much copy- pasting, and I am happy to see that. Still, in other places where code duplication arise, there could be similar problems from a maintenance point of view.
  - NateDad 11y ago
    It's 3 lines of code the most newbie of newbies could understand... if this is the biggest problem I have in my day to day programming, I'll be happy. Is it mildly annoying to type out those three lines? Sure. You know what's a lot more annoying? Basically everything else in programming.
    - junke 11y ago
      The problem with code duplication is not about being lazy, or having to type. I love typing. When you dive into a codebase full of vaguely similar yet different blocks, it starts being more than mildly annoying to understand the intent of the code and make the correct change.
      - NateDad 11y ago
        nobutseriously... type userList []*User func (u userList) Len() int { return len(u) } func (u userList) Swap(i, j int) { u[i], u[j] = u[j], u[i] } func (u userList) Less(i, j int) bool { return u[i].Name() < u[j].Name() } What change would you ever need to make to this code that would be at all difficult? The first two methods on userList are never ever ever going to change. The only thing you could possibly want to change is how to sort inside the Less method... and that code would be the exact same code you'd have to change no matter what language you're in. You still have to define the sort one way or another for non-trivial types. So, yes, it's some extra typing... but saying that it makes maintenance harder is just plain wrong.
        junke 11y ago
        Not all duplication is bad in all cases. It is more a factor of quality, not a direct, causal relationship. See for example this review of publications about code duplication: http://eprints.eemcs.utwente.nl/15314/01/ewic_ea09_s4paper2.pdf http://eprints.eemcs.utwente.nl/15314/01/ewic_ea09_s4paper2.....
        NateDad 11y ago

iopq 11y ago

commit c270f19d456e862aeb559098fa32d36fbc5329a0 Date: Wed Apr 13 04:57:46 2016 -0700 fixing level selection again commit dae018e4f76db0e9da810b4560d6c8e1c7029048 Date: Mon Apr 11 07:06:47 2016 -0700 fixing level selection for hint case commit a754bcd0d09ab1e357ae28c8f06baf65d879878f Date: Sat Apr 9 02:33:14 2016 -0700 forgot to fix the level selection in the move case

golergka 11y ago

Maintenance.

parenthephobia 11y ago

What if I'd done that 20 times around my code-base and then later I discover there's an off-by-one error in the original code that's maybe been inherited into all 20 copies? If I could actually reuse code properly I'd only have to fix it once. Without effective code reuse, I have to hunt down the copies, each of which may have slight modifications to make them better fit their use case (and might be hard to grep for as a result), figure out whether or not the bug exists in that copy (and whether it can actually be triggered), and fix it there. The description of inheritance in http://typicalprogrammer.com/abject-oriented/ http://typicalprogrammer.com/abject-oriented/ seems relevant here. (Edit: Derp, junke got there way before me!)

takeda 11y ago

Then one day you find a bug in your code and now will have to find all copies of it and to make things worse someone else modified some of the copies so now not all of them are identical.