Object-Oriented Programming is Bad

An explanation of why you should favor procedural programming over Object-Oriented Programming (OOP).

[Max Kessler]

The biggest takeaway I get from this, is that this man really, really hates jumping around. He wants to read the function in one place. I can respect it.

[Google User]

Well and I don't want to read the function at all when using it in a smaller context somewhere else, what I don't have to if it is on e well named, well abstracted and I know it's tested.

[ldw821]

@Google User This exactly. The author of the video would have you believe that readability is just about aesthetics, while in reality it's arguably one of the most important things and we spend a lot more time reading existing code than writing it.

[yeaa]

Jumping around makes debugging other people's code an abysmal experience

[rndszrvaltas]

@yeaa Could you elaborate on that? I work with (old-ish C-based) rail control systems with dozens of processes and as you can consequently imagine, hundreds of source files and thousands of functions all around. Nothing makes me feel more thankful than coming across a function that doesn't try to do everything. Core dumps are easier to analyze if the stack isn't completely flat, it's easier to set breakpoints, etc.

[Shawn]

@rndszrvaltas It probably depends on how the code is done. Good code would be lots of small functions that do their own thing, they work, and you can ignore the ones that work. A true nightmare would be lots of small functions that are all interlinked in some bizarre way where X relies on Y, Y relies on X, both of them call Z, Z sometimes calls X or Y, etc. It's lots of possible issues and you're never really sure which one is fucking up, so you end up jumping back and forth just to figure out wtf is going on and how it's supposed to work.

[Tharun]

My goodness, as a student learning OOP I found the criticism here so relatable. I spent DAYS thinking about how my project could be conceptualized into classes and which methods belong to which type. I decided it was my own lack of OO design experience but I'm so glad to learn I'm not alone and it's never possible to make perfect object-behavior encapsulation in the real world. The "matchmaking game" is absolutely real.

[eax2010EA]

Fellow student here, I see inheritance useful if the main code changes a lot and the clases that inherit do not change. Otherwise, composition is useful. I find it rarely in my programming that I used OOP succesfully, but the idea that I want emphasize is that if this style of codijg is hard to implement, maintain and change for any programmer at any level, it's probably not good. And I haven't even talked about scalability...

[Sarah]

Also a student! I know, I’m so happy I came across this video.

[Bobby Crosby]

Then when you graduate you'll be writing webapps that make almost zero use of OOP despite you likely writing them in a class-based language.

[websherp]

I've been in the industry for 20+ years and thought I would share my experience. These are just tools. Imagine 2 handymen arguing that the hammer is THE tool and another claiming a screwdriver is THE tool. They go back and forth pointing out the inadequacies of the other while showing the advantages, elegance, power and more than anything personal aesthetic preference for their preferred tool. Meanwhile the thousand other handymen in town use both tools alongside each other as well as a dozen other tools in their toolbox. Out of the 2 arguing handymen one is certainly more right than the other, though no one is likely to know which. All the other handymen in town know how and when to use specialized tools and they are getting paid the same if not more than the 2 arguing. Learn what you can, try it out, use it when it applies, get paid. School is just one of the tools along the way. There are many problems with the educational system, but that's too much to cover here. What the education systems effectively do is certify you can solve problems and you can see things through. You will learn more about effective design in your first year working than you did in the 4 years to get your undergrad. The learning never stops. Your intuition will continue to develop through your entire career. Listen and extract from these hot takes but please don't take them as gospel. Mostly don't take anything as gospel, just figure out how things are useful. Enjoy your journey.

[Peter Theobald]

At company after company I have dealt with confusing messes of deep inheritance hierarchies, sometimes 10-15 levels deep, where each subclass adds just a couple of lines of code. The prime consideration was keeping the classification pure in a philosophical way, like we were inventorying the animal kingdom. A good portion of the developer efforts were targeted towards dealing with the structure of these classifications and not getting any actual features done. Factories that make factories. Singletons with pages of boilerplate to do one simple thing, no object ever necessary in the first place.

[Timothy]

Spot on. Anyone who writes lots of JavaScript, Python, Ruby or Go and then dips into the C# or Java world knows exactly what this nonsense feels like. It's developers scratching their own itches of systems level thinking, trying to create the ultimate "system" to solve code complexity. Like a mini-game where they're trying to create an encyclopedia for the world. But by trying to systemamitize away complexity they create even more of it. Now you need your devs to understand dozens of different "design patterns" that supposedly decouple your program and make the codebase easier to work with. Why then are they so complex, require constant abstract thinking and make the codebase even more complicated to work with? Why does every design pattern come with the disclaimer that it doesn't actually fully decouple anything and that it's just a different form of coupling? The coupling comes from needing the cross cutting code. There is nothing we can do about that problem other than make it easier to understand for our developers. Creating all sorts of wacky service locators, inversion of control containers, factories, dependency injectors doesn't decouple anything.

[A Xerox WorkCentre 7225]

Generic interfaces with only one implementation, factories that just pass the value back to the constructor, subjects and observers that only ever get called once, Massive mutators receiving several different strategies do to the same thing an if/else already does. In general web dev, a lot of "problems" we solve are so simple, and well supported by the base features of the language, that any attempt to show off how smart you are by "using patterns" is guaranteed to generate bloat.

[JeanJean]

your companies need architects, and start writing some baselines before writing code

[Lizi Zhu]

Yes. Some senior developers take pride in turning everything into layers and layers of inheritance.

[WoodyofmC]

Employee: _We're practicing POOP here._ Applicant: _What's POOP?_ Employee: _Proper OOP._

[Drygord Spellweaver]

employeR?

[WoodyofmC]

@Drygord Spellweaver Nope, employeE. In each of my 20yr past cases, applicants (including myself) were talking to their potential teammates about some tech details. Guess most employeRs actually don't even have a plan what the heck their devs are doing in detail... 😁

[Giang Lai]

Should be top comment 😂

[Jacques Mario Sayao]

People Order Our Patties, POOP

[Steve Rempel]

No.... POOP actually stands for Python Object Oriented Programming.

[Botond Hetyey]

The biggest thing for me when switching from OOP to a sort of "some classes with pure functions" approach was testing. If the majority of your logic is in pure functions, you can actually test things without spending 15 lines of code to mock out basically everything, until barely any meaningful code is run.

[Matthew Willis]

This is so good. My first C++ job, 20 years ago, was writing code in corporate codebase where a genius code architect had de-crufted a horrible architecture of earlier encapsulation. Nine layers of OOP encapsulation were collapsed into a single layer in an epic refactoring. That happened shortly before I joined the company and I supported both the "old" product and the "new" product. I had started this job fresh out of procedural coding and the excesses of unsupportable "isa" / "hasa" confusions were freshly there on day one. I still like C++, I guess. But this is such a well thought out, battle scarred view. Thank you for this!

[morbiusfan317]

C++ is not an OOP

[Unca Alby]

The beauty of C++ is that you can practice OOP (classes, encapsulation) etc. where it seems to fit the problem, but not where it doesn't. The problem with Java is *everything* has to be a goddamned object, whether that concept fits the problem or not. Not everything "is-a" object or "has-a" object or "is-a-kind-of" object. Some things just "is".

[morbiusfan317]

@Unca Alby Except java was, is, and forever will be a million times better than C++. At least in java you can actually code a functional, logical code, whereas in C++ the best you can do is some fibonacci

[Unca Alby]

@morbiusfan317 Somehow I get the feeling you're trying to tell a joke, but it went over my head. Sorry.

[Matthew Willis]

@Unca Alby I still like C++, and having OOP in places saves time. I am not sure I'd like to inherit somebody's codebase who goes through all the mistakes of OOP. I also never warmed to Java.

[ImReal JustPreferToBePrivate]

I come back to this video a lot. Here's some timestamps: 4:38 Definition of Terms (Procedural, Imperative, Functional) 8:00 Why does OOP dominate the industry? (Java) 15:50 What is the appeal of OOP? 17:18 The One True Way to do OOP (Bandaids) 18:08 What's wrong with OOP (Encapsulation) 20:05 Shared State (Not too different than a global variable) 21:10 Encapsulation requires direct hierarchy (Problems.) 25:41 Premature erected wall building = cool-aide man solutions (OOoooH YeaaaaH!) 26:14 When starting bad structure is worse than an absence of structure 26:44 The mind games of OOP (Unnatural data types, kingdom of nouns, Manager classes) 28:54 Stupid questions you have to ask yourself (Analysis paralysis) 29:52 Abstractions hide complexity (The princess is in another castle) 31:43 Spreading your code out unhelpfully (Increases the surface area of code) 33:19 Solution! Good procedural code: 34:24 What to do about shared state? 34:46 Parameterize! Try not to use globals. 35:15 Bundle globals you do use into a single datatype 35:48 Prefer pure functions 36:19 Use namespaces / packages / modules 37:15 Long functions are fine! Logic in sequence = code in sequence. Use "section comments" 38:55 Use nested functions. (Functions inside a function, so you know it only gets used multiple times there.) 39:50 Constrain scope of local variables (Anonymous functions, use blocks, Jai programming language) 43:32 Conclusion - liberate yourself. For those who enjoyed this, I also recommend talks from Casey Muratori, Jonathan Blow, and David Acton. Thanks for creating this Brian!

[Nick Di]

Deserves a separate bookmark: 43:50 you don't need to read any of these books Refactoring by Fowler Test Driver Development by Kent Beck etc.

[Yo wut]

44:36 trump 2020

[Maxwell Agbakpem]

Seth Archambault thanks

[Jack Dingler]

"Use namespaces / packages / modules" = OO concepts...

[ScientificBEST]

Just now watching this video. Thanks for the nice index!

[Brian Stewart]

As a Software Developer with over 20 years in, having developed in many different languages using multiple methodologies and patterns, this was an interesting presentation, Thank You Brian! The pitfalls you point out and complexities are absolutely real. While I don't think that falling back to the 90's is the answer, as you seem to insinuate, your argument points to something very important, which is too keep architectural and design concerns at the forefront as you write and modify code. "Bolting on" without understanding the design of a program is a fast way to create spaghetti, not matter functional or OO. I find that good program layering and being familiar with Design Patterns is crucial, and helps avoid some if not all of the pitfalls. If I am a doctor doing surgery, I better know how the organs (objects) are laid out and connected (patterns). Just knowing how everything functions is not sufficient in a complex system. As far as Agile goes, that is not a coding "thing", it is a shift in the way we think about building and maintaining things, but should also involve many non-coders in order to correctly set expectations about what gets done when. I will be watching some more of your content. There are some great titles, and you obviously have a lot of real world experience to draw from.

[KX]

did you just thank yourself?

[visitante 2050]

You're right to bet in design and architecture, but it doesn't change the fact that once in implementation you'll face the dilemma for full/partial encapsulation as he mentions around 25:00 - full encapsulation results in lots of additional classes created to help you deal with state (design patterns). Those classes are not related to the problem being solved. They increase complexity because it doesn't make the code any easier to read and leads to poor performance - partial encapsulation results in spaghetti code.

[Brian Stewart]

@KX accidental click :-)

[Brian Stewart]

@visitante 2050 you are certainly right. I deal with this in two ways. 1. I'm aware of most standard pattern classes and their functions. They are just part of the world I live in 2. A LOT of those classes are relegated to the framework and work magically.

[Ian Rust]

1) OO was proposed as a solution to problems inherent in functional, top-down design. It was first implemented in languages like Simula (1960s) / Smalltalk (1972), Python (1991). Java wasn’t created until 1996, OO was well established by then. 
OO was adopted after struggling with many problems in industry, having a long theoretical debate, then doing some experimentation. 2) Brian fails to mention the problems with functional / procedural design. Top level interfaces become very fragile without encapsulation, Iterative development often leads to repeated refactoring of the higher level interfaces. Reuse within programs is common, having every consumer maintain its state for an interface adds complexity and will become unwieldy at scale.
 It's also simply unnecessary. And no, making the shared state global is not a good solution. 3) Test driven development is not consistent with OO. Test driven development was pretty much a fad imposed by managers. It is just design by interface applied to testing with some other rituals built in, it has more in common with functional design than OO. It suffers from the same shortcomings. 4) Brians biggest mistake is he pitches functional and OO as opposite one another. OO is not about data modeling, or data driven design, or modeling real life objects. The early theoreticians overemphasized the data modeling aspect of OO because they were contrasting it with the prevailing design style at the time, functional design. Had data modeling been popular instead, OO would have been described in terms of designing for behaviors. OO is simply the bundling together of functions and data, with some support for minimizing duplication and access. That ideal balance of functional and data-oriented styles you keep alluding to - that is a good use of OO. OO is also totally compatible with FRP, infact FRP is used alongside objects in most code implementations of FRP. It actually compliments OO very well as it solves most of the state management problems. And FRP is an entirely separate paradigm from functional / procedural programming that dominated in the 60s - 70s. 5) Your object graph is just an undirected mess. You claim the only alternative is a hierarchical structure, this is simply not correct. You can maintain a cyclical object graph and trigger update cycles... you can have mid-level objects that manage lifecycles, and then have an object-graph of them at scale, or a hierarchical structure of them. You can come up with bad designs for anything, this is not a criticism of the paradigm. 6) refactoring code into smaller components is a functional technique, I'm not sure where you got the association with OO. Many functional programmers advocate super-small functions that confuse people ... I've never seen OO designers advocate using tons of super small classes. That's just bad design, the fault of that is on the programmer, not the paradigm. The programmer has to choose the right granularity. 7) Inheritance is used all over the place, there's just a good and bad way to use it. There is not some uniform consensus it should be avoided. When you use inheritance you just have to make sure that the base class won't be torn in different directions. Usually this means using it on smaller components without complex responsibilities. 8) OO is meant for large projects where architectural issues matter. Java was designed specifically for this purpose. If your application is 3000 lines, you might not need OO. You might be able to get away with using global variables at that scale (though if your application grows much larger you're pushing it). In an enterprise scale codebase where you have 10 million lines, no architect would ever design for reliance on global state, this would only result in complete chaos. You exaggerate the flaws of OO without providing a real alternative, and don't address the scalability problems in procedural programs at all, hardly.

[Barnard Rabenold]

As much as I love object-oriented programming, I have to admit that you strike some good points that I haven't considered. After backing up my original code for a particular project, I deleted the whole thing (because it was a mess) and started over from scratch. I will try to implement these principles in that project in hopes of making my code more manageable.

[Ton Bong]

My advice is to write procedural code inside classes and only when it really makes sense use inheritance, interfaces, design patterns and other OO stuff.

[Human Being]

The fault was not with the tool, rather your design.

[A Xerox WorkCentre 7225]

@Human Being Beware, OOP fanboys always gonna try to gaslight you into thinking you are the problem after your code turns into a mess by following their advice.

[Martin Sparkes]

@Ton Bong I have started doing this without realizing what I was doing. My inheritance seldom goes much deeper than 2 levels and even then usually only for datatypes

[Ton Bong]

@Martin Sparkes Objects are great for modeling business logic. When you have a domain expert telling you what he wants software to do it is great to represent his knowledge with objects.

[Justin S]

I’ve spent 15 years at a fortune 200 company where we have almost always been writing procedural code in OOP languages, mostly Java. We generally feel shame for it, and occasionally an overachiever builds something with “proper” OOP. Every time it ends up being a mess and more trouble than it’s worth. This has helped me finally see why that has been the case.

[py Head]

Your company problem stems from too many programmers who don't understand OOP.

[Dovenchiko Doshorete]

@py Head I think OC and OP are both under the impression that writing with objects automatically makes you a good programmer. Hopefully this is obviously wrong because a pile of crap is still a pile of crap no matter what angle you look at it. If the object collection has weird hierarchical madness OO is not to blame, uness implemented so poorly in the language itself, but instead simply is a bad programmer/team.

[Juan Ausensi]

@Dovenchiko Doshorete I agree. Yes, using OO doesn't make you make good programs magically. I think the authour is a good programmer, and as good programmer, doesn't really understand the problem of bad programmers. He is always comparing good procedural programs with good oo programs, and he has some really valid points. But the fact is business wants/needs a replaceable workforce and that causes a high rotation, so you are going to have some bad apples sometimes. And OO really excels limiting the amount of damage a bad programmer can do. I think every criticism the author makes about OO is correct, but he doesn't value enough its advantages, especially the management ones, and also dismisses the problems of procedural programming, i think because he is good at it so he can manage that. And finally, no two programmers are equal: some understand better (and consequently, are better at) some paradigms, an some other understand better another paradigms.

[Juan Ausensi]

@Unformed Void No tool or technique prevents damage, but modularization makes the damage contained. OO forces that modularity, and that's why it is the popular choice for business. That was what i was pointing out. Remember that the 'best' language can be one from the point of view of the programmer, but another one from the point of view of the business.

[chris schaefer]

I'd say MOST good java code is actually written in the style above. The things which are encapsulated in classes tend to be a) various functions which are logically grouped together and b) configuration (which is a bit like global variables as it pointed out in the video ). The reason for this is that most server side codes needs to be entirely re-entrant, so storing state (other than configuration ), is a no no. State ends up in databases (of various forms ). The only exception to this is various caching type functionality.

[Heisenberg]

This is how I saw scientists program intuitively. I was an experimental physicist before changing to the industry and most programs, I have seen back then, written by physicist followed the functional programming idea. Maybe, because all of us were comming from a mathematical background. Some programs were a mess though and comments were in Portugese, German and English on different layers of code. ... Good memories. And good video.

[xox3769v]

everyone knows scientist writes the worst code

[Elliott S]

@xox3769v not even close. engineers.

[Link_Team]

i knoww XD Procedural coding has its name literally because its how most would learn to code if self guided. i think. usually accurate but not probably not correct.

[Ian Rust]

Scientists don't know how to program, this is well known to software engineers...

[00SEVEN28]

Well, the quirky thing is that we're doing OOP when deep "in the beast of the machine" it's literally running the code in a sequence vis a vis procedural.

[TrashPanda]

The irony of this video is most people watching it are just going to be better at OOP by the end of it.

[ParmakSocietySystem]

that is because Brian Will understands OOP. to criticize something you first have to understand it. and if you believe he know OOP better than most of us and also procedural, why is there so much disbelieve in his statement that procedural is better? the way Java does OOP is just a special case of procedural programming. it forbids a lot and what it does not is called OOP in Java.

[TheSimoc]

Yes, and for yet another level of irony, this was at least as boring and confusing as are the tutorial lessons and especially those advocat-preaching speeches of OOP. Well, literally couldn't agree more - only the limits of understanding make barrier for agreeing. This proves that to the limit of understanding and beyond, OOP sucks!

[derp]

The objective was to get better not perfect

[75hilmar]

I understood maybe one third of the video but between the lines it seemed to make a pretty solid case for OOP.

[youuuuuuuuuuutube]

@75hilmar I understood all of it and I can say that if you understood the other 2/3rds, you wouldn't say that. He's really destroying OOP.

[Chiara Coetzee]

Side note: your idea of anonymous functions that don't capture any enclosing scope is very much possible in C++ by just using a lambda with the empty brackets [] which does exactly that. It's a cool idea to structure long functions using that, although I'm not sure how I feel about the arguments being at the end rather than the beginning. The use syntax would be nicer. Personally, in C++, I'd rather just declare some temporary variables right before setting up the lambda, then have it capture just those variables (so that everything will be up front).

[Franciszek Boehlke]

Well, for the thing he proposed you just use capture by value, and the syntax is almost identical to his use: [x, y]() { doStuff(); }();

[username7763]

I've made enough OOP mistakes that much of this resonated with me and wasn't really surprising. But the bigger take-away is much of these same problems apply to microservices. Each microservice couples it's own data storage with the service and they don't share databases. This causes all sorts of problems managing the indirectly-shared state. It is a similar problem, by trying to force a small encapsulation, problems get spread around but not made any easier.

[jonty]

That is a very insightful analogy.

[Ian]

Why would you put data storage into every microservice?

[username7763]

@Ian That is a fundamental concept in microservices. Each service has it's own data store containing all the data it needs to use. The point is to reduce how chatty your system is, rather than call another service for the information, read it from your own data store. This prevents other issues such as deadlocks or infinite recursion. It breaks DRY, but is an intentional duplication.

[Altair Cunha Júnior]

I feel like this guy would love to have an entire system in just one file.

[Jason Cone]

Good video. I was long mired in the OOP world, but a few years ago I started delving into the functional and procedural side of things. At this point, I'd say that I FAR prefer a functional or procedural approach. To me, moving away from classical OOP has been liberating and empowering (and I'd say it's also helped me when I do need to work in OOP codebases). It's changed the way I work. I hardly ever need to step through my own code with a debugger, these days. And I no longer care much about Intellisense-like tools which I used to think of as an absolute requirement -- I no longer need them the way I used to. I know there are many who are deeply invested in the OOP paradigm, think of it positively, and want to defend it (I was one of those programmers). To anyone in that position, I'd encourage you to investigate functional and procedural paradigms with an open mind. You might be surprised to find that you are a happier and better programmer moving with a move away from the OOP world. If not, and you still prefer OOP, there's no loss. Learning different ways of thinking about code will help you in the OOP world, too, and make you a better programmer overall.

[Hidria Marlfolk]

This was an absolutely fascinating video. I intended to just watch the start to get a vibe for the idea here and ended up watching the whole thing. I'm a SD student and we are using Java as our teaching language, and I personally am currently trying to square the circle; to extricate the cross-over from encapsulated objects. Something you said in the end about programmers taking good ideas to holistic extremes is something that even someone at my level can appreciate. A lot of the questions I have asked my lecturer, the ones that did not receive "good" answers anyway, relate to this idea. Super interesting video.

[Sam Hughes]

Oh, heck yeah. I normally hit the skip hard on lines like "One of the most important yada-yada." There was just enough nuance to promise the goods, and yeah. Maybe not a life-changer, but I'm with you!

[Ian Rust]

Lol... the video just speaks above the audiences heads, where most listening aren't educated / experienced enough to refute the horrible ideas. OO is meant for large projects where architectural issues matter. Java was designed for enterprise-scale applications. It was designed by Sun microsystems specifically for this purpose. If your application is 3000 lines, you might not need OO. You might be able to get away with using global variables at that scale (though if your application grows much larger you're pushing it). In an enterprise scale codebase where you have 10 million lines, no architect would ever design for reliance on global state, this would only result in complete chaos. There would be so many unpredictable synchronization issues it would destroy your application. This has been known since the earliest days of high level languages... Most of the people in these comments agreeing with Brian are students, or people with 1 or 2 years experience, small scale web developers, electrical engineers / other scientists working only with C, for whom programming is not their main specialty... etc. I can guarantee you very few of these people are working at scale, these ideas simply do not work at scale. Which is why they are not used...

[cavasnel]

@Ian Rust Linux is millions and millions lines of code in a procedural style. It has more than half a million contributors and has been maintained for 20+ years. Every AAA game that pushes the boundaries is made in a procedural/data oriented fashion because OOP kills performance. These two examples absolutely dwarf any enterprise app by an order of magnitude in complexity.

[Ian Rust]

​@cavasnel ​ Despite the fact Linux is written in C, the code in the kernel leverages many tricks of the C language to mimic OO. For a detailed description of these various tricks and their use within the Linux kernel google "is linux written in procedural style". Also.... according to The Linux Foundation, since 2005, “some 14,000 individual developers from over 1,300 different companies have contributed to the kernel.”. Most of those contributions are drivers, ... but it's not half a million, sorry.

[Ian Rust]

​@cavasnel Games are typically written with components based architectures these days, most are written with Unity or using various C++ libraries. Try describing a real game and how it was architected in detail. You just claimed the entire game was written in procedural style. What game was designed this way...? And what was the reason - was memory severely limited on the platform for some particular reason? This sort of problem was far more common in the days of 16-bit SNES than it is now. If you’re writing your own custom game engine or image processing functions, some piece of code that executes millions of times for a single update to the UI, then extra layers of abstraction could start to degrade performance. If performance is critical and resources are very limited, eliminating those layers will be one of two dozen optimizations you might do here - because you’re dealing with such a critical piece of code. The entire program would not be coded this way, this engine code will be tucked and the rest of the application will only interact with it through an API. In your main application, the part of the code that is user-input driven (not compute bound), memory management is the only thing that matters. A trip to disk takes about 8 orders of magnitude longer than a compute operation, processing extra layers is a compute operation… eliminating a single call to those layers might amount to a few microseconds worth of difference in performance, maybe. Depends on what’s in the cache. Depending on the compiler, it may actually make no difference whatsoever… To optimize in such a way any user-input driven code is purely idiotic, it is compromising the architecture for microseconds worth of performance. Meanwhile if you need to reuse any code, like an object model or behavior, in the entire game... you have to begin maintaining duplicated or global state for your code, and now you have a giant mess on your hands. I don't doubt some developers have done it, developers do all kinds of stupid things, but this is not a good design by any stretch. A more valid concern is potentially pulling in more from standard libraries than you need, increasing memory consumption, so some developers write their own custom algorithms that reimplement some things from standard libraries... but even this is usually a bad idea, the compiler recognizes & optimizes code in standard libraries, the code actually executes 3-4x faster than custom code. But this isn't a paradigm problem, it just has to do with memory management. Carry onward

[Vgamer311]

Hm, yes, this video has definitively shown me that I don’t actually know enough about programming to properly understand this video.

[Andrew Smith]

Just give it a bit of time and one or two serious/professional projects and you will know the problem firsthand!

[The Masked Man]

After two years in university you will understand it.

[avatar098]

@The Masked Man Give him 1-2 years in industry and he will definitely understand it if not already

[Clément Cazaud]

No worry, you have nothing worthy to understand from this video. Better read Gang of 4, Martin Fowler, Robert Martin and other references. His whole argumentation, especially about encapsulation (eg from: 23:04) , is extremely biased and perverse. His arguments are based on object graph examples which are badly designed in first place. If you respect reasonably SOLID and general OOP principles, you should NEVER get that kind of spaghetti object graph in first place. Then the code would be encapsulated already (SRP, DIP, ISP, LSP, demeter law, and so on...). Then you wouldn't need to encapsulate non existing spaghettis such as he's attempting to, to make his point about how "OOP is bad". And about his statement: "Abstraction = simplified complextity; abstract = hard to understand". Well why abstraction simplifies complexity is because we do NOT have to understand what is abstracted if it's abstracted, so again a perverse argument... Furthermore, abstraction is not more related to OOP than to procedural or any other paradigm. "Mistery why industry tends by far toward OOP"... Did you try developping then maintaining complex enterprise applications (changing often) in procedural, compared to OO? That wouldn't be a mistery anymore for you then... "Procedural languages are more polymorphic than OO languages", lol, special mention for that collector one... And the same goes for a lot of his arguments... That guy is a clickbait sophist misleading least experimented people...

[Comic Sans]

@Clément Cazaud Have you seen the guy's video where he breaks down four real OOP examples from proponents of OOP and how they could be rewritten in procedural form? I think one of the examples in that video was from Uncle Bob (Robert Martin). To be clear, I really respect Uncle Bob and I've bought and read his Clean Code book (his chapters about comments, naming things, and code rot really convinced me to kick some bad habits while programming), but I think the guy's video brings up an interesting point on how one example of Uncle Bob's code being convoluted because it was written in OOP fashion. I'm still relatively new to programming, so my opinion probably isn't really worth much at this point.

[jennisonb37]

This is such a profound video. I have always struggled with trying to force my code into an OOP design just for the sake of doing it "right".

[Merlin Moncure]

This is absolutely brilliant and should be required learning for any developer. One thing that is missing from this thesis is the database and the role it plays in managing state sharing across large applications. The same developers that push OOP also tend to push against database development or see the database as an extension of the OOP infrastructure.

[Carl Younger]

In a language like JavaScript, where OOP is optional, I find it makes sense to use some simple classes to structure modules, with a handful of helper functions. Taking bits of each paradigm as required works well in practice.

[Andy O.]

In Javascript OOP isn't "optional" it's just different - duck type Vs class type

[Sodium]

You can't really consider yourself a programmer if you are doing JavaScript.

[Kaspar Siricenko]

@Sodium what? lol It's one of the most popular programming languages out there. You really want to consider them as not programmers?

[Hi Everybody]

@Sodium If you're willing to learn that monstrosity, you deserved to be called "programmer."

[benedict]

After bouncing off OOP and coding in general and picking things back up, I find myself leaning towards this stuff you're saying, even though I'm not sure I understood all the context myself. I REALLY like that concept of a use x,y demi-function. It scratches an itch I had since the very first time I learned what a function was, and needs a lot less jury-rigging than a modified for loop.

[Michael McDonald]

This is really interesting to watch while I'm learning Vulkan. It brings up questions about interfacing with state-heavy shared objects. I guess that's always the rub with functional programming though, keeping the business pure while walling off everything else.

[Milos Zivkovic]

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

[Cruel & Platypus]

@gl3nda so you did the deed?

[geeshta]

- every video or post about programming languages anywhere on the internet

[geeshta]

Neither being used, nor being complained about make any language good.

[Bran Tran]

It's just another way to say the set of all languages is distinct from the empty set. Every language has it's flaws and so there will be complaints about every language. Even if there was a perfect language people would still have different opinions on it. So basically what you posted is a true statement with no use.

[Rose K]

I still never met a person who uses C and complains about C.

[arachno communist]

Thank you for this video! It was very interesting and relatable... glad to know that my issues with OOP weren't necessarily mine, but OOP's. I think I will try following some of the rules you laid out, and hopefully my analysis paralysis will lessen, and my programming will clear up a little! :)

[백수맨]

I agree with that OOP is not the only one perfect principle. However, I believe that you were able to make such a critique because you understood OOP very well. Saying “OOP is not good and you dont need to read those books” to begginers can misguide them. To realize that OOP is bad, they need to know OOP very well.

[C. B.]

That use idea kinda exists in R, there is a with(x,{}) function, but its not general purpose and moreover is super specific to a certain R data structure. Also R has scope searching rules that will try and find objects in every parent scope. Sooo yeah its not the same at all just a similar idea, which I think is a good one!

[Aidan Kemp-Harper]

As an A level student who just had to answer an essay question about why Oop is better suited to problems than procedural paradigms, It's crazy how engrained Oop seems in the industry lol

[cyberjunk2002]

This is a long video and pretty interesting but I'm not sure if it covered my main concern with non-object oriented programming which is how do we do a better job of avoiding side effects or just really messed up shared state? I'm wondering if the solution might be to use object oriented programming specifically when it relates to data but not to "responsibilities". For example you can create an object to represent some type of state that manages that state, including an interface for a database. But you should not create classes to do really anything else other than manage state... For example no factory classes, no controller classes, no classes responsible for some portion of functionality such as a servlet, etc etc.

[fred tingey]

I am a mother one of those old timers - started programming back in 1980. That was with an HP calculator with 15 lines of code and 8 memory registers. There were also the ‘optical cards’. You scribble your program onto cards by selecting various numbers, send them off to the mainframe, then a few days later back comes a printout. No keyboards. No monitors, and the printout just as likely to say ‘syntax error on card 3’ as it is to provide any meaningful result. Imagine, A code, run, test cycle measured in days! I have been through almost every ‘revolution’ there has been. Several times. These new fangled technologies come and go out of fashion on roughly a 10 year cycle, just with new TLAs. I have also been responsible for pushing a fair few of them myself as well as resigning myself to ‘here we go again’. One thing to keep in mind is the Turing Machine. Turing proved that all computers, and all languages, are equivalent. Pretty much, once they can do basic logic, then all languages have equal expressive power. Anything you can do in one, you can do in another. So arguments about procedural vs OO vs Functional are moot. I can write an OO compiler using a procedural language and vice-versa. Not efficient, perhaps, but doable. So what it comes down to, as mentioned in this video, are the practicalities. In practice, in a real team, with real people with real business problems and challenges. The efficiency of writing and maintaining the code. The efficiency of new hires getting up to speed and the risks of losing people with ‘the knowledge’. Building a system that is easy to adapt and extend that Ames the users/customers happy. This video singles out ‘excessive OO’ or ‘extreme OO’ as a bad thing - in particular encapsulation. Quell surprise. Excessive anything is a bad thing! For the comp sci students out there, just remember all these technologies are tools. To be successful in a programming career you will need to master a fair few of them. No real world problem, worth solving, can be done well with a single tool. As a wise boss said to me once, ‘this is technology. With the right tool it will go 100 times faster’. This was when I was writing my own ORM layer - not realising there was already a library to do that. Similarly, I once had 85 lines of procedural code replaced with a single line of (damn clever) SQL. Being a programmer is a bit like being a doctor. You can’t solve every problem with a scalpel. You can’t solve every problem with antibiotics. Every person is a bit different. You need years of training and a wide variety of diagnostic as well as preventative as well as curative tools, medicines, machines and hands on experience - book learning alone will not cut it. The main factor for deciding what tools to use is the Problem Domain. One thing I have noticed, time and time again, is that the ‘best’ computer code accurately reflects the Domain it is working in. I guess it is called DDD these days. From that perspective, and getting back to the video, your encapsulation level should reflect the natural encapsulations of the domain you are working in. Though this is more of a heuristic than an absolute rule. Let’s call it ‘Domain Oriented Heuristic’ programming or DOH programming for short. 👍

[Benny Hansen Lifindra]

Thanks for the information. I'm still an under-graduate. If anything, this gives me insight on my future in computer science.

[Shirom Makkad]

I liked that last paragraph of yours. Do you know of any resources to study this further?

[fred tingey]

Shirom Makkad mmm. Well, Domain Driven Design is the thing to search for. Most custom written (let’s say in-house) systems, built to support a specific business, end up with libraries, objects and data models that reflect the nouns and verbs and datasets that the business users use themselves. Encapsulation is also reflected in the various departments and functions of the business. Where this gets really interesting, is dealing with mergers/takeovers and internal re-organisations. Over time, what happens is that the system moves towards an ‘industry standard’ model - particularly as engineers and users are hired and fired between companies but within that industry.

[graham287]

Well said old timer. Just left my own comment on this 45 minute rant. I beat you though. Had to carry my cards to the computer building in a wheelbarrow. Those were the days - not. You still programming?

[fred tingey]

graham287 yeah - spent quite a few years ‘managing’ and ‘enterprise architecture’ but back to programming now. Mainly Python - which I think is now my favourite language. Mainly because it ‘defaults’ the right way, most of the time and automatically deals with edge cases. So less code.

[Andy K]

There's definitely some interesting ideas in here. One thing I didn't get was the explanation of abstraction. Taken quite literally, it would mean 'not concrete', and it does tend to have the effect of removing or hiding complicated implementation details. The video then goes on to talk about fracturing the complexity. In cognitive science a clear distinction has been made between complicated (having many parts) and complexity (multiple relationships or interactions between parts). In OOP you reduce the number of parts, how complicated it is, by evolving its complexity, making it more sophisticated. This makes it conceptually harder to deal with, but when you understand the concepts, there are fewer parts to deal with. The key to all this is levels of abstraction. The reason for not having long functions is that it's flat. When you compose one function of smaller functions you can understand the higher level function without needing to read through the implementation details. The smaller functions, when encapsulated, can be made private if the functions aren't used anywhere else. This reduces the size of the object's interface, which is what really helps in understanding a program, and also what reduces bugs. The drawback with having multiple levels of functions, that is, complexity instead of complication, is that of needing to pass variables as arguments up and down the hierarchy. Objects allow us to escape from the dichotomy of variables being either local or global, by acting on encapsulated object state, functions require fewer arguments. To borrow a term from the film "up in the air", glocal. That is a bit like punching holes in the walls of your house, but not making a hole that goes into your neighbour's house. You can also do that with scoping in procedural languages anyway, but maybe it's just easier to understand. A pure function is similar to a static method in the sense that you write them without access to the object fields. Component hierarchies have the same problem in frontend frameworks, and that's why you see "teleport" methods to get a value into your low-level components without having to pass them down the tree, and you make them less reusable in doing so. After all that, I'm not sure my conclusion. Some remarks seem to be common to both paradigms and have more to do with good vs bad code in general. One day I'll get my head around all this stuff.

[LC]

yeah i definitely disagree with having one long function all the time. and not every language has that inner scoping he was referring to

[Moisés Arellano]

@LC I think what he was really getting at is that there is a time and place for long and short functions. Encapsulation often results in extra layers of complexity being created that are often solvable if given a procedural approach. If a piece of code is only going to be used in a very small scope, why not just have it exist in that scope? All in all, the flow of logic needs very careful consideration before implementation. For example, is the code reusable? How difficult will it be to implement changes?

[NabsterHax]

Yeah, as a computer science student that took the supposed rules of the OOP paradigm and the supposed virtues it provides, I often wondered as the things I programmed became more complex just how on earth people tolerated writing code like this. I could whip up something fairly complex quickly with a procedural approach, but trying to force everything into boxes I was supposed to keep separate just paralysed me and I spent more time shuffling those boxes around to keep things neat than getting stuff done. All I could think was "this is so much extra work, but I guess it's good practice. It'll be worth it in the future, etc." So, can't say I was particularly impressed when I started looking into real world OOP source code and found out none of these rules are actually followed and people just threw around references to objects that were specifically there to allow global access to references of virtually every other object in a giant clusterfuck void of hierarchy. What's the point?! Now I still have to micromanage state myself, because your code will let me do things I probably shouldn't do, but I have no chance of understanding what's actually going on because most of your code is still pretending to respect encapsulation and is just juggling references to references which is now nothing more than a maze between me and the actual data or functionality.

[Polit Commissar Sarah Helene of the Red Menace]

Hey, I love this video and I observed many of the issues with encapulation. I am relatively new to programming and I would love to see an example of you writing in your favorite/preferred programming language with procedural coding.

[Guillermo Rodriguez]

There is no better paradigm than other, just use cases of each one. I actually use multiple paradigms in a single project. OOP is not really well applied in most projects, without a careful analysis and design you are not gonna get the benefits of OOP and you are gonna get frustrated, and If you come from a structured programming background, you are not really gonna get it. OOAD is about reasoning about the real words and how objects interact with each other, programming is just a detail.

[Joshua Worman]

would love to see a larger scale system architected in the methods advocated for at the end. mostly funcional but with state grouped into large oop chunks. sounds practical and intuitive. but ive had it beaten into my head that never trust a paradigm until youve at least explored it in the context of a larger code base.

[Taxtro]

I spent too much time asking myself whether a specific function should be in the ControllerAdapterFactory class or the FactoryAdapterController class.

[William Drum]

This sounds like a Monty Python joke

[Daniel Gould]

I spent too much time searching Google with "should I..." questions instead of "how do I..." questions.

[GodsAperture]

May God help you! BANISH THE DEMON THAT HAUNTS YOU!!! (Get rid of that evil naming convention you have)

[Onat Korucu]

When in doupt, put it in ControllerFactoryAdapter.

[Matthew Parker]

Sounds like poorly defined clasess to me. Do you really need both of them?

[Stephen Widger]

Each paradigm has its place and use. There are situations that aren't very conducive to OOP, but there are a lot of places where it works really well. There are also a lot of uses where it actually makes things worse. The problem is that a lot of programmers aren't great at deciding when and when not to use objects.

[Davi Mendes Pimentel]

the problem begun when programmers started to create abstractions instead of features. Features are "hard" things, I mean, you know what it will do, you know how it should do, you know the right way to it to do. Abstractions are, instead, "soft" things, it means that you will never know exactly the correct answer to solve a problem, even if you know the "hard" way to solve it. That's why we have the "over engineering" term on the abstract way, while in "hard" way, we don't nearly have it. May be the world could be a better place for new ideas if OOP didn't get so popular and accepted. Today that ones who knows how to do something in a "hard" way are considered lesser than that ones who have a nearly idea of how to make it, but in a "soft" way, and that's sad.

[Stephen Widger]

@Davi Mendes Pimentel abstractions have been the foundation of programming since Ada Lovelace. Do you know how to turn on logic gates and then which logic gates should be used to build a shift register? Most likely not, because of abstraction.

[Davi Mendes Pimentel]

@Stephen Widger When I say "abstractions", I'm talking about high level abstractions. In programming, "abstraction" is synonym of "subjectivity". Even the "High Level Code" and "Low Level Code" terms are subjectives, C Language in Web Development is considered low level code language, while in embbedded softwares, is considered high level language. I'm not saying that abstraction is something bad, I'm just saying that we are wasting too much time thinking on how to create new abstractions, instead of creating true technologies improvements.

[A Xerox WorkCentre 7225]

Sure, but such pragmatic prescriptions go against OOP's original philosophy and vision, there's a clear disconnect of what we've been preached and how things actually turned to be. I think that acknowledging that and making a clear break from this harmful philosophy instead of keeping OOP on the life support through some watered down variation of it is best for everybody.

[ProtFox]

I feel as though the way I program isn't common. I was self-taught with JavaScript and then moved to Java for Minecraft modding, then Kotlin for some other things. When I used JS I mainly did functional-procedural, then when I moved to Java I took on a more object oriented-imperative style. When I eventually switched to Kotlin I found it complements both the programming styles I learned nicely, and I commonly use both functional-procedural and oo-procedural styles in a program, depending on what I need to do with the code.

[distro logic]

My methodology usually goes, only encapsulate what is used in multiple places. Types and functions are made for code reuse. So you start out with writing it directly where you need it, how you need it. And if you at a later point realize you need something similar somewhere else, you encapsulate that function and its exclusive state into a type or function to use. That is basically it. Instead of going ahead and planning top down, you work bottom up and greedily split out duplicate code into encapsulated objects. With that, you get predefined interfaces, but they are actually relevant to your code. If at a later point you find you need something similar again, you can split up the type into smaller parts and recombine them to a new type fitting your new use case. You can also define interfaces or traits to describte this "class of types" so possibly different code can use all of them interchangeably.

[Lester Drake]

Hey, just want to thank you for this video. This explained something really well that I’ve noticed from trying to grapple with existing codebases at work and have intuited as a kind of encumbrance. Chasing classes down gives me a headache - when I want to understand what code does ideally I want it as sequential as is sensible so that I can follow the changes of values and potentially interrogate by pulling values out at different stages. Having classes built on classes built on classes all the way down means that often I get to the functionality I want but then can’t find weird the values get into that piece of functionality in the first place as whilst I’ve followed the hierarchy down one leg I now need to follow it up another! I’m a Data Engineer but have come into it without a degree in any computing field, and many of the things you’ve mentioned in this video I have come to on my own. Such as passing global variables into functions explicitly not just calling them for the sake of it. I totally agree that there is a place for objects/classes for data structures makes sense but not making all functionality Objects. DataFrames are excellent for my work and what they do makes sense, but that doesn’t mean that style of structure makes sense for everything.

[dustysoodak]

I have a visceral reaction against OOP from learning to code when it was going through its Evangelical phase, so I started watching this with the expectation to be entertained. Instead, I got some really well thought out commentary. I still think that features such as encapsulation and inheritance are incredibly useful for GUI programming, though.

[Forgotten Lich King]

Me who has done just a simple calculator in python: "He does have a point"

[ChillTyme]

A calculator is a very decent program to compare differences between languages, you observed right. You don't need complexity to know the rightness, only how logically sound and consistent it is. A calculator program fills these requirements very well.

[Equinox]

@ChillTyme Depends on how the calculator was implemented, in python you can use the eval function and evaluate most basic arithmatic in one line of code.

[Sapioit]

@Equinox But you have to limit the input to a certain set of characters, otherwise you can end up with a code-injection vulnerability in your program.

[badunius]

@Sapioit it's not the thing you'd worry about writing your first program

[Sapioit]

@badunius Not the first, true, but among the first hundred or thousand, maybe sooner if you hit that problem early on.

[Roman Rogowski]

Thanks for the video Brian! I’d be very interested to hear your thoughts on testing procedural programs, and whether you employ TDD, mocking, etc.

[Alessandro LaVolpe]

41:20, again, the D language has that: a _static_ local function. Used like a free function, but its name is only visible in the scope where it’s defined. Or, alternatively, you can explicitly mark a lambda as a function: Normally in D,   x => f(x) is a shorthand for   delegate(x){ return f(x); }, but if you’re explicit and use   function(x){ return f(x); }, you’re guaranteed by the language that the lambda has no captures.

[Manai]

I don't know where ECS fits into all this but all I know is that that pattern is what I use the most and I do away with polymorphism most of the time. I'm not sure if this is better perse than OOP but I've gotten so used to it. At first it was a performance choice but... at the same time, there's just something really complicated to me about class hierarchies. I do use interfaces sometimes but I never make a tree of it, so to speak, and the patterns I use are thusly very simple. The downside maybe of ECS is that it has to go through a lot of systems where the execution order matters a lot and often it's a pain to organize and replicate them.

[darkesco]

Great video! I'm definitely not an expert so this is kind of a beginner view. I love the Subject.Verb methodology, but I work in ultra high level systems like Unity, I feel like I'm coding more maintenance than say, a virtual reality game. Performance is important so I have to cache all possible references. Passing script references is tedious, especially when you need an object references at a physics collision or just want to pass an int to objects within the same heirchy. It becomes spaghetti. I've gotten lazy and passed entire prefabs (objects of objects) as a parameter. I follow the rules loosely based on what needs to be fast (game loop), but lazy where I have some milliseconds to spare (load scene, save file, etc.) Everything else is stupid Private [Serialized Feild], encapsulation, and circular communication. It seems to be more complex and nebulous. It's difficult to read and not really re-usable. Passing a simple bool to an animator becomes tedious. Going the other direction, trying to make a generic projectile script that can support multiple objects leads to a huge class that probably would have been better as 2 or 3 scripts with duplicate code. Like I said, I'm not an expert, but I feel the pain of encapsulate and trying to access so many references.

[Joni Hanski]

This was the trigger that pushed me to functional style, ditching most of baggage of OOP. I think encapsulation is a powerful tool, but all the good ideas about it have already been taken into all existing languages regardless of them being OOP or not. Spreading a project into two files is an act of encapsulation, say.

[pineapple ‎]

My (C)ommunist Coding style: A classless society

[Master Mati]

Your coding style is marxism. Communistic paradigm be like... Every variable, every method public. No private APIs. No borders between namespaces. No inheritance - every variable is common! Get rid of bourgeoisie class. Lines of the code, unite!

[Florin Jurcovici]

@Master Mati That would explain why communist societies failed ... they should've learned to be object-oriented :-D

[Master Mati]

​@Florin Jurcovici I find some things from programming outside IT: My favourite example are ads. Ads are nothing other than some unreliable message from some host to us clients. Normal people see products. I see that some outside API tries to change my internal state in suspicious way, so I need to project my thinking, so I will be able to handle this spam. (Sorry for my eng) PS Minutes before writing my previous comment I had watched Zizek xD

[federico saviano]

dontlikemath -.- Nice.

[Matthias Schuster]

@Master Mati Its maybe more like functional programming :P

[M P]

I started my programming experience in PHP. With PHP, you can use classes, but you can also write functions without classes. At the beginning, I just started writing functions procedurally in different files based on my need, without thinking about classes or other things. I continued programming like that for some time. After some years, I started a project in Java (a very specific text editor/IDE) because the company required it. I discovered all the things that you mentioned in this video by myself. I spent hours asking myself stupid questions, such as "Is class A related to this data more than class B?" and "Why can't I write a simple script for this?" The real problems start when the code grows. In this case, if you make initial design errors (which is inevitable because it's impossible to know what your complete program needs at the beginning, especially for large programs that take years to develop), there are two ways to proceed: 1) You don't care and start making objects that communicate with other objects with which they shouldn't be related. This will lead you to write spaghetti code, where if you edit a single class, you could potentially break the entire program. Adding something new will become a nightmare. 2) You have to refactor your entire program by introducing abstract concepts and classes that do stuff. However, these classes conceptualize subjective ideas that solve problems not related to the stuff that your program is intended to do. Classes and objects are not useless. I have used some classes in my PHP or Python projects in a few specific cases. Just starting with the idea that "I must use classes for everything (including writing a 'Hello, World' program)" is foolish.

[Alexander Marsteller]

This cuts into a fresh wound, so I just need to vent... The codebase at work is the extreme of what is described. Loads of tiny functions and Objects, scattered throughout hundreds of files (of course, half the functions are in header files for more searching fun). And the worst part, almost every function intransparently changes object state and the path of code execution is practically impossible to follow. On top of that, at most token attempts at catching bad user input, causing stuff to segfault for reasons completely unknowable without crawling along the path of code execution.

[Markus Kasperczyk]

I usually only use data objects, and I think of them as inspectable curried closures, and I treat methods as a more structured way of calling the closure and knowing exactly which inputs map to which outputs. The only reasons I ever do reference types are when I do any nontrivial resource management or stateful multi-threading. In those instances, I actually do try to structure my code in with a lot of indirection and inversion of control so it stays testable. But at the very least, I try to design a data-only state machine inside those objects to structure their behavior.

[Zoltan]

Thank you so much. You managed to explain years of my frustration and I couldn't put into words why I hate OOP. You put it perfectly. PP/FP forever!

[pepe crespo]

Functional programming has also its clear limits when you need mutable variables/objects/functionality because that is available only in run time: for instance user interface devices and dynamic inputs/outputs. In this case it is better and easier to code the business with dynamic objects than with monads.

[user2609980]

Try Clojure. Great constructs for safe mutable state like atoms.

[Omar]

In reality though the "combination of objects and functional programming" is already the real world way people use OOP and i might argue the standard. The problems with OOP are really just strawman uses of OOP. In the real world, encapsulation and abstraction are only used if it is beneficial, like reducing complexity and improving readability. In school, it's probably the case that everything is over-engineered, but that has educational benefits too. You get to experience the friction that comes with objectifying everything

[Ashraf Khalil]

One hundred percent agree. For example, he introduces a theoretical OOP practice(not sending object references), completely admits that almost nobody follows this practice, and then spends minutes following that explaining why this practice that nobody follows is bad. Well yeah, no shit, thats why nobody does it.

[Florian Maire]

Agreed. Even when in java, a lot of big projects end up having one or several "Tool" static classes which are used as a repository of procedural functions, used with parameters and all that. Because it makes sense, even if it is not ideologically perfect.

[Jorge Manuel De León Pinelo]

If I'm not mistaken, he acknowledged that people don't really program that way, didn't he? Anyways, I don't really care about that point. The thing you said that bothered me was the "school fail upwards by teaching you to do things that way", kind of part. I agree, but I just don't like that reality. Could schools be explicit about this and tell you that full OOP doesn't work? Shouldn't students learn something useful instead of that? If anything, I think we should push back against the literature that pretends that full OOP works.

[Omniphage]

in every project i was involved in, there has at some point been a situation where we went "damn, if only we hadnt cut corners back then"

[Omniphage]

@Florian Maire yes, those repositories suck ass, because they are usually strewn all over the code base, and the next guy is just gonna write his own "Helper" function rather than see if something already does the job. They result from not actually working on the architecture.

[Melvar Chen]

It’s interesting to me, coming from functional programming, to look at the thoughts at the end about a `use` block and the behavior of `return`. `return` has the odd behavior of jumping out of the nearest surrounding block *of a specific kind* - generally, ones tied to a specialized function definition syntax. In some languages, such specialized syntax doesn’t exist and all names use the same basic forms for binding; these also generally don’t include `return` in a recognizable form - the closest thing in some of them is a construct which serves *only* to be the target of a return, and has nothing to do with scope but only control flow. Further, there is some implication in the description of `use` in this video that only names within a specific kind of surrounding scope need be specified, with at least globals freely accessible. In a language where all scopes and the names from all of them are expected to behave uniformly, that sort of privilege would be undesirable, and you would need to `use` everything - even basic arithmetic operators, if those are bound names rather than built-in syntax.

[Icee Frags]

YES 100% yes. you have managed to expertly put into words my exact frustrations with new coding paradigms and frameworks. I would much rather write functions instead of having weird datatypes and meaningless required declarations strewn all across multiple files that is hard to follow.

[Anau Naga]

11:26 i felt that. I saw a LPWSTR was needed in my code and had no clue what that was until i searched it up I prefer c++ because of how low level it is while maintaining ease of use. I feel more in control of the data structures.

[bulletmunchr]

I never really understood this until I did business work in both OOP and Procedural Code. Procedural Coding was so much easier, like a shopping list of steps to do, like a flight plan. OOP, while it worked, required more overhead to do the simple stuff.

[David Green]

I've just started trying to learn OOP, and it has been an up-hill struggle coming from a lifetime of procedural programming. With all the fuss about OOP, I thought I was living in the past, a dinosaur who didn't know that it was extinct, now I am not so sure…

[Necronomicon]

11:43 "It seems like real programming, it has curly braces after all." I see, a fellow man of culture.

[Bel Rick]

I recently ported a PHP web api client into my project without thinking . It has 1300 lines of code, 8 classes 4 files. Pure unadulterated OOP straight out of College... The amount of lines performing the actual function of the application? 8 lines. Which was what was left after i pilfered it for my own use (i had a duh day not knowing php uses CURL library for webapi.)

[az chen]

*python has left the chat*

[William Drum]

haha goto go brrr

[Dominexis]

@William Drum Underated comment.

[Jorge C. M.]

@Bel Rick Who did that and why? 😨

[Verb Budders]

Cool video. I've definitely run into the problems you talk about at work but I always just thought "eh whatever I'm stuck with this" and tried to band-aid them as best I can like you discuss lol. The "excessive splitting" problem is particularly relevant, because we have these dogshit code sniffers that complain if any one particular function has too much stuff happening. I find myself needing to split up functions into building blocks that literally don't ever even get used anywhere else besides that one original function anyway, which feels pointless. That being said, I find your solutions to still sort of just be "do OOP better." In my experience anyway, all of your suggestions at 37:30 are things I've read and applied to a programming style that is still OOP at heart, discovered through an essential goal of "I want to do OOP better" - but maybe that's OK? In fact, the entire "Functions" section of the video seems to encapsulate what I just talked about, where a function should be split up in a way that does not make its components any more "widely usable" and instead is just breaking up the big function for readability. Perhaps I missed something, but I still really feel "procedural programming" as you described it is "doing OOP better." Which again I think is fine! But the video title then becomes a bit disingenuous, idk

[Vladimir the Aesthete]

I feel like the way OOP is actually implemented in coding practice is close to what Brian WIll is describing as procedural style. It's just that is some set of problems it's useful to think of a datafield as a piece of data (attributes) bundled with operations (methods), while in others this way of thinking about a problem at hand provides no additional value, and then it's better off to use pure functions or closures. Think of a GUI design or video gaming characters - thinking about them in ways which doesn't involve objects would probably result in heavy reliance on boilerplate and global namespace.

[Duckbilled Walrus]

I think putting everything in objects often makes code more convoluted, e.g. Factory classes for everything where it's really not needed, but I don't think putting everything inline separated by comments is a solution to that. When used with a modicum of thought, objects are very powerful and effective. Also method naming is really not that hard. Most of the time a name which succinctly describes the method can be easily picked, and using docstrings allows you to neatly add descriptions for extra detail without having to inline all of that information. If you're confused by a method, most editors will show you the docstring when you hover the mouse over them, so you don't need to clutter your codebase with excessive comments

[Dir Wir]

In my experience, it is enough that one programmer thinks naming is hard to get poor naming in the project.

[Nick Junes]

You don't put everything inline. You put logic in separate files you can pull in and compose. It's like using objects except you just pull in what you need when you need it. Then you thread the data like a needle. The needle goes in and gets transformed and then it comes back out and you use it in your current thread.

[A Xerox WorkCentre 7225]

As he said at the beginning of the video, there's nothing inherently bad about using objects as (one) way to organise code, the issue is not objects per se but the whole "philosophy" that comes with it.

[Skjöld Game Studio]

“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ -Joe Armstrong, creator of Erlang progamming language Btw, I code OOP in C++ :P

[Floyd Maxwell]

(1) Upper management loves to interfere in all aspects of a business. Executives are in love with their own abilities. Executives talk to other executives and fall in love with other ways of doing things. Without other executive knowing anything whatsoever about what they have fallen in love with. We can thank upper management/executives for OOP and other bullshit (like canned software programs...that don't fit your business...that you spend umpteen dollars on to get them to work...that then break with the next canned update...that upper mgmt/execs want you to go to...because they say so. (2) Microsoft has done more to harm programming than any other force on Earth. Microsoft has ZERO incentive to make good products. Microsoft has massive incentives to control the industry and get people coming back for new shiny dog food. If you make really good, really portable, really long-lived products...people won't need you any more.

[Holo]

As someone relatively new to programming, I appreciate how thoroughly you managed to explain your argument in this video despite all the jargon that was involved. It also taught me more about how and when to use both procedural and OOP, so thank you for that.

[Ian Anthony Martin]

The beauty of OOP, when done correctly, still fills me with joy.

[WERTYOO]

Wow. Really well done 💯 I couldn't help but crack up at your point about encapsulation flying out the window once objects are shared. Mainly because how obvious the point is yet I somehow never thought of it that way

[QATAB Chakir]

I just wanna thank you for this video your really validate my frustration, you exactly spotted and revealed clearly the OOP, MVC and Clean Architecture non sense and complexity i have been fighting lately

[The Zip Creator]

this is how I've pretty much always intuitively programmed. Recently I've had the disfortune of having to use java for a project and these are all things that I've thought of in my head.

[Sam McBride]

Readability, maintainability, and code reuse are way more important than being clever or just adding unnecessary layers. I don't recall when a template really solved anything for me, but a namespace did.

[Morgan Blem]

Minimizing state is something I think a lot of people gradually learn over time. Function side effects make your code difficult to use if your project grows enough, function side effects can just cause an overwhelming amount of bugs.

[Techno Turnovers]

I really disagree with people saying OOP is bad, but that's mostly because if it weren't for OOP, modding minecraft would be fuckin *impossible*, like holy hell it would suck.

[Daedalus]

@Techno Turnovers Coding efficient game engines and game logic would also be a pain with only functional or procedural programming.

[Hồng Kỳ Đặng]

@Daedalus not really, doom classic and quake 1 are those that were written in C very optimize and modable.

[Walter]

@Hồng Kỳ Đặng Moddable because it's small. For bigger size ones like Minecraft it's practically impossible to do with just procedurals and even if you could, you'll need a degree on Minecraft to mod it.

[Daedalus]

@Hồng Kỳ Đặng Doom was written in Objective-C. Quake was written in QuakeC.

[Angel Talavera]

Having no experience whatsoever and not bragging about doing what everybody else has been doing for the past 30 years, following the herd, I can appreciate the advice of an honest man! Thanks!

[grepgrok]

41:20 have you checked out c++ lambda expressions (which i guess is just functional programming) where you can specify in the capture exactly which outside variables you want to use and how to capture them (by memory reference, read-only copy, or read-write copy with the mutable keyword)

[Marco Chiappetta]

"Inheritance is irrelevant" A kid who just inherited a fortune: "🥺"

[Sean Foreman]

Everything has its place. I code daily in c++ for UE4. I favor comfortable easy-to-read code (because I have to maintain it). I like objects, factories and polymorphism. I also like longer methods where I can see everything in one place. I don't create a bunch of tiny methods because it not only makes it difficult to read but it also makes it difficult to refactor. I got sent to multiple training sessions with Sandy Metz when I coded in Ruby and she was a code-smell, tiny method, object oriented fanatic. Thing is, she wasn't a great coder. When I saw her ruby code she passed maps of data around into methods instead of individual variables because she didn't have to rewrite method signatures when requirements changed... and this person was training our company... repeatedly...

[Kevin Ray]

We had a propriety OOP programming language (not a full language) for a computer gaming company I used to work for. It served the purpose for what we needed.

[Chris Hawkes]

I know from experience, anytime you put an opinion out on something like this it brings out the pitchforks for sure.

[Jerome Potts]

Well he shouldn't have claimed this to be the most important video, or whatever similar.

[ScientificBEST]

Jerome Potts I mean, this is one of the ONLY videos on KZbin which explicitly calls out OOP as a bad paradigm. If his assertion is more true than false, then I would say this video is indeed one of the most important programming-related videos on KZbin right now. If it’s not, then whatever, maybe it’s not that important, and then the pitchforks wouldn’t be necessary... just a thought.

[30 seconds Tech]

Most people blindly believe what they have been taught at school. It's hard to fight decades of brainwashing

[La AmmO]

@30 seconds Tech lol

[RandomUser r95_1024]

@30 seconds Tech lol

[MechShark]

Interesting. I made a total-conversion ARPG mod for an RTS recently and found dealing with class organization to be the key struggle. The code, though powerful in the context of the mod, ended up as spaghetti as anything outside of the object's scope required additional subclasses or types to control things since they didn't necessarily belong to that class, or could exist in one class or another since they shared featurization (in game dev, this is probably a common issue as features are added). For every added layer of complexity I'd wager the effort to make a change increased by 3 to 4x (which is pretty crazy). It starts to make sense why the AAA titles coming out today are a mess, given the size of the stack at play and the corporations fiddling with them. Nightmare fuel.

[A Xerox WorkCentre 7225]

A lot of games today are entity based, not OOP, so instead of a class for each NPC, the NPCs are just a number, that refers back to a container that has all the data of all NPCs, that is then updated by a "NPC" algorithm. I'm not familiar with those systems but that's the gist of it.

[MechShark]

@A Xerox WorkCentre 7225 Does this mean that OOP languages are wrappers for the entity engine? i.e. Unity and Unreal?

[A Xerox WorkCentre 7225]

@MechShark I have no idea, Unity seems to be OOP, but no one in their right mind would write a brand new engine using OOP these days. edit: apparently unity was refactored to an entity system

[Ryan]

When I first started my current job, I saw methods that were 400-500 lines long. And my initial reaction was, woah that's way too long and it's gonna be really hard to figure out what's going on. But it was totally the opposite. It is so nice to not have to step into functions in the debugger. It's perfectly easy to follow because when I initially look at the file I only have one method to look at and I know the order that every code gets called in, as opposed to seeing 20 methods and not knowing when they get called or how useful they are.

[Joakim Wahlström]

Yeah this. I have been suffering the last 20 years with this madness that the universities teaches. Making endless access methods, abstractions and millions of classes out of everything. I don't mind shallow inheritance every now and then, but personally I love procedural code done with pure functions. Every function just has some input and leaves some output. No state kept or changed inside. This means that you don't need to know what is going on inside the function. Code gets so easy to understand and read. I often find larger OO projects extremely stale, hard to grasp and almost impossible to alter after a while. I sometimes rewrite some OO system... and the procedural one becomes 10 times smaller, and ridiculously simple in comparison.

[Nevo Krien]

I am fairly on the procedural/functional camp but when using tensorflow i got to say that the build in classes do make things easier

[Wayne Thompson]

My first programming language was Fortran IV in 1979. For over 30 years I got paid to write COBOL code. During the time I’ve seen languages and theories come and go. I learned PL/SQL in 1997. As a procedural programmer, switching to OOP drove me nuts for many of the reasons you mentioned. All those factories and patterns made it nearly impossible to find the business logic. I retired and came back to do pl/sql again.

[Elke Ospert]

COBOL and Fortran are optimized for a specific area of problems - and inside their area they are fine because they are very limited - it is difficult to write code in COBOL or Fortran which is hard to understand. But imagine you have to implement a graphical user interface having a dynamic number windows containing complex dynamic layouts of widgets of different type (Checkboxes, Radiobuttons, Textedits) using COBOL or Fortran - it would be a nightmare...

[TrueFork]

reminds me of a time I was on a Java project, one part was an incomprehensible kludge and the developer responsible answered every question with "oh this is the (whizbang) design pattern, refer to (book) if you want to understand it." When I finally dove into the code, I found the synchronisation was completely broken, and that he didn't have a clue about multithreading but always managed to blame the resulting crashes on other things.

[TehNetherlands]

In my limited experience, object oriented programming and design patterns mostly thrive in large projects with an extensive architecture and clearly defined requirements, hierarchy and modular setup. But ONLY if the initial OO design can be made with extensibility in mind. The problem is, most projects do not start out like this. Instead what happens is that the initial design quickly becomes obsolute, and the added overhead of religiously sticking to OOP principles at all cost can lead to additional overhead and headaches, especially when a project starts out small and then slowly keeps on growing with new features being added until it becomes an eclectic hybrid OOP / functional mess. Somewhere along the way, new features could not be incorporated in the existing object model, and a full redesign would take too long, so compromises were made. The technical debt increases, more concessions will be made, until eventually the project becomes a tangled mess. For smaller scripts and programs, stick to functional programming, especially when you need to work fast and produce results. More complex projects should have a solid OO architecture from the start. If that is not possible due to some unknown future requirements, then at least embrace the fact that a full redesign may be necessary. Unfortunately the customer is often willing to pay for the extra hours required to work around technical debt rather than the cost of a full redesign, significantly reducing the quality of life of many a software engineer.

[Fathin]

Imo that's why microservices arch shines, because rebuilding a service is easier and harmless (as in easily switched with any programming language and paradigm)

[A Xerox WorkCentre 7225]

"Somewhere along the way, new features could not be incorporated in the existing object model, and a full redesign would take too long, so compromises were made." And remember, all those patterns were added on the promise of making changes faster and easier, and yet you get the absolute opposite. It's a simple equation, the more constrains a program has, the more stuff you need to refactor when those constrains change. Maximising constrains in order to "avoid mistakes" always lead to development time increasing with no end in sight. The solution is removing (most) constraints, and letting programmers do what they think it's best instead of writing all this bloated mess to try and constrain what can and cannot be done in the system. Even it the programmer screws something, fixing their mess is gonna be easier and faster than plowing through all the boilerplate code to update the constrains. Let people access whatever data they want, and bind it to whatever function they want, that way any change can be implemented on a heartbeat. Of course this may lead to things get entangled on weird ways, but by following simple procedural best practices this can be avoided without the complexity and slow development time that comes with a high-constrain approach. The issue is that because procedural programming is the most simple and intuitive style, it's the one preferred by n00bs, so it got a bad reputation, many programmers look at a procedural code and automatically say it's bad just because it's procedural, even tho if they were to work on this code they would be able to understand and modify things 10 times faster than they do in the OOP codebase.

[Graham Plowman]

Something I have frequently come across in client organisations is projects that started with the right intentions around a solid OOP architecture, but ended up being implemented by people who didn't have a clue what they were doing and were supervised by people who had even less of a clue! Once that happens, all the issues noted by @TehNetherlands become reality.

[Daniel Jeffery]

I return to this video periodically, every year or so, as I improve my knowledge of programming concepts, each time I understand it a little bit better :)

[AmadeusK525]

Me too!

[MFilipe777]

same

[Daniel Jeffery]

@MFilipe777 Good to know there are others out there who do likewise :)

[AmadeusK525]

@Daniel Jeffery Hahahah this is too much of a coincidence. I returned to the video today again and here I find a comment from you from 1 day ago.

[Daniel Jeffery]

@AmadeusK525 I agree!

[Praveen b]

Brian, please consider making a tutorial with tips for those who aspire to make presentations as well as you do.

[magicmulder]

Recently I had to implement a Google BigQuery API call using Google’s own library into an old PHP project that didn’t have all the modern composer stuff, no autoloaders etc. I ended up having to include 97 (!) classes until all dependencies for a simple API call were satisfied. (That is what modern frameworks hide from you.) That’s when I realized this sh.t had gone too far.

[Andreas Maertens]

I can really associate to that video. People are often burning way to much energy in creating unnecessary complex stuctures even for small pretty straight forward programms when there is no need to. You are always diverted by numbers of subclasses or you are running against an interface and have to look up the realisations. Once you found them you forgot why you are there and have to rethink a load of functionallity and loose track. My inner developer always had that feeling and your words are straightening up those feelings quite good. Thanks mate.

[A Xerox WorkCentre 7225]

in my experience, interfaces are only good if you can write them once and never look back, if you gotta to keep going back and re-read the implementation then it's better to just remove the interface since interfaces get in the way of understanding the implementation.

[Donald Strubler]

I think the main issue is the assumption that the abstraction tree cannot be structured in a way where you avoid the complex relational lookups. I would argue that running into those situations is indicative of bad initial design approach in general, or a method existing within the wrong object in the first place. It seems like neither would help here, but instead to allow tests to drive the structure.

[Randy MacLean]

Excellent video! I have decades of programming experience, have written high-performance code in broad commercial use, and now oversee a complex system of over a half-million lines of code -- most of which I've written personally, and uses the exact methodology you've outlined here. The code base has been reasonably easy for others to understand and maintain, and substantially contributes to productivity as well-designed functions return predictable and reliable results, speeding development of new capabilities. I'll be sharing and recommending this video so others may benefit from your wisdom and experience!

[A Xerox WorkCentre 7225]

Your juniors are really lucky. I was also lucky to work with a senior like that, he valued simplicity and using basic language constructs that are understood by everybody instead of some weird custom thingy.

[Huzzah]

I really needed to see this. It's like I'm looking back at myself of the past, and this was always the obvious point I was supposed to reach but I somehow got lost along the way. This is what programming should have always been about for me but it never was, and it made me displaced because I was always looking at it from this artistic angle, but the pieces of the puzzle just never truly fit together, while nobody else ever gave a damn. That tree, the need to send a message up the nodes to send it back down, I felt that hard, it's the kind of minor thing that leaves me stuck for days working on until it kills the passion for what I'm working on and effectively kills the thing I'm working on. The way you talk about documenting your code, organizing things, it's like staring into a mirror. I wouldn't even know where to begin, but I would love to talk to you more about this, or even better, have some group pertaining exclusively to this kind of discussion, I cannot put into words how refreshing this would be to me. You did an excellent thing bringing light into this topic, I'm thankful.

[Graham Davies]

Huzzah, thank you for writing this comment because now I don't have to. I feel exactly the same way in every particular. Fortunately for me, I am now retired and have taken up woodworking. Now I agonize over whether to use a hardening oil finish, shellac or water-based urethane.

[User Name]

If you haven't already seen it, you may appreciate Rob Pike's "Public Static Void" speech. Mr. Pike was one of the designers of Go, a language that Brian brings up in this video a few times himself (and does so in a positive manner).

[ChillTyme]

Yep! Started out with Java in school and its good until you get out of the basic algorithms and data structures in isolation. Started making Android apps cause I figured that's how its done since I already know Java and wow, did I have this same frustrating experience to the point that I quit! I never much bothered to look into how people felt about these things and would sometimes read an article or two from people who should rather be designers with a keyboard instead of pencils, the web developer types, and would never really get anything concrete, very vague things that, at the time, I assumed I did not quite 'get' because they were simply better than me. Now that I am in a better position, it seems so surprising to me just how much contet surrounding this industry on the internet is utter pollution advising you to do things in a way that makes other things get in your way than get the job done!

[John -]

Same here. I realized the importance of refactoring code but what killed my passion was thinking that everything had to fit together into labels and that it’s useful to do one thing in a million places for the future. I guess in any situation, one shouldn’t do X just for X’s sake

[Euquila]

I've been programming since 1994, when I was 10 years old. At 38 years, I've seen a lot and consider myself to have a lot of experience on these matters. Here is my wisdom: think in terms of tradoffs. In tech, choosing one thing over another entails tradeoffs. That's it! That's all I got :)

[Milkman-007]

ok boomer

[Gladuos]

@Milkman-007 ur cringe

[Paras Mittal]

That's really just decision making in general!

[Herbie Goes Bananas]

That's all there is really.

[Herbie Goes Bananas]

@Milkman-007 ok child

[Eccentric Orange]

Several people have commented on general quality of the video, OOP itself, and other relevant topics. What the heck does one have to do to have a wonderful voice like yours?

[AramisWyler]

When I learned OOP in the late 90s in C++, it was much more similar in concept to his list of how to do good procedural programming (except the sub functions, which would violate loose coupling) than anything in the perversion of OOP that was Java or ADA. Those languages took encapsulation to rediculous degrees and crapped on other principles of good Object Oriented work, and so I feel like the poster here has put together an excellent rant against say, Java, but has misplaced his rage against Object Oriented in general. Such was the brainwashing popularity of Java that people started to take it as the reference implementation of OOP and not just an overbuilt mass of systemized syntactic sugar (w/ garbage collection, which I appreciate like I appreciate airbags; only usefull when someone screwed up, but screw-ups happen).

[Jacques杰]

Just about to finish Java, and I already agree to this video 100%. It’s been 6 years now, I think more people are coming to this idea.

[H. H.]

I don't understand half of the jargon you're using, but I think it's funny to hear my intuitions as someone who hasn't (until just now) ever formally studied programming being repeated. I've never seen the point in writing functions I'm not going to repeat several times, so I usually write code all together with comments and spaces if I need to separate it (structured programming, I think) like you describe after 37:20. I've never really been sure why I should use a class. I did develop (in Python) a, perhaps unfortunate, habit of using cryptic tuples or lists instead of attributes of objects defined in a class definition, but dictionaries with string keys can be just as uncryptic as attributes.

[RevStickleback]

Something I wrote was very much like that. Some guy came in and had to take it over for a while, and he wanted it to all be refactored into functions, to be 'cleaner'. In fairness, the code did look beautiful when he had finished. It didn't work any more, unfortunately, but he didn't seem to think that was such an issue.

[Tachibana Kyosuke]

“Procedural code is better” Me, a COBOL programmer: Is it finally my time?

[Justin S]

Always has been ;-)

[Serghei Tricolici]

Hahhaa :) I've done COBOL in the past, don't really want to go back to it sincerely )

[moestietabarnak]

procedural is not an essay ! COBOL is so damn verbose, is it still ADD X TO VARIABLE or MOVE BlahBlah TO thisOtherVariable ? Everyone else found that Variable += X or variable =variable + x is as informative without screaming in prose.

[Martin]

@Serghei Tricolici I cut my teeth on SNOBOL. It's not really SNOBOL I wouldn't want to go back to (although frankly I can't remember much that far back) it's the primitive Dec MicroVax hardware I'd rather not go back to. "Hey guys, is the tape deck free?" or "is anyone running anything at the moment?" Glad we're not heading back there!

[na zo]

Yes, you would be very successful working on OOP projects. You could join all the teammates not understanding and hating OOP. ;-)

[seamuskills]

As a game programmer who is used to using OOP, I don't really know how I would do it without OOP. I am probably too used to making things like walls into code classes that are used as blueprints for objects to be used in level loading. Other than for things like that though, I rarely use OOP.

[Surplus King]

For game development, OOP is the best option among other options (functional, procedual, etc.) you could choose from. only ritually 'strict' OOPs are inefficient.

[Ribulose15diphosphat]

Game Programming however has a big pitfall for OOP: Vectors. From the mathematical POV, Abstracting Vectormath (wit Operator Oveload) into Objects seems natural, as you can simple add vectors with the + opearator.. From the Assembly POV, doing that is killing the performance with automatic Memory Mangment, as every singe Object on a functions stack will be alloc()ed individually. Doing it the hard way: "vecmov(&v3,&v1); vecadd(&v3,&v2);" may seem bad compared to "v3=v1+v2;", but since v2,v2 and v3 are just local (=on the stack) structures instead of pointers to structures allocated with "new" it runs much faster.

[indie sigi]

@Ribulose15diphosphat those vectors are never heap allocated with operator + calls optimized out. Compilers are insanely good nowadays and vector would have never been malloc'd . In c++ that is. It's zero cost abstraction it's one of those great things of c++ and it's oo.

[H ot]

It is more about encapsulating it in modules and lose couple everything in a "god object" per module. So only the the "god object" per module is entangled, no other classes in that module, which means you pass a lot of Parameters which results in more use of structs to maintain those. As he said, you can't escape the tangling completly but you can make it very easy to understand and minimize the tangling zoo. So no more Singletons that pop out here and there and see everything in "Modules" or "Context".

[lie]

​@Surplus King that isn't true at all. A data driven ECS approach is fantastic and quickly becoming industry best practice.

[Mick Namens]

21:06 In a system which handles parallel requests you need transactions to avoid that mutable shared state might cause problems. Each request processing thread needs to get its own copy of objects with their state. At the end of the transaction you try to write the result to the database which might fail if some other thread was faster to write its results. In this case your process has to start over.

[Ian Rust]

Just one of the many problems completely glossed over in this video, lol. The video just speaks above the audiences heads, where most listening aren't educated / experienced enough to refute the horrible ideas.

[UNDINI]

Thanks for this video. The ideas and suggestions made here have solidified some murky thoughts that had been rattling around in my head. I've just started thinking about these things and I feel like this video has given me the inspiration and tools I need to make a practical improvement in the way I write programs starting today. What a lucky find!