1. 24

  2. 7

    I disagree with his argument, but some of his premises seem right. I’m not the most experienced object oriented programmer, but my impression is that he’s right about why object oriented programming became successful. As he said, as it became easier to write code, people started writing too much of it, and it became difficult to manage the complexity. Object oriented programming is fundamentally a solution to a social problem, not a technical one.

    It seems like it’s a clever way to get people to namespace their code well. I think where I disagree with him is about whether that’s useful or not. I think naming things is hard, and even namespacing things is hard. Good object oriented programming typically keeps namespaces very, very small, which is useful because the technology stays manageable.

    1. 7

      The problem with OOP is that it’s always been kind of a “poor man’s mathematical abstraction”. Abstracting reality, wether processes, states or relations is a difficult task (ask any physicist or mathematician). Thus OOP offered the easy “cat inherits animal”, and seemed just right for many people-oriented problems. But as usual, when all you have is a hammer…. you end out with a lot of pitted abstractions.

      1. 3

        That is an insightful point about it incentivizing namespacing. I didn’t watch the video, so I don’t know whether it’s yours or the speaker’s, but that sounds exactly right.

      2. 6

        Object is “thing of which I have incomplete knowledge”. Often and more specifically, it defines something that we’re not going to interpret. For example, with Peano arithmetic, we have certain rules:

        • There exists an object called 0 of class (or type) Nat.
        • For every Nat x there is an object S x of class Nat.
        • … and so on (commutativity and associativity of addition, same for multiplication, identity properties).

        In this case, we don’t need to interpret the objects further. For arithmetic, 2 (or S (S 0) has all of the information that we need about it. It’s a legitimate object. (Preferably, your language has it being immutable; otherwise what you actually have is a cell containing a Nat, and then we get into instability of equality semantics, unless you use object equality, which is the right choice.) We don’t need more information about 2. We don’t care if some purist says that it’s “really” an equivalence class of sets under equal cardinality.

        The mess we get into with object-oriented programming is that, while the existence of interfaces (allowing one to work despite incomplete knowledge of, or concern with, internals) is often beneficial– it’d be painful to have to know the innards of one’s file system to do routine I/O– it makes poor infrastructure for objects to be one’s basic building block. It often means, in practice, that you intend to build infrastructure on items of squishy definition.

        For example, I’m learning Ruby right now because I’m helping some people set up a consulting business and they may need me to supervise some of their Rails work. (I’m not thrilled with the language yet; maybe I just haven’t gotten it.) I get that Ruby allows code to look pleasing by a certain aesthetic, but Ruby objects are just such an ill-defined mess. To be fair, few other languages have anything that I could put more trust in: Python’s objects can be monkey-patched and adorned with various flavors of weirdness, and Scala doesn’t make it hard to subvert the type system and go full-blown OOP either.

        I think that objects, like existentially-quantified types in a language like Haskell, have limited uses. They shouldn’t be thrown out entirely. However, I think that they make poor infrastructure, just as a Swiss Army Knife is a great tool but you wouldn’t use it as a brick, and time seems to be proving out the claim that an object-based language (as opposed to a language that offers objects as an occasional feature) is a bad idea.

        1. 5

          I think that objects, like existentially-quantified types in a language like Haskell, have limited uses. They shouldn’t be thrown out entirely. However, I think that they make poor infrastructure, just as a Swiss Army Knife is a great tool but you wouldn’t use it as a brick, and time seems to be proving out the claim that an object-based language (as opposed to a language that offers objects as an occasional feature) is a bad idea.

          I agree, I’ve written the below article on this. The gist of it is that runtime-subtyping is a feature that comes with a lot of baggage and is only really useful in a very few number of cases and can be pretty easily replicated in any language with records. My argument is that static subtyping gives all the same usescases most people actually want with much stronger guarantees. But it’s a difficult discussion to have with a many people because they don’t know other options exist and thus don’t have the option of feeling like OOP is a pain point.


          1. 4

            Thanks for that, it really helps to show how O'Caml functors work.

            1. 1

              Thank you, I’m glad you found it insightful!

          2. 4

            Standard thing here is to reference McLarty’s Numbers Can Be Just What They Have To.


          3. 1

            I agree with some of his points, but then he goes into a rant about large functions I quite can’t agree on. The “large function with commented sections” at the end (for those patient enough).

            Splitting large functions into smaller functions might not be necessary in his given example (typical of a setupThis, setupThat method). The intended functions of this refactor are those that have some kind of flow that encodes a “business rule”. His example has just a straight flow. In this case there’s not much difference between using some methods or some comment headers.

            The purpose of this kind of refactor is to clarify the business logic of the method so you can read it at a clear abstraction depth, without other concerns. E.g.

            if (amount < available) { // Remove amount from account
            // ... and some hundred lines...
            } else { // Transfer funds from secondary account 
            // ... some hundred lines more

            Which splits into:

            if (amount < available) {
            } else {

            Which is a clear spec of the intended purpose of the function or method.

            • Edited to make a valid point ;)
            1. 1

              I can buy some of this, I started as a kid before OOP really hit me.

              I wonder if this is why Go seems to be popular.

              It also occurs to me that procedural software ended up as bad as some of our bad oop code. In this light, this guy’s solution is simply another solution in a long long of solutions.

              1. 2

                FWIW Go is OO in every way that matters. This question usually comes up because it doesn’t use the common inheritance-based model of OO. Instead it has a different model which uses composition to achieve similar results. But either way you’re still programming with objects.

              2. 1

                Just a few points:
                Inheritance is optional (in C++ at least) in most cases. Composition, templates, function overloading on parameter type etc. are almost always prefered.

                Java is great for forcing what is essentially a namespace on every line of code. This compartmentalizes everything, greatly cleaning up the code. I wish C++ required every new line of code to be in a namespace. OO programming is generally neater than the alternatives.

                OO code doesn’t have to have a class keyword. You can program OO in C with raw structs and global functions such as person_set_address(person* p, const char* address). You can even add function pointers to you struct to implement virtual functions (I would just use C++ if possible though).

                1. -1

                  45 minutes video? 15000 views by programmers? thats 1.3 years of potential code output wasted IMHO, unless he’s discovered a major flam in OOP that will make everyone more effective. Why not a a bullet list of his main points? Time is the essence. You cant get those minutes back.

                  1. 4

                    That’s a logical fallacy. You’re pretending programmers spend all their time writing code. Most likely, for most of the people watching this, it replaced watching other videos without more value than this one, possibly while playing a game or doing other activities.

                    1. 0

                      Hello mort. I do not believe it is a logical fallacy to say the video form is ill-fitted to state an argument about programming paradigms. It is true to say that programmers do not spend all their time writing code, but would you agree that browsing lobste.rs would happen most likely during the time leading to (procrastinating?) to code output? I invite you to revisit your comment and mine in 10-15 years. Cheers, F

                      1. 0

                        I don’t have the kind of metrics which would be necessary to determine whether time on lobste.rs generally leads to programming or to procrastinating, but for myself, if I felt like programming, I would already be programming.

                        I don’t know if video form is so ill-fitted to state an argument about programming topics, but I don’t have strong opinions on that and won’t dispute it because it’s unrelated. I didn’t say it was a logical fallacy to say a video is a bad medium for it however; you’re attributing arguments I didn’t make to me. What I called a logical fallacy was how you calculated how much programming time was wasted from a lot of programmers watching that video, as that assumes all those programmers would otherwise be writing code, which is false.

                  2. -2

                    I completely disagreement with this vision of the life, black or white.