I'm not smarter than you but.
I believe the terms reified generics and erased generics is the type sweaty donkey ball terminology you get for professional CS academics.
Sticking my neck out further.
Reified generics means the type is available at run time. In C# you can write if(obj.GetType() == typeof(typename))
Erased generics the type information is not available at run time. That's the way Java does it and it kinda sucks.
Academics invent short names for common (in their field) concepts not because they're 'sweaty' but because if the thing you're going to mention in every second paragraph in a good chunk of the communication you do with other people working on the same topic requires a full sentence to explain you're going to A. get really annoyed at having to type it out all the time and B. probably explain it slightly differently every time and confuse people.
Academic jargon isn't invented to be elitist, it's invented to improve communication.
(of course there's a good chance you understand this already, and you're just making a dumb joke, but I figured I'd explain this anyway for the benefit of everyone reading)
I don't take issue with the naming but with the names that feel a bit beyond my ken. "Erased" makes sense when explained but not before. "Reified" is a word I simply do not use so it feels like academia run amok.
Regardless, I recognize myself as the point of failure, but those names do strike me as academia speak, though better than some/many. <shrug>
Another shrug, but part of it is that the PL community (programming language community) is pretty deep into its own jargon that doesn’t have as much overlap as you might think, with other subfields of computer science.
People describe a type system as “not well-founded” or “unsound” and those are specific jabs at the axioms, and people talk about “system F” or “type erasure” or “reification”. Polymorphism can be “ad-hoc” or “parametric”, and type parameters can be invariant, covariant, and contravariant. It’s just a lot of jargon and I think the main reason it’s not intuitive to people outside the right fields is that the actual concepts are mostly unfamiliar.
> Another shrug, but part of it is that the PL community (programming language community) is pretty deep into its own jargon that doesn’t have as much overlap as you might think, with other subfields of computer science.
The word reified dates back to the 1800s. It isn't the most common word, but it also definitely wasn't invented by the programming language community.
It was (and is) used a lot by philosophers and there was a large overlap between a certain class of philosophers and a certain class of mathematicians who developed early type theory. Any type theorist who knows his literature will run into reification very early on.
> Erased generics the type information is not available at run time. That's the way Java does it and it kinda sucks.
In a good statically-typed language you don't need runtime type information. It could be a Void in the bytecode for all I care, as long as it behaves correctly.
> obj.GetType() == typeof(typename)
In a statically-typed language, this can be optimised away to a bool at compile time.
Oh absolutely not true AT ALL.
Occasionally it is really useful to be able to do something like `new T()`. Without reified generics that is not possible.
new T? What's wrong with the old one?
Jokes aside, what's the use case for not knowing what T is until runtime?
Pretty much all polymorphism works by not knowing the concrete type til runtime. If you have an Animal reference to a Dog instance, any method you call on it is resolved at runtime, because the reference knows the type. Reified generics do the same for type parameters, whereas erased types are only used for type checking at compile time.
> Erased generics the type information is not available at run time. That's the way Java does it and it kinda sucks.
To be more precise: in Java, generics on class/method/field declarations are available at runtime via reflection. The issue is that they aren’t available for instances. So a java.util.ArrayList<java.lang.String> instance is indistinguishable at runtime from a java.util.ArrayList<java.lang.Object> instance