I wanted to ask this question in day's 38 prestream but there was none (I blame Microsoft, for not making their taskbar easy to hide/ set as not topmost window), so I'll just ask here.
Do you think it would be beneficial for people, that are just learning to program to also dig into whole OOP culture and learn how programs are structured when using OOP? I know Casey and other programmers in game industry are opposed to what is usually called OOP (although that might be misinterpretation of original idea). But it seems to me, that to fully grasp why it is bad for high performance game development, you kinda have to know how it works and what are real disadvantages of it. Even Casey said that he used to write his code in OOP style for several years before being taught other way (data-oriented? I'm not sure). I'm not suggesting people should spend 3-4 years learning ins and outs of C++ OOP style and all it's new exciting features from 2011/2014 spec, but maybe writing at least one project that way might help you to understand why it's probably not the best idea.
Also if you ever end up in company that has whole codebase in OOP style and you have to comply, it sure would be handy to be able to jump right in. What are your thoughts guys? What I would do is, study OOP and the practices that usually come with it, and learn how to structure my code in that way but maybe I wouldn't buy too much into it.
"Know your enemy and know yourself and you can fight a hundred battles without disaster." - SunTzu
Do you think it would be beneficial for people, that are just learning to program to also dig into whole OOP culture and learn how programs are structured when using OOP? I know Casey and other programmers in game industry are opposed to what is usually called OOP (although that might be misinterpretation of original idea). But it seems to me, that to fully grasp why it is bad for high performance game development, you kinda have to know how it works and what are real disadvantages of it. Even Casey said that he used to write his code in OOP style for several years before being taught other way (data-oriented? I'm not sure). I'm not suggesting people should spend 3-4 years learning ins and outs of C++ OOP style and all it's new exciting features from 2011/2014 spec, but maybe writing at least one project that way might help you to understand why it's probably not the best idea.
Also if you ever end up in company that has whole codebase in OOP style and you have to comply, it sure would be handy to be able to jump right in. What are your thoughts guys? What I would do is, study OOP and the practices that usually come with it, and learn how to structure my code in that way but maybe I wouldn't buy too much into it.
"Know your enemy and know yourself and you can fight a hundred battles without disaster." - SunTzu
Edited by BlueWolf
on
It's always a good idea to familiarize yourself with other tools and techniques, then make up your own mind about them. You shouldn't blindly believe anyone telling you that OOP is the greatest thing since sliced bread, just like you shouldn't blindly believe anyone (even Casey) when they're telling you that OOP is a really bad idea with even worse implementations. (Note: you can replace "OOP" with any of "functional programming", "compression-oriented programming", "node.js" or any other paradigm / library / tool you can think of.)
Worst case: you wasted time on learning stuff you'll never use, but at least you'll know why you won't use it. Best case: you'll have a new tool in your toolbox and maybe, one day, you can swoop in and save the day.
Now, on the topic of the merits and shortcomings of OOP. I'm currently in the phase that Casey described where he only programmed object-oriented, but was slowly realizing that overdoing it can easily suck the fun out of programming. If Handmade Hero had come around five years ago, the program I'm currently working on (lots of classes, virtual functions, some templates strewn in) might look very different, both code-wise (I'd love to have hotloading, so I guess no virtual functions at all), but probably also in its features (some of those have more or less emerged from the code structure). Would it be better? Hard to say. After working with the same codebase for several years and no definite "finish" in sight (not because we keep missing our schedule, but because we intentionally evolve the product with new features) you tend to yearn for those simple days when you could fit half or more of the codebase into your head at once.
That said, I don't think blanket statements like "OOP is bad, don't do it" are warranted. I would say that you need to be very, very careful with OOP and particularly C++ in applications with hard realtime requirements (like games). Besides the obvious performance impact of virtual function calls, C++ tends to obfuscate the exact code flow on the CPU with constructors, destructors, overloaded operators, move operations, aforementioned virtual functions and complicated template resolutions involving lots of SFINAE. That can make it really difficult to follow the exact control flow of a piece of code, and nigh impossible to gauge its performance without intimate knowledge of all classes involved.
One of the main benefits of OOP, in my mind, is that it enables very clear interfaces. You can design classes in a way so that other people can learn exactly how to use them, just by reading their declaration. Access modifiers make it clear what is part of the public interface, and what's just implementation detail. Virtual functions are explicit extension points where users can hook in their own code. Inheritance makes it easier to design and use interfaces for the smallest common denominator of related data structures. You can do all that with C, of course, but it's nice to have syntactic sugar to make the code more concise and (potentially) easier to read.
Worst case: you wasted time on learning stuff you'll never use, but at least you'll know why you won't use it. Best case: you'll have a new tool in your toolbox and maybe, one day, you can swoop in and save the day.
Now, on the topic of the merits and shortcomings of OOP. I'm currently in the phase that Casey described where he only programmed object-oriented, but was slowly realizing that overdoing it can easily suck the fun out of programming. If Handmade Hero had come around five years ago, the program I'm currently working on (lots of classes, virtual functions, some templates strewn in) might look very different, both code-wise (I'd love to have hotloading, so I guess no virtual functions at all), but probably also in its features (some of those have more or less emerged from the code structure). Would it be better? Hard to say. After working with the same codebase for several years and no definite "finish" in sight (not because we keep missing our schedule, but because we intentionally evolve the product with new features) you tend to yearn for those simple days when you could fit half or more of the codebase into your head at once.
That said, I don't think blanket statements like "OOP is bad, don't do it" are warranted. I would say that you need to be very, very careful with OOP and particularly C++ in applications with hard realtime requirements (like games). Besides the obvious performance impact of virtual function calls, C++ tends to obfuscate the exact code flow on the CPU with constructors, destructors, overloaded operators, move operations, aforementioned virtual functions and complicated template resolutions involving lots of SFINAE. That can make it really difficult to follow the exact control flow of a piece of code, and nigh impossible to gauge its performance without intimate knowledge of all classes involved.
One of the main benefits of OOP, in my mind, is that it enables very clear interfaces. You can design classes in a way so that other people can learn exactly how to use them, just by reading their declaration. Access modifiers make it clear what is part of the public interface, and what's just implementation detail. Virtual functions are explicit extension points where users can hook in their own code. Inheritance makes it easier to design and use interfaces for the smallest common denominator of related data structures. You can do all that with C, of course, but it's nice to have syntactic sugar to make the code more concise and (potentially) easier to read.
Edited by Benjamin Kloster
on
Nimbal
... C++ tends to obfuscate the exact code flow on the CPU with constructors, destructors, overloaded operators, move operations, aforementioned virtual functions and complicated template resolutions involving lots of SFINAE. That can make it really difficult to follow the exact control flow of a piece of code, and nigh impossible to gauge its performance without intimate knowledge of all classes involved.
Well said, this is the major reason I moved away from C++.
OOP techniques can be (very occasionally) useful, but you don't need C++ to program with objects. Eg the book Mastering Turbo Assembler published over 20 yrs ago had a chapter on OOP in x86 assembly.
This article points out OOP patterns used in the Linux kernel, which is all C.
If you don't learn OO you will be limiting your options in today's world. There is a lot of OO code out there and lot of groups programming in that style. One of the problems with OO is there doesn't seem to be universally accepted definition of what it is. A good source to start with is Robert Martin (aka "Uncle Bob") here:
Principles of OOD
Even if you hate OO it is important to remember that a lot of smart people have put a great deal of thought into how to do it. It is useful to try to understand what problems they were trying to solve with the approach that they advocate. Even if you don't like their solutions at least you will understand what they thought the problem was.
Also, a great introduction to OO design patterns specific to game programmers is here:
Game Programming Patterns
He has written the most easily digestible coverage of design patterns that I am aware of and he uses OO concepts in his C++ sample code.
Principles of OOD
Even if you hate OO it is important to remember that a lot of smart people have put a great deal of thought into how to do it. It is useful to try to understand what problems they were trying to solve with the approach that they advocate. Even if you don't like their solutions at least you will understand what they thought the problem was.
Also, a great introduction to OO design patterns specific to game programmers is here:
Game Programming Patterns
He has written the most easily digestible coverage of design patterns that I am aware of and he uses OO concepts in his C++ sample code.