While you’re of course right that implementation inheritance can’t commonly be modeled in FP, it can be used in multi-paradigm languages with explicitly functio

While you’re of course right that implementation inheritance can’t commonly be modeled in FP, it can be used in multi-paradigm languages with explicitly functional semantics devoted to it (eg Swift’s take on structs), and its purpose can be handled in FP languages either by data structures providing consistent interfaces into their constituent parts (exceedingly common in lisps) or by static types with similar consistency (exceedingly common in MLs). In the latter cases it’s not inheritance in the sense that one thing derived from another, but that all the things you’d model that way are derived from broadly compatible base types. Aside: Rich Hickey’s introduction to Clojure made all of my lisp anxieties vanish when he illustrated the syntactic difference as primarily moving a function call’s open bracket before the function name rather than after. It’s silly in hindsight, but it helped me feel more familiar at once and ready to learn the rest. Un-aside: I think this kind of exercise would be valuable in translating functional-ish OOP (state is isolated but largely operated on with stateless functions) to its FP syntactic equivalent. For example in Clojure, in Clojure you could syntactically rewrite (map some-hash some-fn) as a map method on a class instance and it’s just moving some punctuation around. Another one which is probably not very mind blowing here, but did tickle my brain when I recognized it for what it was: before the great concurrency upheavals over the last decade+ (eventually settling on Promises and async/await), Node had monadic Either/Option types as a core part of its interface (you just destructure them as callback arguments). None of this is meant to disagree with anything you said of course. Just wanted to add some “if you’re approaching state the same way there’s a representation in your environment” flavor to the discussion.