It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). Microservices, in fact, could be considered "network objects" and a microservice framework as network OOP. The problem there is that normal making a function call is straight-forward. The call produce a failure result, but the call actually happens. On the network, the call might not happen, and you might not be aware that the call cannot and will not happen for some seconds. This is not likely to simplify your code...

OOP can be just about structuring code, like the Java OOP fundamentalism, where even a function must be a Runnable object (unless it's changed since Oracle took over). If there's anything that is not an object, it's a function!

Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from. In transforming information and passing it around, no state is needed or wanted, and immutability is helpful. FP in a UI or a game is not so fun (witness all the hooks in React, which in anything complicated is difficult to follow), since both of those require considerable internal state.

Algorithms are a sort of middle ground. Some algorithms require keeping track of a bunch of things, others more or less just transform the inputs. OOP (internal to the algorithm) can make the former much clearer, while it is unhelpful for that latter.

▲

hackthemack 5 hours ago | parent | next [-]

> It's unclear to me what the author thinks OOP is

I rather liked the old post "Object Oriented Programming is an Expensive Disaster that Must End" written over 10 years ago.

https://medium.com/@jacobfriedman/object-oriented-programmin...

Many complained the post was too long, and then debated all kinds of things brought up in the article (such is the way of the internet).

But the one thing I really liked is how it laid out that everyone has a different definition of what OOP is and so it is difficult to talk about.

	▲	swader999 32 minutes ago \| parent [-]
		I'd settle for just getting inheritance to fade away.

▲

senderista 5 hours ago | parent | prev | next [-]

The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.

▲

elcritch an hour ago | parent | next [-]

IMHO the real key of message passing is localized decision making on a specific instance of data.

Similarly message passing allows an actor to decide how to respond to an event, to forward a message, to ignore it, etc. That's possible but more difficult to achieve with Java/C++ "straightjacket" style OOP. Important patterns for GUIs like the Observer pattern are just simpler with a message passing paradigm.

▲

webstrand 2 hours ago | parent | prev [-]

And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.

Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state.

And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.

	▲	Jensson 18 minutes ago \| parent [-]
		> Personally I'm against the practice of enforced state-hiding Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message. Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.

▲

gwbas1c 5 hours ago | parent | prev | next [-]

> It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with.

The author is complaining about bloat.

The thing is, in this case, the bloat has highly tangible costs: Spreading an application across multiple computers unnecessarily adds both operation costs and development costs.

	▲	bloppe 3 hours ago \| parent [-]
		Unnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary. The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.

▲

deepsun 3 hours ago | parent | prev | next [-]

> If there's anything that is not an object, it's a function!

Why, functions have state -- their closure.

▲

endgame 3 hours ago | parent | next [-]

Ancient wisdom: closures are a poor man's objects; objects are a poor man's closures.

https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...

▲

knome 3 hours ago | parent | prev [-]

closures and objects with a single invoke() method have been considered equivalent in many views for some time.

	▲	deepsun an hour ago \| parent [-]
		Exactly, that's why I disagree with parent's comment: > If there's anything that is not an object, it's a function!

▲

airstrike 2 hours ago | parent | prev [-]

> So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit).

OOP is not better suited for user-interfaces than the alternatives.