[throwaway234232]

I think in Java, you would need to do a type-class approach.

    interface Numeric<T> {
        T zero();
        T add(T a, T b);
    }

    static <T> T sum(Numeric<T> n, T[] v) {
        T summer = n.zero();
        for (int k = 0; k < v.length; k++) {
            summer = n.add(summer, v[k]);
        }
        return summer;
    }

[0xmarcin]

This will work, but will have poor performance due to the way Java generics are implemented. You could use your function with `Integer[]` or `Long[]` arrays but not with `int[]` or `long[]`. `Integer` being a wrapper class around `int` is a regular Java object accessible via reference, hence slow and memory-inefficient.

On the other hand C# offers "real" generics and you can use almost exactly the code that you wrote (generic syntax is slightly different).

[kasperni]

Type classes are on the roadmap after Valhalla [1].

[1] https://blogs.oracle.com/javamagazine/post/what-are-they-bui...

[throwaway234232]

This is good news.

My wishlist for Java is for null to be illegal for all types unless they are encoded as nullable such as `T?`.

Until then, I just use Kotlin and/or Scala when I require JVM.

[Avlin67]

also in .Net but then you enter a generic hell and you start thinking vanilla es6 is better

[sbelskie]

C# is getting support for generic math in 11 with the addition of static abstract members (including operators) for interfaces.

[nine_k]

AFAICT this is basically how numbers work in Haskell, and I see no particular problems with them. You usually don't need too many number types of different nature.

[maxbond]

Generics are great when you need them, but they will cut you badly if you misuse them.

Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too.

Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that can be safely ignored anywhere it isn't used.

When this component you're updating is highly connected to other parts of your code, perhaps add another generic parameter to it, it completely explodes and you have to jump all around your codebase adding generics.

The kicker is that you may be updating components which are themselves generic and highly connected, setting off secondary explosions. Pretty soon you're throwing that codebase out, starting over, and swearing to yourself that you'll never touch generics again.

My advice is to assume generics are a premature abstraction until you've exhausted what you can do with more concrete approaches.

[fauigerzigerk]

>Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too

Do you have an example of that? Can't you always "typedef" any particular generic type as a concrete type and work with that going forward?

>Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that can be safely ignored anywhere it isn't used.

I don't see how this is different from concrete types or interfaces. If you change a public API you may have to update callers. If you change internals you don't have to update callers. Perhaps you can show an example to clarify what you mean.

I'm not a huge fan of generics myself, but I think your claim is that generics force you to introduce unnecessary dependencies. I don't see how this is true on a logical level. Dependencies between compiled artifacts are a different matter, but that's an implementation issue and I don't think it's what you're talking about.

[orthoxerox]

https://github.com/dotnet/csharplang/issues/1328

> Have you ever wanted an interface (or abstract type) to be parameterized on a polymorphic variable to its implementer, but not its users? Have you ever wanted to parameterize over internal state, without revealing what that state contains to your users? This is what existential types allow you to do.

[maxbond]

I mentioned in a sibling comment, I just don't wanna write an example, sorry.

You can't typedef, or populate the generic in any way, until you've reached a point in your code where you have sufficient information to know what to populate it with. This can often be further from the point of the initial change than you might like, as I described. (ETA: I didn't realize viral implied that you can _never_ concretize, I only meant there's a tendency to pass it up the chain.)

Changing public APIs will cause secondary changes. Generics are coupled more tightly than some other kinds of changes. For example adding a parameter to a method in an interface does force you to update all those implementations, and then all the usages of those implementations, which is a lot of work and could potentially trigger a similar situation. But generally it doesn't bubble up as high. Because generics are more abstract, it's more difficult to populate that parameter - you're more likely to need to pass the buck by being generic over that yourself, which causes you to update more usages, etc.

[hardware2win]

Please show code then

I dont remember misusing C# generics even once and I struggle to see example of such a case

[maxbond]

This is a reasonable request, but I don't really want to write a code example, that feels like a lot of work and I have 0 investment in changing anyone's mind about this (I didn't really expect this to be controversial - I was just sharing my experiences and expanding on Avlin67's comment about "generic hell"), but if you had a question I'd be happy to answer it.

[kgeist]

The only example I can think of is the bifurcation non-generic collections vs. generic collections in the early days of C# when you had a non-generic collection and couldn't pass it to a method which expects a generic collection, but it was the consequence of the development history of C# and is not a problem of generics per se.

[blep_]

All of the things you said apply equally well to function parameters.

[maxbond]

That's an interesting point. From a strictly theoretical perspective you're right. I think it's that generics are more abstract and have a higher blast radius. Eg, you add an argument to a method, you need to update usage of that method. You add a generic to a class, you need to update everywhere that class is used.

The fact that arguments are less abstract also I believe tends to prevent them from bubbling all the way to the top. Generics can often only be populated at the top-level usage. Function arguments I find don't usually bubble up that far.

[blep_]

> you add an argument to a method, you need to update usage of that method. You add a generic to a class, you need to update everywhere that class is used.

You're talking about two different things here, though. What if you add a generic parameter to a function? It'll often be inferred at existing call sites, but worst case, same as any other change to a function's signature.

[rowanG077]

This is not the case with traits/type class approach seen in Rust/Haskell.

[maxbond]

I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem.

Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic.

That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.

[4ad]

Lifetimes are viral in Rust because 1. you can't abstract over them, 2. affine types are viral by design, but generics themselves are anything but viral.

[hgomersall]

They're not viral in rust - you can always replace the generic with a concrete type in super types.

[kaba0]

How is that different from any other part of a function signature? It’s part of the type system, of course changes have to be accounted for at use sites. But not doing so would be just incorrect.

[enw]

Honestly I have no idea what's going on with this code.

Where is `zero()` defined? Why does a `Numeric` have a function to `add` two numbers? Shouldn't you add a single number to a numeric? What is the relationship between `<T>` and `Numeric<T>`? I thought `T` was a `Numeric`?

Edit: Upon closer inspection, I kind of get what's going on. But it's really cryptic for something that should be simple to express.

[aw1621107]

> Where is `zero()` defined?

It's defined by whatever implements the interface.

> Why does a `Numeric` have a function to `add` two numbers?

Because Java doesn't have user-defined operator overloading, so if you want to add stuff in a generic fashion you can't rely on `+`.

> Shouldn't you add a single number to a numeric? What is the relationship between `<T>` and `Numeric<T>`? I thought `T` was a `Numeric`?

`Numeric` doesn't contain data, it just defines operations on numbers. So `Numeric<Integer>` would define operations on `int`s, `Numeric<BigInteger>` would define operations on `BigInteger`s, etc.

[ndriscoll]

Think of `Numeric<T>` as analogous to `Comparator<T>`. T is the type you're doing stuff with, `Comparator<T>` tells sorting algorithms how to compare two Ts, and `Numeric<T>` tells mathematical algorithms how to add two T's, and what a "zero" value for T should be.

There are probably other reasons to do this that I'm forgetting, but off the top of my head,

1. You can implement `Numeric<T>` or `Comparator<T>` for types `T` that come from a library that you can't change (so can't make T implement an interface that the library author didn't implement), or where you don't want to introduce a dependency (you could have a type class `JsonDecoder[T]` that comes from a library, and you don't want the library with your T to introduce a dependency on the json library).

2. You can have more than 1 implementation for a given T. For JSON decoders/validators, you might provide a decoder which bails out on the first error, or one which tries to continue reading fields so it can return all errors (field X was a string, expected number. Field Y was expected to be >= 1024, etc.). For comparators, you might have a `.reversed` function to easily make a comparator that sorts in reverse order. etc.

[throwaway234232]

I think this may be good reference material: http://learnyouahaskell.com/types-and-typeclasses

Basically I'm encoding this approach in Java.

[red_admiral]

Isn't the java problem that (a) the + operator is only defined for some built-in types, and (b) the int/Integer boxing distinction?

[throwaway234232]

Right, you can't overload the + operator, and primitives can't be used in generics.

[kelseyfrog]

yep, though a monoid isn't strictly necessary - a semigroup is sufficient for this use-case.