Right. But OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs.
Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.
"OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs."
ADTs are not an intrinsic part of FP, as not all FP languages even have them.
I'd also question whether ubiquitous polymorphism is overall a good thing in a language, or whether it's misguided complexity. In most OOP languages, any public method can be polymorphic, but a polymorphic function is inherently less predictable than one dispatches off a single type.
It does not. -XOverloadedStrings unlocks `fromString :: String -> a.` That is not a polymorphic string interface; it's just syntax sugar for making something else from a string literal.
Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.