1. 14

Uses a Go project as an example but not really Go-specific.

  1.  

  2. 11

    What I found interesting about this is that I agree with the general idea that OOP is not a great paradigm. However that seems to be about the only thing the author and I agree on. He thinks small files with larger functions are good, I prefer lots of small functions. He puts all of his types into one module, I like each module to represent a type.

    But for those who don’t want to watch the whole thing, here are the highlights from my perspective (some of which I agree with and some of which I don’t):

    • He uses interfaces to implement sum types, where he has an empty interface and then switches on the type.
    • He argues strongly for only putting things in classes that make sense from a data modeling perspective. Specifically, there are a few places in the code where a data structure points to the data structure that contains it. He thinks this is because the author didn’t want to pass the values as separate parameters to functions, but the author of the video thinks you should prefer parameters to functions in these cases.
    • He thinks that many short functions add a cognitive load to a reader of code that is unnecessary and prefers to make larger functions, inlining more code. He inlines almost all functions that are called only once.
    • His code is the same number of lines as the code he is modifying, so his argument is not about one style being shorter than the other but about how understandable the resulting code is.
    1. 9

      Nicely summarized. I also vehemently disagree with his assertion about short methods. Long methods are much harder to reason about.

      1. [Comment removed by author]

        1. 4

          As with so many things around code clarity and readability, there’s a lot of personal preference in this discussion, so I respect your preference.

          However I have found that breaking super long methods down pretty much always makes code more readable to me at least, but then it’s possible that I haven’t had to solve problems like you have and maybe those demand longer functions, I dunno.

          1. 4

            One large differentiator for me is cyclomatic complexity (though I rarely formally measure it).

            If it takes a hundred lines of code to read out the NES registers and map them into OpenGL, fine, there’s just a lot of state moving around. But if a function is long because there’s a dozen loops and ifs, I want smaller functions because of the combinatorial explosion of test cases for comprehensive coverage.

      2. 2

        I think his point about logic being scattered about lots of small files being hard to follow is legitimate. The key is to know when it is appropriate to group logic together and when it is appropriate to split it up.

        Also i would add that an emulator is not going to shrink much not matter how you write it, because most of the code is a straight forward translation of cpu instructions and memory mapping, not convoluted business logic.

      3. 6

        So let me get this straight, the author is claiming that OO is garbage because this NES emulator author didn’t factor his classes very well?

        And after all this ranting and roaring the KLOC in the project didn’t go down at all?

        To me this is a classic case of a tool being used poorly being confused for a tool being generally ineffective.

        1. 5

          I think your response is unjustly flippant.

          So let me get this straight, the author is claiming that OO is garbage because this NES emulator author didn’t factor his classes very well?

          This argument can be used every single time, so I don’t think it’s a really valuable response. A counter argument would be to fix the code the author started with and seeing how it matches up.

          And after all this ranting and roaring the KLOC in the project didn’t go down at all?

          The author never argued that it reduces sourcecode lines, but rather that it’s more understandable.

          To me this is a classic case of a tool being used poorly being confused for a tool being generally ineffective.

          This argument can, and is, always used as rebuttal. The author is at least taking existing code and refactoring it. I think that an OO-defender would need to fix the code to be what they think is good OO or judge the two pieces code based on their existing merit, not their potential.

          1. 5

            I don’t disagree that my tone was flippant, and I do appreciate the time and effort the author put into his critique.

            I can also appreciate the arguments about OO being an imperfect paradigm. Using it well requires a fair bit of discipline, and it’s very easy to go off the rails.

            So I take your point and thanks for making it. I learned the principles of OO programming very early in my career and I suppose there’s some defensiveness there which isn’t helpful.

        2. -5

          No one is going to watch an hour long video…

          1. 2

            They are. But I do wish this sort of thing was in a blog post with code examples and an embedded/linked video.

            1. 1

              I watched it.