4 ms·

That's what college textbook OOP taught us. It only took me a couple decades to figure out that college textbook OOP taught us wrong. If all you're doing is hid

That's what college textbook OOP taught us. It only took me a couple decades to figure out that college textbook OOP taught us wrong. If all you're doing is hiding state, it's like sweeping dirt under the carpet - you're skimping on your work now, in a way that will only create more work later. Good object oriented design goes much, much further. To quote Alan Kay, "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." (emphasis mine)

staticassertion 6y ago
Well yeah, obviously Kay and Armstrong agree.
- eyelidlessness 6y ago
  Not only that, but it’s pretty clear the philosophical roots of OOP are basically just FP with a particular organizational model. The idea was never “everything is mutable and gets to mutate everything else unless you say otherwise”, it was about organizing functions (real functions) with the specific data they operate on. The big blob of imperative programming that got bolted onto that is a disservice to the idea. But unfortunately that cat’s been out of that bag for decades and isn’t going anywhere.
  - zozbot234 6y ago
    > Not only that, but it’s pretty clear the philosophical roots of OOP are basically just FP with a particular organizational model. That's true of much of OOP, but implementation inheritance is the elephant in the room - it can't be modeled or understood using a pure FP model, because the combination of late binding and so-called 'open recursion' requires a dispatch step on all virtual method calls (that would in turn be modeled in FP via a "tying the knot" trick). The resulting semantics are extremely tricky, and most practitioners are aware of the problems with them (see "fragile base class"). Some recent programming languages have abandoned implementation inheritance altogether, e.g. Rust. IOW, they're really more like FP-semantics languages with OOP-like syntactic sugar on top.
    - eyelidlessness 6y ago
      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.
      - zozbot234 6y ago
        My claim was specifically about implementation inheritance. Providing 'consistent interfaces' falls under interface inheritance (which is non-problematic), and 'inheriting' static data types only is semantically indistinguishable from composition. The problem with OOP is also how it conflates patterns that have very little to do semantically with one another as one overly general thing ('inheritance!') even though the general case is not really useful.
        6y ago
anonymouse008 6y ago
Yeah, Alan Kay once likened OOP to biology saying the ultimate embodiment is replicating “messages” between cells. Once I heard that, it makes natural sense that Combine became a first class library in Swift, giving the code base ion channels so that messages just aren’t sprayed everywhere with NotificationCenter or requiring you to name each individual “protein/hormone” message in your program.
- fsckboy 6y ago
  > Alan Kay once likened OOP to biology once? it's Alan Kay's only speech!
jrochkind1 6y ago
That Alan Kay quote is intriguing to me, I haven't heard it before, and I'm not sure I understand what it means. I found that it's from this piece, although a brief skim I'm not this piece gives me more guidance about how to do that, but I plan to spend more time with it. http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ If anyone has other articles to recommend on this concept, please.
- mumblemumble 6y ago
  That's the paper I pulled the quote from. Reading it, and learning Pharo, and reading some Smalltalk code, was, for me, one heck of a revelation.

staticassertion 6y ago

Well yeah, obviously Kay and Armstrong agree.

eyelidlessness 6y ago
Not only that, but it’s pretty clear the philosophical roots of OOP are basically just FP with a particular organizational model. The idea was never “everything is mutable and gets to mutate everything else unless you say otherwise”, it was about organizing functions (real functions) with the specific data they operate on. The big blob of imperative programming that got bolted onto that is a disservice to the idea. But unfortunately that cat’s been out of that bag for decades and isn’t going anywhere.
- zozbot234 6y ago
  > Not only that, but it’s pretty clear the philosophical roots of OOP are basically just FP with a particular organizational model. That's true of much of OOP, but implementation inheritance is the elephant in the room - it can't be modeled or understood using a pure FP model, because the combination of late binding and so-called 'open recursion' requires a dispatch step on all virtual method calls (that would in turn be modeled in FP via a "tying the knot" trick). The resulting semantics are extremely tricky, and most practitioners are aware of the problems with them (see "fragile base class"). Some recent programming languages have abandoned implementation inheritance altogether, e.g. Rust. IOW, they're really more like FP-semantics languages with OOP-like syntactic sugar on top.
  - eyelidlessness 6y ago
    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.
    - zozbot234 6y ago
      My claim was specifically about implementation inheritance. Providing 'consistent interfaces' falls under interface inheritance (which is non-problematic), and 'inheriting' static data types only is semantically indistinguishable from composition. The problem with OOP is also how it conflates patterns that have very little to do semantically with one another as one overly general thing ('inheritance!') even though the general case is not really useful.
      - 6y ago

anonymouse008 6y ago

Yeah, Alan Kay once likened OOP to biology saying the ultimate embodiment is replicating “messages” between cells. Once I heard that, it makes natural sense that Combine became a first class library in Swift, giving the code base ion channels so that messages just aren’t sprayed everywhere with NotificationCenter or requiring you to name each individual “protein/hormone” message in your program.

fsckboy 6y ago
> Alan Kay once likened OOP to biology once? it's Alan Kay's only speech!

jrochkind1 6y ago

That Alan Kay quote is intriguing to me, I haven't heard it before, and I'm not sure I understand what it means. I found that it's from this piece, although a brief skim I'm not this piece gives me more guidance about how to do that, but I plan to spend more time with it. http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ If anyone has other articles to recommend on this concept, please.

mumblemumble 6y ago
That's the paper I pulled the quote from. Reading it, and learning Pharo, and reading some Smalltalk code, was, for me, one heck of a revelation.