Must OOP be shoved down everyone's throat at every turn and opportunity? One of the great things about Lisp is that it's a champion of functional programming, whereas OOP is extremely complicated and it produces truly horrible machine code which needs a lot of CPU cycles and even more memory, not to mention being unnecessarily difficult to understand and debug!
The nice thing about Common Lisp is, you have the choice, which style of programming you use. There is a lot of good things to be said about functional programming, but for a lot of problems, OOP is the natural pattern. And with Common Lisp, you can use both in the same program, depending on which pattern fits the best for that part of the program.
Mind you, I am not using OOP in that sense it has degenerated to in the Java universe. It is actually less the language itself but the culture of trying to express too much in object hierarchies and protocols.
I try to keep my object models simple, avoiding too much inheritance and complex class hierarchies. But it is a wonderful method of decoupling routines from heterogeneous data, which is well expressed as object with their methods implementing the common behavior.
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 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.
> 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.
> I can: Modular code using modules, instead of shoe-horning everything into classes
It's your lucky day then, as this is how CLOS programs are written. Methods are associated with generic functions, which are in turn associated with packages.
You should probably try writing something under a functional paradigm, emphasizing immutability and pure functions. You'll quickly see how that will help you reason about a large functional project.
Where does the "100% purely functional" requirement come from? By some strict definition, this is impossible, because you'd not have any means of communicating the result of your computation.
In pure OOP speak: A "final static" method is easier to reason about than some non-static, non-final method. (But when a method is defined as "final" and "static", the providing class only serves as a namespace - where is the OOP in that?)
