> If you actually work on a project of significant size I don't see how one can reason about code that's not encapsulated via classes. I can: Modular code usin

> If you actually work on a project of significant size I don't see how one can reason about code that's not encapsulated via classes. I can: Modular code using modules, instead of shoe-horning everything into classes. There are way fewer cases, where classes have actual good reasons for existing in a program than people think. Classes should not be the first go-to solution for grouping things together. First one needs to think about behavior and state. Do I even have a state, that needs to live inside an object over the time, that the program runs? If I don't have state, no class. Done. Similarly for when I only have state and no behavior, that needs to be put together with that state. Often a module, which exports functions, which deal with that state, is more than sufficient and does not allow for inheritance nightmares. > I used to contribute to RunUO, an emulator for Ultima Online, and it's near the 1000000-SLOC level. There's too much going on, too much state, too many corner cases, to consider functional as an architecture. Sounds exactly like something, that should not be done in the typical OOP everything-calls-everything way, because then you will end up with lots of state changes mutation happening everywhere. It will not even be clear to the implementers of the system. Therefore you will not know what to test for and therefore it might run accidentally, but not in a way, that one can be approximately be sure to be correct. Every test of a complex scenario will require loads of setup test code, so that you can get some kind of environment, which might be similar to what happens in the system. Designing in a functional way would give you a sort of "entrypoint" at every function to test it, giving all required state as arguments. I don't think OOP is a given in any big project, especially, when looking at how to write unit tests for mostly everything, and when looking at parallelizing stuff. I see OOP perhaps when it comes to building GUIs, but even in that area attempts are being made to use declarative approaches and functional approaches, so maybe in the future we will see OOP lose ground there as well.