Programming

This is something that’s difficult to demonstrate with small toy examples, which gives OOP languages an unfair disadvantage.

This is well said. It's such a frustrating meme when I see people talk about how many lines a "hello world" application needs as if that's the benchmark of what makes a language good.

This is something often repeated by OOP people but that doesn't actually hold up in practice. Maintainability comes from true separation of concerns, which OOP is really bad at because it encourages implicit, invisible, stateful manipulation across disparate parts of a codebase.

I work on a Haskell codebase in production of half a million lines of Haskell supported by 11 developers including myself, and the codebase is rapidly expanding with new features. This would be incredibly difficult in an OOP language. It's very challenging to read unfamiliar code in an OOP language and quickly understand what it's doing; there's so much implicit behavior that you have to track down before any of it makes sense. It is far, far easier to reason about a program when the bulk of it is comprised of pure functions taking in some input and producing some output. There's a reason that pure functions are the textbook example of testable code, and that reason is because they are much easier to understand. Code that's easier to understand is code that's easier to maintain.

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?