Case against OOP is understated, not overstated (2020)
I don&#x27;t quite understand what this is trying to say. It&#x27;s a summary review of some reviews? Or something. It&#x27;s not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It&#x27;s peppered with sentences like:<p><i>&quot;That you don&#x27;t understand something doesn&#x27;t mean it&#x27;s flawed or bad.&quot;</i><p>Precisely. Many of the arguments against OO are from academics that don&#x27;t write real-world, large-scale software.<p>More arguments are from <i>beginner</i> programmers with a mere 2-5 years of experience that have never personally encountered the mess that programming <i>at scale</i> was before OO made it <i>manageable</i>.<p>Even more arguments are from people that assume that &quot;precisely what language X happens to do&quot; is exactly what OO is or isn&#x27;t, and then argues from that straw man position.<p>Those same people then cheerfully embrace microservice or K8s, even though they are object-oriented! In case this is not clear, let me define OO for you:<p><i>&quot;Object oriented design is all about encapsulated private state with abstract interfaces that have varying implementations that clients don&#x27;t need to know the specifics of -- even the type names -- ahead of time.&quot;</i><p>Sounds like microservices? Or K8s? Or REST? Or service bus? Or event streams? Or <i>any</i> large-scale programming pattern? Yes. That&#x27;s because abstract interfaces and decoupled components are critical to enabling large teams to collaborate on software too big to hold in the head of any one person.<p>OO is not intended to solve manager-human-employee-customer categorisations of real-world entities. That&#x27;s a stupid straw-man argument born of toy textbook examples that aren&#x27;t representative of real-world programs to begin with.<p>OO is intended to allow programming at the scale where simple procedural programming no longer works. I didn&#x27;t understand the need for OO either until I worked at that scale myself. It seemed overcomplicated and unnecessary.<p>This is why it cracks me up to see language designers (and random Internet bloggers) talk about how &quot;they don&#x27;t need OO&quot;. Yes... <i>you</i>. Singular. One person doesn&#x27;t ever need OO. Many people do. You&#x27;re not many people!<p>Has anyone seen <i>large scale</i> development done successfully in an an &quot;anti-OO&quot; language like Rust? I haven&#x27;t. The single largest codebase is probably Mozilla&#x27;s Servo, which is still a toy compared to what&#x27;s been written in C++ or Java! It was written by a few people, mostly in one building. Notably development of it slowed down and was abandoned. It was never shipped as intended.<p>How would you even envision a Rust project working with, say, 1000 developers? What happens when there&#x27;s some new functionality added? Does developer #587 have to go notify the other 999 developers to update their switch statements, pattern matching code, etc... ?<p>Right now... generally speaking, yes. You&#x27;d have to go tell other people to go update their code. As you can imagine, 1000 developers telling 1000 developers to update things is a 1M-level organisational scaling problem.<p>That&#x27;s why <i>automated tooling</i> was invented to handle this problem automatically, even at <i>runtime</i>, let alone compile time.<p>If you think automation is bad, then we no longer agree on the most basic concepts and this conversation is over.<p>If you have a <i>better</i> method for automating this problem, then I&#x27;d love to hear about it! Just make sure it&#x27;s not OO with a different name...