- interface/trait based programming / structural subtyping (widely used in go/rust, increasingly in TS and python)
- terraform
- react
- aws lambda / cloud functions
- flow-based data processing (the whole of deep learning, spark/hadoop)
- and of course, anything declarative DSL based (SQL, jq and friends)
So I would counter that the more valuable skill is "how do I solve problems in terms of applying and composing transforms to data"
To clarify, since everyone has their own definition of OOP, and of the four pillars, Abstraction, Polymorphism, aren't at all unique to OOP, and Encapsulation is just Abstraction: the defining features of OOP are inheritance and poking-and-prodding-state into opaque objects. Inheritance is subsumed by interfaces / structural subtyping, and poking at state is contrasted with reactor patterns, event sourcing, persistent data structures, etc.
Oop really shines at the middlin-low level, in languages without a lifetime (state for things like IO resourcese, at the GUI widget level, and the (micro)service level, which is more like the original smalltalk sort of objects, in which case inheritance isn't a think.
So is using SQL. My point, as well as the parent author's point, is that I've found a technology that has been a useful source of value for my entire career. I make no claims that there aren't other useful sources of value, but I've never for a second regretted the time I've spent getting better at writing object-oriented code.
I'm also quite comfortable writing functional and dataflow-oriented code, but I've never found those to be as exciting as some people seem to.
And yeah, since OOP is everywhere, there's zero downside to getting better at it.
> I've never found those to be as exciting as some people seem to.
It's less about excitement (for me at least) and less about the hair pulling associated with reasoning about complex state. I find the more independent attributes an object has, the harder it gets to reason about, unless I can serialize the whole thing (which usually goes against encapsulation).
I'd say that's the number 1 thing I do to get "better at OOP": have a healthy suspicion towards any long-lived object I can't serialize/deserialize using primitive types.
The React "way" is very much leaning into pure immutable data that flows through components which react to changes. Components aren't objects in the OOP sense. You don't call methods on them to update their internal state.
Weird how many large OOP codebases there are to find oneself working on and how few large FP ones. :) Maybe that's just coincidental, or maybe not.
FP doesn't scale?
- or -
FP inherently creates small code bases?
How on earth is that weird when OOP is a hundred times more popular than FP?
Anyway structs plus FP is no less object oriented. You just don't have to write the methods in the same code module. See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm...
Yes, I know NIM is not purely functional. Use F# instead to get a bit closer to purity, it also does OOP quite nicely as does pretty much any functional language that has closures.
OOP is a tool just as Git is a tool.
See also: https://medium.com/extreme-programming/oop-vs-fp-182475457a0...
In fact, Erlang (and Elixir, I suppose) may be the only object-oriented programming language[1].
Fad means popular (in a deragetory way). 90’s was its popularity heyday.
> See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm...
So oop is when you `obj.methodName(args)` instead of `methodName(obj, args)`? Well if that’s all it is about then I can get behind it...
> OOP is a tool just as Git is a tool.
An iron maiden is just a tool. Don’t be hatin’ it’s just a tool what has it done to you?