OOP culture promotes bad practices, you should be thinking about the data you are working on and how to transform it so it does the actual "thing" that you want.
A good explanation of why this is bad in game code and a explanation of an alternative more simple and straightforward way to do things can be found here:
http://mollyrocket.com/casey/stream_0019.html
that been said i do use a certain amount of very basic OOP for the things i do. but most of the time i think is better to avoid it.
A good explanation of why this is bad in game code and a explanation of an alternative more simple and straightforward way to do things can be found here:
http://mollyrocket.com/casey/stream_0019.html
that been said i do use a certain amount of very basic OOP for the things i do. but most of the time i think is better to avoid it.
javier,
Well I feel thoroughly chastised after reading that. I did 2 years as a CS major before moving on to other things and I never even thought to question what I was thought in school about OOP. While I still think OOP looks pretty and I enjoy it's logic, it really can be amazingly inefficient.
Thanks for the reply and link.
Well I feel thoroughly chastised after reading that. I did 2 years as a CS major before moving on to other things and I never even thought to question what I was thought in school about OOP. While I still think OOP looks pretty and I enjoy it's logic, it really can be amazingly inefficient.
Thanks for the reply and link.
I don't know if OOP is less optimal or not, but i like OOP concept of group code in classes , feels more cleaner and easy to understand, and probably we can do all that just with structs,
but im definelty agree with casey of all those buch of classes like the Person, Manager, contractor example that makes no sense ,
i think we can use it in some degree
but im definelty agree with casey of all those buch of classes like the Person, Manager, contractor example that makes no sense ,
i think we can use it in some degree
Edited by José De Gouveia
on
The simple way to put my problem with OOP is that it is "noun based" instead of "verb based".
A verb is really a relationship between nouns, and in OOP it's hard to say to which object the relationship belongs.
Like if one object in your game is a table, and another object in the game is fire, where do you put the code that covers what happens when the chair and fire interact? Does fire know how to burn things, or does a chair know how to be burnt? OOP usually encourages you to split the difference, find the interface between the relationship and split it in half.
What you end up with is that the relationships, the verbs, tend to get broken up over several source files. OOP doesn't group your code nicely, it fragments it terribly. The relationships, the verbs, the solution is obfuscated and scattered. It becomes very difficult to even figure out what these relationships are, and how things work, because everything is buried under syntax and object hierarchies you don't care about, such that it makes it hard to figure out what things actually do. It encourages solutions that are opaque, that have these hierarchies of objects that are set up like trick shots in billiards. You can't even tell if the code is doing what it's supposed to do.
I think the approach to programming that goes, "How do I devise a hierarchy of objects that will create a system that solves the problem?" is just kind of terrible.
A verb is really a relationship between nouns, and in OOP it's hard to say to which object the relationship belongs.
Like if one object in your game is a table, and another object in the game is fire, where do you put the code that covers what happens when the chair and fire interact? Does fire know how to burn things, or does a chair know how to be burnt? OOP usually encourages you to split the difference, find the interface between the relationship and split it in half.
What you end up with is that the relationships, the verbs, tend to get broken up over several source files. OOP doesn't group your code nicely, it fragments it terribly. The relationships, the verbs, the solution is obfuscated and scattered. It becomes very difficult to even figure out what these relationships are, and how things work, because everything is buried under syntax and object hierarchies you don't care about, such that it makes it hard to figure out what things actually do. It encourages solutions that are opaque, that have these hierarchies of objects that are set up like trick shots in billiards. You can't even tell if the code is doing what it's supposed to do.
I think the approach to programming that goes, "How do I devise a hierarchy of objects that will create a system that solves the problem?" is just kind of terrible.
Edited by kbailey
on
Another commonly referenced "introduction to why OOP is bad":
https://www.youtube.com/watch?v=rX0ItVEVjHc
- Casey
https://www.youtube.com/watch?v=rX0ItVEVjHc
- Casey
Bjarne Stroustrup: Why the Programming Language C Is Obsolete
https://www.youtube.com/watch?v=KlPC3O1DVcg
I'm confused right now:( so who is wrong ?
https://www.youtube.com/watch?v=KlPC3O1DVcg
I'm confused right now:( so who is wrong ?
It is true they should be one language, but C++ is not the answer to everything, C++ is a overcomplex mess of things that propably will never concern you if you are trying to make efficient programs, videogames or not. On the other hand, i dont understand how people can find making classes and objetcs "cleaner" and "easy" to understand, when you have to write things like header files, yuck. (maybe they are talking about Java or c#)
C++ its not designed to make video games and adding more complexity to your tasks its only gonna make your work harder.
C++ its not designed to make video games and adding more complexity to your tasks its only gonna make your work harder.
Another classic is Steve Yegge's Execution in the Kingdom of Nouns. There are good things to learn from OOP, but the hoops you have to jump through to fit everything into it can get ridiculous.
hendrix
Bjarne Stroustrup: Why the Programming Language C Is Obsolete
https://www.youtube.com/watch?v=KlPC3O1DVcg
I'm confused right now:( so who is wrong ?
I am going to try to take a stab at this....
If you are confused on why he thinks C is obsolete:
I am thinking what Bjarne is referring to is that C itself is obsolete (i.e. invoking clang instead of clang++), not necessarily coding in a "C-style".
Since C itself is nearly a subset of C++, you can really do almost all of the things using a C++ compiler (i.e. clang++) that you can do using a C compiler (i.e. clang) and more. Don't forget, Handmade Hero is actually written in C++, even though it is in a style that is reminiscent of what a C coder would do as opposed to a "modern" C++ coder.
I don't necessarily have an opinion on whether he is right or not, but maybe this will relieve some confusion.
Please some one correct me if I am wrong about what Bjarne is thinking.
If you are confused on why he thinks Object Oriented programming is good:
Note: I feel that I am too inexperienced to give a definitive answer. But here are my thoughts and maybe this also can clear up some confusion.
If I understand correctly from that video, Bjarne was advocating for a language (C++) that people other than computer engineers can use without having to learn the innards of a computer. This is nice for people who don't want to learn the details of how computers work, but want to have a way of expressing their problem (which has nothing to do with a computer) in a way that the computer can understand. You don't have to waste your time learning about how the CPU cache works, because the language takes care of that for you.
The philosophy seems to be: "You can program the computer without having to know how it actually works" This is where the disagreement comes in between people like Casey, Jon Blow and other data-oriented proponents, and people like Bjarne and other OOP proponents.
OOP/GC (garbage collected) languages cannot be implemented without some sort of performance overhead, because it is just not how computers work.
Some (most?) OOP/GC proponents believe that computers are fast enough today where we don't have to care about this overhead, or that the the compilers/interpreters are so good that the program will be performant. It is with this philosophy, that ...ates 25,000 strings per keystroke (look at the the second post).
Data-oriented proponents are frustrated with this philosophy because it teaches people not to care about performance and that these languages are good enough to make programs that will run just fine everywhere. It obscures the reality that there is no real way of making such a program run well without understanding how the hardware works.
It is also important to note that the Casey and Jon are game programmers and each frame in a game must be rendered in a certain amount time in order for it to be playable. Performance is mission critical for games.
It seems to me that the people who write programs like web browsers don't care as much about performance, hence the usage of OOP. (Please correct me if I am wrong).
So back to your question: "Who is wrong?" I'd like to take Jon and Casey's side and say that the OOP proponents are wrong. This is because you should probably care more about the end product than the code itself. The game developers have made a pretty good point that there is a lot of software that just runs slow because it is written in things like Java (think, Eclipse or Minecraft). Unfortunately, I feel I am too inexperienced to hold a strong opinion on this. Maybe there is a better reason why OOP is so prevalent other than thinking in OO way is easier than thinking in a data-oriented way. I'd like to see an experienced OOP/GC proponent try to refute Jon, Casey, etc's claims.
One way to really test to see who is wrong is do a project in OOP and a project using a data-oriented model and see which one runs better, but that might take a while...
I am curious to see what people's thoughts on this are.
In my experience, if you want to code without knowing the details of how a computer works, C++ is not the language for you.
That being said, I think there actually is a very valid point to be made for having a spectrum of tools available. We can't expect everyone to become experienced computer engineers just to make their computers do something new and interesting, and we certainly don't want to see computers play a smaller role in the future than it looks like they will right now.
Perhaps the qualm that Casey & Co. have with seeing this philosophy in the real world is that there is the very real possibility (and occurrence) of programmers who purport to actually be computer engineers using these tools as an excuse for laziness when writing code, and with experience in the area, they see the lost potential. Like with the Chrome example, these are supposed to be the hot-shot programmers at Google, yet they're being lazy with strings and memory, which costs user time and resources on a large scale because of the popularity of the product. (Well, it was Chromium, so the Chrome browser itself might be a little different, but probably not much).
As someone who is interested in more high-intensity computer applications like games, I'm just glad I came across the data-oriented philosophy early in my career. I could have wasted several more years on OOP.
That being said, I think there actually is a very valid point to be made for having a spectrum of tools available. We can't expect everyone to become experienced computer engineers just to make their computers do something new and interesting, and we certainly don't want to see computers play a smaller role in the future than it looks like they will right now.
Perhaps the qualm that Casey & Co. have with seeing this philosophy in the real world is that there is the very real possibility (and occurrence) of programmers who purport to actually be computer engineers using these tools as an excuse for laziness when writing code, and with experience in the area, they see the lost potential. Like with the Chrome example, these are supposed to be the hot-shot programmers at Google, yet they're being lazy with strings and memory, which costs user time and resources on a large scale because of the popularity of the product. (Well, it was Chromium, so the Chrome browser itself might be a little different, but probably not much).
As someone who is interested in more high-intensity computer applications like games, I'm just glad I came across the data-oriented philosophy early in my career. I could have wasted several more years on OOP.
I think good indicator of how good "paradigm" X is inverse of number of books titled "Effective X","X Design Patterns" or "X. Good Parts". Also, for good reference point we could take Math. It has centuries of proven track record and zero (for my knowledge) number of books in aforementioned spirit. Math just works. Therefore the closer a "paradigm" to math the better it is.
To bash some OOP: in short it is hilariously broken concept. OOP mostly known for 3 "magic words": Encapsulation, Polymorphism and Inheritance.
Encapsulation (http://en.wikipedia.org/wiki/Enca...ion_(object-oriented_programming)), or hiding details of implementation, existed before, so have nothing to do with OOP. It's basically a module system and/or interfaces.
Polymorphism (http://en.wikipedia.org/wiki/Polymorphism_(computer_science)), also existed long before OOP and not just in weird subtype form on which OOP insists (and introduces problems with parametric polymorphism).
Which leaves us with Inheritance:
Inheritance (http://en.wikipedia.org/wiki/Inhe...nce_(object-oriented_programming)) is broken. Wikipedia says that there is two kinds of Inheritance: syntactic (reusing data fields) and semantic (reusing behaviour), which is weird. I'm yet to see a person that would use inheritance as a way to solely reuse data fields. Most of the time you are after semantic one. And guess what? It's broken. It's broken in medium-to-big projects (http://en.wikipedia.org/wiki/Composition_over_inheritance, also even subtle change to base class behavior now can break one or more classes that inherit it, and that could be 3rd party one, that you can't access.) and it's broken in principle (http://en.wikipedia.org/wiki/Lisk...ion_principle#A_typical_violation) unless you restrict yourself to immutability or just ignore one of the SOLID (http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) principles. Also you don't go above 3 or so of inheritance level or you brain will melt supporting that. Languages with multiple inheritance (like C++) are especially bad with it and also introduce another problem (http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem).
In short, programming OOP way will make you fight it a lot of times. That's unproductive in my book.
People, being smart and willing to get the job done, found their way through that mess of course. That's how Design Patterns book was born. And Martin Fowler stuff. And 1000s of blog posts.
But even if you ignore all that stuff I wrote above: adopting OOP *severely* restricts your options on how to write your code, how to compose your stuff, and, worst of all - how to think about problems. Because not all problems are good fit for hierarchy taxonomy.
To bash some OOP: in short it is hilariously broken concept. OOP mostly known for 3 "magic words": Encapsulation, Polymorphism and Inheritance.
Encapsulation (http://en.wikipedia.org/wiki/Enca...ion_(object-oriented_programming)), or hiding details of implementation, existed before, so have nothing to do with OOP. It's basically a module system and/or interfaces.
Polymorphism (http://en.wikipedia.org/wiki/Polymorphism_(computer_science)), also existed long before OOP and not just in weird subtype form on which OOP insists (and introduces problems with parametric polymorphism).
Which leaves us with Inheritance:
Inheritance (http://en.wikipedia.org/wiki/Inhe...nce_(object-oriented_programming)) is broken. Wikipedia says that there is two kinds of Inheritance: syntactic (reusing data fields) and semantic (reusing behaviour), which is weird. I'm yet to see a person that would use inheritance as a way to solely reuse data fields. Most of the time you are after semantic one. And guess what? It's broken. It's broken in medium-to-big projects (http://en.wikipedia.org/wiki/Composition_over_inheritance, also even subtle change to base class behavior now can break one or more classes that inherit it, and that could be 3rd party one, that you can't access.) and it's broken in principle (http://en.wikipedia.org/wiki/Lisk...ion_principle#A_typical_violation) unless you restrict yourself to immutability or just ignore one of the SOLID (http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) principles. Also you don't go above 3 or so of inheritance level or you brain will melt supporting that. Languages with multiple inheritance (like C++) are especially bad with it and also introduce another problem (http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem).
In short, programming OOP way will make you fight it a lot of times. That's unproductive in my book.
People, being smart and willing to get the job done, found their way through that mess of course. That's how Design Patterns book was born. And Martin Fowler stuff. And 1000s of blog posts.
But even if you ignore all that stuff I wrote above: adopting OOP *severely* restricts your options on how to write your code, how to compose your stuff, and, worst of all - how to think about problems. Because not all problems are good fit for hierarchy taxonomy.
Edited by itsuart
on
Reason: is -> are
I'm going to try to be fair here. OO isn't "bad" in and of itself, but it's not what you want here.
You (if you learned programming at any point in the last 10-15 years) learned objects for the same reason why engineers of the 1880s learned steam: that's the world that you will probably have to work in. Steam isn't bad; even the modern world uses quite a bit of steam (e.g. much power generation). But it's not everything.
For many programming tasks, the hard part is trying to model some real-world system. In other programming tasks, the hard part is modelling a bunch of arbitrary and ad hoc constraints or business rules which are in a constant state of change. In the late 80s and early 90s, OOAD was the only game in town as far as managing this kind of complexity, and it still compares favourably with its competitors.
For games, modelling the world isn't the hard part. In Handmade Hero, the model of the world is actually quite simple compared with the model of a medium-sized company, or library, or biological system. OOAD wouldn't help here, although using C++ as "C with modules" wouldn't be wrong.
You (if you learned programming at any point in the last 10-15 years) learned objects for the same reason why engineers of the 1880s learned steam: that's the world that you will probably have to work in. Steam isn't bad; even the modern world uses quite a bit of steam (e.g. much power generation). But it's not everything.
For many programming tasks, the hard part is trying to model some real-world system. In other programming tasks, the hard part is modelling a bunch of arbitrary and ad hoc constraints or business rules which are in a constant state of change. In the late 80s and early 90s, OOAD was the only game in town as far as managing this kind of complexity, and it still compares favourably with its competitors.
For games, modelling the world isn't the hard part. In Handmade Hero, the model of the world is actually quite simple compared with the model of a medium-sized company, or library, or biological system. OOAD wouldn't help here, although using C++ as "C with modules" wouldn't be wrong.
C++ <=/=> OOP. I've worked on C++ and Java OOP projects and they were not good.
The projects I've worked on haven't been games, but most of them have been things that needed to perform reasonably. One of them was a rendering engine/driver for digital printers, and performance metrics were important for marketing. It was part of the QA acceptance tests--if you introduced something that caused a slowdown, your change would get rejected. The application also had to manage its own memory because a 8.5x11" 600 DPI raster at 32bpp (CMYK) is ~128MB of memory, and you need several in memory at once to keep the printer speed up. It was all in C.
It's not just games.
I also worked on a scientific molecular drawing program that was all C. It had some pseudo-OOP stuff, like dynamically typed struct/unions (like Casey has done in HH), or structs full of function pointers as interfaces or member functions. OOP can give you those with syntactic sugar to make them more neat (or not-so-neat in C++'s case), but with C you have them only where you need them, you don't have to pretend that everything in the universe is a precious hidden nugget of data with its own API... a sub-API of an even larger API, a senseless explosion of syntax that makes life miserable for anyone trying to use, extend, or maintain your code.
Because OOP wants to hide and fragment code all over, it doesn't do well when you care very much about managing side effects like memory allocation or thread safety. But those "side effects" are part of high level architectural concerns a lot of the time, and very much of interest to professionals making many kinds of programs. Good programming isn't about patting yourself on the back because you added two matrices with + instead of matrix_add().
I think OOP can be okay if you require a solution where you have large complex data structures that you are trying to process with difficult algorithms, and you just want some syntactic sugar to help deal with it all. There's something about OOP, though, that is satisfying to the minds of a lot of programmers. It's fun to abstract things out. It's fun to push a button that triggers a Rube Goldbergian system that automagically produces the correct outcome. I think even some very very smart people want to apply it as if it was a good way to approach solutions for everything. Things were pretty dark in the heyday of Java and XML.
(And more specifically about that Bjarne Stroustrup video -- how much would you have to hate a non-programmer colleague of yours to recommend they use C++ and OOP???)
The projects I've worked on haven't been games, but most of them have been things that needed to perform reasonably. One of them was a rendering engine/driver for digital printers, and performance metrics were important for marketing. It was part of the QA acceptance tests--if you introduced something that caused a slowdown, your change would get rejected. The application also had to manage its own memory because a 8.5x11" 600 DPI raster at 32bpp (CMYK) is ~128MB of memory, and you need several in memory at once to keep the printer speed up. It was all in C.
It's not just games.
I also worked on a scientific molecular drawing program that was all C. It had some pseudo-OOP stuff, like dynamically typed struct/unions (like Casey has done in HH), or structs full of function pointers as interfaces or member functions. OOP can give you those with syntactic sugar to make them more neat (or not-so-neat in C++'s case), but with C you have them only where you need them, you don't have to pretend that everything in the universe is a precious hidden nugget of data with its own API... a sub-API of an even larger API, a senseless explosion of syntax that makes life miserable for anyone trying to use, extend, or maintain your code.
Because OOP wants to hide and fragment code all over, it doesn't do well when you care very much about managing side effects like memory allocation or thread safety. But those "side effects" are part of high level architectural concerns a lot of the time, and very much of interest to professionals making many kinds of programs. Good programming isn't about patting yourself on the back because you added two matrices with + instead of matrix_add().
I think OOP can be okay if you require a solution where you have large complex data structures that you are trying to process with difficult algorithms, and you just want some syntactic sugar to help deal with it all. There's something about OOP, though, that is satisfying to the minds of a lot of programmers. It's fun to abstract things out. It's fun to push a button that triggers a Rube Goldbergian system that automagically produces the correct outcome. I think even some very very smart people want to apply it as if it was a good way to approach solutions for everything. Things were pretty dark in the heyday of Java and XML.
(And more specifically about that Bjarne Stroustrup video -- how much would you have to hate a non-programmer colleague of yours to recommend they use C++ and OOP???)