<story><title>Why OO Sucks by Joe Armstrong (2000)</title><url>http://harmful.cat-v.org/software/OO_programming/why_oo_sucks</url></story><parent_chain><item><author>3pt14159</author><text>I&amp;#x27;ve said this multiple times over multiple years and I&amp;#x27;ll say it again just because so many green developers get misled.&lt;p&gt;Object oriented programming is good. Not in absolutely every situation, but for most business applications it&amp;#x27;s better than the alternatives. The reason it&amp;#x27;s good is that it is productive. Objects map neatly to records, which pushes global state persistence and all the hairiness of locks to a good RDMS like Postgres. It&amp;#x27;s naturally normalized, but can be denormalized without much work, and in exchange for bundling state with functions you get easier introspection which is especially helpful in debugging.&lt;p&gt;These conversations are better done with examples. Say you want to build a social network around videos, like YouTube. Say a user can block another user and, thus, stop them from commenting on their videos.&lt;p&gt;Would you rather type out this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    user.blocked_by? other_user
&lt;/code&gt;&lt;/pre&gt;
Or this&lt;p&gt;&lt;pre&gt;&lt;code&gt;    is_blocked(user, other_user)
&lt;/code&gt;&lt;/pre&gt;
When doing the check? Personally, seeing the the is_blocked? method on a user makes it easy for me to understand. Who has blocked whom is more natural to talk about when there is a primary object subjecting the other object to a test. For all the anti-OO stuff out there, it all boils down to the same thing in the end. For business logic, your functions need to know so much about the data that they are operating on that it&amp;#x27;s pointless to try to avoid bundling the state. I&amp;#x27;m never going to pass a cheeseburger into my is_blocked function so why on earth would I avoid bundling state and operation together? It&amp;#x27;s like a map of a city trying to avoid listing shops since &amp;quot;maps should be about roads and geography, not shops.&amp;quot; A pointless dogma that doesn&amp;#x27;t actually help programs get built. Most successful startups use OOP and there is a clear reason for that: It&amp;#x27;s more productive.&lt;p&gt;Now, do I use OOP when I&amp;#x27;m doing data science stuff? Mostly no. I don&amp;#x27;t need it there. But where it works, it&amp;#x27;s magic.</text></item></parent_chain><comment><author>geocar</author><text>I&amp;#x27;m not sure I understand you.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    is_blocked(user, other_user)
&lt;/code&gt;&lt;/pre&gt;
seems like it’s still object-oriented to me. Oh sure it has terrible syntax, but we’re still designing our application with encapsulation and if this is CL and “is-blocked” is a generic then it’s how you would write this in an CLOS-style OOP — it would just be written (is-blocked user other-user)&lt;p&gt;On the other hand:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    other_user.id in user.blocks
&lt;/code&gt;&lt;/pre&gt;
is what I would imagine a non-OOP version might look like, because it’s not dynamic and not encapsulated. If we were to write it:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    in(other_user.id, user.blocks)
&lt;/code&gt;&lt;/pre&gt;
or:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    (in (other-user :id) (user :blocks))
&lt;/code&gt;&lt;/pre&gt;
I also still think these functions are better than the object-oriented ones: they’re faster, and it’s clear to the reader if you can get the ids without the object (say by pushing this into your query) you will save a lot of runtime and programmer-time.&lt;p&gt;I also think if you make decisions based on what is popular (e.g. for startups), instead of actually thinking about it, you &lt;i&gt;are&lt;/i&gt; subscribing to dogma. Maybe sometimes not-thinking is good, but it seems possible that what you think of as a “start up” has largely only existed in the short time period that object languages were in vogue. Why do you think this is causal? Do you think if go (for example) becomes popular we won’t have startups any more?</text></comment>
<story><title>Why OO Sucks by Joe Armstrong (2000)</title><url>http://harmful.cat-v.org/software/OO_programming/why_oo_sucks</url></story><parent_chain><item><author>3pt14159</author><text>I&amp;#x27;ve said this multiple times over multiple years and I&amp;#x27;ll say it again just because so many green developers get misled.&lt;p&gt;Object oriented programming is good. Not in absolutely every situation, but for most business applications it&amp;#x27;s better than the alternatives. The reason it&amp;#x27;s good is that it is productive. Objects map neatly to records, which pushes global state persistence and all the hairiness of locks to a good RDMS like Postgres. It&amp;#x27;s naturally normalized, but can be denormalized without much work, and in exchange for bundling state with functions you get easier introspection which is especially helpful in debugging.&lt;p&gt;These conversations are better done with examples. Say you want to build a social network around videos, like YouTube. Say a user can block another user and, thus, stop them from commenting on their videos.&lt;p&gt;Would you rather type out this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    user.blocked_by? other_user
&lt;/code&gt;&lt;/pre&gt;
Or this&lt;p&gt;&lt;pre&gt;&lt;code&gt;    is_blocked(user, other_user)
&lt;/code&gt;&lt;/pre&gt;
When doing the check? Personally, seeing the the is_blocked? method on a user makes it easy for me to understand. Who has blocked whom is more natural to talk about when there is a primary object subjecting the other object to a test. For all the anti-OO stuff out there, it all boils down to the same thing in the end. For business logic, your functions need to know so much about the data that they are operating on that it&amp;#x27;s pointless to try to avoid bundling the state. I&amp;#x27;m never going to pass a cheeseburger into my is_blocked function so why on earth would I avoid bundling state and operation together? It&amp;#x27;s like a map of a city trying to avoid listing shops since &amp;quot;maps should be about roads and geography, not shops.&amp;quot; A pointless dogma that doesn&amp;#x27;t actually help programs get built. Most successful startups use OOP and there is a clear reason for that: It&amp;#x27;s more productive.&lt;p&gt;Now, do I use OOP when I&amp;#x27;m doing data science stuff? Mostly no. I don&amp;#x27;t need it there. But where it works, it&amp;#x27;s magic.</text></item></parent_chain><comment><author>continuational</author><text>What you seem to like is infix syntax and overloading on the first argument.&lt;p&gt;I think this is really the most valuable part of OOP; it makes code read in the order that functions are applied, which is both natural and enables type driven autocompletion.&lt;p&gt;What bothers me about OOP is inheritance, subtyping and the emphasis on mutable state, which greatly complicate call chains, the type system and temporal reasoning.</text></comment>