3 ms·

I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write

I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write functional code. For whatever reason, even if they're working in a language like Java that's fundamentally object oriented, they'll write primarily procedural code (mostly static functions accessing datatypes with no functionality besides getters and setters): either they don't understand that there's an alternative, or they see some benefit in it.

OkayPhysicist 4y ago
I'm a functional guy myself, so I think OO is a downgrade from plain ol' procedural code. Regardless, the procedural soup model gets applied because it's the end result of too many hands touching any given codebase. Elegant abstractions take time to grok, and are opinionated. If you start a project with a UML diagram, I'm going to be disgusted. If I start a project by defining the whole thing as a left fold over an infinite stream, someone else is going to be appalled. Abstractions have a target audience, and that rarely aligns with corporate hiring practices. If you're working on a given project for a long time, you'll appreciate the abstractions. If you just want to monkeypatch in a quick fix/feature because your boss told you to, you find where it fits, you hammer it into place, and call it a day. Rinse repeat for a few years, and all corporate code becomes procedural.