3 ms·

The funny thing is; your code has a syntax error (two, actually). Its dumb to nitpick, but its symbolic of the problem; even if you're so sure that you have no

by 013a 7y ago

The funny thing is; your code has a syntax error (two, actually). Its dumb to nitpick, but its symbolic of the problem; even if you're so sure that you have no mistakes, that what you've written is well designed and will work well... you're probably wrong. Even the simplest blocks of code will have issues, and the language should do everything it can to help this. No one likes to be told that all they deserve is a blunt knife, but frankly, it's more true than it isn't. I'll gladly wield that blunt knife if it means I get to build awesome products that don't break at 2am. (Edit) I made a mistake in my analysis of your code; there's actually three errors. Everyone makes mistakes. Our tools shouldn't encourage us to make more.

ailideex 7y ago
Would the mistakes compile? In many cases having a simpler less powerful language increases the amount of code you have to write. In this case it would be one place to fix, if the function was implemented for n different types then a mistake would have to be fixed n times. If Go Contracts reduce duplication they help at eliminating an anitipattern.
logicchains 7y ago
Now imagine if I'd copy-pasted that code for every builtin int and float type; there'd be ~ 36 errors.
- 013a 7y ago
  That's a fair point, but it harkens back to the argument we see a lot for generics; "we'd have to repeat that 5 times for int8, int16, int32, int64, and just int, not to mention floats!". I think there's a problem of complexity with that core argument. Why are you replicating this function 5 times? Why not just use `int`? Or just `float`? In other words, you're creating a solution that is (probably) too complex, and to manage that complexity you're asking for more language complexity. How about we attack the root of the issue: why is the solution so complex? Can we reduce that complexity? More often than not, we can. Developers tend to over-engineer things, and Go's type system is a forcing function toward simplicity. Every once in a while, we run into a problem that would benefit from generics. But its very rare. The cost of "having" generics in every situation, including many where you don't need them, far outweighs the cost of being forced to grab `interface{}` or `reflect` in the very few situations where you don't have them. The problem is: It's not as obvious that this cost is higher. That's the challenge the Go team has had over the past few years; convincing us, who hold a loaded gun pointed straight at our foot, to not pull the trigger and turn this language into Java2.

by 013a 7y ago

ailideex 7y ago

Would the mistakes compile? In many cases having a simpler less powerful language increases the amount of code you have to write. In this case it would be one place to fix, if the function was implemented for n different types then a mistake would have to be fixed n times. If Go Contracts reduce duplication they help at eliminating an anitipattern.

logicchains 7y ago

Now imagine if I'd copy-pasted that code for every builtin int and float type; there'd be ~ 36 errors.

013a 7y ago
That's a fair point, but it harkens back to the argument we see a lot for generics; "we'd have to repeat that 5 times for int8, int16, int32, int64, and just int, not to mention floats!". I think there's a problem of complexity with that core argument. Why are you replicating this function 5 times? Why not just use `int`? Or just `float`? In other words, you're creating a solution that is (probably) too complex, and to manage that complexity you're asking for more language complexity. How about we attack the root of the issue: why is the solution so complex? Can we reduce that complexity? More often than not, we can. Developers tend to over-engineer things, and Go's type system is a forcing function toward simplicity. Every once in a while, we run into a problem that would benefit from generics. But its very rare. The cost of "having" generics in every situation, including many where you don't need them, far outweighs the cost of being forced to grab `interface{}` or `reflect` in the very few situations where you don't have them. The problem is: It's not as obvious that this cost is higher. That's the challenge the Go team has had over the past few years; convincing us, who hold a loaded gun pointed straight at our foot, to not pull the trigger and turn this language into Java2.