@avdi
gave a good talk relating to some of these ideas at RubyConf in Nashville.
I'm not functional aficionado, but I tend to think OOP and FP are not mutually exclusive. A good example, in my opinion, is the Actor Model which (as I understand it) fits into both camps.
From the sidelines of this conversation, I kinda wonder, "why not both?"
A traditional Actor is almost definitionally an object with private state and public behavior via messages. But to your point, there are functional adaptations which, instead of having private state, are provided their previous state and a new message to process, then return a new state and side effects to execute. MVU update function is exactly this from a dev perspective. Although from a runtime perspective it is usually still hosted inside a traditional actor/object. Because of our heritage from the von Neumann architecture at a low level.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@avdi gave a good talk relating to some of these ideas at RubyConf in Nashville.
I'm not functional aficionado, but I tend to think OOP and FP are not mutually exclusive. A good example, in my opinion, is the Actor Model which (as I understand it) fits into both camps.
From the sidelines of this conversation, I kinda wonder, "why not both?"
A traditional Actor is almost definitionally an object with private state and public behavior via messages. But to your point, there are functional adaptations which, instead of having private state, are provided their previous state and a new message to process, then return a new state and side effects to execute. MVU
updatefunction is exactly this from a dev perspective. Although from a runtime perspective it is usually still hosted inside a traditional actor/object. Because of our heritage from the von Neumann architecture at a low level.