"Is pixel an object or a group of objects? Is there a container? Do I have to ask a factory to get me a color?" I literally died there... that's literally the best description of my programming for the last 5 years.
Also, if one thinks of pixels as objects in the OO-sense, an entire 1920*1080 frame will start to feel too big and slow. Roughly a decade ago I wrote a quick Mandelbrot example in C for a friend of mine who wanted to learn some simple graphics programming. He had only written JavaScript for web projects. When he saw my example and the double for-loop where I looped over the pixel buffer, he couldn't understand how it ran so fast. He also couldn't understand that the pixels weren't objects, but concise data that was laid out contiguously in memory.
@@miikavihersaari3104 That's pretty awful for them, but it proves something that i've been saying for a while. New school programmers have no knowledge about basic IT and computers and have only been taught how to use a bunch of black box abstractions without learning how they really work. :(
@@wilfridtaylor I literally had no idea I had a comment with 450 likes here. No, you actually need an abstract base class for a property of the pixel, and its child class PixelColorProperty, which you then construct an abstract factory class PixelColorPropertyFactory for, which then returns the concrete red color by constructing it from the central ColorFactory class, and you have to use dependency injection to specify which ColorFactory it is that you want(it needs to implement the IColorFactory interface though). This gross oversimplification is obviously only intended for read-only scenarios.
"I want to emphasize that the problem with object-oriented programming is not the concept that there could be an object. The problem with it is the fact that you're orienting your program, the thinking, around the object, not the function. So it's the orientation that's bad about it, NOT whether you end up with an object. And it's a really important distinction to understand."
My favorite example is RESTful API. Backend then, is not even supposed to deal with state. But backend developers do a bunch of classes, state manipulation back and forth, just because OOP dictate that design. They artifically for each API call create temporary state(and a lot of it, not just local variable with data from database) and destory it after.
I mean, are they? I've seem plenty of Javascript and Python code that's a lot more procedural, and sometimes even almost functional. I mean, they still suck because they're Javascript and Python, but definitely not OOP.
@@franciscofarias6385that's a relatively new phenomenon. Even just 10 years ago it was mostly Java (for those who had moved on from PHP). JS on the backend has only been about the past 5-10 years
This is so true. I wrote OOP style for 10-15 years. Eventually I started playing around with functional programming and it changed everything for me. I now try to design in terms of functions and how I can transform data from one state to another. It makes code much easier to reason about (just inputs and outputs), easier to compose, and often means you don't end up with silly abstractions that only make sense if you try to put your problems into the "box" of objects. Treating everything as objects means you have to write more code to handle this abstraction that you might not even need.
Unfortunately, when I first started programming, I encountered nothing but tutorials that jumped right into OOP like it was the only way to program. And of course I didn't know any better! So much friction has been removed from my process since I've broken free from that state of mind. It's easier to judge when objects are appropriate when you don't think they're always appropriate!
fascinates me to look in on the OOP world from the outside. basically looks like utilities made for dealing with shared state in a simulation got prematurely made universal on everyone
@@ramireznoy the problem is OOP points you towards using it wrong time and time again. And good OOP looks more and more like other programming paradigms as time goes on, and has morphed into nothing like what OOP was 20 years ago. It's really one of the worst programming paradigms today because it's harder to use correctly for the same payoff.
@@bobbycrosby9765 A paradigm does not change, otherwise it is not. I think you are confusing programming language with programming paradigm. Or even worst, confusing implementation with design and analysis since OOP is NOT a coding paradigm, it is an analysis and design paradigm you can use anywhere, also for coding. It doesn't points you to anywhere the same way a framework doesn't points you to anywhere neither. It is just a set of tools and principles you can decide to use or not depending on how complex is your problem. The bigger and/or more complex the problem, the shinier the OOP approach
I lost an entire decade to OOP, and agree with everything Casey said here. The code I wrote in my first year as a programmer (before OOP) was better than the code I wrote in my 15th year (OOP expert). It's a shame that students are still indoctrinated into this regressive model. Also, as a professional customer of Casey's work, I totally vouch for his judgement in software architecture and API design. Granny3D (we were on version 2, iirc - we used it for animation) remains my favorite middleware of all time.
Similar experience. Though I was poisoned with the OO mindset from day 1 at university. After 15 years as a professional I am only now awake enough to question the sacred cow and realize what a terrible, terrible idea it is in almost every instance (pun intended).
Just recently I realised my OOP college really messed up me, not because OOP is inherently bad, but it's the only way I've ever learned + worked at programming. Now I almost always get caught in an infinite conceptual loop, refactoring, losing sight of the original problem. I actually can't think in different terms
I was taught OOP first (Java in my case). My tip would be to try functional programming. Functional will require you to learn new ways of thinking about a program and push you to decompose problems in a much more data oriented way. It is kinda like jumping head first into the cold water instead of slowing wading out in it. Functional will be so increadibly strange and foreign to you that you can't lean at all on your old OOP reflexes. For me it was hard when first time looking at C code to not think of it as less complex OOP code. I needed that complete confusion functional code gave me the first couple of times to shake old habits off. If you while working a bit with functional at the same time look a bit at some C code you will realize how in a lot of ways it is more close to a functional mindset than an OOP way of looking at it. Some kind of combination of this was what made me realize the limitations of OOP. I think the map and filter streams in Java 8 was the first step on that journey (they seemed so practical and cool to use) and then I tried to learn functional by myself at the same time as we had some introductions to C in school.
@@nishanth6403 No, I am pretty sure I meant Functional. But this was 4 years ago, I don't fully remember what I was thinking when I wrote this comment. It is not a very good comment looking back at it, but I still agree with the general idea. And yes, I definitely meant Functional. I guess it depends on what characteristics you require of a "functional" language. If you require the language to be based on lambda calculus then, yes, C is not that. C is procedural at its core and "good" C code will probably always be very imperative, but I would argue one could definitely write code leaning towards the functional paradigm in it. Programming language "paradigms" are not very well defined terms and functional programming imo is probably one of the most illdefined of them all. In the definition of functional programming there are a bunch of things that practitioners of functional programming thinks are good design principles, things like: - Pure functions whenever possible. - Immutability. - Composition and higher order functions. - Recursion instead of iteration. - Functional datastructures. Most of these are just good design patterns . All languages that are usually called functional make use of most of these, but they differ usually somewhat in how much focus they put on each of these. It is usually possible to write code in whatever paradigm in most languages. I can give multiple examples of this: - It is possible to write very functional code in Common Lisp (it is a lisp, how much more functional can you get), but at the same time CL was one of the first langs to have Objects in the language - so you can write very OOP-code in it too. - OCaml is a great functional language, but it also has a loop construct making it possible to write quite imperative and procedural code in it too. - Java is probably the mainstay OOP language, yet it has the very functional-inspired high order functions; map and filter (which I mention in my original comment). - And finally, yes, you can write functional code in C - by making good use of function pointers for composition, having pure functions whenever possible, keeping immutability as much as possible. You probably shouldn't use recursion much though. I would say you have a very limiting way of thinking about functional programming if you don't think its design patterns and insights could be transferred to other languages that are not "as functional". If this is the case I would almost hesitate to say you have learned functional programming very well at all and maybe should go back and look at it again. Sorry that this comment got so long. Your comment hit a nerve with me, I guess, and I felt I had to present my arguments against it properly.
In sum: objects are not the problem, but *orienting* you program *around objects*. Program thinking on *what the CPU must do*, write *functions* that get the job done first. THEN you simplify stuff.
2:20 «Do I need to abstract the concept of a screen? Should red be an object? Is a pixel an object or is that a group of objects? Is there a container? Do I have to ask a factory get me a color and that color is red?»
Oddly enough some of the above can be useful. Abstracting the concept of the screen can make it so that your game can run without a screen (eg. if you want a version of your game that runs on a cloud server for multiplayer games and you want to discard visual output entirely), or let you "mock" the screen so you can test code that writes to it automatically without the hassle (for the computer) of the actual screen involved. Or if you want to log everything being sent to the screen in addition to actually displaying it, for later debugging purposes. Making "red" be an object means that it becomes possible to reference the colour red by name in your program, which sometimes has its uses. Don't think you need a factory to get it, though, typically when I see "red" as an object it's a global constant.
@@babgab You're proposing to discard the visual output... instead of not producing any visual results in the first place. That's some very broken thinking right there.
@@etodemerzel2627 In a testing context, discarding output sent to a mock is fine if that output isn't relevant or even produced by the code you're actually trying to test. That's kind of the *point* of a mock, actually. This situation can happen when adding tests to an existing codebase that wasn't written to consider testability. You might just want to test (for example) that a player can walk from A to B, which *shouldn't* need screen output to verify, but the game code you're dealing with may be hard to put in a test harness on its own. It may for example keep all of its state in global variables or keep its state in some structure that can't be instantiated properly without the entire engine being up and running (including video output being turned on). Both of those are pretty common design choices in video games. In principle, you could refactor all that out, given enough time, but sometimes you don't have that time. Sometimes a refactoring to do things "properly" would take *years* for a team of experts on that specific system and all its warts and corner cases, and your manager won't give you years; they (and probably you) want that test NOW. I'm not generally a fan of mocking, either, because of how much "test-induced damage" it causes to one's interfaces, but it IS useful sometimes. Same thing could happen in the dedicated server case. Maybe you're remastering an old game with a codebase that would take months to properly make it not tell the renderer to draw some stuff on the screen because the code (which you didn't write) is spaghetti, but you need it to start running in a cloud server in a week or you won't make your ship date. Spending those months isn't an option given to you, so you have to make do with what you have. If this happens on the level of individual pixel draws, then that's a pretty pathological case, but stuff like that does happen. I seem to recall hearing that StarCraft's remastering ran into some problems like that where the actual visual appearance of some units was tied into the gameplay logic and upscaling the sprites broke gameplay. I find that "broken thinking" in software development is often a reaction or adaptation to "broken situations." Much of software's ongoing enshittification can probably be blamed on "broken situations." Or at the very least, "broken incentives."
The first language I was taught was Java, so I was taught OOP from the get go. Removing the OOP mindset was actually really easy, but what was left stuck in my head is the practice of having small functions and make your code look artificially "clean". So I am in a constant struggle of refactoring and not refactoring, knowing that over-refactoring will unnecessarily complicate my codebase if it gets big. Even after removing my OOP mindset, my emphasis is still on the code itself, and that is much harder to cure in comparison.
Java was my first language (still learning) and I've been wanting to learn c after starting nand2tetris, because the inner workings of the computer fascinate me. Hence the handmade hero.
@@RoscleHilltopple It is purely centered around OOP. People who are just starting with programming should only be using procedural languages, or languages that allow procedural code. OOP is just plain garbage. Inheritance is hit-or-miss, Encapsulation is worthless (instead of creating a public member variable, I'll just make a private member variable and then write a public method for getting the variable's value and a public method for setting the variable's value; thanks Java!), and you can achieve Polymorphism easily without OOP (function overloading for example).
I am very happy I learned how to program by myself 25 years ago and not at school or uni, and did not learn OOP first. I do use OOP though, since I learned it four years ago. But I only use it if I am going to use the features of OOP. I will never automatically make something a class just because it's 'the right/professional/trendy thing to do'. So I always start by looking at what I plan to do with what I'm declaring, and use the features of the language I know that best suit that.
Years ago, I was struggled with my engine project with oop mindset. It’s impossible or unefficent to design a system with oop that you never build already. As the video said, It’s ok to end up using oop. Just don’t start with it.
I suggest giving LISP/Racket a turn around the block if you have a need to rid your mind of oop. These are likely to be mind-bending if you are new to them and are pretty simple to get a functioning environment up and running.
I could never wrap my mind around OOP. Common Lisp taught me to program. I now write mostly in C and while I've gotten my feet wet in other languages (most of which aren't worth mentioning), and have a little knowledge of and appreciation for certain others such as Forth and Standard ML, I have very little interest in other "popular" languages outside of C. Lisp still has a special place in my heart and if I need to get something done fast, CL is my friend. I still don't get OOP, but at least I no longer feel like I'm missing out!
Tagged unions (sum types) and pattern matching solve a lot of problems that OOP hideously fails at. And yet there are still people trying to defend Visitors and Factories instead of using tagged unions.
whenever i code something in a language which has classes, i just look at them as c structs. coz thats basically what they are. in some rare ocassions i do put methods inside them though, just for convenience. but rarely.
This is a great explanation of how to make your life simple as a programmer. The way I think of it is to start with static classes, and only make non-static classes as needed.
I'm fan of OOP (C#) and feel like it's honestly helped me become a better developer, but I can also agree that thinking of everything as an "object" can be counter productive. If you have a bunch of related data and keeping it together makes it easier to read & write your code, put it in an object. If you have a a bunch of related data, have some standard ways you need to interact with it, and keeping it together makes it easier to read & write your code, put it in an object. As soon as it makes it harder to read and write your code, consider either doing things differently or at least thinking about it differently. Will separating the data and functionality make it easier, for example? Well then just do that, don't sweat it. For me, I'm happier thinking in terms of modules, not really much different than you'd find in JavaScript (e.g. util functions & complex reusable logic that for data transformations for example). At the end of the day, I'm just bundling up some functionality and passing it around; why make it more complicated than that?
I don't even know what people mean when they say OOP anymore. I once read a tutorial about how OOP was terrible and you should use entity component sytems. The programming language they used to implement their ECS was ruby, where everything is literally an object.
Classes do not equal oop. You could use classes. Bundle stuff that belongs together in them. Avoid polymorphism mostly and even do functional programming in the classes. You use classes but that is not oop
At the heart of OOP is encapsulation of a sort that bundles all related data and logic together. ECS isn't OOP since it distributes the bulk, if not all logic, into systems and most, if not all, data into components. At the heart of ECS is a very big separation of data away from logic which is fundamentally anti-OOP.
@@darkengine5931 ECS is an architecture pattern, it can't be anti-OOP. It's like saying that using only one file for a program is anti-OOP. You can replace ECS with MVC and you still get a similar thing, though working on events rather than on calling other code directly. It's even better than MVC, because it's closer to original term of OOP.
@@doktoracula7017 A lot of the incompatibility I see with at least common interpretations of OOP and how it's taught in CS vs. at least a pure ECS is that the ECS fundamentally abandons the concept of encapsulation, including information hiding. Components become pure data, publicly-accessible by any system, while systems contain the functions that process and transform that data. That basic separation of data from functions rather than bundling them together makes the ECS seem far more in line with procedural or functional programming as I see it. I can't really pick out anything like an "object" from an ECS in the sense of something that has both state and functionality combined together. I see systems that have functionality but no state, and components that have state but no functionality.
I learned BASIC as a kid but when OOP came along, I set my programming hobby aside and never pursued it. Now I'm learning again and working in C I'm relieved how familiar it seems
I think schools should teach at least 3 languages / paradigms, C for Procedural, Java for OOP, and Scheme (or any Lisp-style languages) for Functional paradigms.
My question to those who reject OOP: given the popularity of OOP (for better or worse), how do you manage in team settings where you're the odd one out? I understand that OOP isn't the end-all-be-all for every scenario on earth, but how do you navigate collaborating with others who exclusively use it?
Don't fight it. If you're working in a framework/environment/codebase that's OOP-based there's no way around it, just work with it, you'll be in for a lot of headaches otherwise. The point is just to not make things over complicated, keep things simple, do only the things you need to do to solve a problem, don't abstract for the sake of abstraction, you can do that in any style of programming or language.
I feel like as a novice programmer I should master the OOP mindset or at least understand it well. It's a way to wrangle in imperative code. And then after that you can know why or why not you should use a certain way of doing something. Like what are we even talking about? What parts of OOP are good and bad? Is this the same "don't abstract until you have to"? Learn all types of programming.
I would probably agree. Try to make a project with a decent scale/size using OOP and whatever principles they teach in schools, then try Casey's way, expose yourself to as many ideas/methods of programming and pick what you like most/what works for your application.
I began to get rid of OOP mindset, when I switched from mobile dev to game dev/game engine dev. As soon as I hit a critical issues in new fields, I realized I need to try write more data oriented code and think more about my platform. You won't believe but it is much more exciting than programming with OOP design architecture and building UML diagrams or any other virtual stuff that is unnecessary. I didn't completely ignore such things as inheritance, composition and template programming, since they are comfortable for me and I can live with that :) Second thing, I throw out the window was - design patterns, clean code and SOLID principles. Absolutely useless stuff that didn't really payoff in real world projects and creates more bugs and slows down your perfomance. Instead, I am creating my own kinda "rules of coding" for each project and publish it in Confluence document for my team.
Pure detox: go program on a Commodore 64. That's what we did when I was a kid. You don't have to learn MOS assembly to detox yourself of OOP (although it's a fun thing to do), just learn Commodore BASIC 2. No classes, no stricts, line numbers, have to interface with the hardware through menory-mapped registers... Yup that's perspective on how computers work.
Nicely stated, HH. On youtube, MPJ, Brian Will, and Jonathan Blow also address this matter. OOP sucks and can be largely avoided. Even "reuse" is overdone. Straightline probably results in faster execution but slightly greater memory use. But memory is cheap and the resultant code is much easier to follow. Learn a little assembly language. X86 is fascinating and you'll know what the computer is actually doing.
Because OOP method is best & easy way to adapt to a learning institution. Expert people who taught a young generation required concept to measure and tangible without a coding in my country. They already hard work and not required addition work on something new .
hey, the video is quite interesting, thanks for sharing! In my experience, language paradigms are like tools in a toolbox. Forgetting OOP to learn a new paradigm is like saying you must forget how to use a screwdriver to wield a hammer. In my opinion, if someone needs to "forget" OOP in order to learn something else, it suggests they haven't truly understood OOP to begin with.
To me, OOP is a toolbox full of advanced tools that you don't want to use unless you absolutely have to. Like, if you're giving a presentation and need a laser pointer to point at something on a whiteboard, why would you use a military-grade laser for that?
so, rewriting the same line of code is not bad? I was trying to wrap my head around ECS and odin-lang (no OOP, jut data) but I just can't think of any implementation that doesn't use a class, am I a failure?
Hey, I'm not sure what you mean by your first line, could you elaborate? Classes/structs are essential in any style of programming, when casey talks about OOP he's mostly talking about all the rest of the crap that comes with it: abstractions for the sake of abstractions, unnecessarily complicated design patterns, lot of useless smart words just to sound smart, etc... Just write the bare minimum code to solve your problem, write only the code you need no more no less. If you have a problem and start by writing the simplest solution you could think of, you can quickly see if it works or not, if it doesn't, then you didn't waste a ton of time (making UML diagrams Lol) and you can move on to try something else, fast iteration is key.
@@vexedev the best implementation of ECS in odin I can think of is just adding a bunch of arrays and each time that I add a component/system I have to do some manually work to it be considered and calculated
Great advices. So the Golden Rule here is: K.I.S.S. (Objects - and any other complicated Structure - only need to be programmed: when there is a REAL NEED for them..., Keep It Simple, Smarty-ass XD - btw: I don't like the 'Stupid' part) Thank you.
I feel like this is what i'm currently doing in aspnet core with blazor, it's not like i'm doing a object out of everything. Near the UI layer you have viewmodels and in the database you have entities, you send and receive dtos which are generally records. But stuff like sending emails, accessing the db, business logic processes lives in their services which are injected where needed. You end up having an anemic model and i prefer to have a main view model per page doing the initialization that is also treated as a service so you dont need callbacks and updates all over the places. Classes are good too aggregate properties and i usually extract them when i see i need the same properties in two or more places. I avoid inheritance if possible. Is this still bad oop thinking?
I started programming by making OOP Flash games for 10 years. I think a big first step to getting out of the mindset is to make everything global/static. If you do that then you're never passing arguments to functions for reasons of access or "I need a reference to this thing", instead you always just pull from the global unless you explicitly need to work on a single instance of a thing. Of course you'll have horrible organization for a bit, but as you look at your parameter lists and messy global scope, bundling will look more natural.
I'm a programming student that started with java... I remember asking my teachers why I couldn't just make everything I wanted to pass to a function a class variable, and I was told it was bad practice. And looking back, I often just did that with utility objects (like scanners) and such. I guess I have some benefits from having self learned java from a website before taking the class.
I’m new to C++ and programming. Should I learn OOP or is it a dated way? If people don’t use OOP what do they use now? Just the normal C way of coding?
Hey! There's no straight forward answer to this. OOP is everywhere, Unreal, Unity, etc. almost everywhere you go there's always some OOP one way or another. The problem at its core isn't really in the semantics of how you write code, whether its object.method() or function(object), they both accomplish the same thing. I believe a good programmer can write good code in whatever environment, engine or language they're in, sure some languages enforce OOP more, but It's more of a mindset issue than anything else. Making things complicated and abstract just for the sake it. Massively overengineering and overthinking problems that are mostly made up and not real problems. Programming rigidly by principles and theory somebody else wrote in a book with no real life experience that has no practical use of any kind. What Casey is saying is just to keep it simple, dont over complicate, do the exact amount of work necessary to get the job done, not more. You need to parse a config file? Sure, just write a little utility function that does just that. Oh wait... no. I should make a UML diagram first and make it an interface and implement IParserBase, make sure the interface is nice and clean and modular for other people to use, then anybody could give it their virtual abstract adapter proxy generator factory and it would just work!! .... you get the point. Should you learn OOP? I say absolutely! Expose yourself to the different programming paradigms out there, oop, procedural, functional etc. Take what OOP principles say with a grain of salt. Most important don't take your information from one source/person. Have multiple sources see how they think and do their thing and make up your own style around it, take the best out of everything, dont be dogmatic, be open and flexible to new ideas. I always say, write the simplest bare minimum amount of code possible to solve a problem first, see if it works. If it did, great now just clean it up a bit. If not, well you learned and you didn't waste time so you're one step closer to the solution that works.
@@cxlappsed1548 Hi, I think the biggest mess up is being dogmatic - not thinking about how to get a good solution but just thinking how to do it some prescribed way regardless whether it fits the given problem. ( my conclusion from reading and thinking about it for quite some time) Note that I am still more a beginner than anything.
brilliant. thankfully is started out with c and now most of this oop stuff seems weird and unnecessary to me. all this thinking and planning and trying to force things into boxes... multiple inheritance, virtual functions... gross. i am a beginner still so takes this with a grain of salt
Short answer no. Long answer, I'd really just watch HMH. You can only learn so much from books, you might learn techniques, but not how to program, think about problems, approach issues etc. You only learn that from experience, doing it, or seeing someone do it.
Yes I agree with you but I'm just realising that All my knoweldge about OOP will gonna be droped into my garbage memory ;( And I'm not super fancy to follow the 400 and more episodes from HMH :'(
You really don't need to watch all eps. For me, my programming style, thought process, philosophy and productivity sky-rocketed just by watching the first 30 or so eps. Then you could just cherry pick episodes and learn what you need at the time you need them. I have tons of game programming books, really all I take from them is techniques. A lot of them use OOP, just their style of programming but the concepts/tech stuff is still valid. Tricks of the 3D Gurus is one of my favs by Andre Lamothe, procedural style. Again teaches how to build an engine, but not how to program. And don't worry about dropping things in garbage, we all did that. You're getting experienced, knowing what works from what doesn't!
I am late to the game but can someone pick me up? As far as I understand, a method which acts upon the object it was called on is bad but a function which acts upon an object it was passed as reference/pointer is good?
Not really, object.method() vs function(&object) are purely semantic differences, personal preference, I use a mix and match sometimes, neither is good or bad just different. What he's referring to when he says OOP, is more of a mindset/way of thinking approach to problem solving. OOP code tends to be unnecessarily more complicated, abstractions for the sake of abstractions, a AbstractPixelFactorySingletonAdaptor just to plot a pixel on the screen, thinking about code reuse before the code is even usable in the first place, lots of deeply nested inheritance trees for things that dont even need inheritance, obsessing over 'hiding' data from the user, 1% of the time its valid, 99% of the time they're just hiding things that should've been accessible thus taking away valuable control from the user (this leans more into bad API design in general). Thinking about 'objects' in their pure form and writing solutions around that tend to produce less than optimal code in terms of cache coherency etc. Instead if you think of code as just a way to transform data from one form to another (thats all that you're doing) you'll be able to write more efficient transformations and represent data in a manner that makes much more sense to the problem you're solving. In short its thinking "what objects do I need to come up with to solve my problem" vs "what data transformations do I need to solve my problem", its a slight mindset switch but it yields massively different results in terms of the solutions.
@@vexedev I've looked into dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your-software but still have the linked videos to watch. I think I am on the brink of understanding but there are still some pieces I have do grasp. I see that I do tend to start designing classes and their relations at the beginning and that things start to get complicated very fast and that it is often hard to find a "clean" oop solution whatever that means. But I am missing the experience of how to do it instead or some real world examples. What I've read so far are abstract discussions which stop at the point where it gets interesting... In the implementation details. Will dig a little deeper maybe I can find the holly grail of enlightenment somewhere. =)
@@r2-p2 Yeah it will come from experience the more you code and try to think of simpler terms. I would say just try your best to simplify your thought process as much as possible, start by writing the most straight forward simplest solution to the problem, and iterate on that. I was confused at first when I first watched Mike Acton's talk about oop, like I didn't know how to code instead. But then I watched how Casey code and solve problems, and how simple things are, then things started to change. Also, exploring different architectures can help break the thought of always thinking in objects, e.g. ECS. (Not saying you should always do ECS, but just saying its a completely different way of thinking, and if you can wire your brain to think in that way, I'd say you've broken free from OOP)
As a beginner to programming, i just finished my OOP course and I do think its helpful (noob perspective may change) but during the course i did have thoughts like "Do we have to make this an object"
So basically the problem is that people misuse OOP. because most people i know only apply OOP incrementally as we need it.
5 ปีที่แล้ว +5
The problem is that making objects a language feature makes their design very rigid, which leads to that incremental application and organic development. If objects exist only as temporary constructs inside the minds of programmers, they are much more adaptable and powerful. If we create our objects as structs with data and functions pointers, they are much more flexible, we can use polymorphism to a much greater extent, and people are less inclined to apply OOP incrementally. OOP as a language feature was the dumbest mistake a language creator could've done. We don't need it to do OOP, and it severely limits the kind of OOP we can do. The problems of more complex and unpredictable control flow and strict boundaries that make OOP code harder to understand and refactor are still there, so it should still be used sparingly.
A program cannot be objected ORIENTED if it only use clases sporadically. What you are describing is the way most people do it, but it's not what OOP philosophy dictates.
OOP is bad depending entirely on which of the infinite amount of definitions that you use. He says it himself that objects arent the problem with OOP, yet so many people think that C# or Java is bad because everything is an object.
@@nickwilson3499 Nope! Not a required feature of OOP at all. Ints are not objects in Java, and they compile to raw data in C#. Being averse to something like that 'just because' is the real brain rot here! ;D
@@zacharychristy8928 you didn't say why it's not a bad thing... my argument was clearly not about performance. My earlier comment on the state of your brain is even more relevant.
I think theres a good OOP and a kind of dogmatic version thats overbearing where you must use design patterns and such. I actually learnt OOP by just playing around in java mostly on my own. I would also say some people just dont have a good intuition for OOP (in my experience) so use whatever works for you. I would say for me it immediately clicked and made more sense than a procedural style.
Compression oriented programming, yet how many times do you write the same syntax for loops and switches, and error handling, when all of that could be simplified using macros. See apl or k programming languages
3:54, this is the key point. FP programmers use to fail noticing that, which makes their entire point fall, because depending on how complex the project is, having all data as public (which they think is "natural") will lead to disaster!
I think it depends on your project, framework, available tools etc. OOP is nice for design and IDE completions. It makes communication easier in many ways.
Why is everybody talking about OOP as if it is some sort of cancer? I mean it is a tool, and it is important to learn where and how to use it (and there is definitely not enough preaching about function-first programming), but I deem it absolutely necessary for any larger project.
The problem is not with the notion of objects (structs are that, too). The problem is the "oriented". You should not orient your programming style towards creating objects. That's how you get the factory and service etc. It's all bullshit.
Lazy Monk You might have been exposed only to the wrong use cases. Java's paradigm is indeed a beast, and yes it's overused, but there are situations where you have relationships where using oop is actually easier to reason about. I've found it necessary in audio programming where you have such an intrinsically modular model that doing things otherwise would become cryptic a lot faster. I just don't think you can say it's never an appropriate paradigm considering how many use cases are out there. That being said I think it would be interesting to see how far you could take audio programming using functional and no inheritance or objects, but in my mind it's less tractable.
Programming as a "coding" became wide popular now days for mass and this is ok, but many of them don't even no what the big-O notation is and don't want to know. The point is, this is a business, there's a lot of courses, instructors, etc. Using and writing classess and polyphorism is nothing wrong. That is concept for reusable code presents in HMH videos. Using this for anything and anywhere with mindset of "object oriented DATA", that's a problem. Look at some code for example 90's/00's of games.
Understanding asymptotic complexity is nice and all, but even that sometimes doesn't tell you much. A simple linear scan on a linked list and an array are both O(n), but the linked list is still going to be much slower than the array, and in my opinion it's much more important to understand why that's the case rather than thinking of things in academic terms of big-O. You can have modularization and polymorphism without OOP and classes, and it'll be faster because it won't require virtual table lookups. I think having no understanding of how a program executes, what cache lines are and why memory layout is important is actually a huge problem, and a big part of why modern software is slow despite how fast hardware has become. All the slow and expensive indirection in modern software is a direct result of the OOP paradigm, and I think we're all paying dearly for it. The amount of collective man-hours wasted waiting on needlessly slow software is astronomical and has probably cost us billions of dollars in lost productivity. How many days of your life have been wasted staring at loading spinners? Those are days you're never getting back, simply because some geniuses thought it would be a good idea to teach everyone to work against the computer and chase pointers around all over the place.
I agree, big-O notation is theoretical aspect of course and by knowing it I mean know what is going on around. Generally speaking, theory becomes from practical searching and vice-versa and understanding that properly is nice but can help a lot.
To me, OOP is just a way to eliminate unnecessary concepts from code. Nothing more. Procedural: push(stack, value) //"please push value on the stack", so you got 3 objects to think of: a stack, value and implicit performer. OOP: stack.push(value) //"stack, please push value", so now you only have 2 objects to think of: a stack and value. The stack now combines the both roles, so you don't need to consider them separately, and so the code is now easier to comprehend. That's the whole point of OOP for me. Nothing dogmatic here.
I don't really understand the 'implicit performer' thing. Do you mean the CPU that actually executes your code? I think it's still there even in the method version =) Sometimes bundling functions with datatypes works fine, when the connections are obvious, like with stacks and pushing. But when you have 'cross-cutting concerns' (and really, most of the interesting stuff in your program is cross-cutting), there's no good way to assign methods to a concrete type. renderer.draw_particles(particle_system) or particle_system.draw(renderer)? message.send(reciever)? reciever.get(message)? connection.transmit(message, reciever)? When you use standalone functions, you have to spend exactly zero time worrying about that stuff, which I find to be nice, but whatever helps you reason about the program best, I guess)
I only see a syntactical difference there. push(stack,value) vs. stack.push(value). They all involve three separate identifiers and ideas: collection, function, value. I could see how the latter can maintain invariants over the stack's internals, although generic containers are probably the most straightforward uses of classes... yet they're not exactly what epitomizes OO principles, since they're very leaky abstractions (they're supposed to be).
It sounds to me like you're describing JavaScript framework programming that people learn to start from. It hasn't seemed to me like object-oriented programmers who aren't doing web stuff have any problem directly describing an algorithm and then translating it into imperative or functional or just direct instructions for a computer. it's quite possible to use object-oriented languages or languages that support object-oriented stuff to directly command a computer.
Not necessarily true. Even in static languages like C#, there are a vast amount of patterns where inheritance is utilized excessively to create a bunch of abstractions that can be utilized as a data structure that handles all future changes of the system. The only problem with that is that those abstractions cannot predict the change the data overtime in the system and at worse force programmers to commit to those abstractions (invent problems for the abstraction to be a useful solution than solve the natural existing problem). JS frameworks problematic issues for the most part aren’t mostly of OOP(exception of angular); most of the problems come from unnecessary and excessive creation of objects, overuse of higher order components, using functions as state containers and lack of discipline in profiling performance bottlenecks(large bundle sizes).
I use OOP when I need it. I use functional when I need it. I use what is best for the project at hand. Why limit your toolsets because of ideology? You only limiting yourself. The rage and anger towards OOP is honestly out of control and misguided.
@@uipo1122 What's actually important about objects isn't classes, inheritance, etc. it's the idea that you can carve out a piece of functionality and isolate it from the rest of your code to the point where in order to understand it, you don't need to hold the rest of the program in your head at the same time. OOP tries to do this by making it so that the "object" can only interact with the rest of the program through "messages" (and Alan Kay, one of the influential figures in the history of OOP, is on record saying that objects weren't the point, the *messages* were), meaning you can understand the object's behaviour in terms of those messages only. There are useful side effects of this isolation, in addition to needing to hold less in your head at once: * because the object is entirely focused on the specific functionality it provides, sometimes multiple copies of the object ("instances") can be used to reduce duplication in the same way that a function can save you from repeating particular sequences of individual lines of code; the exact circumstances of its user code is unimportant because the object only needs to care about itself and perhaps its immediate dependencies (other objects that it sends messages to) * because all interactions go through "messages", it becomes easier to swap objects for other objects that respond to the same messages with the same general semantics (which is to say, they "implement the same interface"); in some cases this is very useful, because it means the program can alter its own behaviour in a succinct way by swapping which object responds to a particular set of messages * related to both of the above, and much like with functional programming, it becomes easier to put the "object" alone in a test harness and verify that it behaves as expected automatically, which saves programmer and QA time; test driven development is based around the idea that putting the code in a test harness *first* will force the code to evolve in such a way that it is as focused and atomic as described above. As I said, though, this isn't unique to OOP, functional programming is another way things could evolve. If those benefits are valuable to you and are not outweighed by other concerns (eg. performance of virtual dispatch in very low level code), then you will not find OOP useless. I find OOP is perfectly useful for structuring things at the large scale where these benefits most matter. It's the use of it at the fine detail level (ie. pure, academic OO code where *everything* must be an object that interacts through messages) where it can make things unnecessarily fussy.
@@babgab That's theory, it has nothing to do with reality. Practice is the criterion of truth. If your new programming thing doesn't help solving problems in the real world (spoiler: it doesn't) then it's not good. > ... you don't need to hold the rest of the program in your head at the same time If you want to produce a quality product you absolutely need to know how the rest of the system works. The whole idea of "I will build this module as a black box and provide a public api" just doesn't work. It's fine to use black boxes to save time if you are working on the project. But it is always better to know what actually is happening in those black boxes. And the current programming culture discourages you from trying to understand how stuff works. > ... it becomes easier to swap objects for other objects that respond to the same messages with the same general semantics You don't need this level of modularity 99% of the time. BUT if you really encounter a situation where you need it there is this thing called "function pointers", I know that's probably alien technology but it solves the problem. > If those benefits are valuable to you and are not outweighed by other concerns (eg. performance of virtual dispatch in very low level code) Performance is indeed an argument against OOP (not the the only one). >I find OOP is perfectly useful for structuring things at the large scale where these benefits most matter. I find that writing the code and organizing it is never the problem. The code is just a minor thing that gets transformed by this program called "compiler" to run on my CPU. The real problem is design - understanding the thing I am trying to program. Making it efficient and minimizing complexity. And OOP the opposite of that. It builds structure prematurely. And any premature structure will always be wrong, structures in the program should emerge naturally, not by drawing UML diagrams and deciding that that's the thing. Wrong structures lead to accidental complexity and accidental complexity kills projects. Modularity that interfaces (/function pointers) provide is not needed most of the time. It is a very specific thing needed for very specific situations and you don't need OOP for that.
Why the hate on OOP? A minimal use of it is good. You know what I hate? Those Cpp template classes? What garbage! Use a runtime type system like Objective-C / Swift and downcast safely! I code in X++ daily, it is fine but honestly, use static members as much as possible, just use classes for namespace mostly.
Objective-C/Swift is so much slower than optimized well written C++. I liked Objective-C much but there is a reason why it is only used in the GUI layer and nowhere else.
@@llothar68 Runtime dynamic type checking does not come for free. Use only where necessary. Still, was best option vs. CORBA and Java and interpreted that were the contemporaries. Actually, my intro to Objective-C was with K&C compiler and I'd used it on a War Games Simulator for Defence Research Organization. It was not GUI. Although, there was a separate service you could attach and you'd get a gui representation of the simulation in real time. Even with realtime type checking, there was a warm up phase where string types are resolved and subequent instance use was faster.
@@kippie80 I was an Eiffel programmer. So much could have been avoided if the world had not gone with the c++ object model , the VMT dispatch and the concept of dynamic linking and separate compile units. That’s rooting 1970s technology
Me & 4 other programmers sit down to plan a code project. Me: So, have you ever started by thinking about the basic operations required by the CPU to transform some data? Them, OOP educated: u wut? Me: 😩
That's not them "being oop educated"... That's just you being horrible at communication and possibly have a slight degree of autism. Why would you ever word it in such a stupid way?
This seems like a huge over-reaction to the drawbacks of object oriented programming. Class-based OOP simply allows one to extend the language with their own more abstract primitives. In a language which supports OOP, a HashMap can be a primitive in the same way that the built-in array type is a primitive.The only difference between a HashMap in a C-style functional language and a HashMap in an object oriented language is the way in which you interact with it syntactically. Some languages like Go and Python make this obvious by requiring that one explicitly declare a function's receiver as a parameter. In any complex system there's going to be a set of components (objects), and a set of standalone functions. Where people go wrong is when they take a dogmatic view that OOP is bad or that plain functional programming is bad.
Factories, builders, and containers are all just design patterns on-top of OOP. Some design pattern you read from a book isn't necessarily a good abstraction. Nor is it the essence of OOP.
Dogmatic thinking is probably a natural stage in a programmer's evolution. Some are never put into the situations that force them to outgrow that dogmatism, though.
Of course you can't use it successfully if you haven't yet wrapped your head around the basics! It's the same problem with math, people are just shit at both! And no wonder really, most of the resources online have less insight into the topic than a daily mail article.
Trying to "avoid OOP" is a silly, and often purely ideologically idea. OOP certainly has it's place and can make your code FAR more maintainable. The fastest code isn't always the best code, especially when you're working on large enterprise applications where maintainability and correctness are far more important than optimization. Of course you should always strive to write clean code, also fast code, but fast is a relative term. Fast relative to what? In a game engine, it has to be blazing fast, that said, I wouldn't litter the hot-path in my game engine with virtual method calls. In a situation where you're writing a back-end service that calculates shipping costs across various countries, having good abstraction is certainly better than shaving off a few milliseconds. A lot of junior devs are under the impression that OOP is just about "putting things in a class". OOP concepts are far bigger than that, and various OOP driven design patterns can make your work far better and more pleasant.
The problem with OOP is not that there might be a class or an interface or an abstraction where it makes sense. The problems start when you _orient_ your whole thinking around constructing these object trees instead of writing code to solve the actual problem you have, to do the actual computation you want to do.
@@SiisKolkytEurooObject trees? What are you talking about? You basically said "The problem is not OOP abstractions, but poor uses of OOP (object trees)." Yes, correct, lol, I don't care what bad programmers do with OOP, I care about the core principles. I don't understand what you mean "instead of doing actual computation". Writing classes, interfaces or design patterns doesn't mean you're not writing computations and algorithms, it simply means you write APIs that lend themselves well to abstraction, large-scale code reuse and extensibility. That is why OOP focused languages like C# and Java have dominated in the enterprise. I've spent the last 20 years writing solutions that require malleability, long term maintenance and testability, this is where OOP shines. The arguments I read against OOP stink like dogmatic amateurism.
@@NickEnchevAll of us *should* care about what bad programmers and dogmatic amateurs do with OOP. We exist in the same industry as them. In fact, I'd venture a guess that most programmers are bad, which means bad programmers are difficult to avoid and maintaining their bad code is even more difficult to avoid. I have actually seen arguments *for* OOP on the grounds that bad programmers' bad code can be encapsulated and isolated away from the better stuff. :D I would also point out that you're in the comments of a video originally posted by a game (and game middleware) programmer. A game programmer critiquing OOP is going to critique it from within the context of game development, which due to various industry structural factors has not historically valued (automatic) testability, long-term maintenance, code malleability, or even hiring experienced programmers. Most of us are not going to care that OOP is great for some shipping cost calculator; for us, in the days of 240hz refresh rates and ever escalating visual quality bars, a few milliseconds is a horrifically long time, and for some of us the object spaghetti our OOP-dogmatist coworkers produce is an active impediment to our ability to deliver a product on time. Not to mention to our calm as we try to find "the code that actually does something" in the rat's nest of factories and visitors and adapters and facades that is the product of an inexperienced and dogmatic OOP practitioner, whose main exposure to OOP has been through an undergraduate course evaluated with a *paper* exam, so we can actually do our job of maintaining the code. People you talk to in the game industry generally find it more valuable to evaluate OOP with the code that is actually written by its usual practitioners, in the context where they are actually working, than to consider what a many-year veteran of an industry (that has wildly different from values from our own) would do with the concepts in hypothetical scenarios that they will never experience. So, in this comments section, I suggest that talking about what's valuable to experienced enterprise devs is a discourse that requires recalibration.
As the video mentions, OOP isn't entirely bad in all cases. It's the "structurally orienting the code around OOP all the time" that's not very efficient. Computers work on data, so writing code that favors that is the most efficient way of programming a computer to do things.
If you don't abstract away complexity, making reusable systems, how would you ever create a program bigger than one file? Sounds like you are a fan of putting every single line of code inside one file. If you use colors, you should white the hex value each time, you cant create a Color-class that holds the hex value, that you can then reference from different places in your code, that is "bad". It's much "better" to have the hex value many places in your code. And then if you decide to change color, now you have to change it 3884 places in your code. Much better.
> you cant create a Color-class that holds the hex value You don't need a class, you just put constants in a separate file and use it. The problem is languages like Java and C# force everything to be inside a class and then you get all these static classes that are really small namespaces.
Actually, yes... you should start by repeating the HEX value throughout your code. Only when it becomes repetitive, at least 3 or more instances, do you factor it out. With a rigid OOP mindset, you could end up with a color class for an application that only needs to reference it in two places.
You don't need a color class. Colors are nothing more than #define WET_ASPHALT 0x... declared in colors.h that you include anywhere you need a color value. He is a fan of monolithic files, yes. Yet he clearly separates them into dedicated “modules” like platform, math, game, entity etc.
OOP is not a coding paradigm. That's the most shameful and harmful misconception. OOP is an analysis and design paradigm. The reason why many people fail to use it is because they are using it wrong. If you want to open an editor and start coding classes, you are defeated from the very first line of code
@@Vitorruy1 So what...? The fact that oop is an analysis and design paradigm doesn't prevent people from building tools and languages around the concepts. Even more, it creates implementation paradigms. But do this: ask any of those gurus if it is possible to do the same thing with different languages and how they would proceed :-) Pretty sure they will be more than happy to show you the real essence of oop. Unless... you talk to a C++, or Java, or Assembler guru. That's a different story
Wow, a guy who did not understand OOP at all says it is bad. Well, have you considered the possibility it went over your head? By the way, your idea that you should think like a computer is regressive at least and absolutely stupid at most. You have to think in terms of objects if you want to write in OO style. Read Object Thinking by David West.
I just wondered why Casey had shut down the comments in his own videos, what could be so stupid that it would warrant closing down the whole comment section for the rest of us. And then I saw your comment.
It makes me laugh to see people slagging off OOP like it's a massive mistake. It's a tool like everything else. You use the right tool for the job. Also if you don't have a good knowledge of OOP good luck getting a job.
That's a lot of the point, though. OOP is the best tool to get many programming jobs. Once there, it's the tool you *will* use, because you're stuck in Java, C#, or a very OO Javascript or Python framework, because that's what the team is using. It's shoehorned into being called a good way to solve many problems for reasons of business politics, but that part isn't taught.
It took me about 3 years to get a handhold on OOP. It just wasn't hard after that. Programming, good design, all these in general hard, even in a functional or procedural language.
Well I would say that OOP is useless, I stand by that pretty strongly, but if you want realistic workable unambiguous abstraction amd organization, then functional is the way to go. Functional is naturaly the "correct" way, because it is built up from category theory, which is a very natural foundation to mathematics. You think of the programs like boxes that take input and put out output. In category this would mean that you start at an object and want to get to another object, so you get there by composing morphisms(arrows), which is what you do in functional languages. You decompose your problem into the smallest bits possible, write the functions(morphisms) and then compose them together to get the final result. Im not that familiar with category theory yet and I might have said some wrong things, but I think that is basically how it works. This is the most natural, clean, abstract, organized, etc, way to do programming IMO. But its not the most useful one, sometimes we dont really care, but just want to get things to work, work fast and make them still as reliable as possible. Then procedural is the next best thing IMO, which is why python and java script are two of the most popular languages out there. Yes python does support OOP, but seriously, how many people do actually actively use OOP in python other than to break up huge chunks of their programs into a bit smaller pieces, its not like they actually use OOP like its meant to be used, but just so that stuff is a bit cleaner. Remember, you dont have sth like structs in python really, you only have classes. That was a rant and a half
@@berserker8884 You are kind of lost and also mixing and talking about two different things. In real life we do think about actions and properties, not only actions. That's a point for the object abstraction. But also, OOP is about design and analysis, not coding. You can (an should) think your problems from the OOP perspective and code it finally in whatever you need, even assembly languaje, or english! :-) OOP provides you with the most complete toolset you need(until now) to organize the implementation in any context
@@ramireznoy first of all, why cant you describe all properties via actions only? Thats the whole point of category theory and it just happens to be the prefered way of understanding things in modern mathematics. You dont talk about what the objects are, you only talk about how they are related. Secondly, why should I think of things in OOP way? Yeah abstraction is wonderful, but again, catgeory theory is, IMO, a much better way to go and understand things. And if you talk about organizing things and making them clean, you dont need OOP because thats not what its about, you can be organized without OOP. In fact, solving a difficult math problem might go much better if you look at things from universal properties stand point, than from your down to earth intuitive set theoretic way. OOP goes even further than that and just seems like a messy paradigm that engineers threw together to organize things, but it definitely seems to lead to great confusion, overengineering with uncesessary "protection" and "features", etc. And if you dont use those things, then you arent even doing OOP... Im admitedly not an expert here, but Im talking from experience of always finding it much cleaner to organize things in a free relational manner, while programming things by just solving the problems one at a time, either conpletely cleanly ina functional setting, or doing it normally in procedural manner. Im not saying noone is using OOP, in fact Id bet most professional software like Adobe and Mathematica were built with help of OOP, but I myself and many other programmers just simply dont use it, because we see no reason to. Finally, Ive never worked on an enterprise level project, so I have no experience in that and it might be that with such massive projects OOP might help, but again, I myself think that there are better ways to handle it, or at least that there is room for improvement. I just dont buy into "objects have private properties" kind of thibking, too dangerous for me. And there is a reason why data base design is nothing like OOP, at all.
@@berserker8884 That's fine. Don't forget we are talking about tools. So, the same way you can use a chainsaw or even a screw-driver to build a chair, despite the fact those are not the best tools for the job. All things considered, software development is a reality chunck in which results are what matters. But... what do you consider a "result" for your specific problem? There are two extremes. 1. If all you care is the running code or just coding something, go ahead! It doesn't actually matter how do you get there. As long as it works, anything else will make none or little difference. 2. If you want to Build software as a product and you want to achieve certain predictability in delivery times, quality, security and maintainability, then you will need to think twice before doing things as an artisan. I am not implying by any chance there is an absolutely better way to get there. But the only battle-tested one until now, is using OOP design approach. This may change in the future sure, and it will. But in any case the new paradigm will need to be build on top of the current knowledge. Now, answering your questions: a) why cant you describe all properties via actions only? Sure you can, but is that as "natural" as you claim? To put things simple: at some point, you will need variable values. How could your model then assume those are actions without forcing abstraction? What if that variable needs to be a complex structure or even a completely independent entity? The whole idea behind abstractions is to map and simplify, not to be enforced. If you enforce abstraction, you are doing it wrong. b) why should I think of things in OOP way? You don't have to. But even refusing to use OOP concepts in the conventional way, you are still using OOP components. File, Process, Threads, Event, Program, Table, JSON, UI component... are all objects and/or object instances depending how do you use them. At some point, if you don't want to drive yourself crazy, or you are not a masochist, you will need such an abstractions into your code and use them accordingly to the implementation style they are designed for. You may not notice that from your code, but you are just handling abstract objects through their properties and actions. Even your mentioned category theory uses categories, objects and morphisms, that clearly makes the category theory a perfect match for analyzing any implementation from the OOP perspective. c) The "great confusion" you are talking about is often a result of bad practice or missunderstanding. But that by itself doesn't validates avoiding the practice and use of OOP design. I agree you may not need OOP for every single aspect of a code, specially the funcitonal parts, but you may agree with me anyone can make a mess using any tool. You can take for example, the classic paint-like app, implement it with both: using the OOP design and going stright to code business to make it work. Then verify by yourself a couple of points after finishing. 1. How long it took me, alone 2. How long it would take me with a dev team. Considering paralellizing as much as possible to make sense of hiring more people and finish faster and testing the code 3. How easy is to maintain and modify current features or incorporate new ones, like for example handling layers, saving and reading many formats, cloud storage and consuming external plugins or even adding internationalization. 4. How easy is to make an on-board process for new developers with zero previous experience in your architecture 5. How easy can I apply much of the code and/or the architecture in a similar problem like for example crating block diagrams or painting 3D objects 6. How easy is to translate my solution between languages or port the solution to be web based, or mobile based. 7. How possible is to take lessons and patterns out of my experience that can lead me to speed up my development the next time, regardless the problem to be solved. d) I just don't buy into "objects have private properties" kind of thinking, too dangerous for me. And there is a reason why data base design is nothing like OOP, at all. Databases are all about objects :-) The fact that you miss private, public, inheritance, class, instance in some of the available DBMS, doesn't mean the OOP paradigm is absent. Even in a NoSQL database you must consider properties and actions, relationships between instances and distinguish schema from record. But in any case, OOP is not about private and public properties :-) those concepts are implementation specific, and very useful when you have a complex system and you want to ensure that despite your library being used by many others in the same final software, your base implementation remains intact and reliable by your specifications. But OOP is actually easier than that, so easy that it shows up kind of automatically. Just try to not to forget OOP is a design and analysis tool set, not a programming methodology nor language. Currently, it looks like you are trying to eat the carrot before pulling it from the ground. If you are interested in learning how to use OOP tools, I highly recommend you the following book. If you are in rush and have the basic knowledge, you may want to jump straight into chapter (hour) 16 - 17 read.pudn.com/downloads140/ebook/601014/Teach%20Yourself%20UML%20in%2024%20Hours%20Complete%20Starter%20Kit%20(3rd%20Edition).pdf
@@ramireznoy I hear your argument and like I said, I dont have experience in large enterprise projects where OOP is definitely dominant and very useful. Few things still. 1. You don't need to ever encounter "variables" in functional design for the most part, other than when you have to deal with IO and some other rare things. 2. Data base design is nothing like OOP. What makes OOP the OOP is the class diagram structure, which is to say you design classes, how they are all "connected" via inheritence and object membership, etc, but that is not like database design, which looks similar at first glance, but differs in many key points. 3. Again, to me it seems like you are trying to sell me data abstraction in general, which I agree plays a large role in design, analysis and implementation, but Im specifically talking about OOP data abstraction. But I think I agree with your point that OOP is reliable when it comes to different implementations and people understanding your design, simply because it is the most widely known and used way to abstract data. 4. The confusion comes from the fact that OOP "forces" you into rigid object design, they cannot be meta modified. Hence here in comes a large difference between OOP and database design, in which entity component diagrams are the backbone. This is why most game devs don't love to use OOP for their game design, because it really forces them into rigidity. Sometimes devs go overboard and overengineer thinga on both ends, but in many situations OOP can be too rigit. Im not saying things cant be done or cant be designed, but im just saying that a lot of times its just a pain when you need 10 things to be all intertwined and changing fundementally in real time. Here you can make the objects have bezillion million properties, or you can have inheritence, which limits you to no end as we all know, OR you can have an entity component system in which you swap in and out the components in real time. And here I agree with Blow that people overengineer entity component systems and focus way too much on them. Other than that, I understand your argument yeah. OOP is a tested way of desnigning things that worked well so far and that is why it should be learned and why it is widely used.
"Is pixel an object or a group of objects? Is there a container? Do I have to ask a factory to get me a color?" I literally died there... that's literally the best description of my programming for the last 5 years.
Also, if one thinks of pixels as objects in the OO-sense, an entire 1920*1080 frame will start to feel too big and slow.
Roughly a decade ago I wrote a quick Mandelbrot example in C for a friend of mine who wanted to learn some simple graphics programming. He had only written JavaScript for web projects. When he saw my example and the double for-loop where I looped over the pixel buffer, he couldn't understand how it ran so fast. He also couldn't understand that the pixels weren't objects, but concise data that was laid out contiguously in memory.
type "F" in chat for @@miikavihersaari3104's friend...
@@miikavihersaari3104 That's pretty awful for them, but it proves something that i've been saying for a while. New school programmers have no knowledge about basic IT and computers and have only been taught how to use a bunch of black box abstractions without learning how they really work. :(
What about each of the colour channels? Do they need to be objects too? :p
@@wilfridtaylor I literally had no idea I had a comment with 450 likes here.
No, you actually need an abstract base class for a property of the pixel, and its child class PixelColorProperty, which you then construct an abstract factory class PixelColorPropertyFactory for, which then returns the concrete red color by constructing it from the central ColorFactory class, and you have to use dependency injection to specify which ColorFactory it is that you want(it needs to implement the IColorFactory interface though).
This gross oversimplification is obviously only intended for read-only scenarios.
I have to thank C a lot for protecting me from OOP during the months I was learning the fundamentals.
thats why i ask people who are starting out these days to start with golang. imo its the modern c.
"I want to emphasize that the problem with object-oriented programming is not the concept that there could be an object. The problem with it is the fact that you're orienting your program, the thinking, around the object, not the function. So it's the orientation that's bad about it, NOT whether you end up with an object. And it's a really important distinction to understand."
I find that most people in the web and CRUD app world are completely locked into OOP thinking, so this is quite refreshing.
My favorite example is RESTful API.
Backend then, is not even supposed to deal with state. But backend developers do a bunch of classes, state manipulation back and forth, just because OOP dictate that design.
They artifically for each API call create temporary state(and a lot of it, not just local variable with data from database) and destory it after.
I mean, are they? I've seem plenty of Javascript and Python code that's a lot more procedural, and sometimes even almost functional. I mean, they still suck because they're Javascript and Python, but definitely not OOP.
They're stuck because that's that gets preached to beginners
Usually a fake OOP or a partial OOP
I've yet to see an actual Alan Kay style OOP as a web application with the exception of possibly MicroServices
@@franciscofarias6385that's a relatively new phenomenon. Even just 10 years ago it was mostly Java (for those who had moved on from PHP). JS on the backend has only been about the past 5-10 years
This is so true. I wrote OOP style for 10-15 years. Eventually I started playing around with functional programming and it changed everything for me. I now try to design in terms of functions and how I can transform data from one state to another. It makes code much easier to reason about (just inputs and outputs), easier to compose, and often means you don't end up with silly abstractions that only make sense if you try to put your problems into the "box" of objects. Treating everything as objects means you have to write more code to handle this abstraction that you might not even need.
Unfortunately, when I first started programming, I encountered nothing but tutorials that jumped right into OOP like it was the only way to program. And of course I didn't know any better! So much friction has been removed from my process since I've broken free from that state of mind. It's easier to judge when objects are appropriate when you don't think they're always appropriate!
fascinates me to look in on the OOP world from the outside. basically looks like utilities made for dealing with shared state in a simulation got prematurely made universal on everyone
i like the way you put it
I made a game 4 years ago. Then I learned OOP and now I haven't finished any projects since
That only means you are using it wrong... or you didn't learn it
we are all fucking struggling with OOP mindset. It brainwashed us. You are absolutely correct. It is not OOP, it is OOLess
Bayram İnanç i finishes projects OPP and functional, both work fine
@@ramireznoy the problem is OOP points you towards using it wrong time and time again. And good OOP looks more and more like other programming paradigms as time goes on, and has morphed into nothing like what OOP was 20 years ago. It's really one of the worst programming paradigms today because it's harder to use correctly for the same payoff.
@@bobbycrosby9765 A paradigm does not change, otherwise it is not. I think you are confusing programming language with programming paradigm. Or even worst, confusing implementation with design and analysis since OOP is NOT a coding paradigm, it is an analysis and design paradigm you can use anywhere, also for coding.
It doesn't points you to anywhere the same way a framework doesn't points you to anywhere neither. It is just a set of tools and principles you can decide to use or not depending on how complex is your problem. The bigger and/or more complex the problem, the shinier the OOP approach
Learned C# first and that was a huge mistake. Programming got all exciting when I learned C
me too dude and I feel like this is mostly unity’s fault
@@vzvdm u need to learn .net's best pratice not unity to learn C#
@@keaganroos2288 c is the only language i know 100% what is happening
Now you can go back to C# and use it from a different perspective.
I don't think that people shouldn't learn stuff like C# or Java, BUT FOR THE LOVE OF GOD please start with C
I lost an entire decade to OOP, and agree with everything Casey said here. The code I wrote in my first year as a programmer (before OOP) was better than the code I wrote in my 15th year (OOP expert). It's a shame that students are still indoctrinated into this regressive model.
Also, as a professional customer of Casey's work, I totally vouch for his judgement in software architecture and API design. Granny3D (we were on version 2, iirc - we used it for animation) remains my favorite middleware of all time.
Similar experience. Though I was poisoned with the OO mindset from day 1 at university. After 15 years as a professional I am only now awake enough to question the sacred cow and realize what a terrible, terrible idea it is in almost every instance (pun intended).
Just recently I realised my OOP college really messed up me, not because OOP is inherently bad, but it's the only way I've ever learned + worked at programming. Now I almost always get caught in an infinite conceptual loop, refactoring, losing sight of the original problem. I actually can't think in different terms
I was taught OOP first (Java in my case). My tip would be to try functional programming. Functional will require you to learn new ways of thinking about a program and push you to decompose problems in a much more data oriented way. It is kinda like jumping head first into the cold water instead of slowing wading out in it. Functional will be so increadibly strange and foreign to you that you can't lean at all on your old OOP reflexes. For me it was hard when first time looking at C code to not think of it as less complex OOP code. I needed that complete confusion functional code gave me the first couple of times to shake old habits off. If you while working a bit with functional at the same time look a bit at some C code you will realize how in a lot of ways it is more close to a functional mindset than an OOP way of looking at it.
Some kind of combination of this was what made me realize the limitations of OOP. I think the map and filter streams in Java 8 was the first step on that journey (they seemed so practical and cool to use) and then I tried to learn functional by myself at the same time as we had some introductions to C in school.
I am sure you meant procedural there and not functional.
Functional programming is something totally different and C is highly imperative by nature.
@@nishanth6403 No, I am pretty sure I meant Functional. But this was 4 years ago, I don't fully remember what I was thinking when I wrote this comment. It is not a very good comment looking back at it, but I still agree with the general idea. And yes, I definitely meant Functional.
I guess it depends on what characteristics you require of a "functional" language. If you require the language to be based on lambda calculus then, yes, C is not that. C is procedural at its core and "good" C code will probably always be very imperative, but I would argue one could definitely write code leaning towards the functional paradigm in it.
Programming language "paradigms" are not very well defined terms and functional programming imo is probably one of the most illdefined of them all. In the definition of functional programming there are a bunch of things that practitioners of functional programming thinks are good design principles, things like:
- Pure functions whenever possible.
- Immutability.
- Composition and higher order functions.
- Recursion instead of iteration.
- Functional datastructures.
Most of these are just good design patterns . All languages that are usually called functional make use of most of these, but they differ usually somewhat in how much focus they put on each of these.
It is usually possible to write code in whatever paradigm in most languages. I can give multiple examples of this:
- It is possible to write very functional code in Common Lisp (it is a lisp, how much more functional can you get), but at the same time CL was one of the first langs to have Objects in the language - so you can write very OOP-code in it too.
- OCaml is a great functional language, but it also has a loop construct making it possible to write quite imperative and procedural code in it too.
- Java is probably the mainstay OOP language, yet it has the very functional-inspired high order functions; map and filter (which I mention in my original comment).
- And finally, yes, you can write functional code in C - by making good use of function pointers for composition, having pure functions whenever possible, keeping immutability as much as possible. You probably shouldn't use recursion much though.
I would say you have a very limiting way of thinking about functional programming if you don't think its design patterns and insights could be transferred to other languages that are not "as functional". If this is the case I would almost hesitate to say you have learned functional programming very well at all and maybe should go back and look at it again.
Sorry that this comment got so long. Your comment hit a nerve with me, I guess, and I felt I had to present my arguments against it properly.
In sum: objects are not the problem, but *orienting* you program *around objects*. Program thinking on *what the CPU must do*, write *functions* that get the job done first. THEN you simplify stuff.
I like that he pronounces OOP like oop. Like it was a mistake: "oops!"
and also it's only one consonant away from poop!
2:20 «Do I need to abstract the concept of a screen? Should red be an object? Is a pixel an object or is that a group of objects? Is there a container? Do I have to ask a factory get me a color and that color is red?»
Oddly enough some of the above can be useful. Abstracting the concept of the screen can make it so that your game can run without a screen (eg. if you want a version of your game that runs on a cloud server for multiplayer games and you want to discard visual output entirely), or let you "mock" the screen so you can test code that writes to it automatically without the hassle (for the computer) of the actual screen involved. Or if you want to log everything being sent to the screen in addition to actually displaying it, for later debugging purposes. Making "red" be an object means that it becomes possible to reference the colour red by name in your program, which sometimes has its uses. Don't think you need a factory to get it, though, typically when I see "red" as an object it's a global constant.
@@babgab You're proposing to discard the visual output... instead of not producing any visual results in the first place. That's some very broken thinking right there.
@@etodemerzel2627 In a testing context, discarding output sent to a mock is fine if that output isn't relevant or even produced by the code you're actually trying to test. That's kind of the *point* of a mock, actually. This situation can happen when adding tests to an existing codebase that wasn't written to consider testability. You might just want to test (for example) that a player can walk from A to B, which *shouldn't* need screen output to verify, but the game code you're dealing with may be hard to put in a test harness on its own. It may for example keep all of its state in global variables or keep its state in some structure that can't be instantiated properly without the entire engine being up and running (including video output being turned on). Both of those are pretty common design choices in video games.
In principle, you could refactor all that out, given enough time, but sometimes you don't have that time. Sometimes a refactoring to do things "properly" would take *years* for a team of experts on that specific system and all its warts and corner cases, and your manager won't give you years; they (and probably you) want that test NOW. I'm not generally a fan of mocking, either, because of how much "test-induced damage" it causes to one's interfaces, but it IS useful sometimes.
Same thing could happen in the dedicated server case. Maybe you're remastering an old game with a codebase that would take months to properly make it not tell the renderer to draw some stuff on the screen because the code (which you didn't write) is spaghetti, but you need it to start running in a cloud server in a week or you won't make your ship date. Spending those months isn't an option given to you, so you have to make do with what you have. If this happens on the level of individual pixel draws, then that's a pretty pathological case, but stuff like that does happen. I seem to recall hearing that StarCraft's remastering ran into some problems like that where the actual visual appearance of some units was tied into the gameplay logic and upscaling the sprites broke gameplay.
I find that "broken thinking" in software development is often a reaction or adaptation to "broken situations." Much of software's ongoing enshittification can probably be blamed on "broken situations." Or at the very least, "broken incentives."
The first language I was taught was Java, so I was taught OOP from the get go. Removing the OOP mindset was actually really easy, but what was left stuck in my head is the practice of having small functions and make your code look artificially "clean". So I am in a constant struggle of refactoring and not refactoring, knowing that over-refactoring will unnecessarily complicate my codebase if it gets big. Even after removing my OOP mindset, my emphasis is still on the code itself, and that is much harder to cure in comparison.
java is a terrible first language. Sadly more and more people start with it...
ya, especially in schools, very sad indeed.
Java was my first language (still learning) and I've been wanting to learn c after starting nand2tetris, because the inner workings of the computer fascinate me. Hence the handmade hero.
@@theitatit Why do you think java is a terrible first language?
@@RoscleHilltopple It is purely centered around OOP. People who are just starting with programming should only be using procedural languages, or languages that allow procedural code. OOP is just plain garbage. Inheritance is hit-or-miss, Encapsulation is worthless (instead of creating a public member variable, I'll just make a private member variable and then write a public method for getting the variable's value and a public method for setting the variable's value; thanks Java!), and you can achieve Polymorphism easily without OOP (function overloading for example).
I am very happy I learned how to program by myself 25 years ago and not at school or uni, and did not learn OOP first. I do use OOP though, since I learned it four years ago. But I only use it if I am going to use the features of OOP. I will never automatically make something a class just because it's 'the right/professional/trendy thing to do'. So I always start by looking at what I plan to do with what I'm declaring, and use the features of the language I know that best suit that.
Years ago, I was struggled with my engine project with oop mindset. It’s impossible or unefficent to design a system with oop that you never build already. As the video said, It’s ok to end up using oop. Just don’t start with it.
I suggest giving LISP/Racket a turn around the block if you have a need to rid your mind of oop. These are likely to be mind-bending if you are new to them and are pretty simple to get a functioning environment up and running.
I could never wrap my mind around OOP. Common Lisp taught me to program. I now write mostly in C and while I've gotten my feet wet in other languages (most of which aren't worth mentioning), and have a little knowledge of and appreciation for certain others such as Forth and Standard ML, I have very little interest in other "popular" languages outside of C. Lisp still has a special place in my heart and if I need to get something done fast, CL is my friend. I still don't get OOP, but at least I no longer feel like I'm missing out!
let the problem tell you how it wants to be solved.
Tagged unions (sum types) and pattern matching solve a lot of problems that OOP hideously fails at. And yet there are still people trying to defend Visitors and Factories instead of using tagged unions.
whenever i code something in a language which has classes, i just look at them as c structs. coz thats basically what they are. in some rare ocassions i do put methods inside them though, just for convenience. but rarely.
This is a great explanation of how to make your life simple as a programmer. The way I think of it is to start with static classes, and only make non-static classes as needed.
I'm fan of OOP (C#) and feel like it's honestly helped me become a better developer, but I can also agree that thinking of everything as an "object" can be counter productive.
If you have a bunch of related data and keeping it together makes it easier to read & write your code, put it in an object.
If you have a a bunch of related data, have some standard ways you need to interact with it, and keeping it together makes it easier to read & write your code, put it in an object.
As soon as it makes it harder to read and write your code, consider either doing things differently or at least thinking about it differently. Will separating the data and functionality make it easier, for example? Well then just do that, don't sweat it.
For me, I'm happier thinking in terms of modules, not really much different than you'd find in JavaScript (e.g. util functions & complex reusable logic that for data transformations for example). At the end of the day, I'm just bundling up some functionality and passing it around; why make it more complicated than that?
I don't even know what people mean when they say OOP anymore. I once read a tutorial about how OOP was terrible and you should use entity component sytems. The programming language they used to implement their ECS was ruby, where everything is literally an object.
I don't think people know what they mean when they say OOP anymore either...
Classes do not equal oop. You could use classes. Bundle stuff that belongs together in them. Avoid polymorphism mostly and even do functional programming in the classes. You use classes but that is not oop
At the heart of OOP is encapsulation of a sort that bundles all related data and logic together. ECS isn't OOP since it distributes the bulk, if not all logic, into systems and most, if not all, data into components. At the heart of ECS is a very big separation of data away from logic which is fundamentally anti-OOP.
@@darkengine5931 ECS is an architecture pattern, it can't be anti-OOP. It's like saying that using only one file for a program is anti-OOP. You can replace ECS with MVC and you still get a similar thing, though working on events rather than on calling other code directly.
It's even better than MVC, because it's closer to original term of OOP.
@@doktoracula7017 A lot of the incompatibility I see with at least common interpretations of OOP and how it's taught in CS vs. at least a pure ECS is that the ECS fundamentally abandons the concept of encapsulation, including information hiding. Components become pure data, publicly-accessible by any system, while systems contain the functions that process and transform that data. That basic separation of data from functions rather than bundling them together makes the ECS seem far more in line with procedural or functional programming as I see it. I can't really pick out anything like an "object" from an ECS in the sense of something that has both state and functionality combined together. I see systems that have functionality but no state, and components that have state but no functionality.
I learned BASIC as a kid but when OOP came along, I set my programming hobby aside and never pursued it. Now I'm learning again and working in C I'm relieved how familiar it seems
1:34 basically, go back and learn imperative
I think schools should teach at least 3 languages / paradigms, C for Procedural, Java for OOP, and Scheme (or any Lisp-style languages) for Functional paradigms.
Most oop languages are procedural languages
Replace Java with C# or C++ and I'll agree with you. Especially with C++ since it will be pretty easy to jump from C to C++.
I learned Java, Haskell and Prolog in my first semester of university at least. Unfortunately java and OOP was still the main focus.
My question to those who reject OOP: given the popularity of OOP (for better or worse), how do you manage in team settings where you're the odd one out? I understand that OOP isn't the end-all-be-all for every scenario on earth, but how do you navigate collaborating with others who exclusively use it?
Don't fight it. If you're working in a framework/environment/codebase that's OOP-based there's no way around it, just work with it, you'll be in for a lot of headaches otherwise. The point is just to not make things over complicated, keep things simple, do only the things you need to do to solve a problem, don't abstract for the sake of abstraction, you can do that in any style of programming or language.
I feel like as a novice programmer I should master the OOP mindset or at least understand it well. It's a way to wrangle in imperative code. And then after that you can know why or why not you should use a certain way of doing something.
Like what are we even talking about? What parts of OOP are good and bad? Is this the same "don't abstract until you have to"?
Learn all types of programming.
I would probably agree. Try to make a project with a decent scale/size using OOP and whatever principles they teach in schools, then try Casey's way, expose yourself to as many ideas/methods of programming and pick what you like most/what works for your application.
I began to get rid of OOP mindset, when I switched from mobile dev to game dev/game engine dev. As soon as I hit a critical issues in new fields, I realized I need to try write more data oriented code and think more about my platform. You won't believe but it is much more exciting than programming with OOP design architecture and building UML diagrams or any other virtual stuff that is unnecessary. I didn't completely ignore such things as inheritance, composition and template programming, since they are comfortable for me and I can live with that :)
Second thing, I throw out the window was - design patterns, clean code and SOLID principles. Absolutely useless stuff that didn't really payoff in real world projects and creates more bugs and slows down your perfomance.
Instead, I am creating my own kinda "rules of coding" for each project and publish it in Confluence document for my team.
Pure detox: go program on a Commodore 64. That's what we did when I was a kid. You don't have to learn MOS assembly to detox yourself of OOP (although it's a fun thing to do), just learn Commodore BASIC 2. No classes, no stricts, line numbers, have to interface with the hardware through menory-mapped registers... Yup that's perspective on how computers work.
oop i did it again...
It's all about entropy and applied information theory 😄
It’s not Object Oriented, it’s Class Oriented
I go into detail about this in my free programming course on my channel
Hey I just watched some of your videos. Good stuff :)
I'm so happy that I learned asm on my C64. I never understand OOP and I hate C++
C++ is not an OO language
th-cam.com/video/AUT201AXeJg/w-d-xo.html
Thanks for these clips! Keep em coming. Subbed.
You're welcome dude. Thanks for the sub. Always try my best to harvest all the hidden HMH gems :)
i only lost 9 months to OOP..........
If you were actually learning it and thinking about when it's useful and not useful, that's a good thing. Otherwise, yes, you were wasting your time.
This is excellent.
Tank god I learned pascal first
Same. Pascal was really nice to start programming in.
05:34 One sentence sums the whole video.
Nicely stated, HH. On youtube, MPJ, Brian Will, and Jonathan Blow also address this matter. OOP sucks and can be largely avoided. Even "reuse" is overdone. Straightline probably results in faster execution but slightly greater memory use.
But memory is cheap and the resultant code is much easier to follow.
Learn a little assembly language. X86 is fascinating and you'll know what the computer is actually doing.
Lol "learn a little assembly", that advice is useless to 99% of software developers.
When I started programming, I couldn't grok pointer. After learning a little assembly, it's very easy to understand.
Because OOP method is best & easy way to adapt to a learning institution.
Expert people who taught a young generation required concept to measure and tangible without a coding in my country.
They already hard work and not required addition work on something new .
hey, the video is quite interesting, thanks for sharing!
In my experience, language paradigms are like tools in a toolbox. Forgetting OOP to learn a new paradigm is like saying you must forget how to use a screwdriver to wield a hammer. In my opinion, if someone needs to "forget" OOP in order to learn something else, it suggests they haven't truly understood OOP to begin with.
To me, OOP is a toolbox full of advanced tools that you don't want to use unless you absolutely have to. Like, if you're giving a presentation and need a laser pointer to point at something on a whiteboard, why would you use a military-grade laser for that?
so, rewriting the same line of code is not bad?
I was trying to wrap my head around ECS and odin-lang (no OOP, jut data) but I just can't think of any implementation that doesn't use a class, am I a failure?
Hey, I'm not sure what you mean by your first line, could you elaborate?
Classes/structs are essential in any style of programming, when casey talks about OOP he's mostly talking about all the rest of the crap that comes with it: abstractions for the sake of abstractions, unnecessarily complicated design patterns, lot of useless smart words just to sound smart, etc... Just write the bare minimum code to solve your problem, write only the code you need no more no less. If you have a problem and start by writing the simplest solution you could think of, you can quickly see if it works or not, if it doesn't, then you didn't waste a ton of time (making UML diagrams Lol) and you can move on to try something else, fast iteration is key.
@@vexedev the best implementation of ECS in odin I can think of is just adding a bunch of arrays and each time that I add a component/system I have to do some manually work to it be considered and calculated
Great advices.
So the Golden Rule here is: K.I.S.S.
(Objects - and any other complicated Structure - only need to be programmed: when there is a REAL NEED for them...,
Keep It Simple, Smarty-ass XD -
btw: I don't like the 'Stupid' part)
Thank you.
I feel like this is what i'm currently doing in aspnet core with blazor, it's not like i'm doing a object out of everything. Near the UI layer you have viewmodels and in the database you have entities, you send and receive dtos which are generally records. But stuff like sending emails, accessing the db, business logic processes lives in their services which are injected where needed.
You end up having an anemic model and i prefer to have a main view model per page doing the initialization that is also treated as a service so you dont need callbacks and updates all over the places. Classes are good too aggregate properties and i usually extract them when i see i need the same properties in two or more places. I avoid inheritance if possible.
Is this still bad oop thinking?
Is that even OOP?
I started programming by making OOP Flash games for 10 years. I think a big first step to getting out of the mindset is to make everything global/static.
If you do that then you're never passing arguments to functions for reasons of access or "I need a reference to this thing", instead you always just pull from the global unless you explicitly need to work on a single instance of a thing.
Of course you'll have horrible organization for a bit, but as you look at your parameter lists and messy global scope, bundling will look more natural.
I'm a programming student that started with java... I remember asking my teachers why I couldn't just make everything I wanted to pass to a function a class variable, and I was told it was bad practice. And looking back, I often just did that with utility objects (like scanners) and such. I guess I have some benefits from having self learned java from a website before taking the class.
Isn't that worst when it comes to memory access?
I’m new to C++ and programming. Should I learn OOP or is it a dated way? If people don’t use OOP what do they use now? Just the normal C way of coding?
Hey! There's no straight forward answer to this. OOP is everywhere, Unreal, Unity, etc. almost everywhere you go there's always some OOP one way or another. The problem at its core isn't really in the semantics of how you write code, whether its object.method() or function(object), they both accomplish the same thing. I believe a good programmer can write good code in whatever environment, engine or language they're in, sure some languages enforce OOP more, but It's more of a mindset issue than anything else. Making things complicated and abstract just for the sake it. Massively overengineering and overthinking problems that are mostly made up and not real problems. Programming rigidly by principles and theory somebody else wrote in a book with no real life experience that has no practical use of any kind. What Casey is saying is just to keep it simple, dont over complicate, do the exact amount of work necessary to get the job done, not more. You need to parse a config file? Sure, just write a little utility function that does just that. Oh wait... no. I should make a UML diagram first and make it an interface and implement IParserBase, make sure the interface is nice and clean and modular for other people to use, then anybody could give it their virtual abstract adapter proxy generator factory and it would just work!! .... you get the point.
Should you learn OOP? I say absolutely! Expose yourself to the different programming paradigms out there, oop, procedural, functional etc. Take what OOP principles say with a grain of salt. Most important don't take your information from one source/person. Have multiple sources see how they think and do their thing and make up your own style around it, take the best out of everything, dont be dogmatic, be open and flexible to new ideas. I always say, write the simplest bare minimum amount of code possible to solve a problem first, see if it works. If it did, great now just clean it up a bit. If not, well you learned and you didn't waste time so you're one step closer to the solution that works.
@@vexedevI don't understand how does it mess up? I've started from java and I'm now learning c++ but I don't see it
@@cxlappsed1548 Hi, I think the biggest mess up is being dogmatic - not thinking about how to get a good solution but just thinking how to do it some prescribed way regardless whether it fits the given problem. ( my conclusion from reading and thinking about it for quite some time) Note that I am still more a beginner than anything.
brilliant. thankfully is started out with c and now most of this oop stuff seems weird and unnecessary to me. all this thinking and planning and trying to force things into boxes... multiple inheritance, virtual functions... gross. i am a beginner still so takes this with a grain of salt
Give Raylib a try if you want a nice and quick entry to C gamedev!
"Throw away the OOP".
What is “compression mindset” in this context?
There's an old article about it on his blog caseymuratori.com/blog_0015
weird question but what are the colors of your cmd for the FG and BG?
Just functions and PODs man, no inheritance or polymorphism.
And you would call it OOP? I guess nobody really knows where OOP ends and procedural programming begins.
Do I need a factory for my color? Do I need a factory for my factory?
Did you use a Factory for this comment?
So basically keep the namespaces, get rid of most objects?
Do you have any recommandation about some books to learn how to analysis and planning a software with Procedural or data oriented design ? thank you
Short answer no. Long answer, I'd really just watch HMH. You can only learn so much from books, you might learn techniques, but not how to program, think about problems, approach issues etc. You only learn that from experience, doing it, or seeing someone do it.
Yes I agree with you but I'm just realising that All my knoweldge about OOP will gonna be droped into my garbage memory ;( And I'm not super fancy to follow the 400 and more episodes from HMH :'(
You really don't need to watch all eps. For me, my programming style, thought process, philosophy and productivity sky-rocketed just by watching the first 30 or so eps. Then you could just cherry pick episodes and learn what you need at the time you need them.
I have tons of game programming books, really all I take from them is techniques. A lot of them use OOP, just their style of programming but the concepts/tech stuff is still valid. Tricks of the 3D Gurus is one of my favs by Andre Lamothe, procedural style. Again teaches how to build an engine, but not how to program.
And don't worry about dropping things in garbage, we all did that. You're getting experienced, knowing what works from what doesn't!
can you point me to, tell me what hmh is? or a link?
Handmade Hero
I am late to the game but can someone pick me up? As far as I understand, a method which acts upon the object it was called on is bad but a function which acts upon an object it was passed as reference/pointer is good?
Not really, object.method() vs function(&object) are purely semantic differences, personal preference, I use a mix and match sometimes, neither is good or bad just different. What he's referring to when he says OOP, is more of a mindset/way of thinking approach to problem solving. OOP code tends to be unnecessarily more complicated, abstractions for the sake of abstractions, a AbstractPixelFactorySingletonAdaptor just to plot a pixel on the screen, thinking about code reuse before the code is even usable in the first place, lots of deeply nested inheritance trees for things that dont even need inheritance, obsessing over 'hiding' data from the user, 1% of the time its valid, 99% of the time they're just hiding things that should've been accessible thus taking away valuable control from the user (this leans more into bad API design in general). Thinking about 'objects' in their pure form and writing solutions around that tend to produce less than optimal code in terms of cache coherency etc. Instead if you think of code as just a way to transform data from one form to another (thats all that you're doing) you'll be able to write more efficient transformations and represent data in a manner that makes much more sense to the problem you're solving. In short its thinking "what objects do I need to come up with to solve my problem" vs "what data transformations do I need to solve my problem", its a slight mindset switch but it yields massively different results in terms of the solutions.
@@vexedev I've looked into dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your-software but still have the linked videos to watch. I think I am on the brink of understanding but there are still some pieces I have do grasp. I see that I do tend to start designing classes and their relations at the beginning and that things start to get complicated very fast and that it is often hard to find a "clean" oop solution whatever that means. But I am missing the experience of how to do it instead or some real world examples. What I've read so far are abstract discussions which stop at the point where it gets interesting... In the implementation details.
Will dig a little deeper maybe I can find the holly grail of enlightenment somewhere. =)
@@r2-p2 Yeah it will come from experience the more you code and try to think of simpler terms. I would say just try your best to simplify your thought process as much as possible, start by writing the most straight forward simplest solution to the problem, and iterate on that. I was confused at first when I first watched Mike Acton's talk about oop, like I didn't know how to code instead. But then I watched how Casey code and solve problems, and how simple things are, then things started to change. Also, exploring different architectures can help break the thought of always thinking in objects, e.g. ECS. (Not saying you should always do ECS, but just saying its a completely different way of thinking, and if you can wire your brain to think in that way, I'd say you've broken free from OOP)
Once you go one way you should just keep going that way.
there is no spoon
His name is Casey? Any other channels out there that you recommend that are also "anti-OOP" ?
Yeah check out HandmadeHero.org, there's quite a few guys for that matter, Brian Will for one th-cam.com/video/QM1iUe6IofM/w-d-xo.html
The video is not playing :(
As a beginner to programming, i just finished my OOP course and I do think its helpful (noob perspective may change) but during the course i did have thoughts like "Do we have to make this an object"
How are your studies going?
Right?
So basically the problem is that people misuse OOP. because most people i know only apply OOP incrementally as we need it.
The problem is that making objects a language feature makes their design very rigid, which leads to that incremental application and organic development. If objects exist only as temporary constructs inside the minds of programmers, they are much more adaptable and powerful. If we create our objects as structs with data and functions pointers, they are much more flexible, we can use polymorphism to a much greater extent, and people are less inclined to apply OOP incrementally. OOP as a language feature was the dumbest mistake a language creator could've done. We don't need it to do OOP, and it severely limits the kind of OOP we can do. The problems of more complex and unpredictable control flow and strict boundaries that make OOP code harder to understand and refactor are still there, so it should still be used sparingly.
A program cannot be objected ORIENTED if it only use clases sporadically. What you are describing is the way most people do it, but it's not what OOP philosophy dictates.
courtesy of Java
Oops
OOP is bad depending entirely on which of the infinite amount of definitions that you use.
He says it himself that objects arent the problem with OOP, yet so many people think that C# or Java is bad because everything is an object.
They are bad because everything is an object. An int is a data type, not an object. Thinking otherwise just shows brain rot.
@@nickwilson3499 Nope! Not a required feature of OOP at all. Ints are not objects in Java, and they compile to raw data in C#. Being averse to something like that 'just because' is the real brain rot here! ;D
@@zacharychristy8928 you didn't say why it's not a bad thing... my argument was clearly not about performance.
My earlier comment on the state of your brain is even more relevant.
OOP is fine. Just remember _it's a tool._ It's _not the solution._
I think theres a good OOP and a kind of dogmatic version thats overbearing where you must use design patterns and such. I actually learnt OOP by just playing around in java mostly on my own. I would also say some people just dont have a good intuition for OOP (in my experience) so use whatever works for you.
I would say for me it immediately clicked and made more sense than a procedural style.
Compression oriented programming, yet how many times do you write the same syntax for loops and switches, and error handling, when all of that could be simplified using macros. See apl or k programming languages
3:54, this is the key point. FP programmers use to fail noticing that, which makes their entire point fall, because depending on how complex the project is, having all data as public (which they think is "natural") will lead to disaster!
I think it depends on your project, framework, available tools etc. OOP is nice for design and IDE completions. It makes communication easier in many ways.
"OOP mindset" lol
Why is everybody talking about OOP as if it is some sort of cancer? I mean it is a tool, and it is important to learn where and how to use it (and there is definitely not enough preaching about function-first programming), but I deem it absolutely necessary for any larger project.
The problem is not with the notion of objects (structs are that, too). The problem is the "oriented". You should not orient your programming style towards creating objects. That's how you get the factory and service etc. It's all bullshit.
That is quite zealous view.
Vojtěch Kaiser I agree. I learned on OOP, but I don't think it's bad. It's not always the right tool, but at least modularity is good in general.
Lazy Monk You might have been exposed only to the wrong use cases. Java's paradigm is indeed a beast, and yes it's overused, but there are situations where you have relationships where using oop is actually easier to reason about. I've found it necessary in audio programming where you have such an intrinsically modular model that doing things otherwise would become cryptic a lot faster. I just don't think you can say it's never an appropriate paradigm considering how many use cases are out there.
That being said I think it would be interesting to see how far you could take audio programming using functional and no inheritance or objects, but in my mind it's less tractable.
+orazdow, you can write modular code without OOP, I think you might be confusing OOP with data structures.
Programming as a "coding" became wide popular now days for mass and this is ok, but many of them don't even no what the big-O notation is and don't want to know. The point is, this is a business, there's a lot of courses, instructors, etc. Using and writing classess and polyphorism is nothing wrong. That is concept for reusable code presents in HMH videos. Using this for anything and anywhere with mindset of "object oriented DATA", that's a problem. Look at some code for example 90's/00's of games.
Understanding asymptotic complexity is nice and all, but even that sometimes doesn't tell you much. A simple linear scan on a linked list and an array are both O(n), but the linked list is still going to be much slower than the array, and in my opinion it's much more important to understand why that's the case rather than thinking of things in academic terms of big-O. You can have modularization and polymorphism without OOP and classes, and it'll be faster because it won't require virtual table lookups. I think having no understanding of how a program executes, what cache lines are and why memory layout is important is actually a huge problem, and a big part of why modern software is slow despite how fast hardware has become. All the slow and expensive indirection in modern software is a direct result of the OOP paradigm, and I think we're all paying dearly for it. The amount of collective man-hours wasted waiting on needlessly slow software is astronomical and has probably cost us billions of dollars in lost productivity. How many days of your life have been wasted staring at loading spinners? Those are days you're never getting back, simply because some geniuses thought it would be a good idea to teach everyone to work against the computer and chase pointers around all over the place.
I agree, big-O notation is theoretical aspect of course and by knowing it I mean know what is going on around. Generally speaking, theory becomes from practical searching and vice-versa and understanding that properly is nice but can help a lot.
OOP should be banned
To me, OOP is just a way to eliminate unnecessary concepts from code. Nothing more.
Procedural: push(stack, value) //"please push value on the stack", so you got 3 objects to think of: a stack, value and implicit performer.
OOP: stack.push(value) //"stack, please push value", so now you only have 2 objects to think of: a stack and value. The stack now combines the both roles, so you don't need to consider them separately, and so the code is now easier to comprehend. That's the whole point of OOP for me. Nothing dogmatic here.
I don't really understand the 'implicit performer' thing. Do you mean the CPU that actually executes your code? I think it's still there even in the method version =)
Sometimes bundling functions with datatypes works fine, when the connections are obvious, like with stacks and pushing. But when you have 'cross-cutting concerns' (and really, most of the interesting stuff in your program is cross-cutting), there's no good way to assign methods to a concrete type.
renderer.draw_particles(particle_system) or particle_system.draw(renderer)? message.send(reciever)? reciever.get(message)? connection.transmit(message, reciever)?
When you use standalone functions, you have to spend exactly zero time worrying about that stuff, which I find to be nice, but whatever helps you reason about the program best, I guess)
I only see a syntactical difference there. push(stack,value) vs. stack.push(value). They all involve three separate identifiers and ideas: collection, function, value. I could see how the latter can maintain invariants over the stack's internals, although generic containers are probably the most straightforward uses of classes... yet they're not exactly what epitomizes OO principles, since they're very leaky abstractions (they're supposed to be).
Thats not what's bad about OOP. The problem is inheritance (vs composition), is-a vs has-a.
@@fschutt247 modern OOP focus on interfaces and SOLID, an animal vs cat problem is textbook teaching.
Such a nice demonstration of a broken mental model.
It sounds to me like you're describing JavaScript framework programming that people learn to start from. It hasn't seemed to me like object-oriented programmers who aren't doing web stuff have any problem directly describing an algorithm and then translating it into imperative or functional or just direct instructions for a computer. it's quite possible to use object-oriented languages or languages that support object-oriented stuff to directly command a computer.
Not necessarily true. Even in static languages like C#, there are a vast amount of patterns where inheritance is utilized excessively to create a bunch of abstractions that can be utilized as a data structure that handles all future changes of the system. The only problem with that is that those abstractions cannot predict the change the data overtime in the system and at worse force programmers to commit to those abstractions (invent problems for the abstraction to be a useful solution than solve the natural existing problem).
JS frameworks problematic issues for the most part aren’t mostly of OOP(exception of angular); most of the problems come from unnecessary and excessive creation of objects, overuse of higher order components, using functions as state containers and lack of discipline in profiling performance bottlenecks(large bundle sizes).
I use OOP when I need it. I use functional when I need it. I use what is best for the project at hand. Why limit your toolsets because of ideology? You only limiting yourself. The rage and anger towards OOP is honestly out of control and misguided.
Because it's not useful? Why use a useless tool that does not help?
@@uipo1122 Then use another tool. Simple as that.
@@romangeneral23 Right.
@@uipo1122 What's actually important about objects isn't classes, inheritance, etc. it's the idea that you can carve out a piece of functionality and isolate it from the rest of your code to the point where in order to understand it, you don't need to hold the rest of the program in your head at the same time. OOP tries to do this by making it so that the "object" can only interact with the rest of the program through "messages" (and Alan Kay, one of the influential figures in the history of OOP, is on record saying that objects weren't the point, the *messages* were), meaning you can understand the object's behaviour in terms of those messages only.
There are useful side effects of this isolation, in addition to needing to hold less in your head at once:
* because the object is entirely focused on the specific functionality it provides, sometimes multiple copies of the object ("instances") can be used to reduce duplication in the same way that a function can save you from repeating particular sequences of individual lines of code; the exact circumstances of its user code is unimportant because the object only needs to care about itself and perhaps its immediate dependencies (other objects that it sends messages to)
* because all interactions go through "messages", it becomes easier to swap objects for other objects that respond to the same messages with the same general semantics (which is to say, they "implement the same interface"); in some cases this is very useful, because it means the program can alter its own behaviour in a succinct way by swapping which object responds to a particular set of messages
* related to both of the above, and much like with functional programming, it becomes easier to put the "object" alone in a test harness and verify that it behaves as expected automatically, which saves programmer and QA time; test driven development is based around the idea that putting the code in a test harness *first* will force the code to evolve in such a way that it is as focused and atomic as described above. As I said, though, this isn't unique to OOP, functional programming is another way things could evolve.
If those benefits are valuable to you and are not outweighed by other concerns (eg. performance of virtual dispatch in very low level code), then you will not find OOP useless. I find OOP is perfectly useful for structuring things at the large scale where these benefits most matter. It's the use of it at the fine detail level (ie. pure, academic OO code where *everything* must be an object that interacts through messages) where it can make things unnecessarily fussy.
@@babgab That's theory, it has nothing to do with reality. Practice is the criterion of truth. If your new programming thing doesn't help solving problems in the real world (spoiler: it doesn't) then it's not good.
> ... you don't need to hold the rest of the program in your head at the same time
If you want to produce a quality product you absolutely need to know how the rest of the system works. The whole idea of "I will build this module as a black box and provide a public api" just doesn't work. It's fine to use black boxes to save time if you are working on the project. But it is always better to know what actually is happening in those black boxes. And the current programming culture discourages you from trying to understand how stuff works.
> ... it becomes easier to swap objects for other objects that respond to the same messages with the same general semantics
You don't need this level of modularity 99% of the time. BUT if you really encounter a situation where you need it there is this thing called "function pointers", I know that's probably alien technology but it solves the problem.
> If those benefits are valuable to you and are not outweighed by other concerns (eg. performance of virtual dispatch in very low level code)
Performance is indeed an argument against OOP (not the the only one).
>I find OOP is perfectly useful for structuring things at the large scale where these benefits most matter.
I find that writing the code and organizing it is never the problem. The code is just a minor thing that gets transformed by this program called "compiler" to run on my CPU. The real problem is design - understanding the thing I am trying to program. Making it efficient and minimizing complexity.
And OOP the opposite of that. It builds structure prematurely. And any premature structure will always be wrong, structures in the program should emerge naturally, not by drawing UML diagrams and deciding that that's the thing. Wrong structures lead to accidental complexity and accidental complexity kills projects.
Modularity that interfaces (/function pointers) provide is not needed most of the time. It is a very specific thing needed for very specific situations and you don't need OOP for that.
Why the hate on OOP? A minimal use of it is good. You know what I hate? Those Cpp template classes? What garbage! Use a runtime type system like Objective-C / Swift and downcast safely! I code in X++ daily, it is fine but honestly, use static members as much as possible, just use classes for namespace mostly.
Objective-C/Swift is so much slower than optimized well written C++.
I liked Objective-C much but there is a reason why it is only used in the GUI layer and nowhere else.
@@llothar68 Runtime dynamic type checking does not come for free. Use only where necessary. Still, was best option vs. CORBA and Java and interpreted that were the contemporaries. Actually, my intro to Objective-C was with K&C compiler and I'd used it on a War Games Simulator for Defence Research Organization. It was not GUI. Although, there was a separate service you could attach and you'd get a gui representation of the simulation in real time. Even with realtime type checking, there was a warm up phase where string types are resolved and subequent instance use was faster.
@@kippie80 I was an Eiffel programmer. So much could have been avoided if the world had not gone with the c++ object model , the VMT dispatch and the concept of dynamic linking and separate compile units. That’s rooting 1970s technology
Me & 4 other programmers sit down to plan a code project.
Me: So, have you ever started by thinking about the basic operations required by the CPU to transform some data?
Them, OOP educated: u wut?
Me: 😩
That's not them "being oop educated"... That's just you being horrible at communication and possibly have a slight degree of autism. Why would you ever word it in such a stupid way?
This screwdriver doesn't drive in these nails. Stupid screwdriver.
there is nothing wrong with OOP if you use it correctly.
There's nothing wrong with ANYTHING if you use it correctly.
Absolutely nobody has agreed on how to use OOP. You have a bunch of standards but nobody follows them, only 50-60%.
@@etodemerzel2627 This, of course, is very true but totally useless statement.
@@spicynoodle7419 If you misuse OOP (e.g. by creating crazy complicated inheritance trees), then it is your fault and not fault of OOP.
@@vladimirkraus1599 This is exactly my point. Your statement about OOP is useless and provides no grounds for a constructive discussion.
Hahahaha OOP is so cringe
This seems like a huge over-reaction to the drawbacks of object oriented programming. Class-based OOP simply allows one to extend the language with their own more abstract primitives. In a language which supports OOP, a HashMap can be a primitive in the same way that the built-in array type is a primitive.The only difference between a HashMap in a C-style functional language and a HashMap in an object oriented language is the way in which you interact with it syntactically. Some languages like Go and Python make this obvious by requiring that one explicitly declare a function's receiver as a parameter. In any complex system there's going to be a set of components (objects), and a set of standalone functions. Where people go wrong is when they take a dogmatic view that OOP is bad or that plain functional programming is bad.
Factories, builders, and containers are all just design patterns on-top of OOP. Some design pattern you read from a book isn't necessarily a good abstraction. Nor is it the essence of OOP.
Dogmatic thinking is probably a natural stage in a programmer's evolution. Some are never put into the situations that force them to outgrow that dogmatism, though.
Of course you can't use it successfully if you haven't yet wrapped your head around the basics! It's the same problem with math, people are just shit at both! And no wonder really, most of the resources online have less insight into the topic than a daily mail article.
Trying to "avoid OOP" is a silly, and often purely ideologically idea. OOP certainly has it's place and can make your code FAR more maintainable. The fastest code isn't always the best code, especially when you're working on large enterprise applications where maintainability and correctness are far more important than optimization. Of course you should always strive to write clean code, also fast code, but fast is a relative term. Fast relative to what? In a game engine, it has to be blazing fast, that said, I wouldn't litter the hot-path in my game engine with virtual method calls. In a situation where you're writing a back-end service that calculates shipping costs across various countries, having good abstraction is certainly better than shaving off a few milliseconds. A lot of junior devs are under the impression that OOP is just about "putting things in a class". OOP concepts are far bigger than that, and various OOP driven design patterns can make your work far better and more pleasant.
The problem with OOP is not that there might be a class or an interface or an abstraction where it makes sense. The problems start when you _orient_ your whole thinking around constructing these object trees instead of writing code to solve the actual problem you have, to do the actual computation you want to do.
@@SiisKolkytEurooObject trees? What are you talking about? You basically said "The problem is not OOP abstractions, but poor uses of OOP (object trees)." Yes, correct, lol, I don't care what bad programmers do with OOP, I care about the core principles. I don't understand what you mean "instead of doing actual computation". Writing classes, interfaces or design patterns doesn't mean you're not writing computations and algorithms, it simply means you write APIs that lend themselves well to abstraction, large-scale code reuse and extensibility. That is why OOP focused languages like C# and Java have dominated in the enterprise. I've spent the last 20 years writing solutions that require malleability, long term maintenance and testability, this is where OOP shines. The arguments I read against OOP stink like dogmatic amateurism.
@@NickEnchevAll of us *should* care about what bad programmers and dogmatic amateurs do with OOP. We exist in the same industry as them. In fact, I'd venture a guess that most programmers are bad, which means bad programmers are difficult to avoid and maintaining their bad code is even more difficult to avoid. I have actually seen arguments *for* OOP on the grounds that bad programmers' bad code can be encapsulated and isolated away from the better stuff. :D
I would also point out that you're in the comments of a video originally posted by a game (and game middleware) programmer. A game programmer critiquing OOP is going to critique it from within the context of game development, which due to various industry structural factors has not historically valued (automatic) testability, long-term maintenance, code malleability, or even hiring experienced programmers. Most of us are not going to care that OOP is great for some shipping cost calculator; for us, in the days of 240hz refresh rates and ever escalating visual quality bars, a few milliseconds is a horrifically long time, and for some of us the object spaghetti our OOP-dogmatist coworkers produce is an active impediment to our ability to deliver a product on time. Not to mention to our calm as we try to find "the code that actually does something" in the rat's nest of factories and visitors and adapters and facades that is the product of an inexperienced and dogmatic OOP practitioner, whose main exposure to OOP has been through an undergraduate course evaluated with a *paper* exam, so we can actually do our job of maintaining the code.
People you talk to in the game industry generally find it more valuable to evaluate OOP with the code that is actually written by its usual practitioners, in the context where they are actually working, than to consider what a many-year veteran of an industry (that has wildly different from values from our own) would do with the concepts in hypothetical scenarios that they will never experience. So, in this comments section, I suggest that talking about what's valuable to experienced enterprise devs is a discourse that requires recalibration.
wtf is this shit about hating on oop for everything. i mean damn, it's useful for some shit though
As the video mentions, OOP isn't entirely bad in all cases. It's the "structurally orienting the code around OOP all the time" that's not very efficient.
Computers work on data, so writing code that favors that is the most efficient way of programming a computer to do things.
If you don't abstract away complexity, making reusable systems, how would you ever create a program bigger than one file?
Sounds like you are a fan of putting every single line of code inside one file. If you use colors, you should white the hex value each time, you cant create a Color-class that holds the hex value, that you can then reference from different places in your code, that is "bad". It's much "better" to have the hex value many places in your code. And then if you decide to change color, now you have to change it 3884 places in your code. Much better.
> you cant create a Color-class that holds the hex value
You don't need a class, you just put constants in a separate file and use it. The problem is languages like Java and C# force everything to be inside a class and then you get all these static classes that are really small namespaces.
In Python this is a function and a dict? Or even a lambda inside a dict to one-line it.
Actually, yes... you should start by repeating the HEX value throughout your code. Only when it becomes repetitive, at least 3 or more instances, do you factor it out. With a rigid OOP mindset, you could end up with a color class for an application that only needs to reference it in two places.
You don't need a color class. Colors are nothing more than #define WET_ASPHALT 0x... declared in colors.h that you include anywhere you need a color value.
He is a fan of monolithic files, yes. Yet he clearly separates them into dedicated “modules” like platform, math, game, entity etc.
OOP is not a coding paradigm. That's the most shameful and harmful misconception. OOP is an analysis and design paradigm. The reason why many people fail to use it is because they are using it wrong. If you want to open an editor and start coding classes, you are defeated from the very first line of code
Even the most respected oop gurus teach oop as a way of coding not a mere analisys method.
@@Vitorruy1 So what...? The fact that oop is an analysis and design paradigm doesn't prevent people from building tools and languages around the concepts. Even more, it creates implementation paradigms.
But do this: ask any of those gurus if it is possible to do the same thing with different languages and how they would proceed :-) Pretty sure they will be more than happy to show you the real essence of oop.
Unless... you talk to a C++, or Java, or Assembler guru. That's a different story
Wow, a guy who did not understand OOP at all says it is bad. Well, have you considered the possibility it went over your head?
By the way, your idea that you should think like a computer is regressive at least and absolutely stupid at most. You have to think in terms of objects if you want to write in OO style. Read Object Thinking by David West.
I just wondered why Casey had shut down the comments in his own videos, what could be so stupid that it would warrant closing down the whole comment section for the rest of us.
And then I saw your comment.
@@SiisKolkytEuroo another imperative programmer, I assume?
@@user-lk1fw1lp8b Tell me you are OOP zealot without telling me you are OOP zealot.
@@Salantor I just know OOP, is that a problem?
@@user-lk1fw1lp8b And what makes you think that Casey don't?
It makes me laugh to see people slagging off OOP like it's a massive mistake. It's a tool like everything else. You use the right tool for the job. Also if you don't have a good knowledge of OOP good luck getting a job.
That's a lot of the point, though. OOP is the best tool to get many programming jobs. Once there, it's the tool you *will* use, because you're stuck in Java, C#, or a very OO Javascript or Python framework, because that's what the team is using. It's shoehorned into being called a good way to solve many problems for reasons of business politics, but that part isn't taught.
It took me about 3 years to get a handhold on OOP. It just wasn't hard after that. Programming, good design, all these in general hard, even in a functional or procedural language.
Well I would say that OOP is useless, I stand by that pretty strongly, but if you want realistic workable unambiguous abstraction amd organization, then functional is the way to go. Functional is naturaly the "correct" way, because it is built up from category theory, which is a very natural foundation to mathematics.
You think of the programs like boxes that take input and put out output. In category this would mean that you start at an object and want to get to another object, so you get there by composing morphisms(arrows), which is what you do in functional languages. You decompose your problem into the smallest bits possible, write the functions(morphisms) and then compose them together to get the final result. Im not that familiar with category theory yet and I might have said some wrong things, but I think that is basically how it works.
This is the most natural, clean, abstract, organized, etc, way to do programming IMO. But its not the most useful one, sometimes we dont really care, but just want to get things to work, work fast and make them still as reliable as possible. Then procedural is the next best thing IMO, which is why python and java script are two of the most popular languages out there. Yes python does support OOP, but seriously, how many people do actually actively use OOP in python other than to break up huge chunks of their programs into a bit smaller pieces, its not like they actually use OOP like its meant to be used, but just so that stuff is a bit cleaner. Remember, you dont have sth like structs in python really, you only have classes. That was a rant and a half
@@berserker8884 You are kind of lost and also mixing and talking about two different things. In real life we do think about actions and properties, not only actions. That's a point for the object abstraction. But also, OOP is about design and analysis, not coding. You can (an should) think your problems from the OOP perspective and code it finally in whatever you need, even assembly languaje, or english! :-) OOP provides you with the most complete toolset you need(until now) to organize the implementation in any context
@@ramireznoy first of all, why cant you describe all properties via actions only? Thats the whole point of category theory and it just happens to be the prefered way of understanding things in modern mathematics. You dont talk about what the objects are, you only talk about how they are related.
Secondly, why should I think of things in OOP way? Yeah abstraction is wonderful, but again, catgeory theory is, IMO, a much better way to go and understand things. And if you talk about organizing things and making them clean, you dont need OOP because thats not what its about, you can be organized without OOP. In fact, solving a difficult math problem might go much better if you look at things from universal properties stand point, than from your down to earth intuitive set theoretic way. OOP goes even further than that and just seems like a messy paradigm that engineers threw together to organize things, but it definitely seems to lead to great confusion, overengineering with uncesessary "protection" and "features", etc. And if you dont use those things, then you arent even doing OOP...
Im admitedly not an expert here, but Im talking from experience of always finding it much cleaner to organize things in a free relational manner, while programming things by just solving the problems one at a time, either conpletely cleanly ina functional setting, or doing it normally in procedural manner.
Im not saying noone is using OOP, in fact Id bet most professional software like Adobe and Mathematica were built with help of OOP, but I myself and many other programmers just simply dont use it, because we see no reason to.
Finally, Ive never worked on an enterprise level project, so I have no experience in that and it might be that with such massive projects OOP might help, but again, I myself think that there are better ways to handle it, or at least that there is room for improvement.
I just dont buy into "objects have private properties" kind of thibking, too dangerous for me. And there is a reason why data base design is nothing like OOP, at all.
@@berserker8884 That's fine. Don't forget we are talking about tools. So, the same way you can use a chainsaw or even a screw-driver to build a chair, despite the fact those are not the best tools for the job. All things considered, software development is a reality chunck in which results are what matters. But... what do you consider a "result" for your specific problem? There are two extremes.
1. If all you care is the running code or just coding something, go ahead! It doesn't actually matter how do you get there. As long as it works, anything else will make none or little difference.
2. If you want to Build software as a product and you want to achieve certain predictability in delivery times, quality, security and maintainability, then you will need to think twice before doing things as an artisan. I am not implying by any chance there is an absolutely better way to get there. But the only battle-tested one until now, is using OOP design approach. This may change in the future sure, and it will. But in any case the new paradigm will need to be build on top of the current knowledge.
Now, answering your questions:
a) why cant you describe all properties via actions only? Sure you can, but is that as "natural" as you claim? To put things simple: at some point, you will need variable values. How could your model then assume those are actions without forcing abstraction? What if that variable needs to be a complex structure or even a completely independent entity? The whole idea behind abstractions is to map and simplify, not to be enforced. If you enforce abstraction, you are doing it wrong.
b) why should I think of things in OOP way? You don't have to. But even refusing to use OOP concepts in the conventional way, you are still using OOP components. File, Process, Threads, Event, Program, Table, JSON, UI component... are all objects and/or object instances depending how do you use them. At some point, if you don't want to drive yourself crazy, or you are not a masochist, you will need such an abstractions into your code and use them accordingly to the implementation style they are designed for. You may not notice that from your code, but you are just handling abstract objects through their properties and actions. Even your mentioned category theory uses categories, objects and morphisms, that clearly makes the category theory a perfect match for analyzing any implementation from the OOP perspective.
c) The "great confusion" you are talking about is often a result of bad practice or missunderstanding. But that by itself doesn't validates avoiding the practice and use of OOP design. I agree you may not need OOP for every single aspect of a code, specially the funcitonal parts, but you may agree with me anyone can make a mess using any tool. You can take for example, the classic paint-like app, implement it with both: using the OOP design and going stright to code business to make it work. Then verify by yourself a couple of points after finishing.
1. How long it took me, alone
2. How long it would take me with a dev team. Considering paralellizing as much as possible to make sense of hiring more people and finish faster and testing the code
3. How easy is to maintain and modify current features or incorporate new ones, like for example handling layers, saving and reading many formats, cloud storage and consuming external plugins or even adding internationalization.
4. How easy is to make an on-board process for new developers with zero previous experience in your architecture
5. How easy can I apply much of the code and/or the architecture in a similar problem like for example crating block diagrams or painting 3D objects
6. How easy is to translate my solution between languages or port the solution to be web based, or mobile based.
7. How possible is to take lessons and patterns out of my experience that can lead me to speed up my development the next time, regardless the problem to be solved.
d) I just don't buy into "objects have private properties" kind of thinking, too dangerous for me. And there is a reason why data base design is nothing like OOP, at all. Databases are all about objects :-) The fact that you miss private, public, inheritance, class, instance in some of the available DBMS, doesn't mean the OOP paradigm is absent. Even in a NoSQL database you must consider properties and actions, relationships between instances and distinguish schema from record. But in any case, OOP is not about private and public properties :-) those concepts are implementation specific, and very useful when you have a complex system and you want to ensure that despite your library being used by many others in the same final software, your base implementation remains intact and reliable by your specifications.
But OOP is actually easier than that, so easy that it shows up kind of automatically. Just try to not to forget OOP is a design and analysis tool set, not a programming methodology nor language. Currently, it looks like you are trying to eat the carrot before pulling it from the ground. If you are interested in learning how to use OOP tools, I highly recommend you the following book. If you are in rush and have the basic knowledge, you may want to jump straight into chapter (hour) 16 - 17
read.pudn.com/downloads140/ebook/601014/Teach%20Yourself%20UML%20in%2024%20Hours%20Complete%20Starter%20Kit%20(3rd%20Edition).pdf
@@ramireznoy I hear your argument and like I said, I dont have experience in large enterprise projects where OOP is definitely dominant and very useful.
Few things still.
1. You don't need to ever encounter "variables" in functional design for the most part, other than when you have to deal with IO and some other rare things.
2. Data base design is nothing like OOP. What makes OOP the OOP is the class diagram structure, which is to say you design classes, how they are all "connected" via inheritence and object membership, etc, but that is not like database design, which looks similar at first glance, but differs in many key points.
3. Again, to me it seems like you are trying to sell me data abstraction in general, which I agree plays a large role in design, analysis and implementation, but Im specifically talking about OOP data abstraction. But I think I agree with your point that OOP is reliable when it comes to different implementations and people understanding your design, simply because it is the most widely known and used way to abstract data.
4. The confusion comes from the fact that OOP "forces" you into rigid object design, they cannot be meta modified. Hence here in comes a large difference between OOP and database design, in which entity component diagrams are the backbone. This is why most game devs don't love to use OOP for their game design, because it really forces them into rigidity. Sometimes devs go overboard and overengineer thinga on both ends, but in many situations OOP can be too rigit. Im not saying things cant be done or cant be designed, but im just saying that a lot of times its just a pain when you need 10 things to be all intertwined and changing fundementally in real time. Here you can make the objects have bezillion million properties, or you can have inheritence, which limits you to no end as we all know, OR you can have an entity component system in which you swap in and out the components in real time. And here I agree with Blow that people overengineer entity component systems and focus way too much on them.
Other than that, I understand your argument yeah. OOP is a tested way of desnigning things that worked well so far and that is why it should be learned and why it is widely used.