<story><title>OO in Python is mostly pointless</title><url>https://leontrolski.github.io/mostly-pointless.html</url></story><parent_chain><item><author>throwaway894345</author><text>&amp;gt; The same is true of functional and procedural programming, too.&lt;p&gt;There are some specific criticisms that are levied against FP for which proponents respond “that’s not true FP”. For example, the criticism “FP is too preoccupied with monads” might engender such a response; however, this response is appropriate because it’s not one of the defining features of FP. Yet for FP, there are still pretty widely-agreed upon features or conventions (functional composition, strong preference for immutability, etc).&lt;p&gt;For OOP, I can’t think of any features or styles that are widely agreed upon. If you mention inheritance, half of OOP proponents will argue that inheritance isn’t a defining characteristic because Kay didn’t mention it in his definition. If you mention message-passing, many others will object. If you mention encapsulation, then you’ve accidentally included virtually all mainstream paradigms.&lt;p&gt;If OOP is a distinct thing, and it isn’t about inheritance or message passing or encapsulation or gratuitous references between objects (the gorilla&amp;#x2F;banana&amp;#x2F;jungle problem), then what exactly &lt;i&gt;is&lt;/i&gt; it?</text></item><item><author>mumblemumble</author><text>&amp;gt; This argument seems to come up for every criticism of OO.&lt;p&gt;The same is true of functional and procedural programming, too.&lt;p&gt;The problem, as I see it, is that the profession has a history of treating programming paradigms as just being a bag of features. They&amp;#x27;re not just that, they&amp;#x27;re also sets of guiding principles. And, while there&amp;#x27;s something to be said for knowing when to judiciously break rules, blithely failing to follow a paradigm&amp;#x27;s principles is indeed doing it badly.&lt;p&gt;This is a particular problem for OO and procedural programming. At least as of this current renaissance that FP is enjoying, advocates seem to be doing a much better job of presenting functional programming as being an actual software design paradigm.&lt;p&gt;It&amp;#x27;s also the case that, frankly, a lot of influential thought leadership in object-oriented programming popularized some awful ideas whose lack of merit is only beginning to be widely recognized. If null is a billion dollar mistake, then the Java Bean, for example, is at least a $500M one.</text></item><item><author>throwaway894345</author><text>&amp;gt; It’s not bad because it’s OO, but that it’s very badly done OO&lt;p&gt;This argument seems to come up for every criticism of OO. The criticism is invalid because &lt;i&gt;true&lt;/i&gt; OO would never do that. It seems like a No True Scotsman. Notably, when you whittle away all of the things that aren’t &lt;i&gt;true&lt;/i&gt; OOP, you seem to be left with something that looks functional or data-oriented (something like idiomatic Go or Rust). There isn’t much remaining that might characterize it as a distinct paradigm.</text></item><item><author>benkuhn</author><text>The author’s OO example is hard to understand, but they’re wrong about why. It’s not bad because it’s OO, but that it’s very badly done OO: the class couples two different concerns (network API client and database). That’s why it makes more sense as a bag of functions.&lt;p&gt;The general version of the point doesn’t work very well, and many of the other OO use-cases the author discusses actually work much better than alternatives.&lt;p&gt;For example, on abstract base classes: if you replace this with a bag of functions I think you end up reinventing virtual dispatch—that is, each function’s top level is a bunch of `if isinstance(...)` branches. This is much harder to read, and harder to add new implementations to, than abstract methods. It’s also no easier to understand.&lt;p&gt;(There is a subset of this advice that I think does improve your code’s understandability, which is “only ever override abstract methods,” but that is very different from “don’t use OO.”)&lt;p&gt;For impure classes, the author suggests e.g. using `responses` (an HTTP-level mocking library) instead of encapsulating these behind an interface. This is a fine pattern for simple stuff, but it is &lt;i&gt;not&lt;/i&gt; more understandable than a fake interface. The hand-written fake HTTP responses you end up having to write are a lot less readable than a mock implementation of a purpose-built Python interface. (Source: I once mocked a lot of XML-RPC APIs with `responses` before I knew better; it was not understandable.)</text></item></parent_chain><comment><author>josephg</author><text>The term may be muddied but it’s not meaningless. Alan Kay’s vision of OO (“it’s about message passing”) never seemed to really take off in the world. When people talk about OO they usually mean classes, objects and methods, used for almost everything as the primary unit of composition. And classes with public methods encapsulating private fields. And often with a dash of inheritance. C++ and Java seem like the flag bearers for this style of programming. It’s popular in C# too.&lt;p&gt;When people criticise OO, they’re usually criticising this the “Effective Java” style, expressed in whatever language. This style is deserving of some criticism - it’s usually more verbose and harder to debug than pure functional code. And it’s usually less performant than the data oriented &amp;#x2F; data flow programming style you see in most modern game engines.</text></comment>
<story><title>OO in Python is mostly pointless</title><url>https://leontrolski.github.io/mostly-pointless.html</url></story><parent_chain><item><author>throwaway894345</author><text>&amp;gt; The same is true of functional and procedural programming, too.&lt;p&gt;There are some specific criticisms that are levied against FP for which proponents respond “that’s not true FP”. For example, the criticism “FP is too preoccupied with monads” might engender such a response; however, this response is appropriate because it’s not one of the defining features of FP. Yet for FP, there are still pretty widely-agreed upon features or conventions (functional composition, strong preference for immutability, etc).&lt;p&gt;For OOP, I can’t think of any features or styles that are widely agreed upon. If you mention inheritance, half of OOP proponents will argue that inheritance isn’t a defining characteristic because Kay didn’t mention it in his definition. If you mention message-passing, many others will object. If you mention encapsulation, then you’ve accidentally included virtually all mainstream paradigms.&lt;p&gt;If OOP is a distinct thing, and it isn’t about inheritance or message passing or encapsulation or gratuitous references between objects (the gorilla&amp;#x2F;banana&amp;#x2F;jungle problem), then what exactly &lt;i&gt;is&lt;/i&gt; it?</text></item><item><author>mumblemumble</author><text>&amp;gt; This argument seems to come up for every criticism of OO.&lt;p&gt;The same is true of functional and procedural programming, too.&lt;p&gt;The problem, as I see it, is that the profession has a history of treating programming paradigms as just being a bag of features. They&amp;#x27;re not just that, they&amp;#x27;re also sets of guiding principles. And, while there&amp;#x27;s something to be said for knowing when to judiciously break rules, blithely failing to follow a paradigm&amp;#x27;s principles is indeed doing it badly.&lt;p&gt;This is a particular problem for OO and procedural programming. At least as of this current renaissance that FP is enjoying, advocates seem to be doing a much better job of presenting functional programming as being an actual software design paradigm.&lt;p&gt;It&amp;#x27;s also the case that, frankly, a lot of influential thought leadership in object-oriented programming popularized some awful ideas whose lack of merit is only beginning to be widely recognized. If null is a billion dollar mistake, then the Java Bean, for example, is at least a $500M one.</text></item><item><author>throwaway894345</author><text>&amp;gt; It’s not bad because it’s OO, but that it’s very badly done OO&lt;p&gt;This argument seems to come up for every criticism of OO. The criticism is invalid because &lt;i&gt;true&lt;/i&gt; OO would never do that. It seems like a No True Scotsman. Notably, when you whittle away all of the things that aren’t &lt;i&gt;true&lt;/i&gt; OOP, you seem to be left with something that looks functional or data-oriented (something like idiomatic Go or Rust). There isn’t much remaining that might characterize it as a distinct paradigm.</text></item><item><author>benkuhn</author><text>The author’s OO example is hard to understand, but they’re wrong about why. It’s not bad because it’s OO, but that it’s very badly done OO: the class couples two different concerns (network API client and database). That’s why it makes more sense as a bag of functions.&lt;p&gt;The general version of the point doesn’t work very well, and many of the other OO use-cases the author discusses actually work much better than alternatives.&lt;p&gt;For example, on abstract base classes: if you replace this with a bag of functions I think you end up reinventing virtual dispatch—that is, each function’s top level is a bunch of `if isinstance(...)` branches. This is much harder to read, and harder to add new implementations to, than abstract methods. It’s also no easier to understand.&lt;p&gt;(There is a subset of this advice that I think does improve your code’s understandability, which is “only ever override abstract methods,” but that is very different from “don’t use OO.”)&lt;p&gt;For impure classes, the author suggests e.g. using `responses` (an HTTP-level mocking library) instead of encapsulating these behind an interface. This is a fine pattern for simple stuff, but it is &lt;i&gt;not&lt;/i&gt; more understandable than a fake interface. The hand-written fake HTTP responses you end up having to write are a lot less readable than a mock implementation of a purpose-built Python interface. (Source: I once mocked a lot of XML-RPC APIs with `responses` before I knew better; it was not understandable.)</text></item></parent_chain><comment><author>mumblemumble</author><text>So, that&amp;#x27;s still focusing on features. If we&amp;#x27;re talking about it from a paradigmatic perspective, instead, then I would argue that the prototypical idea behind object-oriented design is indeed encapsulation.&lt;p&gt;It&amp;#x27;s true that this is not a distinguishing feature. I don&amp;#x27;t see that as problematic, it&amp;#x27;s just how things work. Object-oriented programming, like any paradigm, evolved over time, as people built languages with new ideas, and then spent time figuring out how best to make use of them. And there&amp;#x27;s no rule saying that nobody is allowed to subsequently adopt and adapt a useful idea in other domains. Fuzzy boundaries are part of the natural order, and that is a good thing.&lt;p&gt;But, if you go back and read the seminal papers, it&amp;#x27;s clear that the common thread is encapsulation, every bit as much as referential transparency is the core idea that unites all the seminal work in functional programming. The idea was that programs would be decomposed into modules that were empowered to make their own decisions about what code to execute in response to some instruction. And that this was supposed to liberate the programmer from needing to micro-manage a bunch of state manipulation. Not by eliminating state, as is the ideal in FP, but by delegating the responsibility to manage it.&lt;p&gt;This is why the concept of Beans bothers me. A Bean is a stateful object that throws its state into your face, and forces you to directly manage it. That sort of approach directly contradicts what OOP was originally supposed to be trying to accomplish. For my part, I am convinced that the bulk of the backlash against OOP is really a response to the consequences of that sort of approach having become orthodox in OOP. Which is deeply ironic, because this is an approach that enshrines the very kinds of practices that the paradigm originally sought to eliminate.</text></comment>