[AQXt]

Your conjecture may only hold for tiny (< 500 lines of code) problems.

But when you deal with big problems -- millions of lines of code, written by hundreds of developers over a period of years -- you'll definitely see the benefit of OO.

Of course, most projects are somewhere in the middle; but you shouldn't dismiss OO just because you can't see the benefit in tiny projects.

[leontrolski]

I'm currently on a project with 100s of thousands of lines of code (admittedly not millions) - working in the bag-of-functions style - and I've yet to miss any OO features.

Surely it's possible to construct a smaller example? It's not like the millions of lines codebase isn't de-composable?

[bananaface]

For what it's worth, Emacs is an example of what you describe and it's extremely functional (and carries a huge amount of global state). Millions of lines, an insane number of contributors, development period of decades with a very decentralised management structure.

Emacs has a lot of problems but once you learn the base language, it's quite easy to interface with. I'd argue it's because of the limitations on structural complexity - you don't need to wrap your head around non-locally-defined structure in order to understand any one line. The parts that attempt to emulate OO tend to be a lot harder to deal with as an outsider.