4 ms·

It's not about eliminating state it's about hiding it. OOP hides state, which means mutability is often shared and hidden.

sodapopcan 6y ago
I'm ripping a quote from another HN user the last OO/FP discussion I read on so apologies if you see this and are like, "Hey! I said that!" buuuut: OO says: "State is hard—let's hide it!" (er, sorry, "encapsulate it") FP says: "State is hard—let's isolate it!"
- bmitc 6y ago
  I think languages like F# and Racket get it right, because multiple paradigms are available to you. I like F#’s stance on functional-first programming. There are times in which you want to expose the underlying types and there are times you do not. When I recently started a ray tracer implementation, it was a good example of this. The vector, color, point, transform, world, camera, etc. types where all readily implemented by records and discriminated unions which properly isolated but exposed the types. However, for the matrix library, I chose to use F#’s Array.Parallel library and thus a 1D array as the underlying implementation, and this was a perfect use case for using a class. I wanted to hide the implementation of the matrices from the user of the type and encapsulate the internal behavior, only exposing a clean API. Even in that case, the matrix type was immutable because the operations on matrices would simply return new matrices. I think F#’s acceptance of multiple paradigms is really the way to go.
- colllectorof 6y ago
  Encapsulation has nothing to do with hiding stuff. It is the idea that an object is effectively defined by its externally observable behavior.
  - sodapopcan 6y ago
    I was being cheeky—I regret it.
- mmis1000 6y ago
  Probably "State is hard—let's eliminate it!" is better if it is possible. Lots of states just shouldn't exist at first place because they are clearly derivations of some other state.
deleted 6y ago
[deleted]
mumblemumble 6y ago
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.

sodapopcan 6y ago

I'm ripping a quote from another HN user the last OO/FP discussion I read on so apologies if you see this and are like, "Hey! I said that!" buuuut: OO says: "State is hard—let's hide it!" (er, sorry, "encapsulate it") FP says: "State is hard—let's isolate it!"

bmitc 6y ago
I think languages like F# and Racket get it right, because multiple paradigms are available to you. I like F#’s stance on functional-first programming. There are times in which you want to expose the underlying types and there are times you do not. When I recently started a ray tracer implementation, it was a good example of this. The vector, color, point, transform, world, camera, etc. types where all readily implemented by records and discriminated unions which properly isolated but exposed the types. However, for the matrix library, I chose to use F#’s Array.Parallel library and thus a 1D array as the underlying implementation, and this was a perfect use case for using a class. I wanted to hide the implementation of the matrices from the user of the type and encapsulate the internal behavior, only exposing a clean API. Even in that case, the matrix type was immutable because the operations on matrices would simply return new matrices. I think F#’s acceptance of multiple paradigms is really the way to go.
colllectorof 6y ago
Encapsulation has nothing to do with hiding stuff. It is the idea that an object is effectively defined by its externally observable behavior.
- sodapopcan 6y ago
  I was being cheeky—I regret it.
mmis1000 6y ago
Probably "State is hard—let's eliminate it!" is better if it is possible. Lots of states just shouldn't exist at first place because they are clearly derivations of some other state.

deleted 6y ago

[deleted]

mumblemumble 6y ago

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.