4 ms·

I broadly agree, but this article is really poorly written. It takes every downside of OOP to extremes which make it really hard to take the author seriously. Y

by mathw 7y ago

I broadly agree, but this article is really poorly written. It takes every downside of OOP to extremes which make it really hard to take the author seriously. Yes there are problems with mutable state, even if you think you've encapsulated it. Yes there are problems with dependencies, dependency injection and the associated boilerplate. Yes there are hideous issues with concurrency. I don't think OOP as we see it in most languages today is particularly helpful. I do increasingly feel that data structures and operations should not be muddled together, and the polymorphism strategy should be something more like Haskell's typeclasses/Rust's traits or Go's idea of interfaces. I'm also sure that using those for a few decades would show us plenty of things wrong, and lead to something else. We are still children in this world. There are no correct answers - but there are definitely some wrong ones, and the increasing realisation of that is evident in the popularity of languages like Go and Rust, and the development of C# is also interesting - increasingly new language features are FP features, not OOP features, and the language becomes increasingly hybrid. It will always be limited by being built on a fundamentally OO runtime, but it's interesting how things are changing.

0815test 7y ago
This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing. Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through. Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!

by mathw 7y ago

0815test 7y ago

This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing. Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through. Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!