6 ms·

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complic

by gnoack 5y ago

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

HideousKojima 5y ago
I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.
- tptacek 5y ago
  As with everything else, sometimes this is true, sometimes it isn't. In languages with pervasive generics, figuring out how things work can mean following several extraneous layers of indirection as any opportunity to parameterize something is always taken. But writing the same stupid loop to delete something from a slice is also unclear and complicated. The point isn't that generics are bad, just that they should be used judiciously.
- gnoack 5y ago
  ...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate<T> and Matcher<T>, making test errors hard to comprehend for very little additional benefit. etc etc There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complicates a language significantly. [1] https://docs.oracle.com/javase/tutorial/java/generics/bounded.html https://docs.oracle.com/javase/tutorial/java/generics/bounde...
  - pjmlp 5y ago
    Still better than messing with code generators and template language workarounds.
- CraigJPerry 5y ago
  >> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not in general application programming which is where most developers spend most of our time. But of course the shiny toy can be hard to resist and so generics are often overused and abused.
  - stouset 5y ago
    As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less complicated than sum := 0 for i, v := range nums { if i > 20 { break; } if v % 2 == 1 { continue; } sum += v; } The former is less complicated for those people (including me) because it expresses high-level intent rather than low-level implementation. Multiplied over a large code-base, the ability to express intent adds up to an enormous saving in mental overhead rather quickly. You can always drill down and focus on implementation where it matters, but with golang there's almost zero ability to separate a program's detailed implementation from a high-level description of what you're actually trying to accomplish. The Ruby version of this is also less bug-prone (did you spot the bug in the go example?). And it's also easier to apply to new contexts: the former works automatically for infinite enumerations.
    - cdelsolar 5y ago
      should be == 0? I don't like the Ruby example myself.
      - stouset 5y ago
s-video 5y ago
The thing that worries me is people trying to reconstruct features from other languages with generics. One of the things I like about Go is that no matter whose code you're looking at, it's almost certain that you're already familiar with any feature you'll see, because the set of features is relatively small.

by gnoack 5y ago

HideousKojima 5y ago

I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.

tptacek 5y ago
As with everything else, sometimes this is true, sometimes it isn't. In languages with pervasive generics, figuring out how things work can mean following several extraneous layers of indirection as any opportunity to parameterize something is always taken. But writing the same stupid loop to delete something from a slice is also unclear and complicated. The point isn't that generics are bad, just that they should be used judiciously.
gnoack 5y ago
...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate<T> and Matcher<T>, making test errors hard to comprehend for very little additional benefit. etc etc There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complicates a language significantly. [1] https://docs.oracle.com/javase/tutorial/java/generics/bounded.html https://docs.oracle.com/javase/tutorial/java/generics/bounde...
- pjmlp 5y ago
  Still better than messing with code generators and template language workarounds.
CraigJPerry 5y ago
>> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not in general application programming which is where most developers spend most of our time. But of course the shiny toy can be hard to resist and so generics are often overused and abused.
- stouset 5y ago
  As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less complicated than sum := 0 for i, v := range nums { if i > 20 { break; } if v % 2 == 1 { continue; } sum += v; } The former is less complicated for those people (including me) because it expresses high-level intent rather than low-level implementation. Multiplied over a large code-base, the ability to express intent adds up to an enormous saving in mental overhead rather quickly. You can always drill down and focus on implementation where it matters, but with golang there's almost zero ability to separate a program's detailed implementation from a high-level description of what you're actually trying to accomplish. The Ruby version of this is also less bug-prone (did you spot the bug in the go example?). And it's also easier to apply to new contexts: the former works automatically for infinite enumerations.
  - cdelsolar 5y ago
    should be == 0? I don't like the Ruby example myself.
    - stouset 5y ago

s-video 5y ago

The thing that worries me is people trying to reconstruct features from other languages with generics. One of the things I like about Go is that no matter whose code you're looking at, it's almost certain that you're already familiar with any feature you'll see, because the set of features is relatively small.