Design - DOD e COP

Criticisms of OOP

Abstraction

  • JBlow - Opinion on 'problems of OOP' .

    • "You are just shuffling papers in your desk, you are not solving anything".

  • Casey - Difficulties integrating something in OOP {4:23 -> 5:09} .

    • {4:23 -> 5:09}

      • "The claim that OOP makes integration easier is a lie", etc, etc.

      • (2025-03-11)

        • I 1000% agree with this phrase, integration is really very complicated when you consider that the interface in the program was made to handle only the single case described by the interface.

    • Casey says he really likes 'operator overloading'; "if the language doesn't have operator overloading, I'm not using it".

      • I have no opinion about that.

  • Casey and Primeagen - "what should be put inside a struct?" {51:44 -> 59:40} .

    • "You can have 2 reasons:"

      • It helps the CPU with performance.

      • It helps me be less confused and make fewer mistakes.

    • "Never make a structural decision based on what some book told you".

  • Casey and Primeagen - Criticisms of OOP and Clean Code .

  • Casey getting pissed at the use of Access Modifiers, Setters and Getters .

    • (2025-03-11)

      • I 100_000% agree with how ridiculously verbose the process is, BUT I believe the example he gave is somewhat unfair.

      • He makes the variable private but implemented public setters and getters; that sounds senseless.

      • I believe private accessors have a lot of value for debugging, when it comes to limiting who can modify something.

      • I still can understand his point and maybe there is some logic behind it like "it's simply not worth the security for the absurd work of having to write this kind of thing"?.

        • Casey didn't say that phrase, but maybe there is such a philosophy behind it? I can't say if the phrase makes sense, anyway.

      • Overall, I feel this is a problem the programming language could solve, instead of having to define setters and getters; which I consider ultra imbecilic and tedious.

Performance

DOD (Data-Oriented Design)

About

  • Think minimum to solve the problem.

  • Think outside of OOP.

  • Reduce the number of abstractions.

  • What is the minimum to do this? Ignore any notion of OOP.

    • Ignore Godot Nodes notions, just consider the minimum.

  • Don't make a generic engine or a generic game, make YOUR game.

    • Do not necessarily be flexible / generic. That causes problems. It slows production.

  • Philosophy :

    • "The only purpose of any code is to transform data".

    • "The programmer's job is not to write code, but to solve data transformation problems".

    • "Writing the code is the tool you use to do your job".

    • "Therefore, only write code that has direct, provable value, that transforms data in a meaningful way".

    • "To understand the data is to understand the problem".

  • Organize data for performance (minimizing cache misses).

  • ECS and DOD generally go together.

    • ECS organizes data into separate components.

    • DOD optimizes how that data is accessed for better performance.

  • Excellent explanation of DOD .

    • It explains:

      • CPU.

        • Registers.

        • L1.

        • L2.

        • L3.

        • Main Memory.

        • Disk

      • What a CPU cache miss is.

      • Cache Line.

  • DOD, by Mike Acton .

    • Mike Acton, Insomniac Games.

      • Prinicpal engineer of Unity engine.

      • He is reaaaally "rigid" and reaaaally aggressive about what he doesn't like, sometimes without elaborating much, or not being able to see the value in other things and other strategies.

      • "Anyone who wants to say 'premature optimization' can leave the room. That's the most abused quote of all time.".

      • {01:22:20} As shown here, "if the algorithm changes, the data changes and the code has to change". This left the questioner very frustrated, showing how absurdly inflexible Mike's design is.

      • "Why use C++ and not C?" "It's just a cultural choice, but if I had to choose I would use C 99".

    • {00:00 -> 28:30}

      • Very strict definition of what DOD is.

        • "Nothing here is necessarily new, it's just a reminder of important things".

        • He hates OOP, because OOP has a mentality that distances the problem from the Hardware and real problems, while valuing a set of abstract ideas and "metaphors" that move away from the real problem.

    • {28:30 -> }

      • "Can the compiler do it?"

      • "The compiler is a tool, not a magic wand".

  • Advanced explanation of DOD, by Andrew Kelley .

    • Andrew Kelley, creator of Zig.

    • Ideally watch the video above to better understand this one.

    • .

    • .

    • It only talks about 'memory footprint' (alignment, size).

      • .

    • After that it talks about a case study with the Zig Compiler

  • DoD and SOA in JAI, by Jonathan Blow .

    • {00:00 -> 47:40}.

      • He uses data composition, instead of inheritance, via the use of using  in procedures and structs to bring the contents of an object into scope.

        • The object has another object inside it, instead of the second object inheriting the first object.

    • {47:40 -> end}.

      • Demonstration of SOAs in JAI, via the keyword SOA .

      • A vector can be SOA , a struct can be SOA  via :: struct SOA { //etc }

  • Advice for programmers, by Mike Action .

    • It's a good video, with several useful tips.

    • The video is in Iran.

    • Commenting on the 'bad advice' given by people on Quora when asking "What are the most important programming concepts?"

    • I found it quite interesting and valuable.

    • Problems programmers normally have.

    • Learn to practice.

    • Have problem solving defaults established.

    • Problem solving targeted at the problem you actually have.

    • {29:24} Don't do something so generic, thinking about being absolutely flexible or future proof.

  • Problems with OOP, with Tony Albrencht .

    • The subject is somewhat repeated with other videos, but the video is ok.

    • Sony, Riot Games.

      • The last question in the video talks about LoL, but superficially, the rest is just about DOD.

    • Memory access has grown very slowly and became the bottleneck, so the CPU L1, L2 cache are super valuable.

    • Profiling finds the slow cases and it is noticed that it was due to cache misses.

    • {44:00} "Is OO bad?"

      • Logic/Function vs Data.

      • Data is the most realistic.

      • "OO used without care can produce slow, complex, unmaintainable and unoptimizable code".

  • Interview with Mike Acton .

    • Overall, the video is not worth it, nothing very useful.

    • Topics:

      • Team.

      • "The best solution is the one that works for your problem, with the least amount of abstraction".

      • Kinematics.

      • File format documentation.

      • Practice, etc.

  • Assembly Language is simpler than React / The problem of 30 million lines of code .

    • Only from {38:20}.

    • It's a very good video, from what I watched.

    • The problem of 30 million lines is based on:

      • Huge security problems due to extreme complexity of OS, Hardware APIs, etc.

      • Innovation problems because "it is extremely unlikely that any new operating system will be released that is purely not a fork of Linux, or a Mac mod, or something obtained by leaks from Microsoft".

    • Very interesting.

Existential Processing

  • Complexity ,

    • It is said to be measured via the number of control flows in your code.

  • Part of the DoD philosophy is to reduce this.

COP (Compression-Oriented Programming)

About

  • "COP is not a formal paradigm, but a set of principles that can be applied to any programming style to create more efficient and organized systems."

  • Casey - Explanation of COP .

    • Make your code usable before you try to make it reusable.

    • Starting with the details and repeatedly compressing to arrive at the eventual architecture avoids all the pitfalls of trying to conceive the architecture ahead of time.

    • "This is the correct way to give birth to “objects”. We made a real, usable bundle of code and data: the Panel_Layout structure and its member functions. It does exactly what we want, it fits perfectly, it’s really easy to use, it was trivial to design."

    • But if you just forget all that, and write simple code, you can always create your objects after the fact and you will find that they are exactly what you wanted.

    • I spend exactly zero time thinking about “objects” or what goes where.

    • The fallacy of “object-oriented programming” is exactly that: that code is at all “object-oriented”. It isn’t.

    • Code is procedurally oriented, and the “objects” are simply constructs that arise that allow procedures to be reused .

    • if you just let that happen instead of trying to force everything to work backwards, programming becomes immensely more pleasant.

    • After reading :

      • Very nice, it's a very good article.

      • The way he designed the UI example architecture reminded me A LOT of how Blender's API works, at least the layout construction part.

  • Casey - Tips to move from OOP to DOD / COP .

Philosophies

  • Finishing your software .

    • (2025-07-24)

    • The video is very good, I liked it a lot.

    • The video ends at 39:00.

    • ABI: Application Binary Interface.

    • About Eskil Steenberg:

      • C89. He is part of the C committee. He votes no on CY.

      • He doesn't like macros.

      • He doesn't use version control (git).

        • "Do you do backups? Sometimes, it happens".

        • "Never gave me anything".

        • Oh geez.

      • For Visual Studio.

      • The way he organizes functions is bizarre.

      • Never used OOP.