3 ms·
You seem to be misunderstanding the generality at which I'm speaking. Take this: >It's pretty hard to argue that more developer time is wasted That's NOT what
by Retra 10y ago
You seem to be misunderstanding the generality at which I'm speaking. Take this:
>It's pretty hard to argue that more developer time is wasted
That's NOT what I'm arguing. I'm saying that it takes a different amount of time. Hence the concept of "trade-offs", AKA "cost."
With that said...
>Your alternatives are A. duplicate the classes yourself B. let the compiler duplicate them. Where's the bloat?
C. Monomorphise at runtime.
>Less human written code, so this reduces the surface area to the compiler; which is an "issue" no matter how low level your code is.
Yes, but it's a different issue. Again, there are trade-offs.
>What concrete thing do generics model? Tediously copy-pasted code?
No. They model the behavior of the algorithm as it physically exists in a machine.
>What? It's an abstraction over an already typed system that obviates the need to duplicate code, which after the generics are unwound produces the same code you would have had anyway. You're just as far or close to the low-level un-typed system as you were before.
Generics are part of your language. They do not abstract over the language. They abstract over the behavior of your program. It's just a feature of the language that does so with greater generality that the rest of the language.
And the code you "would have written anyway" is machine code. Which you are abstracting over. Generics allow you to pretend your algorithm doesn't need a fixed machine representation. The fact that you can produce two different machine representations for the same template code is an example of what I'm talking about, not a counter example. The abstraction leaks. You write one algorithm, and it has to be compiled into two different representations. That's the cost of the abstraction. You get increased generality at the cost of memory and time.
- johncolanduoni 10y ago> Generics are part of your language. They do not abstract over the language. Most generics systems allow the code to be unfolded into generic free code; this is how templates are usually compiled in C++. So in a material sense the compiler treats templates as syntactic sugar added over C++ without templates (which is a valid language, which the compiler uses internally). > C. Monomorphise at runtime. A lot of generics (like my complex number example) can't be monomorphized at runtime since floats and doubles don't have dynamic dispatch in these languages. Not to mention the loss of type safety even if you implemented it this way. So that is not equivalent. > And the code you "would have written anyway" is machine code. That's not analyzing the cost of generics, that's analyzing the cost of the whole language, and then putting it on generics. If that's fair, why wouldn't we add the cost of designing and operating computers instead of doing it on paper? There's nothing special about machine code here. > The abstraction leaks. You write one algorithm, and it has to be compiled into two different representations. That's the cost of the abstraction. If (as in my example before) you need complex numbers with floating point numbers, and complex numbers with doubles, the compilation will likely be faster because the compiler doesn't need to take two parallel implementations through the whole parsing process, and can instead generate the necessary ASG itself. If you use on only one, then maybe there is a detectable differential cost. Also, how is that even a leak? That's the abstraction working absolutely perfectly and giving you exactly what you intended.