With the procedural-OO hybrid, we see it applied in industry a little more often because it’s…

With the procedural-OO hybrid, we see it applied in industry a little more often because it’s taught. That said, I think we often use more OO than is justified (I work for a large company and we have a large, essentially monolithic system for loading things from flat files into databases that’s megabytes upon megabytes of java code, most of which consists of less-than-100-line classes with deeply nested inheritance — to perform a task that would be more reliably performed by a single line shell script). When procedural or proper OO is the Right Thing (or, when a procedural-OO hybrid is the Right Thing), we have a leg up on the problem, but until recently most CS program graduates would have very little familiarity with functional or declarative languages.

The tasks I see at work are rarely good matches for OO: I process large streams of data, mostly, so pipes are the appropriate abstraction. The tasks I see in my personal projects sometimes require OO, and other times are a better match for a functional style; only the simplest pipe-component type tasks end up being something I’d want to use a purely procedural style with.

That said, we do the tasks we know how to do, and we solve them with the tools we’re familiar with. Very useful tools of the past have been totally forgotten by the industry: how often do you see a junior dev who knows what PROLOG is, or FORTH, or MUMPS, or tumbler indexing of enfilades? I’m very happy that certain useful tools are becoming much more common (asymmetric key encryption and hashing used outside of the context of communications security, for instance, and combining functional programming with implicit parallel execution), but when tools become subject to fashion everyone suffers.