Hacker News Reader

Comment by Zababa | Hacker News Reader

I wonder what the OOP version of that would look like. Trivially, you can imagine that an assembling machine is an object to which you can send a message CopperPlate, and that will reply with CopperWire, CopperWire. I've been thinking about factories like you see in "How it's made" and how you can imagine the machines in terms of functions with an input and an output, object to which you pass something and receive something back, or even "ingredient flow" where the focus is on the product and the different steps and not the transformations.

View on HN

The line between functional and object oriented actually gets very blurry when you take OO in its traditional sense, i.e. if you accept message passing between objects as the defining feature.

if the object becomes a pure blackbox and all you care about is what it sends and receives then this is hard to distinguish from the functional thinking, because even functions at their core usually have an imperative implementation, they just hide it away.

Erlang has been brought up in the thread and it's a good example of this because people use it as an example of both functional programming and maybe the closest thing to Alan Kay's original ideas about OO.

if you take mutation of state out of the object, and we leave aside all the category theory part of fp then is more a matter of where functions are defined/how they organised

Oop's defining feature is having hidden state behind those interfaces.

Pure functions do not have that

Monads are the little black boxes of state that send and receive messages.

According to wikipedia, "a monad is defined as a functor with additional structure". Not unlike an object.

Monads don’t receive nor send anything.

Arrays are a type that admits a monad instance, what do they send and receive?

  def x(input):
      tmp=input * 5 
      return str(tmp)

hey, hidden state!

If that were Haskell instead of python, it would still work, because tmp is never mutated. So it's not really state in that sense, it's just a binding.

    x input = show tmp
      where tmp = input * 5

It would be a different story if you had something like

    class IntState:
      def __init__(self, val):
        self.val = val
      
      def x(input):
        self.val += input
        return str(val)

Only different is OO languages typically give you an implicit {hierarchical state, logging, OS interfacing}, monad for free (or at least under the generalized async monad), FP makes you request all that yourself.

Reply on news.ycombinator.com