I think this is some combination of strawman, and subset of all cases. You can lament complications of OOP. You can also lament the complications of docker, kubernetes, HTTP APIs etc. These aren't mutually exclusive, and they don't span the breadth of programming techniques. I prefer avoiding all of these.

Anecdotally, I've replaced OOP with plain data structures and functions.

▲

mickduprez 6 hours ago | parent | next [-]

>> _Anecdotally, I've replaced OOP with plain data structures and functions._

I think this is why FP is becoming more popular these days but I'm not sure some people get why. The problem with OOP is you take a data set and spread it all over a 'system' of stateful (mutable) objects and wonder why it doesn't/can't all fit back into place when you need it to. OOP looks great on paper and I love the premise but...

With FP you take a data set and pass it through a pipeline of functions that give back the same dataset or you take a part of that data out, work on it and put it straight back. All your state lives in one place, mutable changes are performed at the edges, not internally somewhere in a mass of 'instances'.

I think micro services et al try to alleviate this by spreading the OO system's instances into silos but that just moves the problems elsewhere.

▲

baq 5 hours ago | parent [-]

IME microservices solve engineering process problems (i.e. synchronization, enforcement of interface boundaries, build and test scale issues), not technical problems in the product.

	▲	mickduprez 5 hours ago \| parent [-]
		I agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop. Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

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

It is somewhat interesting to realize micro services are conceptually solving the same problem that OOP despite working in such different areas.

Though OOP is just one step - structured programming works on the same problem.

▲

phkahler 5 hours ago | parent | prev [-]

>> Anecdotally, I've replaced OOP with plain data structures and functions.

Agreed. I think objects/classes (C++) should be for software subsystems and not so much for user data. Programs manipulate data, not the other way around - polymorphism and overloading can be bad for performance.

▲

cogman10 5 hours ago | parent [-]

Objects/classes work best for datastructures (IMO).

Outside that usecase, I think polymorphism via inheritance is generally a mistake.

Programs manipulate data and datastructures organize that data in a way that's algorithmically efficient.

The main issue with OOP is that without a very clear abstraction, it can be almost impossible to reason about code as you end up needing to know too much about the hierarchy of code to correctly understand what will happen next. As it turns out, most programmers are pretty bad at managing that abstraction boundary.

	▲	FartinMowler 4 hours ago \| parent [-]
		OOP is like alcohol: enjoyable in moderation but dangerous in excess. In moderation, an object is a data structure with associated functions (methods) that acts as a kind of namespace. If your data structure and functions are separate, you might start having function name collisions. Hopefully we won't see a prohibition against OOP.