1. 15
  1. 4

    There would be more things for me to pick up about this post, but I have only few minutes so I have to choose one.

    The problem with OOP and SOLID principles the author promotes, is that they’re superstition. For SOLID, there are several unrelated conclusions and premises aren’t exactly clear or agreed upon. People who use these rules have to take them for belief, because there is no precise explanation why they work, or what the basis is for them to work in the first place.

    Relational model in other hand has some basis in logic. It’s in some manner minimal setting as well.

    I think OOP feels like you’d create a new abstract algebra for every possible data structure you work with. It’s bulky, slow and nonsensical. In meanwhile you also conflate the ideas with actors and processes, while all the time trying to pretend you gain something in the process.

    1. 6

      The problem with OOP and SOLID principles the author promotes, is that they’re superstition. For SOLID, there are several unrelated conclusions and premises aren’t exactly clear or agreed upon. People who use these rules have to take them for belief, because there is no precise explanation why they work, or what the basis is for them to work in the first place.

      If you trace the history of SOLID it was pretty much presented whole cloth by Bob Martin, and while he justified it as a synthesis of prior work SOLID is ultimately one man’s opinions on OOP that somehow became gospel.

      1. 4

        I mean there are some things in ‘SOLID’ that make decent sense. The ‘single responsibility principle’ is basically ‘do one thing and do it well’, the liskov substitution principle is really ‘what it means to be type-safe in a language with subtyping’ and I can’t remember the name of one of the others but don’t they basically come down to ‘program to well-defined interfaces’ and ‘separate policy and mechanism’?

        The problem is that they’re interpreted far too narrowly, in the context of ‘solving problems using OOP’, and they’re treated as some kind of gospel. Sometimes it’s okay to do two things. Sometimes it’s okay to put some policy in amongst mechanism. etc.

        1. 2

          In other words, it’s a synthesis of prior work, but the selection of principles is kind of arbitrary. Why should subtyping be in a list of abstract design goals that are supposed to be applicable to any programming language? Why isn’t “tell don’t ask” in there? There’s nothing about testing, either, or about the proper use of any of the Gang of Four patterns, except, for some reason, Dependency Injection.

      2. 3

        It’s really interesting that game development has its own self-contained software design method disputes and innovation.

        1. 14

          I would say that game development is probably the hardest mainstream development path. It includes the following mess of problems:

          • soft-realtime performance requirements
          • a need to generate tooling for people to build highly specific data for levels/scripting and whatnot
          • lack of control of the entire stack (both some messy middleware and things like peculiarities of consoles/different PC SKUs)
          • high coupling between subsystems, since generally you have this main game state and everything is touching that
          • requirements changing can mean ripping out entire subsystems. Hard to salvage certain kinds of work
          1. 6

            And:

            • hard deadlines, especially around December every year
            • cutthroat competition and market overcrowding
            1. 2

              Add to that:

              • very little control over the hardware used to run the software at the end of the day

              At least with consoles you know what the hardware will be, but you still can’t control it. But with PC games, you don’t even know what the hardware will be. So many other areas of software development just take a ‘throw more hardware at it’ approach to problem solving. In games, you just cannot do that. The end user’s computer is the end user’s computer. You’ve got access to what you’ve got access to. Nothing you can do about it.

              1. 1

                This is the reason why I feel that web frontend development is harder than backend development. When doing backend dev, I can actually choose (or at least influence the choice of) what machine the program will run on. :)

            2. 3

              A common pattern seems to be switching away from raw pointers into integer handles that index an array where objects are allocated. It’s gaining some traction in the Rust game development community as well.

              It would be interesting to see a detailed breakdown of pros and cons of that approach when compared to e.g. reference counted C++ smart pointers. I’ve seen someone scold it as “garbage collection from the 70’s” but they didn’t elaborate their critique further. At least with regular pointers reading from an invalid value (usually) produces an obvious crash instead of a silent failure you get with handles.

              1. 3

                A common pattern seems to be switching away from raw pointers into integer handles that index an array where objects are allocated.

                This has, as I understand it, been the standard in game development for decades at this point.

            3. 3

              Every pro-OOP discussion is always:

              • You are doing it wrong
              • Learn Object Oriented Design
              • Learn Design Patterns
              • Worship SOLID
              • Don’t overuse each everything (inheritance, composition, interfaces, OOP itself)

              Then is OOP really useful abstraction, if it requires studying of lots of tomes with vague language and vague conclusions? What tools you’ll get after reading all these works? You still have to use inheritance to model sum types. You praise “tell, don’t ask”, but your code is still full of getters because you just can’t figure out how to avoid this — no one can figure out.

              ECS is limited, arbitrary and not enough abstract, but I can use it right away, just like, for example, React, which is too, arbitrary and not enough abstract. But I can’t completely understand second part of this article and advices in it. ECS violates OOP and SOLID rules? C++ standard library (“STL”) violates them too, so what?

              virtual void update()? What correct signature should be for time-step update function? Why is it “anti-pattern”?

              OOP is computer religion, not computer science.

              1. 2

                This is the same thing with every pro-X discussion, where X is some way to program computers. “You’re doing it wrong” and “You’re not X-ing hard enough”

                1. 2

                  Cross out everything after the first comma.

                2. 2

                  virtual void update()? What correct signature should be for time-step update function? Why is it “anti-pattern”?

                  Because the author has worked on a bunch of game systems and found that ones which had that in them were difficult to work on because of it. They do actually talk about why, particularly in the comments on that article.