4 ms·

On the contrary, I would apply the 90/10 rule and would say that you only need to know what actually IS in memory when you have to care about it (and it becomes

On the contrary, I would apply the 90/10 rule and would say that you only need to know what actually IS in memory when you have to care about it (and it becomes a performance problem). And for the other 90% of the situations, I'll take the development speed/convenience. Also, as an example, most JITs (including the JVM one) optimize through vtable lookups (so you can inline a whole series of polymorphic calls that might boil down to a constant value). That's an example of an ease of dev vs performance tradeoff (polymorphic methods) that's been alleviated in an automated way by tools.

mrich 12y ago
Then again, there are countless websites which fail to outperform a comparable desktop app written in C++ 15 years ago, on today's powerful computers, which is sad.
blt 12y ago
That's what I'm arguing though. I think its way less than 90/10. 50/50 at most. Its not just a performance thing. Polymorphism moves the burden of reasoning about types from compile time to run time, and complicates the programmers mental model of the code. Sure, the use of interfaces appears to separate out the differences between types into clean capsules, but in practice understanding much of the polymorphic code ive worked on still requires a mental process of "OK, if it's THIS type then this happens; if its THAT type then something else happens." And then look at dynamic languages where loads of unit tests do the work of the type system. I'm not saying its never useful but its usefulness is over hyped. Many of these cases can be replaced by small localized changes at compile time or a one time cost of copying data into a canonical form.
- Dewie 12y ago
  > Polymorphism moves the burden of reasoning about types from compile time to run time, How? Doesn't this depend on the specific kind of polymorphism/implementation of which, rather than being about polymorphism inherently? What if types are erased at compile-time and the compiler generates functions and such for all the relevant types that you need? > but in practice understanding much of the polymorphic code ive worked on still requires a mental process of "OK, if it's THIS type then this happens; if its THAT type then something else happens." I think this is impossible with parametric polymorphism - if you say that the input data can be any type, you can't make any assumptions about what type it might be. If the incoming type only has the constraint that it can be tested for equality on other values of the same type, they only function you can use on it is ==, and so on.

mrich 12y ago

Then again, there are countless websites which fail to outperform a comparable desktop app written in C++ 15 years ago, on today's powerful computers, which is sad.

blt 12y ago

That's what I'm arguing though. I think its way less than 90/10. 50/50 at most. Its not just a performance thing. Polymorphism moves the burden of reasoning about types from compile time to run time, and complicates the programmers mental model of the code. Sure, the use of interfaces appears to separate out the differences between types into clean capsules, but in practice understanding much of the polymorphic code ive worked on still requires a mental process of "OK, if it's THIS type then this happens; if its THAT type then something else happens." And then look at dynamic languages where loads of unit tests do the work of the type system. I'm not saying its never useful but its usefulness is over hyped. Many of these cases can be replaced by small localized changes at compile time or a one time cost of copying data into a canonical form.

Dewie 12y ago
> Polymorphism moves the burden of reasoning about types from compile time to run time, How? Doesn't this depend on the specific kind of polymorphism/implementation of which, rather than being about polymorphism inherently? What if types are erased at compile-time and the compiler generates functions and such for all the relevant types that you need? > but in practice understanding much of the polymorphic code ive worked on still requires a mental process of "OK, if it's THIS type then this happens; if its THAT type then something else happens." I think this is impossible with parametric polymorphism - if you say that the input data can be any type, you can't make any assumptions about what type it might be. If the incoming type only has the constraint that it can be tested for equality on other values of the same type, they only function you can use on it is ==, and so on.