3 ms·
This feels less of polymorphism eroding type safety as it is aliased terms eroding it. Stated differently, programming/abstraction doesn't protect you from syn
by taeric 3y ago
This feels less of polymorphism eroding type safety as it is aliased terms eroding it. Stated differently, programming/abstraction doesn't protect you from synonyms.
That is, it means different things to iterate over all allowed values of a list than it does to iterate over the existence of something. That they can be abstractly described in the same way feels powerful, of course, but such is the case of powerful tools?
- tlb 3y agoYes, and common synonyms like `length` can hose you when you convert from a string to a list of strings. They shouldn’t really have the same name, especially in a Unicode world where there are several different lengths for a string.
- cmrdporcupine 3y agoYes it's in the same category of "we know better now, hopefully?" as people overloading the + operator for string concatenation. Refining for clarity of categories is hard. I'm not sure 'type polymorphism' is the problem here as much as it is false conceptual polymorphism.
- cryptonector 3y agoYes, this is about aliases. When you see `length` in a language like Haskell you don't know what length exactly it refers to without looking at the type of its argument. But if you see `list_of_foo_length` then you know there can be only one `list_of_foo_length` and where to look for it. This makes things like source code indexers have to know how to parse the language and how to understand its types even. Compare to the lowly ctags/etags/cscope of C world! Clearly monomorphic APIs are easier to deal with in some ways, though they also clutter things up a bit.