8 ms·

I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. He always has a

I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. He always has a lot of interesting things to say, but it also kinda reads like a C guy trying to code in C++. I'm glad his thinking keeps evolving and he's not dogmatic about anything. I'd honestly love to hear his thoughts on C++11 "The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it." That's the equivalent of saying "the faster you drive the safer you are b/c you're spending less time in danger" You'll just end up with larger monster functions that are harder to manage. "Method C" will always be a disaster for code organization b/c your commented off "MinorFunctions" will start to bleed into each other when the interface isn't well defined. " For instance, having one check in the player think code for health <= 0 && !killed is almost certain to spawn less bugs than having KillPlayer() called in 20 different places" I don't completely get his example, but I see what he's saying about state and bugs that arise from that. You call a method 20 times and it has an non obvious assumption about state that can crop up at a later point - and it can be hard to track down. However the flip side is that when you do track it down, you will fix several bugs you didn't even know about. The alternative of rewriting or reengineering the same solution each time is simply awful and you'll screw up way more often

Guvante 12y ago
> The alternative of rewriting or reengineering the same solution each time is simply awful and you'll screw up way more often He might not have communicated it completely correctly, but I believe he wasn't advocating for getting rid of functions to reduce redundancy. He instead was advocating getting rid of functions that simply provide documentation of the process, and instead find a way to inline those functions clearly. > However the flip side is that when you do track it down, you will fix several bugs you didn't even know about. I think he is saying a class of bugs is avoided. For instance if I do X, Y and Z where all are only ran when the player is alive and Y might kill the player, leaving the player alive avoids a bug in Z if it assumes that the player is alive.
phkahler 12y ago
>> I don't completely get his example To use Minecraft as an example, a player may die from falling from too high, drowning, getting attacked by a monster. If killPlayer() is called serparately for each of those cases, he asserts that it may cause bugs due to differing context or sequencing relative to other parts of the code. If OTOH you just decrement player health in each of those places and then check for health<=0 at only one place, you eliminate that class of bugs.
- protonfish 12y ago
  I am working on the most close-to-finished computer game I have written yet, and I have a bug caused by this exact thing! (I am learning a lot about what not to do as I go.) I plan on refactoring it to the check-once-per-loop style this weekend.
- ranran876 12y ago
  That makes sense - though most of the time if a method call only makes sense give a particular state, it's generally set to be protected. You can still call it with the wrong state from within the same class, but I can't honestly think of a case of that happening in my work.. You generally are familiar with the workings of the class you are currently touching. If you aren't able to do that practically, then that generally means your class is simply too large.
archagon 12y ago
For some reason, a lot of older game/graphics programmers seem to feel the same way about OO programming. I don't know if it's force of habit or experience on their part, but I try to keep it in the back of my head nowadays.
phkahler 12y ago
>> I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. I'm starting to think object oriented programming is a bit over rated. It's hard to express why exactly, but I'm finding plain functions that operate on data can be clearer, less complicated, and more efficient than methods. Blasphemous as it may seem, a switch statement does the equivalent of simple polymorphism and can be kept inline.
- rgoddard 12y ago
  I agree. The simplicity comes from the fact that you are focusing on different aspects at different times. I find that I will start off with defining my data structure and only focusing on the data structure. What information do I need, what is the best way to organize the data. Those sorts of issues. Once I have the data structure then I focus on what I want to do with it. This may result in some functions attached to the data structure using the object oriented features and sometimes the functions live apart from the data structure. The benefit comes from mentally decoupling the data from the functions.
- pjmlp 12y ago
  As Wirth puts it, Algorithms + Data Structures = Programs What OOP nicely brings to the table is polymorphism and type extension. Two things not doable just with modules. Although generics help with static polymorphism. The problem was that the IT world went overboard with Java and C#, influenced by Smalltalk, Eiffel and other pure OO languages. Along the way, the world forgot about the other programming languages that offered both modules and objects. > Blasphemous as it may seem, a switch statement does the equivalent of simple polymorphism and can be kept inline. Except it is not extendable.
  - ufo 12y ago
    Switch statements are extensible in that you can add extra switch statements to your program without needing to go back and add a method to every class you coded, spread over a dozen different files. Its the old ExpressionProblem tradeoff.
hcarvalhoalves 12y ago
> "The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it." > That's the equivalent of saying "the faster you drive the safer you are b/c you're spending less time in danger" What I believe he means is that functions calls at different places can be a source of trouble when you're not side-effect free.
Strilanc 12y ago
A "multiple kill calls" bug is your typical unexpected violation of ever-mounting implicit ordering constraints. For example, you might write: while true: ... if (!wasDead && dead) startFadeOut() ... wasDead = dead doPhysics() and then months later someone adds fall damage to the physics engine, and suddenly there's a way to die where the screen doesn't fade out.
- Tossrock 12y ago
  Wait, like, Power Towers Strilanc? I love your work :) In fact I think I did a competition with some friends to get a high score in the map credits for a while...
  - Strilanc 12y ago
    Story checks out [1]. Yeah, that's me. Wc3 mapping was fun times for sure. 1: https://github.com/Strilanc/Wc3PowerTowers/blob/3b93a83cf63f8afa135ee07178b4111bc32af842/script/Information/Challenges.jass#L143 https://github.com/Strilanc/Wc3PowerTowers/blob/3b93a83cf63f...
    - Tossrock 12y ago
      Pretty crazy, all the things the WC3 scene produced. Like, multimillion dollar gaming sub-genres (tower defense, MOBAs, etc). Glad to see you're still making games!
dkarl 12y ago
I have found myself writing "Method C" code in cases where factoring the code into methods obscures rather than simplifies. I think Carmack sums up the reason pretty well: "The whole point of modularity is to hide details, while I am advocating increased awareness of details." I ask myself, can I factor methods out of this code (a la Method A or Method B) in such a way that the code can be understood without reading the implementations of the smaller methods? If not, then the complexity is in a sense irreducible, and splitting the code into chunks just forces other people (and eventually myself) to jump around and try to knit the pieces together mentally, when it would actually be easier to read the code in one piece. Another way to put it is that Method C is the least bad solution when factoring fails. I had a conflict with a coworker several months ago over a difficult piece of functionality that I had implemented Method C style. It was giving him headaches and he complained incessantly about the fact that the code was written in a linear "non-factored" style. I tried to explain to him that the problem was simply that hard, and the code organization wasn't making it worse, but was rather making the best of a bad situation. (Basically, if he thought the code was hard to understand, then he obviously hadn't tried to understand the problem it was solving!) He ignored me and refactored the code Method B style. A month later he was still struggling (because it was a truly complex problem) and he called me over to help him out. The code was now unfamiliar to me, so I'd point at a method call and say, "What does this method do?" "Uh... let's see. <click>" "What does that method it's calling do?" "Hold on. <click>" And so on, all the way down the call chain. The refactored code had become "easy to read" in the sense that the methods were short, but it also become impossible to read in the sense that reading a method didn't give you any useful information unless you went on to read all the code in all the methods it called. We ended up reading the code exactly as we would have read Method C code, except with a lot of clicking and no visual continuity or context. Abstraction didn't protect us from the details; it just made it harder to see how they fit together into the whole.
imanaccount247 12y ago
>I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. I get the impression that he understands it quite well, which is why he avoids it.
kragen 12y ago
> whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming Can you share a bit about your background here? In the absence of more context, to me, this reads sort of like a guy who plays football on weekends saying that Lionel Messi "doesn't really get" football.

Guvante 12y ago

> The alternative of rewriting or reengineering the same solution each time is simply awful and you'll screw up way more often He might not have communicated it completely correctly, but I believe he wasn't advocating for getting rid of functions to reduce redundancy. He instead was advocating getting rid of functions that simply provide documentation of the process, and instead find a way to inline those functions clearly. > However the flip side is that when you do track it down, you will fix several bugs you didn't even know about. I think he is saying a class of bugs is avoided. For instance if I do X, Y and Z where all are only ran when the player is alive and Y might kill the player, leaving the player alive avoids a bug in Z if it assumes that the player is alive.

phkahler 12y ago

>> I don't completely get his example To use Minecraft as an example, a player may die from falling from too high, drowning, getting attacked by a monster. If killPlayer() is called serparately for each of those cases, he asserts that it may cause bugs due to differing context or sequencing relative to other parts of the code. If OTOH you just decrement player health in each of those places and then check for health<=0 at only one place, you eliminate that class of bugs.

protonfish 12y ago
I am working on the most close-to-finished computer game I have written yet, and I have a bug caused by this exact thing! (I am learning a lot about what not to do as I go.) I plan on refactoring it to the check-once-per-loop style this weekend.
ranran876 12y ago
That makes sense - though most of the time if a method call only makes sense give a particular state, it's generally set to be protected. You can still call it with the wrong state from within the same class, but I can't honestly think of a case of that happening in my work.. You generally are familiar with the workings of the class you are currently touching. If you aren't able to do that practically, then that generally means your class is simply too large.

archagon 12y ago

For some reason, a lot of older game/graphics programmers seem to feel the same way about OO programming. I don't know if it's force of habit or experience on their part, but I try to keep it in the back of my head nowadays.

phkahler 12y ago

>> I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. I'm starting to think object oriented programming is a bit over rated. It's hard to express why exactly, but I'm finding plain functions that operate on data can be clearer, less complicated, and more efficient than methods. Blasphemous as it may seem, a switch statement does the equivalent of simple polymorphism and can be kept inline.

rgoddard 12y ago
I agree. The simplicity comes from the fact that you are focusing on different aspects at different times. I find that I will start off with defining my data structure and only focusing on the data structure. What information do I need, what is the best way to organize the data. Those sorts of issues. Once I have the data structure then I focus on what I want to do with it. This may result in some functions attached to the data structure using the object oriented features and sometimes the functions live apart from the data structure. The benefit comes from mentally decoupling the data from the functions.
pjmlp 12y ago
As Wirth puts it, Algorithms + Data Structures = Programs What OOP nicely brings to the table is polymorphism and type extension. Two things not doable just with modules. Although generics help with static polymorphism. The problem was that the IT world went overboard with Java and C#, influenced by Smalltalk, Eiffel and other pure OO languages. Along the way, the world forgot about the other programming languages that offered both modules and objects. > Blasphemous as it may seem, a switch statement does the equivalent of simple polymorphism and can be kept inline. Except it is not extendable.
- ufo 12y ago
  Switch statements are extensible in that you can add extra switch statements to your program without needing to go back and add a method to every class you coded, spread over a dozen different files. Its the old ExpressionProblem tradeoff.

hcarvalhoalves 12y ago

> "The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it." > That's the equivalent of saying "the faster you drive the safer you are b/c you're spending less time in danger" What I believe he means is that functions calls at different places can be a source of trouble when you're not side-effect free.

Strilanc 12y ago

A "multiple kill calls" bug is your typical unexpected violation of ever-mounting implicit ordering constraints. For example, you might write: while true: ... if (!wasDead && dead) startFadeOut() ... wasDead = dead doPhysics() and then months later someone adds fall damage to the physics engine, and suddenly there's a way to die where the screen doesn't fade out.

Tossrock 12y ago
Wait, like, Power Towers Strilanc? I love your work :) In fact I think I did a competition with some friends to get a high score in the map credits for a while...
- Strilanc 12y ago
  Story checks out [1]. Yeah, that's me. Wc3 mapping was fun times for sure. 1: https://github.com/Strilanc/Wc3PowerTowers/blob/3b93a83cf63f8afa135ee07178b4111bc32af842/script/Information/Challenges.jass#L143 https://github.com/Strilanc/Wc3PowerTowers/blob/3b93a83cf63f...
  - Tossrock 12y ago
    Pretty crazy, all the things the WC3 scene produced. Like, multimillion dollar gaming sub-genres (tower defense, MOBAs, etc). Glad to see you're still making games!

dkarl 12y ago

I have found myself writing "Method C" code in cases where factoring the code into methods obscures rather than simplifies. I think Carmack sums up the reason pretty well: "The whole point of modularity is to hide details, while I am advocating increased awareness of details." I ask myself, can I factor methods out of this code (a la Method A or Method B) in such a way that the code can be understood without reading the implementations of the smaller methods? If not, then the complexity is in a sense irreducible, and splitting the code into chunks just forces other people (and eventually myself) to jump around and try to knit the pieces together mentally, when it would actually be easier to read the code in one piece. Another way to put it is that Method C is the least bad solution when factoring fails. I had a conflict with a coworker several months ago over a difficult piece of functionality that I had implemented Method C style. It was giving him headaches and he complained incessantly about the fact that the code was written in a linear "non-factored" style. I tried to explain to him that the problem was simply that hard, and the code organization wasn't making it worse, but was rather making the best of a bad situation. (Basically, if he thought the code was hard to understand, then he obviously hadn't tried to understand the problem it was solving!) He ignored me and refactored the code Method B style. A month later he was still struggling (because it was a truly complex problem) and he called me over to help him out. The code was now unfamiliar to me, so I'd point at a method call and say, "What does this method do?" "Uh... let's see. <click>" "What does that method it's calling do?" "Hold on. <click>" And so on, all the way down the call chain. The refactored code had become "easy to read" in the sense that the methods were short, but it also become impossible to read in the sense that reading a method didn't give you any useful information unless you went on to read all the code in all the methods it called. We ended up reading the code exactly as we would have read Method C code, except with a lot of clicking and no visual continuity or context. Abstraction didn't protect us from the details; it just made it harder to see how they fit together into the whole.

imanaccount247 12y ago

>I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. I get the impression that he understands it quite well, which is why he avoids it.

kragen 12y ago

> whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming Can you share a bit about your background here? In the absence of more context, to me, this reads sort of like a guy who plays football on weekends saying that Lionel Messi "doesn't really get" football.