How do you figure OOP is falling out of favor? I've seen a few arguments on HN (the old OOP vs FP discussion) but do you actually expect the trend to continue to the point that no one really uses OOP anymore? Highly doubtful. And which specific part of the industry is OOP slipping into obscurity?
It's not so much that OOP is falling out of favour, but that functional programming in particular is being rediscovered, probably because we have to multithread now, and if bugs are hard to keep out of single-threaded code, they're nigh on impossible to keep out of multi-threaded code.
In fairness, a lot of us never truly embraced OOP anyway. I've always avoided objects unless I'm managing state. Even in OOP languages, much of my code essentially repurposes objects as modules for storing functions. The fact that they are implemented as methods is incidental. This is not an uncommon pattern.
I'm stronger with OOP than I am with functional programming because I've been doing OOP for longer. I started out with procedural programming when I was a kid (BASIC and QBASIC), and have since moved on to PHP, Javascript, Python and a bunch of other stuff.
Almost everything I've worked on in the last 8 years has involved OOP in either PHP, Python or Perl. Perhaps I stumbled into a niche and have yet to find my way out, but OOP has been a common theme in my career.
No, you stumbled into the mainstream. The wholesale migration to OOP was complete by the end of the 90s.
But you've probably been doing functional programming within OO languages and not realising it. For example, most of the PHP standard lib is functional. In fact, PHP is really a multi-paradigm language. Python is much closer to a pure OO language.
No, I do realize that PHP in functional. I suppose I misstated my history a bit - I went from procedural to scripting languages, to functional to mostly OOP in languages that support both functional and OOP.
I would say that Python isn't closer to a pure OO language than PHP, rather it allows for more pure OO than PHP. I only say this because you can go pure functional in Python as well.
It was popular in the 90s and early 00s to apply OOP techniques to everything, whether or not it made any sense. Today we use value types and higher-order functions all over the place, we customize objects with composition instead of inheritance, and we use module boundaries for encapsulation.
It doesn't help that it's easy to overdo your taxonomy, or try to model objects after the "real world" (rather than your domain model). Examples in some textbooks are pretty bad... if "dog" inherits from "animal" then you should throw the book out.
I would rather throw the book out if they had "dog" inheriting from "vehicle." Really, metaphors and analogies are nice, one of the most powerful parts of our capacity for human language. Just because math lacks those concepts, and so the same isn't possible in a functional mindset, doesn't mean it is bad.
Some FP textbooks are pretty bad...if fibanocci is implemented with just recursion, then you should throw the book out. </s>
My problem with "dog" and "animal" is not that I hate metaphors, but because the example tends to teach students that "X is a Y" is justification for "class X inherits from class Y". It's also usually found in books that focus more on the hammer than on the nails, if you know what I mean.
Recursive fib is usually taught to show how a naive translation of a recursive formula into code can cause poor performance. I can't think of a better example.
Reclusive FP is usssually the first example of the FP textbook, and is used to teach how elegant FP is from the beginnin jn spite of the fact that you should never write that (and who needs to write fib anyways). Inheritance is subtyping at the basic level: we all know a dog is an animal, and that all animals share a common ancestor. It is a crude instrument, especially in Java, and often can't be used, but not because the concept of extension is flawed in some ways. If you had traits/mixins, extension can be used much more widely.
I'm just as annoyed at the ideological "composition, not inheritance" crowd. The truth is, one has to learn a bunch of generalizations and then practice a lot to get it; good design is just hard to teach in a book.
FWIW, in my corner of the world (Scala, big data, web services) functional is very much the way things are going. It's a much better fit to the problem domain since all these systems very much look like pipelines. E.g. a web service is a function from request to respone. Big data applications are just applying some function over (possibly streaming) data.
It's happening on the front-end as well, with things like React.
Might be worth remembering that OOP was born out of a need to model the real world (SIMUlation LAnguage). I don't think it's a surprise that functions are a good way to work with mathematical models (that is, after all, how we do math).
For the front end, it's my understanding that event-passing systems are still used quite heavily -- which can also be considered OOP (message passing).
Modelling a car as a sub-class of vehicle etc -- makes most sense when you're modelling real-world objects.
You may be interested in the Actor Model [1] computation style. When used for programming, it looks like a programming paradigm where functional and object-oriented styles are neatly supported and blended without any impedance mismatches. Most code is written in a functional style, but there are abstractions that encapsulate state changes and make it work together with the mostly declarative functions.
There are at least a couple of Coursera lectures teaching this style (one about programming paradigms, the other about reactive programming), it's worth giving it a look.
The actor model isn't a computation style itself so much as a concurrency discipline loosely resembling the style of message-passing OO (a la Smalltalk).
It appears that some people have become so zealously opposed to object orientation that they have been unable to realize that not everything is Java.
