3 ms·
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 o
by AQXt 6y ago
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 6y agoI'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 6y agoFor 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.