5 ms·

As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results o

As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results of this. > Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.

KirinDave 9y ago
> After a decade of OOP indoctrination and misuse, we see the results of this. Sure, but that's OO's fault and the lesson is not "abstractions are bad" but rather, "OO's good at domain abstractions and bad at universal abstractions." The takeaway should not be to discard the last 12 years of advances in computer science and call it quits with a bad copy of Erlang's concurrency model and a weak version of C. > This lends me to believe you actually haven't written any go code for yourself. I've written about 5000 lines. So not a ton, but enough to have shipped Go to prod and be capable of reading it. > This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. Go is more OOP-focused with its weak interface{} methodology than anything I promote or have used joyfully in the last 6 years. Even the most cursory examination of my presence will reveal that. Please don't put words in my mouth to tidy your argument.
- deleted 9y ago
  [deleted]
camus2 9y ago
> As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." like writing 500 * if err != nil { return err } is an average Go app? A little yes, but this isn't a little.
- treehau5 9y ago
  like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching. Sorry, the if err != nil horse has been beaten to death already.
  - camus2 9y ago
    > like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? What is insane is believing returning errors is actually handling them, it is not, you're just passing the burden on the caller. Second, Go isn't free of all the bullhshit you described so I'm not sure what is your point, that you don't have to write getters and setters in Go? lol, off course you do have to. > Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching Who cares, go back playing Pokemon since apparently that's the only thing you can think off and stop being an hypocrite. What do you think panics are? yes, it's an half-baked exception system, like everything in Go, a language designed by people who clearly didn't know what they are doing, for people who don't. > Sorry, the if err != nil horse has been beaten to death already Yes, and don't worry, people will keep on beating that horse, because it was designed by people that clearly don't know what they are doing.
StavrosK 9y ago
> "A little duplication is far better than the wrong abstraction." A little exploration is better than a false dichotomy.
- KirinDave 9y ago
  Integer loops over length should be enough for everyone. Especially when poor numerical method error handling has bugged sort implementations for most of my life.
stickfigure 9y ago
You can't write a generic map function for lists. The lack of this abstraction alone should be damning. Even rudimentary functional programming is hard in Go.
DonbunEf7 9y ago
Go is a uniquely rude language which both has over a dozen numeric types (seventeen from my reading of [0]) and also zero code reusability. I can't think of a better way to ruin any chances I might have of avoiding numeric bugs. [0] https://golang.org/ref/spec https://golang.org/ref/spec

KirinDave 9y ago

> After a decade of OOP indoctrination and misuse, we see the results of this. Sure, but that's OO's fault and the lesson is not "abstractions are bad" but rather, "OO's good at domain abstractions and bad at universal abstractions." The takeaway should not be to discard the last 12 years of advances in computer science and call it quits with a bad copy of Erlang's concurrency model and a weak version of C. > This lends me to believe you actually haven't written any go code for yourself. I've written about 5000 lines. So not a ton, but enough to have shipped Go to prod and be capable of reading it. > This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. Go is more OOP-focused with its weak interface{} methodology than anything I promote or have used joyfully in the last 6 years. Even the most cursory examination of my presence will reveal that. Please don't put words in my mouth to tidy your argument.

deleted 9y ago
[deleted]

camus2 9y ago

> As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." like writing 500 * if err != nil { return err } is an average Go app? A little yes, but this isn't a little.

treehau5 9y ago
like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching. Sorry, the if err != nil horse has been beaten to death already.
- camus2 9y ago
  > like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? What is insane is believing returning errors is actually handling them, it is not, you're just passing the burden on the caller. Second, Go isn't free of all the bullhshit you described so I'm not sure what is your point, that you don't have to write getters and setters in Go? lol, off course you do have to. > Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching Who cares, go back playing Pokemon since apparently that's the only thing you can think off and stop being an hypocrite. What do you think panics are? yes, it's an half-baked exception system, like everything in Go, a language designed by people who clearly didn't know what they are doing, for people who don't. > Sorry, the if err != nil horse has been beaten to death already Yes, and don't worry, people will keep on beating that horse, because it was designed by people that clearly don't know what they are doing.

StavrosK 9y ago

> "A little duplication is far better than the wrong abstraction." A little exploration is better than a false dichotomy.

KirinDave 9y ago
Integer loops over length should be enough for everyone. Especially when poor numerical method error handling has bugged sort implementations for most of my life.

stickfigure 9y ago

You can't write a generic map function for lists. The lack of this abstraction alone should be damning. Even rudimentary functional programming is hard in Go.

DonbunEf7 9y ago

Go is a uniquely rude language which both has over a dozen numeric types (seventeen from my reading of [0]) and also zero code reusability. I can't think of a better way to ruin any chances I might have of avoiding numeric bugs. [0] https://golang.org/ref/spec https://golang.org/ref/spec