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.
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.
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!
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.
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.
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.
I've known some very narcissistic programmers who write this kind of code for huge organizations like banks. Usually they have zero experience outside their language of choice from 15 years ago and think "standards" and "good practices" are gospel. They usually have zero creativity and think things like "you should use DateTime to store a year value because it's made for it" instead of using a bleeping int. That guy built a framework for every single little thing, and thought Microsoft invented marshalling. He literally could not define the term outside the context of the .Net Framework. And big companies paid him well to write overengineered crap. Of course, he constantly bragged about all this amazing stuff he'd learned 'at the top.' 😂
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...
@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.
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.
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.
@@googleuser2016 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.
@@s0mbres 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.
@@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.
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.
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.
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...
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.
@@drygordspellweaver8761 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... 😁
right? like there's no silver bullet, there's a lot of these "oop bad functional good" or vice versa bullshit on every forums and it always strikes me as biased. there's soo many different kinds of weird real world problems that one coding style isn't enough.
Seems like too many developers have lost sight of this. The end user doesn't give two shyts about whether you used functional or OOP programming in your coding. They only care that it works...and as long as it does what difference does it make? Code it the way you are comfortable coding it instead of constantly chasing after what's in vogue right now.
Define “the job”. If it’s anything other than “make it work this week and then delete it”, these kinds of discussions are vital to the long term flexibility and maintainability of the code you write.
Transparent “working code” may be working, but it still falls on various spectrums of maintainability, flexibility to change, complexity, performance, etc. I’m tired of people using “different tools for different jobs” as a hand-wavy excuse to use shitty tools just because they feel familiar. Sure, don’t go chasing fads, but it’s worth considering whether programming really IS that difficult, or whether we just make it that way out of ignorance and inertia.
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!
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".
@@UncaAlbyGmail 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
@@UncaAlbyGmail 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.
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.
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.
@@HumanBeingSpawn 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.
@@tongobong1 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
@@MartinSparkes-BadDragon 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.
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!
@@a0flj0 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
The biggest problem I have with this video is that it completely forgoes one crucial aspect of development - testing. Not having modular components and having "God functions" that do everything in one place makes your software really hard to test, you can't really test individual bits of logic and it will become a nightmare to debug your functions if you need to make even tiny changes. Besides that this obviously introduces a very high barrier of entry for understanding your code, there is so much that a human brain can process and keep track of while reading and grasping the full picture will take much longer than if the same logic was split into separate components, and in many cases the ability for your colleagues to quickly understand what the code does without delving too deep into implementation details is really important, they in general would have other shit to do and spending an hour to understand what a function does is not a good use of their time
Working on large, highly complex projects, I've found the opposite to be true. Human brains struggle with interlocking complexity, not cardinality. We use the functional core imperative shell apporach -- even a non-technical person can open the "shell" procedure, read it top to bottom and understand what it does, hell they might even be able to make minor edits. Uncle Bob-style OOP does the opposite -- it fragments business logic into as many small, individually meaningless units as possible, making it much harder to build out a mental model in your head. Our code practically has a UML sequence diagram built-in, and our engineers love it.
@@dukiwave Its funny because I've also worked on large and complex projects, and modular code with broken down function points is absolutely crucial if you ever want to extend or maintain your code. Having smaller function blocks allows fast isolation to problematic code. Not being able to form a mental model is more of a skill issue and can be overcome with time, code comments and documentations.
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.
@@Ian-eb2io 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.
@@username7763 Are you telling me each services having it's own data store is so that it CAN have access to the data? Otherwise it has to call other services to get the data for it?
create state, create controllers, design gui. besides that you need a state that allows function for your site/app the controls to manipulate it towards the users objective and then the GUI for an end user to manipulate the controllers they have access to.
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.
@@equinox2584 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_code my first calculator was a graphical calculator made with tkinter, mostly to avoid messing around with eval and hardening against code injection lol
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.
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.
@@user26912 Clojure/FP makes things much slower and trashes memory so you have to ask yourself why are you using multithreading parallelism at all. It's done only for performance and if you waste this on clean code i don't understand. Then write just zero shared data multitasking.
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. 👍
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.
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?
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.
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!
It really depends on the problem. I programmed the first ever constructed OOP-language in 1970 which was SIMULA and has since then used various OOP-languages including Object Pascal, Java, Javascript, C++ and Ruby. Some problems are really difficult to tackle without objects and for some others objects just distract from the task what you actually want to achieve. Nowadays I mostly use procedural programming but occasionally add in objects for special tasks. It just boils down to common sense when to use it. I agree to that OOP is overused and often just adds confusion when one wants to understand what the code of others actually do.
"The messages only ever go from parent, to the direct child. Otherwise who is responsible, who is managing that state?" Actually the state can take away the child by legal action if the parent isn't responsible.
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.
@@TricoliciSerghei 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!
Just found this video, found it really informative and I'm glad someone pointed out that OOP isn't some magical methodology you learn and becomes default. From what I found with OOP is that most cases it's either a) Trying to be an overengineered struct, or b) Trying to be an overengineered function (or group of functions). It seems most people use them because it's normally the most advanced thing they learnt and they assume "it's what the real programmers do" (Like a kid mimicking adults). Unless you specifically need inheritance or instancing (e.g., gamedev), FP makes way more sense than OOP
There's been a shift in gamedev away from OOP because objects are slow and hard to multithread in practice and class hierarchies are simply too restrictive to express complex game logic nicely. These days many big titles are built using entity component systems which in many ways mimic relational databases, with every entity being an ID with components like position and health associated with it.
There is a other way of seeing it, and it's fairly simple : OOP is good to learn to learn how to suffer in it and know not to touch it later on, while still learning about UML stuff (which can be transposed in FP)...
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.)
You can write bad code in any style. I have been programming for 30 plus years in anything from assembler to lisp, c, java, pyhton, cobol, miranda, basic whatever. The only thing that matters is that you work is tidy, has a consistent strucnture and documents where it has not and communicates it's intention well. The whole OO vs procedural vs functional discussion is irrelevant and frankly feels a bit childish to me. They are just ways of connecting the digital pipework differently. If you are a good programmer you will be flexible and able to recognize logical patterns and structure in any coding style. Or if that is difficult for you, just stick to one and be an ace at it.
Like they say, whatever floats your boat. I, personally prefer procedural programming, but I have nothing against OOP. It has its flaws, yeah, but as long as you can do the job right, tidy and functional, you can do it however you want.
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.
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...
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.
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.
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.
@@visitante-pc5zc 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.
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.
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
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.
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.
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.
@@MjolnirFeaw 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.
I've done a lot of procedural programming back in the early 90's and then switched object oriented programming. For me, OO code is easier to read, quicker to develop and evolve. I do use procedural here and there but if an object is appropriate then I'll use it. I like C++ and Java.
Most of the time objects are not appropriate. The problem with OOP is that it has gone from yet another tool in the toolbox to a forced methodology. It has, Marx forgive me, become the Marxist ideology of programming.
Did you watch the whole video? He isn't advocating against objects. He's advocating against inheritance, polymorphism, instances and strict OOP decoupling. His suggestion was specifically to use objects but not in a dogmatic OOP way.
@@omicronx94 And thus he takes out some of the most important tools in OOP. Without inheritance you won't get the sweet decoupling with dependency injection that is very popular with .Net developers today. Also decoupling isn't bad in fact its very good, when you work with larger programs, you will be very happy that the code is isolated, so when you want to change something, then you will only need to change it in one place and not more. It also really helps to expand your program, by limiting what you need to change. What he is asking for can easily be done with C code, but history has proven him wrong, procedural is inferior to OOP, when one uses OOP correctly, like don't use polymorphism for what is basically a switch case, it should be used when the data structure fits the split into more classes with a common base.
I think the video could be more digestible if you didn't sensationalize it with "This is the most important programming video you will ever watch". Not that I am one to talk though.
Jerome Potts I mean, this is one of the ONLY videos on RUclips 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 RUclips 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.
I would say it is difficult to write large systems that are well structured no matter what language is used. There is always 12 ways to do something and 10 of them are not good choices. Having designed and implemented and programmed in many Common Lisp systems, I've always found everything newer to be worse and disappointing, and it is satisfying that functional+object programming is now finally getting the respect it deserves. Javascript seems the closest to what we had in the 1980's..which is both disturbing and hopeful. I almost wonder if the time is right to bring back Common Lisp, or the simpler subset like NiCL that I created. The last 10 years all I do is write microprocessor apps using C to run in chips that have memory sized in kB. It is refreshing to be able to see the entire app in a few pages of code. I don't think Common Lisp would work in this environment or I would have tried to get it working. I see the chips have gotten big enough that they are running micropython these days...never tried it.
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!
The anonymous functions denoted by the “use” keyword exist in C++ lambdas, right down to the explicit list of named function variables that can be shared with the anonymous function.
Is that what a lambda function is? I have been trying to understand lambdas for so long that it's embarrassing. The "use" idea described at 41:40 makes perfect sense to me. Is this all a lambda is?
@@1u8taheb6 Yes that is exactly what a C++ lambda is, it allows you to capture any or all variables from the enclosing scope either as references or values, and also allows you to pass in regular variables like you would to any function, you can combine these options in any way you like, they are very handy.
@@koacado Python Lambdas allow only one expression. Python lambdas are also closured which means they capture the variables of the surrounding scope. The proposed "use"-block should be like an immediately invoked function that is NOT a closure.
Poo-pooing autocomplete as "groping your way through" is a nonsense argument. Programming isn't about memorizing rote syntax, and having that belief is a recipe for disaster in a codebase of any significant size.
Imo a good programmer is the one that comes out with te best and most efficient solution, not the one that memorized all syntax. Autocomplete is a really good tool that improves workflow exponentialy
Absolutely. Especially if you're modifying someone else's code or code you wrote more than a year ago, autocomplete is an absolute lifesaver. This is why it takes me 3 times as long to write JS as Java.... I have to constantly look for function names in other files that were written years ago by other people.
it seems like these "oop critics" have only ever woked on single person small scale applications where they could reinvent the wheel without it taking years - its also proably a very shitty wheel if they just came up with it themselves.
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
Thank you so much for this. As a programmer from the days of Fortran IV through Pascal, C, Java, JavaScript etc I always felt a bit of a fraud when not writing "proper" object oriented code. I much preferred writing in a procedural way. Now I know why!!! And yes teaching OOP is a real hassle as I'm always thinking, but really I don't need to do this... 😀
+The Foun Neither do I and according to the video it would be a waste of time figuring it out. O well, I don't even program yet. I ordered a book on structured BASIC today. when I am confident in making 3D Games in Basic, I plan to learn C. When I am able to make AI for Arduino in my sleep in C, I plan to learn Varilog. When I am able to synthesis instincts for robotics in Varilog, I plan to learn Assembly. When I can wright a kernel in Assembly, Then I will consider myself a programmer. It all begins with Structured Basic and game programming.
It drives me nuts that people act like Common Lisp never existed, exclaiming "Oh, why can't I have " when it was available for the past 30+ years. Or worse -- crapping on all that Lisp provided and then embracing it as soon as someone adds curly braces instead of parentheses.
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 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 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
About the encapsulated functions / regions-in-larger-functions / anonymous scopes thing (which I do a lot of myself; can recommend)-an example of this in an existing language is C++ lambda functions. By default, none of the enclosing variables are available in the function, though you can choose which to capture (by value or reference, individually or completely).
While I agree with most of your arguments, what you've mostly described is just bad programming practice. Procedural programming has its own pitfalls, and an inexperienced coder will turn it into crap just the same.
Gavin Schuette neither is procedural programming. They're just two different ways of abstracting the logic so you don't have to code on the bare metal. Use whichever floats your boat.
That is a sound premise. I've always felt that C++ is one of the better languages out there because it's a Swiss Army Knife of tools. You can write pure OOP or pure Procedural or mix and match. We even have his "use a, b {...}" example in C++ with lambdas. I think it comes down to picking the right tool for the job. Don't make everything a class, and don't make everything a 64 parameter function. Use what fits the situation best, and remember bad programmers will always choose the wrong tool.
@@djpeterson7479 why couldn't they define classes for c++ too and other functionality of other languages so we could have one single language and either use it as oop or make our own universe. Why is that so hard if c++ is as flexible as you describe? Im just asking i dont know nothing about these but whoever gonna respond to this comment just dont be a dumb
I disagree, because cognitive complexity is a real thing. Our human brains can only hold so much in memory at once, so it is our goal to design a software architecture that optimizes for that. I can say definitively from my own experience that giant procedural code I wrote in my early years is far more difficult to read and comprehend. Once you study it for a while it becomes understandable, but only after a while. Code where I broke up into smaller pieces is much faster to read and comprehend, and I make fewer mistakes with code written like this.
Agree. I think more importantly, breaking code up into smaller pieces, sets things up for unit testing later on. Rather, what I got from this video is to try really hard to avoid needlessly increasing surface area thereby displacing complexity. But in procedural programming's defense, procedural programming often helps me build momentum until i need to break the code up to make it easier to unit test.
Also do not forget that, going into more of a domain driven design paradigm, eventing allows for decoupling when things get too far apart from a domain standpoint. Think about how much UI systems rely on eventing, but often still use OO concepts as well.
Yes, cognitive complexity is a real thing. But OOP does not help with it. All it does is throw the performance aspect out the window so that the problem you are trying to solve is a simpler one. Dumbing things down means you aren't solving the same problem anymore. For a given problem, if you aren't disregarding the codes performance, the problem is necessarily as complex as the problem is. You can't just willy-nilly group things up without affecting how the code runs. When you are trying to solve the more complicated version of the problem (which is not done for nothing, it is useful), thinking in OOP terms will not do anything useful.
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.
@@coreyaruecker Depends what your version of "keep things separate" is. I don't understand how people write code that seems to contain more boilerplate than logic. Like, imagine code that has a comment every other line explaining verbosely what the code's doing in plain English. (Obviously I'm not comparing OOP to comments in terms of functionality, just using it as an extreme example.) Do the comments hurt the functionality? No. Is it useful? Maybe to someone who doesn't know how to read the code itself, or gets lost in it without plain English. Is it pointless busywork at best or a cluttered mess at worst to someone who doesn't need the comments? Absolutely. To be clear again, I'm not trying to say OOP practices are like writing needless comments. I'm just trying to illustrate how it can sometimes *feel* to work in OOP code written with a level of granularity that feels unnecessary. Like having an entire directory designed to contain a single file because to some people that's "more organised," when to others it's needless convolution.
@@harrywang4769Oh I know. Only half joking when I say I realised I wasn't cut out for working in the industry when I figured out most of the job is about working at the level of the lowest common denominator.
I propose the idea that, in programming, there is no good to be found through inconsistency. Great job, Brian. I was in the business for over 35 years, and when OOP was first announced and I got my first taste of it, my thinking swirled around the realization that in the attempt to add clarity, OOP would add layers of complexity that have nothing to do with code functionality. I'm grateful to hear someone else take OOP apart on this basis. Thank you for this presentation.
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.
This video should be named "I have a bad understanding of OOP and I don't like it. 45 minutes of rambling." This was an utter waste of time, entirely infuriating and possibly harmful to many novice programmers. *Random stranger, before you watch, here is a run down:* First 18 minutes: Just opinions without any arguments or examples. Minutes 18 - 29: "I don't know how proper communication between modules is done. Software architecture frightens me. Manager classes are pointless. Yay anarchy." Minutes 30 - 33: "You have to write a class for everything you do! Someone said it and I didn't bother to understand 'when' and 'why', but it is stupid!" (Yes THIS is stupid. No one BUT bad programmers do this. Or giant corporation software architects, who are tasked to combine legacy apples with merger oranges into some big uber solution. They produce bad architecture, because they don't care on a personal level. i.e. "Fuck the SA in 3 years, who has to deal with this software, I'll step up in the corporate ladder or be in another branch or company by then.") Minutes 33-43: Nothing on the topic. It can be summed up with: "Use functions and consider code formatting. I wish I could write functions inside of functions, which act like functions outside of functions, but are not called functions." (probably to hide his obsession. Or maybe because he is not allowed to write private functions just below his public functions, because his supervisor is a code style nazi. Dude, stop working under idiots, plz.) Minutes 43-44: He criticizes books like "Design Patterns". Should've read Software Architecture for Dummies first. Brian Will, wtf. Don't give up, yet. The beginning is hard. Maybe you should check out "static functions" (They give you the "namespace + bunch of methods" functionality you asked for). If you are concerned with states of objects, which are called by several objects, check out "semaphore" or just use setters, as OO advices, because it gives you the freedom to implement priority/concurrency/multithreading/networking any way you like. Don't ditch objects for structs+functions. They help you. From yourself.
***** It's difficult to present arguments against something which does not have any. Especially the first 18 minutes of the video. Tell me some points you regard as valid and I'll gladly refute them. Plz don't take his straw man arguments. i.e. "OO tells you to abstract everything, everywhere, all the time." OO isn't some dogmatic religion you have to follow without questions. It's more of a structure, workflow and tool set intended to extend your work, not replace everything else.
The problem with his video is, that he basically takes the extreme ideas behind OOP, (like "everything is encapsulated") and rambles on about how bad ideas they are, without giving any real arguments to why they are bad (just some hints in that general direction)and without providing examples either. Also he uses plain false information, e.g. that inheritance is generally viewed as bad practice. This is plainly wrong. Inheritance is viewed as both overused, potentially dangerous(hard to use correctly) and misused, but it is not bad. There are situations where it really helps, and sitatuions where it does nothing but hinder you, because you have to use a really ill-fitting abstraction to use it. And finally, my last and biggest complaint: He is treating this as if it was an Ideology! I don't really know how to treat someone who does this, because of how idiotic this is. This is just as valid as saying: "I am a carpenter, and using a Hammer is an Ideology!" OOP, functional programming etc. are tools, not ideologies. The only valid point he briefly made, (just before he continued ignoring just that point) is: OOP and other styles do not exclude each other. They are like hammer, saw and screwdriver. No carpenter in their right mind would ever proclaim: "From this day forth, I shall only use my screwdriver, for it is the most holy of tools, and all the other tool shall be banished from my domain, as I have no use for them". Similarly, I have not met a single programmer worth their salt who thinks that a fanatic degree of OOP is needed to solve a problem. Btw, I mean real programmers, not people who can technically write in Java for 2 months and still have their training wheels on. They see OOP as a tool in their collection, a tool they can use, as well as ignore, whenever they see fit. TL;DR: The video uses a lot of strawman arguments, by treating OOP like an ideology, instead of the simple tool that it is.
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.
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
@@ChristopherGray00 I actually just like listening to people talk about how something sucks which I know nothing about. rn I do know what OOP is about and its usecases and use it myself when needed
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.
I had second hand experience with Java web developers back in my early day as a software engineer. I saw way too many static class methods to the point I thought to myself: Are they even doing OOP? Well I was still an OOP fanatic at that time -- my foolish younger self.
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.
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.
@@hongkyang7107 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.
so.. i did get some way into the video. what i found strange is that first you state that oop shouldn't get all the credit for java has done right since a lot of it is not fundamentally about oop but then you go on to criticise oop for some things which are not per se a problem of oop but rather how things are done in best practice. i am currently at 22:17 and you just complained about shared state and how you shouldn't pass references to other objects (although i dont see why this is a problem when done well. sometimes shared state can help coordination of classes). you could just structure your oop code to always just pass copies of your objects like you do in functional programming. anyways, i wish you had used a different intro for your video, as it doesn't suggest that anything of non-subjective nature is going to follow..
I have 35 years of software development experience. OO is a tool. A very effective tool when used correctly but not so much when you slavishly allow it to dictate every little decision you make. Leverage the strengths of OO (like polymorphism, high cohesion, low coupling) but minimize its pedantic usage (like unnecessarily complex inheritance trees for the sake of OO purity). Unless you are using a pure OO language like Smalltalk, most OO languages are flexible enough to be multi-paradigm. It's a poor workmen who blames his tools, unless of course it's VB.
Agree! In my simple understanding. Objects are stateful and most distributed and multithreading approaches assume stateless where data is separated from the handlers. OOP still is a working horse of all internal logic.
OO is a tool, but in language like Java uses OOP all over the places wherever it's not even necessary. New programmer checking the codebase gets confused when OOP used in places when it's not even necessary, with inheritance its just nonsense abstraction.
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 :)
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.
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.
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.
You must understand that every programming paradigm solves those problems, that other paradigms can't solve. And different tasks require different paradigms
This was amazing. I have programmed as a hobby for many years but now am pursing a CS degree. I've always had mixed feelings about Oop and you just validated so many concerns and philosophical issues I've had with this.
you're literally at the point where you know that your coal oven is working and now the city tells you "coal is now over we're using natural gas" and you're like "oh but I know my coal oven it works perfectly and I know how much I need to put in it when baking my pie ! I don't want of your gas it's obviously just a new trend that has no advantage"... Seriously mate, don't listen to everything you find on the internet. Oop is fine when you use it properly without overdoing it. It's a skill to develop as much as functional programming. I'm sure you were with same with C struct at the start ! you were like "oh no ! I like putting my data as proper argument I don't see the point of allocating a struct to then give the pointer to my method ! doesn't make sense !". Guess what ... real world has real shitty problem that you answer to with data...
@@CrachOveride57 I appreciate this response, thank you. Sometimes I probably let random RUclips videos have too much weight on my opinions. This did seem quite thorough, however, and definitely resonated with me. I wouldn't let that stop me from learning OOP and pursuing whatever else I had to to become a proficient programmer though.
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.
You are doing testing wrong. Like 90% of the people in our industry. You should test larger module levels not class levels. On class level it's much more important to use lots of assert statements and invariant checks. And tests to run but they shouldn't neither be black box nor really result testing (thats left for asserts/invaraints). Unfortunately so few people have done Eiffel programming 20 years ago when it was still a thing.
@@llothar68 In the real world we are required to meet code coverage targets. Useless or not, it's more or less impossible to do without unit testing. I'm not going to do that if I am working for myself but something like 75% statement coverage will not fly with on a review, even if most of the missed statements are in fact checking for invariants and would not be triggered without there being a bug in the rest of the code. In fact those end up making testing more difficult because of code coverage % requirements (>90/95%)
@@AlbertoInselvini I think 90% coverage are good enough. Given that a lot is hypothetical pessimisation error checking. And i'm not against unit testing but how it is done. At least for the algorithm part. For GUI i find it even total useless..
@@llothar68 Unit testing is absolutely useful, if you have complex logic with a lot of edgecases, and if you ever need to refactor that function again. While writing a board game AI for my bachelor's thesis, unit tests were super valuable, once I realized a specific function was very slow, and had to redo it. Unit tests caught a ton of edgecases that would have been really cumbersome to test otherwise. I feel like your comment is against only using unit tests. If so, I agree, integration tests are as, or even more neccessary, but I think if you write good code, unit tests are a very easy and fast way to add future proofing fast. I found the best practice for me is whenever I track down a bug, I add a unit test to catch it, if I can. (Sometimes you can't, cause the bug is in the way bigger modules interact, not in a specific function, sure) That way, if we ever refactor, it won't take an enduser finding that weird edgecase again.
Your description of modelling real world things with OOP makes me think about a large corporation and all the pointless layers of middle management. Its like we found a way to replicate *that* relationship in our code.
@@yousefabdelmonem3788 Well yeah. Furthermore, those necessary evils are a fundamental problems arising from scale. As the problems become bigger and harder to solve by one person, you need to make bigger and bigger compromises. It's also useful to remember when criticising governments as "less optimal" than corporations. They only have more clutter because they have harder problems to solve. Same goes for big code.
@@ekki1993 No. Thats not a fair comparison with the governments. Some governments dont even use version control for their engineers when they make their software. People dont say governments are less optimal because of their messy solutions, people say governments are less optimal because bad managers are even harder to fire, and bad employees are the only ones that flex their worker rights. Its just inherently bad.
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).
Lambas in C++ came later, the video is older ig. Btw, I like this pattern (over just creating a scope with braces) because it allows early return (no if else gymanstics needed)
A lambda "captures" the variables that it uses, but it can access some variables without capturing them. They're not necessarily trivial to factor out.
I completely agree. I have always gravitated towards languages that support OOP concepts (Perl, Python, C++, VFP) and features but didn't force you into the model wholesale. My own style leveraged classes and objects but I still maintained function libraries when practical rather than forcing those into classes.
With C you can shoot yourself in the foot. With C++ you can reuse the bullet. With Java you would have a Bullet factory. With C# you would have a bullet that would query the subject to harm itself.
Most programmers are perfectly capable to make a mess of any project without oop, good programmers can make a gem with any style of programming. Must admit that oop can rely boost the clusterfuckery of a project.
I like the name spacing iOOP provides but I don't think you should be hiding internals of an object unless you actually need to. Other developers just hide things by default and cringe when they are forced to add accessors to their private variables. :/ I go the other way around untill I see abuse I'll keep accessors to private variables and remove them if they start being abused.
@@carlosgarza31 when you expose variables or methods they become part of your public API. removing them in big projects later when you discover that people abuse them (probably because you have exposed something you never intended to be used by someone else than you), then you have to mark those variables and methods as deprecated, release a new version and give time (depending on the size of the project or the user base that process might take years), and then finally you can mark them private to hide them again. information hiding is one of the key principles of oop and a powerful tool in the hands of the right programmer.
@Minori Housaki Not necessarily. It's the difference between `queue_push(q, elem)` and `q.push(elem)`, or even `queue.push(q.elem)` if you put your queue handling functions in a module.
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.
@27:20 why do you start out in OO code with data types already defined (as well as the behaviours) then try to make these 2 components of your model that you designed separately work as one?
This year, I took the plunge and decided to write an entire project using just functions and interfaces, in TypeScript. I had to stop and regroup a few times along the way, but the exciting thing is, the stuff I've had to learn along the way really seems more generally applicable - whereas a lot of the OO patterns and principles often seems like (as he says) a workaround or a bandaid. What you learn by committing yourself to this is much more general - simple techniques that work every time, not just for one specific problem or scenario. I have 23 years of developer experience and pushing myself to go all in on this feels like leveling up - for the first time in a long while. I was on the fence about this video in 2016. I knew there was something true to it, but I had no idea where to start. It does have something to do with the language you're using - I was using mainly PHP, where functions and interfaces aren't really practical or useful the way they are in TypeScript. I don't agree with absolutely everything in this video. Part of me wonders if the author hasn't changed his mind about some of the finer points in this video over the years - we all grow and learn, right? I kind of wish he would post an updated version of this presentation. Anyhow, I gave it my like today, 5 years later. 😄
I also don't agree with everything stated, particularly about functional programming. Computers just don't work that way so will never be efficient enough. I was a true believer of OOP as a C++ game programmer for many years. One day a friend suggested I try writing a game engine in C instead of C++. I was skeptical as I loved my fancy C++ systems and templates etc, but in the end I found my code to be much simpler, smaller and more elegant. Unfortunately I still have to work on OOP game engines and nobody will believe me that procedural is better.
I've started coding in a more procedural style i think, but i like to slap most stuff into a class anyway ... just with more emphasis on making many methods pure functions that don't touch the object's properties. And i reduce the object dependencies. I find when my code is hard to test, it's hard to think about, and it's hard to maintain. I also make most stuff public because idk when i might need to mess with things. Idk. I used to put a lot of weight into designing things perfectly for extensibility or whatever & talks like this (and moreso molly rocket) have lead me more toward just ... get it done, clean it up a little bit, and don't worry so much about design. I feel like I'm explaining myself poorly though
Oftentimes I find that when a module gets to a certain size and complexity, my gut tells tells me it's time to refactor into several object classes. Sometimes it feels like I'm congealing the code I've written into separate piles, but over time I get an intuition about what data and functions belong to which classes. Fortunately, I learned the hard way to keep objects and calls strictly hierarchical. For myself, I have found OOP generally to be the best way to organize code. Having said that, I enjoyed your video and I should be able to find things I can use. Thank you.
"Kernels of good ideas have been taken to holistic extremes." That's a very succinct way of pointing out a bad tendency people exhibit in many areas not just coding. I'm adding that to my "great quotes" list and attributing it to Brian Will.
To those watching this video who are just learning how to code, THE AUTHOR IS MISSING A KEY POINT: OOP is just one of many tools in your tool set, just like several others in the comments here have said. The author is flat out wrong when he says that OOP is completely bad -- there are some types of projects, team sizes, and applications where it might not be a good fit, just like there are MANY projects where the author's style of coding would be an absolute disaster for maintainability. Similarly, when devs say that "OOP is better than functional" or that "functional is better than OOP" they are BOTH wrong -- combine the approaches and use each when they're appropriate for the problem you're solving. Moreover, judging from the comments section on this video, it seems like I am in the minority here, but I haven't ever really had a problem with OOP. In every project, I just get a feel for how things should be abstracted and organized, and everything just flows. There are sometimes moments where I'm not sure where a certain behavior should "live" but it doesn't lead to paralysis -- I just put the behavior where it seems like it makes the most sense and then move the behavior later if I find it's not the best place for it. What's the big deal here? I have 20+ years of experience and the first programming languages I learned were C, Pascal, and JavaScript before moving into PHP and then Java and C# in college. I will say that initially I didn't like how strict Java was compared to PHP, but object-orientedness felt extremely natural and after about a semester I preferred Java's strictness because it made things significantly easier to maintain than procedural C or PHP. Since college, I have written in Ruby, Python, JavaScript ES6, and now quite a bit of C++. I absolutely hated Ruby because it prioritizes aesthetics, individual expressiveness, and brevity over clarity, documentation, and productivity. If you were to ask me today what language and standard library I prefer, it would be Java, then PHP, then C#. The biggest flaw with this video is ironically that it is the epitome of what it's criticizing -- it's TOO ABSTRACT. If the author wanted to make a strong point, they should have demonstrated the advantages of procedural code using one or two decently sized example programs with both OOP and procedural. Instead, the author explains he wants things to be tangible, relatable, and obvious, yet all the criticisms of OOP are only explained in abstract hypotheticals and posed as high-level system messaging designs. Not only do the "solutions" described in the "procedural code" chapter lead to mega-long functions with multiple responsibilities that are hard to test and hard to repurpose beyond the use case that they were written for, but they also don't clearly relate to the messaging challenges that the author set out to address during the discussion of OOP pitfalls. Is OOP perfect? No, but the author's point that because "perfect OOP" isn't possible the whole thing isn't useful just falls flat. I have worked on extremely large projects (including payroll systems and information systems that have hundreds of integrations) as well as small projects, and I have not found the analysis paralysis that the author describes. I have found places where engineers have created a few too many layers of abstraction (usually facades) or places where devs are breaking through the abstraction to get data that should be exposed other ways (usually technical debt in the interest of just getting something working quickly). But... since the advent of dependency injection and coding-to-an-interface, the incedence of both of those things has gone way down. Every project has to balance cleanness of design with performance, and you don't just write this code once -- you're going to iterate on it over time. Smaller, focused code with a single responsibility ages much better than longer code that does multiple things.
"should have demonstrated the advantages of procedural code using one or two decently sized example programs with both OOP and procedural" - cannot agree more!
The man who created this video made two or three follow-up videos where he takes actual OOP codebases and rewrites them in the procedural style. He knows what he’s talking about. I have also been coding for a long time, and the older I get, the more I agree with this video.
41:55 C++ has a solution for this: lambda functions, so instead of doing "use x, y { ... }", you do "[x, y] { ... }". It won't have access to any other variable than x and y. Edit: and it does exactly what you want, it makes clones of those variables, and if you really want to change them, you can pass them as reference for ex, with &x. It's really like having a function but without having to name one, and it can be placed anywhere.
@@jukit3906 SO, it emulate a function with args passed by Value.. great note : capture can also do references. Still the same functionality as a named function, but the named function can be shared more , re-used more and syntax is cryptic ..
@@moestietabarnak nope, it is more useful: it is dynamic (that is, a function can hold lambdas with different captures and function bodies) Only virtual member functions are comparables.
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.
@@pyhead9916 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.
@@Dovenchiko 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.
@@unformedvoid2223 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.
You raise some excellent points. I find this extremely recognizable. Sure OOP and abstraction looks great when you have a simple example that itself is very concrete. But, like you said, real-world problems and programming deal with abstract concepts themselves.
I might have a go at implementing the "use" keyword in Rust using the macro system, although "use" is already a keyword for importing so it'd have to be called something else. I imagine it would create a function parallel in scope to where it is used and call it immediately. Because Rust macros are evaluated at compile-time I don't think this would show up in documentation, and even if it was there's a way to ignore it that could be inserted by the macro.
This is kind of weak. Riffing on Strict OOP's semantic shenanigans. Riffing on Java. Nothing new, no boundaries pushed. Although you present yourself as a fringe, I'd hardly consider you one. You're middle of the bell curve in your opinions - the only difference is that you can accurately point to what irks you and openly say that what you're doing is not really OOP. Most programmers that say they use OOP actually do stuff exactly as you suggest in this talk - they just fail at noticing it's not OOP anymore. And then a purely syntactic proposal "I would like to have this, cause I can't read code". You do understand, that you could just as easily use an anonymous inner function, pass parameters to it and say "this is self-contained" in the comment, right? But I guess you're just too busy, trying to tell us what every practicing coder knows, to actually bother making the best of the tools you have. "Nooo, we need a _very specific_ hammer for this _very specific_ nail, cause a regular hammer just won't do..." I am an average craftsman of the trade. I hate OOP. I hate Java. And I hate people in general. Specifically I hate tech bloggers, that try to be edgy but just end up riding the mainstream.
+SGresponse 1) A comment noting an inner function is self-contained is an OK half-measure, but language-enforced guarantees are better. 2) If you conflate FP hype with anti-OOP, then it might seem anti-FP is middle of the road among recent tech blogging. But a large silent majority of programmers pay no attention to tech blogging, and most of them are at least nominally doing OOP. I'm explicitly advocating for procedural programming regardless of imperative vs. functional. That's not fringe, but it's definitely a minority position held by probably less than 10% of all coders. 3) Yes, a big chunk of supposedly OO code barely follows the prescribed principles in even their weakest forms. That's a good thing. Very often, though, these pseudo-OO code bases make gestures at following the principles because the programmers feel guilty for not making their code "proper" OO like they learned in school. The end result is not as overly complicated as full OO but still overly complicated. More programmers need to hear the message that they can stop feeling guilty and just program the more natural procedural way. 4) You're a dick.
+Brian Will Addressing your response in no particular order: *4:* I indeed am a dick. Did I mention I hate people in general? That's a subtle hint. I am an absolute nightmare, cause I voice my criticism in such smug Dickness, that many people just see Dick and nothing else. Glad you're not one of them. I have gotten better over the years and raised my status from being an _intolerable fucking douche_ to just being a _dick_ , so this self-aware confession is not just means of avoiding the issue. I improve in small steps. *2:* The FP hype I don't conflate with anything because I stay as far away from any technology hype as possible. Every single thing that any larger group gets hyped-up about is ultimately totally impractical for non-edge-case use. This goes for OOP, FP, Prolog, Logo... anything. I'm criticizing you for saying that you take a fringe position - not because currently "FP is on the rise and OOP is passe". I'd be criticizing your mistaken identity even if OOP was _the shizz_. Because ultimately everyone, that had ever experienced in practice the tenets of OOP as they were intended in theory, knows the stuff you say and adheres to it. _That_ makes your opinion middle of the bell curve - not the fact, that the hype train moved away from OOP. Going Procedural is like using MS Windows - it's not glamorous, not glorious, doesn't push any boundaries, you won't write a thesis about it, nor a smug blog post that proves you are awesome because of using Windows. No - you may use Windows, because it has a low entry barrier or because you're used to it or it has all the functionality you need right now (and you don't care about what you'll need in 3 years time) - but mainly you use Windows because it works. Sometimes better, sometimes worse, usually "good enough" - still: it WORKS. And the same is true for Procedural programming - it's "good enough" to handle most cases you will ever need programming for. And people know this on an intuitive level. Meaning, again, *many people agree with you. You are not fringe, nor 10% minority.* You're somewhere in the 40-80%, depending on which company employees you'd interview. And if you're going to argue specifics, then theoretically yes - less than 10% of people holding this position will ever express it openly. Usually out of lack of self-awareness, rather than out of fear of ostracism. *1:* Yeah, it's great when the compiler thinks for you. I love strong-typed languages (no irony here - this one's sincere). But this - this is not the way to go. There are two additional arguments against this I can give, besides the most solid "specific hammer" one I already gave: Firstly Context and scope are a finnicky concept. You will learn that everything that's in {} brackets knows all of its surroundings but anything outside of these brackets won't get in. And that's fine, that's enough, that is working knowledge you get engrained in yourself so deeply, that you don't even consciously notice this assumption in your thinking anymore. And then comes some poorly written VB6 code, where no one bothered to dim the variables, so every single local "tempstr" variable is just a call for the global "tempstr", that god forbid you dare use in a subroutine and expect your local copy to be intact after you call that subroutine. And then you see javascript callbacks where you can switch up the context by virtue of one parameter and you then don't actually know what the current function call can see outside of it. And then you try to use "this" in a standard event callback and it goes south so fast, you're chewing on Antarctic ice before the shift is over. So in summary - don't mess with core concepts. It's unhealthy to have exceptions to rules when rules are the only thing, that can help you stay sane in an otherwise profoundly insane environment that any programming language is. And if your response is "if there already are exceptions - why not just throw in another one?" - please go read whatever your government currently uses as tax law. Go read it, understand it ALL and come back and tell me yet again, that exceptions to general rules are a good thing. I dare you. Secondly Languages are complex. When you said in your talk (paraphrasing) "Why can't we use something like _on this object I give you, enact function F_ ?" I was initially with you on this. "Yeah, why don't we?" I thought to myself. And then an answer flashed back to me: Parsers. You need the language expressive enough to code complex concepts in it, structured enough for the machine to efficiently parse and simple enough for an average shmuck from accounting to learn the basics in a month. Each new keyword adds complexity and reduces the viabilty of the latter two aspects. And while I may understand you're coming from some functional language where the list of keywords is roughly 30 items long, this notion will eventually sip into every popular language, adding to yet another intricacy to something like PHP (nearly 70 keywords) or C# (over 80). After finding what the keyword "yield" means in C# (for those interested: it's a bastard child of _"pointers are too hard for the average accounting shmuck, so we'll use references everywhere"_ and _"our container implementations are slower than C++"_ ). Learning "yield" was one of the contributing factors in my conversion to Satanism. But I digress... after finding "yield" I say *NO* to the notion that we should expand our languages with new features. No! Complexity should be removed, obscure features should be cut from language syntax and, by Jove, never a feature should be added that LIMITS what you can do using the same effort and already existing tools. That is just backwards. *3:* Here's the meat of the subject. The concrete, the Agenda. You see, I've dissed so much of your approach mainly because this is nothing new to me. And you seemed to be making a big deal out of it as if you were a Buddhist monk enlightening me about virtues of clean code and simplicity of life. But the stuff you said was nothing enlightening... Until. This key sentence: _"More programmers need to hear the message that they can stop feeling guilty and just program the more natural procedural way."_ . This is an Agenda. This is Purpose. This is... never mentioned in the video... right? Did I miss it? Did it fall somewhere in the cracks between the Java riffs and the syntax rant? But it is something new to me. Are there poor lost souls, that still think their code is crap just because one method has more than 30 lines in it? Or that their inheritance hierarchy is too weak, because it doesn't give space to every possible entity ever existing in the universe? And because of this they think they're unprofessional? Are there such people? If so - yes they need to be reached and slapped back into their senses. And I am fully in support of such an agenda. But why wasn't it stated explicitly? Is it because for a tech blogger having an agenda is usually viewed as overzealous? Or cultist? Or... unprofessional? If so, then I think more tech bloggers should hear the message, that they can stop feeling guilty and ashamed of their agendas. And just blog and make videos the more natural way - openly stating their intents and allowing viewers more broader context on their position in that way. PS: I should stop putting essays in YT comments. This is a chore to read.
+SGresponse Being in the middle of a bell curve means that you consider the perks of both sides and then you make rational decisions based in unbiased thinking, I hardly see how that is a problem.
***** If you assume that the people that come in after you will be sensible - then the comment is enough. However if you assume that they're the stupids, then pretty much you have to concede that they will fuck something up regardless of the language constructs we put in. Your point supporting the new construct is invalidated either way. And again: the visibility of the broader scope from the nested scope is NATURAL for all bracket-based languages. So making a keyword that will change this behavior would not only be pretty much useless - it would be detrimental. Granted: I can actually see one good use for this in code. When someone is writing code that's so shitty you almost expect to see it cross-cut through all the variables at any point and change them willy-nilly. Then seeing the sandboxer in there would be a blessing. Or leveraging it to do some runtime analysis on that crap code. But really: asking for a special syntax that _breaks general behavior_ (key problem for me), just because you're either shit at writing code or shit at reading it... I can't even express my feelings toward it properly - a mix of distaste and disappointment in one's craftsmanship. It's not even the fun kind of shit-in-code. It's the sad kind. Corbin Crutchley It wasn't both sides of the tale - you will see that in basic approaches to everyday coding Brian and me agree quite readily. If you really want a different side of the coin - look for someone who's into rigid OOP. I can't recommend anyone, cause I stay away from those zealots. Anyway: thanks. I find it rewarding that at least one person read my essay through to the end. Trevor Hart Being middle of the bell curve isn't a problem - that's true. Posing as if you were the fringe while being the average - that's what I challenged Brian on. I still feel like I was right, but it's up to you to make your own opinion on this.
The little "code blocks" that you reference in the end exist in C++ in a form of a lambda. Usage could be almost exactly the same as you have depicted. Example: int main(void) { int a = 10; int b = 20; int var = [a, b]() { return a + b; }(); return 0; }
"Bundle globals into structs/records/classes. But be careful, there's an art to how you bundle these things together. " It's called object-oriented programming Also, I have an issue with this advice "Don't be scared of long functions". The reason why I generally have to avoid them is because I'll need to reuse the "components" of the function. There's a myriad of business areas with similar/overlapping business processes that needs to be mapped like this. And Brian's advice doesn't provide any solution to this. Is the solution to have copies of nested functions everywhere. How do you change your code later? Generally I think he's on point with the problems of stateful, OOP. But I don't think he quite manages to point to any useful remedies. Programming is hard, because mapping complex domains is just hard. Real life is messy, and code that tries to reflect that will also, inevitably, be messy.
Object oriented programming has some good ideas, which applied intelligently can help produce good code. But when those ideas are reduced to formulas and applied blindly, you can get some very bad code. And the latter seems to be the norm for much of the industry.
i like how rust is still at its core very procedural and functional. even when you want more object-oriented behaviour, it still has you separate behaviour from data in a way that is actually modular. you can still `impl MyStruct` to tie behaviour to data types, but this is a conscious decision of the programmer rather than being a limitation like it is in many natively OOP languages.
And you forgot to mention enums that can embed some data for the caller function... That helps a lot. But yeah, defining objects as their behavior is (I think) easier than trying to get their true type...
I like how rust at its core is still worthless like every other opinionated language and C++ is still industry standard in 2024 because it's only opinion is about actually being usable in real world conditions.
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.
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.
@@davimendespimentel6849 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.
@@WowUrFcknHxC 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.
@@davimendespimentel6849 without abstractions we would be nowhere today Abstraction is important because it makes programming easier. And even with this band aid we still don't have enough programmers If every code monkey in the world needs sophisticated knowledge of the inner workings of a language the entire world will grind to a halt
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.
For a while I thought I couldn't learn programming because people needlessly overcomplicate it on purpose. After watching this video, I now realize that I can't learn programming because people needlessly overcomplicate it on purpose.
People dont overcomplicate on purpose, that just doesnt happen. No one in the world is inherently evil, theyre just doing what seems right from their perspective. The problem isnt really overcomplication, it's that programming itself is complicated. Even with that, I dont think that being "unable to learn" it is ever correct. If you just stay curious and learn a little bit at a time and keep experimenting, you can probably become so much more skilled at it over time than you thought you ever could be. It takes effort but I think youre wrong in saying you cant.
Usually, it gets forced by some management, or some practices people learn. Extremely well designed object oriented programming is very easy to read. Much easier than functional or plain old C, because the functions are with the data.
Learn to program in C. It has a name of being hard, but that's incorrect imo. It's hard to write large software packages in C, but the language itself is pretty straightforward. And a great thing about learning that way is that sooner or later you will run into the limitations of the language, and then you will easily pick up on more abstract ideas like object-oriented programming. And you'll learn it not as the one true way, but as a technique that is in some cases helpful.
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.
i would not really call myself a programmer because i'm a data analyst but literally this is exactly what I've started to do in my python code because I'm lazy as hell and there's things I need to do over and over again and it feels clever to wriet a function for it lmao
The whole problem with the industry right now in this point of history is the over abstratction, choosing speed ("don't reinvent the wheel") over quality.
It's actually not faster. Certainly not long term. hinking about the structure of your code may require extra time, but it saves time in the end. I'm currently adding features to legacy code. It can take an entire day to find a single line of code to change since there is no documentation and no structure.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
@@gl3nda96 so you did the deed?
- every video or post about programming languages anywhere on the internet
Neither being used, nor being complained about make any language good.
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.
I still never met a person who uses C and complains about C.
The irony of this video is most people watching it are just going to be better at OOP by the end of it.
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.
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!
The objective was to get better not perfect
I understood maybe one third of the video but between the lines it seemed to make a pretty solid case for OOP.
@@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.
“Better to start with a free form structure than to eagerly create one that turns out to be wrong.” I learned that lesson the hard way.
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.
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.
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.
your companies need architects, and start writing some baselines before writing code
Yes. Some senior developers take pride in turning everything into layers and layers of inheritance.
I've known some very narcissistic programmers who write this kind of code for huge organizations like banks. Usually they have zero experience outside their language of choice from 15 years ago and think "standards" and "good practices" are gospel. They usually have zero creativity and think things like "you should use DateTime to store a year value because it's made for it" instead of using a bleeping int.
That guy built a framework for every single little thing, and thought Microsoft invented marshalling. He literally could not define the term outside the context of the .Net Framework. And big companies paid him well to write overengineered crap. Of course, he constantly bragged about all this amazing stuff he'd learned 'at the top.' 😂
Hm, yes, this video has definitively shown me that I don’t actually know enough about programming to properly understand this video.
Just give it a bit of time and one or two serious/professional projects and you will know the problem firsthand!
After two years in university you will understand it.
@@GuerreroMisterioso95 Give him 1-2 years in industry and he will definitely understand it if not already
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...
@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.
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.
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.
@@googleuser2016 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.
Jumping around makes debugging other people's code an abysmal experience
@@s0mbres 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.
@@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.
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.
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.
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...
Also a student! I know, I’m so happy I came across this video.
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.
@@bobbycrosby9765 so typical nodejs smelly shit? (Even though js does not really have classes ... or does it now with a new standard? not sure)
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.
Employee: _We're practicing POOP here._
Applicant: _What's POOP?_
Employee: _Proper OOP._
employeR?
@@drygordspellweaver8761 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... 😁
Should be top comment 😂
People Order Our Patties, POOP
No....
POOP actually stands for Python Object Oriented Programming.
i do a different coding style . its called "what ever gets the job done"
right? like there's no silver bullet, there's a lot of these "oop bad functional good" or vice versa bullshit on every forums and it always strikes me as biased. there's soo many different kinds of weird real world problems that one coding style isn't enough.
Seems like too many developers have lost sight of this. The end user doesn't give two shyts about whether you used functional or OOP programming in your coding. They only care that it works...and as long as it does what difference does it make? Code it the way you are comfortable coding it instead of constantly chasing after what's in vogue right now.
Define “the job”. If it’s anything other than “make it work this week and then delete it”, these kinds of discussions are vital to the long term flexibility and maintainability of the code you write.
Transparent “working code” may be working, but it still falls on various spectrums of maintainability, flexibility to change, complexity, performance, etc.
I’m tired of people using “different tools for different jobs” as a hand-wavy excuse to use shitty tools just because they feel familiar.
Sure, don’t go chasing fads, but it’s worth considering whether programming really IS that difficult, or whether we just make it that way out of ignorance and inertia.
Sounds like an indian to me
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!
C++ is not an OOP
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".
@@UncaAlbyGmail 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
@@morbiusfan3176 Somehow I get the feeling you're trying to tell a joke, but it went over my head. Sorry.
@@UncaAlbyGmail 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.
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.
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.
The fault was not with the tool, rather your design.
@@HumanBeingSpawn 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.
@@tongobong1 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
@@MartinSparkes-BadDragon 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.
My (C)ommunist Coding style:
A classless society
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!
@@mastermati773 That would explain why communist societies failed ... they should've learned to be object-oriented :-D
@@a0flj0 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
dontlikemath -.- Nice.
@@mastermati773 Its maybe more like functional programming :P
I spent too much time asking myself whether a specific function should be in the ControllerAdapterFactory class or the FactoryAdapterController class.
This sounds like a Monty Python joke
I spent too much time searching Google with "should I..." questions instead of "how do I..." questions.
May God help you! BANISH THE DEMON THAT HAUNTS YOU!!! (Get rid of that evil naming convention you have)
When in doupt, put it in ControllerFactoryAdapter.
Sounds like poorly defined clasess to me. Do you really need both of them?
The biggest problem I have with this video is that it completely forgoes one crucial aspect of development - testing. Not having modular components and having "God functions" that do everything in one place makes your software really hard to test, you can't really test individual bits of logic and it will become a nightmare to debug your functions if you need to make even tiny changes. Besides that this obviously introduces a very high barrier of entry for understanding your code, there is so much that a human brain can process and keep track of while reading and grasping the full picture will take much longer than if the same logic was split into separate components, and in many cases the ability for your colleagues to quickly understand what the code does without delving too deep into implementation details is really important, they in general would have other shit to do and spending an hour to understand what a function does is not a good use of their time
Working on large, highly complex projects, I've found the opposite to be true. Human brains struggle with interlocking complexity, not cardinality. We use the functional core imperative shell apporach -- even a non-technical person can open the "shell" procedure, read it top to bottom and understand what it does, hell they might even be able to make minor edits. Uncle Bob-style OOP does the opposite -- it fragments business logic into as many small, individually meaningless units as possible, making it much harder to build out a mental model in your head. Our code practically has a UML sequence diagram built-in, and our engineers love it.
@@dukiwave Its funny because I've also worked on large and complex projects, and modular code with broken down function points is absolutely crucial if you ever want to extend or maintain your code. Having smaller function blocks allows fast isolation to problematic code.
Not being able to form a mental model is more of a skill issue and can be overcome with time, code comments and documentations.
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.
That is a very insightful analogy.
microservices don't solve any problem, they just move the complexity of the monolith to the infrastructure, it makes no sense
Why would you put data storage into every microservice?
@@Ian-eb2io 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.
@@username7763 Are you telling me each services having it's own data store is so that it CAN have access to the data? Otherwise it has to call other services to get the data for it?
Q:What is the object oriented way to become wealthy?
A: Inheritance.
nice
create state, create controllers, design gui. besides that you need a state that allows function for your site/app the controls to manipulate it towards the users objective and then the GUI for an end user to manipulate the controllers they have access to.
Kiss ppl's asses and procedurally control their minds.
think functionally about money
Multiple inheritance ;-)
Me who has done just a simple calculator in python:
"He does have a point"
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.
@@equinox2584 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.
@@SapioiT it's not the thing you'd worry about writing your first program
@@badunius_code Not the first, true, but among the first hundred or thousand, maybe sooner if you hit that problem early on.
@@badunius_code my first calculator was a graphical calculator made with tkinter, mostly to avoid messing around with eval and hardening against code injection lol
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.
Jerry-rigging.
Isn't it basically a JS arrow function?
@@vibaj16 yes
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.
Try Clojure. Great constructs for safe mutable state like atoms.
@@user26912 Clojure/FP makes things much slower and trashes memory so you have to ask yourself why are you using multithreading parallelism at all. It's done only for performance and if you waste this on clean code i don't understand. Then write just zero shared data multitasking.
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. 👍
Thanks for the information. I'm still an under-graduate. If anything, this gives me insight on my future in computer science.
I liked that last paragraph of yours. Do you know of any resources to study this further?
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.
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?
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.
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!
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.
44:36 trump 2020
Seth Archambault thanks
"Use namespaces / packages / modules" = OO concepts...
Just now watching this video. Thanks for the nice index!
It really depends on the problem. I programmed the first ever constructed OOP-language in 1970 which was SIMULA and has since then used various OOP-languages including Object Pascal, Java, Javascript, C++ and Ruby. Some problems are really difficult to tackle without objects and for some others objects just distract from the task what you actually want to achieve. Nowadays I mostly use procedural programming but occasionally add in objects for special tasks. It just boils down to common sense when to use it. I agree to that OOP is overused and often just adds confusion when one wants to understand what the code of others actually do.
This is exactly how i do OOP.
Objects when it matters / procedural for everything else.
it's the most sane path!
"The messages only ever go from parent, to the direct child. Otherwise who is responsible, who is managing that state?"
Actually the state can take away the child by legal action if the parent isn't responsible.
Blasphemy. How refreshing.
That's the attitude I like to see !
“Procedural code is better”
Me, a COBOL programmer: Is it finally my time?
Always has been ;-)
Hahhaa :) I've done COBOL in the past, don't really want to go back to it sincerely )
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.
@@TricoliciSerghei 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!
Yes, you would be very successful working on OOP projects. You could join all the teammates not understanding and hating OOP. ;-)
When 99% of the time a tool is found to not be used correctly, then maybe that tool is not a good tool.
Just found this video, found it really informative and I'm glad someone pointed out that OOP isn't some magical methodology you learn and becomes default. From what I found with OOP is that most cases it's either a) Trying to be an overengineered struct, or b) Trying to be an overengineered function (or group of functions). It seems most people use them because it's normally the most advanced thing they learnt and they assume "it's what the real programmers do" (Like a kid mimicking adults). Unless you specifically need inheritance or instancing (e.g., gamedev), FP makes way more sense than OOP
There's been a shift in gamedev away from OOP because objects are slow and hard to multithread in practice and class hierarchies are simply too restrictive to express complex game logic nicely.
These days many big titles are built using entity component systems which in many ways mimic relational databases, with every entity being an ID with components like position and health associated with it.
There is a other way of seeing it, and it's fairly simple : OOP is good to learn to learn how to suffer in it and know not to touch it later on, while still learning about UML stuff (which can be transposed in FP)...
11:43 "It seems like real programming, it has curly braces after all."
I see, a fellow man of culture.
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.)
*python has left the chat*
haha goto go brrr
@@williamdrum9899 Underated comment.
@@TheBelrick Who did that and why? 😨
You can write bad code in any style. I have been programming for 30 plus years in anything from assembler to lisp, c, java, pyhton, cobol, miranda, basic whatever. The only thing that matters is that you work is tidy, has a consistent strucnture and documents where it has not and communicates it's intention well. The whole OO vs procedural vs functional discussion is irrelevant and frankly feels a bit childish to me. They are just ways of connecting the digital pipework differently. If you are a good programmer you will be flexible and able to recognize logical patterns and structure in any coding style. Or if that is difficult for you, just stick to one and be an ace at it.
Like they say, whatever floats your boat. I, personally prefer procedural programming, but I have nothing against OOP. It has its flaws, yeah, but as long as you can do the job right, tidy and functional, you can do it however you want.
It almost like arguments saying OO is terrible are "caring too much about surface concerns" and not looking at it pragmatically.
I couldn't agree more.
A dull axe requires several times the effort of a sharp axe when felling. I prefer the sharpest axe that I can possibly get.
why limit yourself to an axe ?
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.
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...
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.
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.
did you just thank yourself?
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.
@@KXBeats accidental click :-)
@@visitante-pc5zc 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.
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.
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
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.
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.
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.
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"
@@MjolnirFeaw 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.
I return to this video periodically, every year or so, to read comments from people coming back to this video periodically, every year or so
8 years later and most folks are moving away from OOP languages, dude was right
I've done a lot of procedural programming back in the early 90's and then switched object oriented programming. For me, OO code is easier to read, quicker to develop and evolve. I do use procedural here and there but if an object is appropriate then I'll use it. I like C++ and Java.
Most of the time objects are not appropriate. The problem with OOP is that it has gone from yet another tool in the toolbox to a forced methodology. It has, Marx forgive me, become the Marxist ideology of programming.
Did you watch the whole video? He isn't advocating against objects. He's advocating against inheritance, polymorphism, instances and strict OOP decoupling. His suggestion was specifically to use objects but not in a dogmatic OOP way.
@@omicronx94 Then he shouldn't have titled his video "OOP is bad"
@@dshcfhthat's the reality of social media - you have to clickbait in order to be heard
Just like academics have "publish or perish"
@@omicronx94 And thus he takes out some of the most important tools in OOP. Without inheritance you won't get the sweet decoupling with dependency injection that is very popular with .Net developers today. Also decoupling isn't bad in fact its very good, when you work with larger programs, you will be very happy that the code is isolated, so when you want to change something, then you will only need to change it in one place and not more. It also really helps to expand your program, by limiting what you need to change. What he is asking for can easily be done with C code, but history has proven him wrong, procedural is inferior to OOP, when one uses OOP correctly, like don't use polymorphism for what is basically a switch case, it should be used when the data structure fits the split into more classes with a common base.
I think the video could be more digestible if you didn't sensationalize it with "This is the most important programming video you will ever watch". Not that I am one to talk though.
+Jesus Bejarano On the other hand, it's also a good hook to get people to watch the whole presentation.
+fburton8 I think is a little bit cheap but I know was he was going for none the less and its merits.
+Jesus Bejarano With OOP being a standard of the industry for 20 years now, I don't think it's too cheap.
+JBeja M
I almost didn't watch it only because of that grandiose promise.
+Shawn McCool
What does my or his ego have to do with this?
I know from experience, anytime you put an opinion out on something like this it brings out the pitchforks for sure.
Well he shouldn't have claimed this to be the most important video, or whatever similar.
Jerome Potts I mean, this is one of the ONLY videos on RUclips 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 RUclips 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.
Most people blindly believe what they have been taught at school.
It's hard to fight decades of brainwashing
@@fwefhwe4232 lol
@@fwefhwe4232 Most people do what will actually get them employed in the real world.
I would say it is difficult to write large systems that are well structured no matter what language is used.
There is always 12 ways to do something and 10 of them are not good choices.
Having designed and implemented and programmed in many Common Lisp systems, I've always found everything newer to be worse and disappointing, and it is satisfying that functional+object programming is now finally getting the respect it deserves. Javascript seems the closest to what we had in the 1980's..which is both disturbing and hopeful.
I almost wonder if the time is right to bring back Common Lisp, or the simpler subset like NiCL that I created.
The last 10 years all I do is write microprocessor apps using C to run in chips that have memory sized in kB.
It is refreshing to be able to see the entire app in a few pages of code. I don't think Common Lisp would work in this environment or I would have tried to get it working. I see the chips have gotten big enough that they are running micropython these days...never tried it.
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!
The anonymous functions denoted by the “use” keyword exist in C++ lambdas, right down to the explicit list of named function variables that can be shared with the anonymous function.
Is that what a lambda function is? I have been trying to understand lambdas for so long that it's embarrassing. The "use" idea described at 41:40 makes perfect sense to me. Is this all a lambda is?
@@1u8taheb6 Yes that is exactly what a C++ lambda is, it allows you to capture any or all variables from the enclosing scope either as references or values, and also allows you to pass in regular variables like you would to any function, you can combine these options in any way you like, they are very handy.
@@CapteinObvious Thank you so much!
yes, python lambdas are the same concept
@@koacado Python Lambdas allow only one expression. Python lambdas are also closured which means they capture the variables of the surrounding scope. The proposed "use"-block should be like an immediately invoked function that is NOT a closure.
Poo-pooing autocomplete as "groping your way through" is a nonsense argument. Programming isn't about memorizing rote syntax, and having that belief is a recipe for disaster in a codebase of any significant size.
Imo a good programmer is the one that comes out with te best and most efficient solution, not the one that memorized all syntax. Autocomplete is a really good tool that improves workflow exponentialy
Absolutely. Especially if you're modifying someone else's code or code you wrote more than a year ago, autocomplete is an absolute lifesaver. This is why it takes me 3 times as long to write JS as Java.... I have to constantly look for function names in other files that were written years ago by other people.
If you can't hold what you want to do in your head before you write it, then your program is shit.
Typical computer scientist completely failing at comprehension lmao. What a terrible, bad-faith strawman.
it seems like these "oop critics" have only ever woked on single person small scale applications where they could reinvent the wheel without it taking years - its also proably a very shitty wheel if they just came up with it themselves.
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
Thank you so much for this. As a programmer from the days of Fortran IV through Pascal, C, Java, JavaScript etc I always felt a bit of a fraud when not writing "proper" object oriented code. I much preferred writing in a procedural way. Now I know why!!! And yes teaching OOP is a real hassle as I'm always thinking, but really I don't need to do this... 😀
What am I doing here, I dont even know what object-oriented programming is
1. Women are objects. I am object-oriented programmer, I'd know.
Hey guys, we have an object that needs to be garbage collected before we get a segfault.
ahahahaha
+The Foun Neither do I and according to the video it would be a waste of time figuring it out. O well, I don't even program yet. I ordered a book on structured BASIC today. when I am confident in making 3D Games in Basic, I plan to learn C. When I am able to make AI for Arduino in my sleep in C, I plan to learn Varilog. When I am able to synthesis instincts for robotics in Varilog, I plan to learn Assembly. When I can wright a kernel in Assembly, Then I will consider myself a programmer. It all begins with Structured Basic and game programming.
that's the most retarded language progression i've ever heard
It drives me nuts that people act like Common Lisp never existed, exclaiming "Oh, why can't I have " when it was available for the past 30+ years. Or worse -- crapping on all that Lisp provided and then embracing it as soon as someone adds curly braces instead of parentheses.
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 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.
@@Vitorruy1 Does this mean that OOP languages are wrappers for the entity engine? i.e. Unity and Unreal?
@@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
About the encapsulated functions / regions-in-larger-functions / anonymous scopes thing (which I do a lot of myself; can recommend)-an example of this in an existing language is C++ lambda functions. By default, none of the enclosing variables are available in the function, though you can choose which to capture (by value or reference, individually or completely).
While I agree with most of your arguments, what you've mostly described is just bad programming practice. Procedural programming has its own pitfalls, and an inexperienced coder will turn it into crap just the same.
you missed the point that oo is not needed
Gavin Schuette neither is procedural programming. They're just two different ways of abstracting the logic so you don't have to code on the bare metal. Use whichever floats your boat.
@@gavinschuette9826 .. "to turn it into crap all the same" ? - I agree.
That is a sound premise. I've always felt that C++ is one of the better languages out there because it's a Swiss Army Knife of tools. You can write pure OOP or pure Procedural or mix and match. We even have his "use a, b {...}" example in C++ with lambdas. I think it comes down to picking the right tool for the job. Don't make everything a class, and don't make everything a 64 parameter function. Use what fits the situation best, and remember bad programmers will always choose the wrong tool.
@@djpeterson7479 why couldn't they define classes for c++ too and other functionality of other languages so we could have one single language and either use it as oop or make our own universe. Why is that so hard if c++ is as flexible as you describe? Im just asking i dont know nothing about these but whoever gonna respond to this comment just dont be a dumb
I disagree, because cognitive complexity is a real thing. Our human brains can only hold so much in memory at once, so it is our goal to design a software architecture that optimizes for that. I can say definitively from my own experience that giant procedural code I wrote in my early years is far more difficult to read and comprehend. Once you study it for a while it becomes understandable, but only after a while. Code where I broke up into smaller pieces is much faster to read and comprehend, and I make fewer mistakes with code written like this.
Agree. I think more importantly, breaking code up into smaller pieces, sets things up for unit testing later on. Rather, what I got from this video is to try really hard to avoid needlessly increasing surface area thereby displacing complexity. But in procedural programming's defense, procedural programming often helps me build momentum until i need to break the code up to make it easier to unit test.
@@solstice5767 all the cool kids do tcr these days
Encapsulation does not fly out the window. While object B method is processing message from object A, object C cannot affect the innards of object B.
Also do not forget that, going into more of a domain driven design paradigm, eventing allows for decoupling when things get too far apart from a domain standpoint. Think about how much UI systems rely on eventing, but often still use OO concepts as well.
Yes, cognitive complexity is a real thing. But OOP does not help with it. All it does is throw the performance aspect out the window so that the problem you are trying to solve is a simpler one. Dumbing things down means you aren't solving the same problem anymore. For a given problem, if you aren't disregarding the codes performance, the problem is necessarily as complex as the problem is. You can't just willy-nilly group things up without affecting how the code runs. When you are trying to solve the more complicated version of the problem (which is not done for nothing, it is useful), thinking in OOP terms will not do anything useful.
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.
I’m quite literally the exact opposite. How do people not write code and keep things separate.
@@coreyaruecker Depends what your version of "keep things separate" is. I don't understand how people write code that seems to contain more boilerplate than logic.
Like, imagine code that has a comment every other line explaining verbosely what the code's doing in plain English. (Obviously I'm not comparing OOP to comments in terms of functionality, just using it as an extreme example.) Do the comments hurt the functionality? No. Is it useful? Maybe to someone who doesn't know how to read the code itself, or gets lost in it without plain English. Is it pointless busywork at best or a cluttered mess at worst to someone who doesn't need the comments? Absolutely.
To be clear again, I'm not trying to say OOP practices are like writing needless comments. I'm just trying to illustrate how it can sometimes *feel* to work in OOP code written with a level of granularity that feels unnecessary. Like having an entire directory designed to contain a single file because to some people that's "more organised," when to others it's needless convolution.
A computer science student doesn't really know what a production code base looks like.
@@harrywang4769Oh I know. Only half joking when I say I realised I wasn't cut out for working in the industry when I figured out most of the job is about working at the level of the lowest common denominator.
assuming people knowledge based on academic levels is just arrogance. maybe this person knows much more than you think@@harrywang4769
I propose the idea that, in programming, there is no good to be found through inconsistency.
Great job, Brian. I was in the business for over 35 years, and when OOP was first announced and I got my first taste of it, my thinking swirled around the realization that in the attempt to add clarity, OOP would add layers of complexity that have nothing to do with code functionality. I'm grateful to hear someone else take OOP apart on this basis. Thank you for this presentation.
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.
This video should be named "I have a bad understanding of OOP and I don't like it. 45 minutes of rambling."
This was an utter waste of time, entirely infuriating and possibly harmful to many novice programmers.
*Random stranger, before you watch, here is a run down:*
First 18 minutes: Just opinions without any arguments or examples.
Minutes 18 - 29: "I don't know how proper communication between modules is done. Software architecture frightens me. Manager classes are pointless. Yay anarchy."
Minutes 30 - 33: "You have to write a class for everything you do! Someone said it and I didn't bother to understand 'when' and 'why', but it is stupid!" (Yes THIS is stupid. No one BUT bad programmers do this. Or giant corporation software architects, who are tasked to combine legacy apples with merger oranges into some big uber solution. They produce bad architecture, because they don't care on a personal level. i.e. "Fuck the SA in 3 years, who has to deal with this software, I'll step up in the corporate ladder or be in another branch or company by then.")
Minutes 33-43: Nothing on the topic. It can be summed up with: "Use functions and consider code formatting. I wish I could write functions inside of functions, which act like functions outside of functions, but are not called functions." (probably to hide his obsession. Or maybe because he is not allowed to write private functions just below his public functions, because his supervisor is a code style nazi. Dude, stop working under idiots, plz.)
Minutes 43-44: He criticizes books like "Design Patterns". Should've read Software Architecture for Dummies first.
Brian Will, wtf. Don't give up, yet. The beginning is hard. Maybe you should check out "static functions" (They give you the "namespace + bunch of methods" functionality you asked for). If you are concerned with states of objects, which are called by several objects, check out "semaphore" or just use setters, as OO advices, because it gives you the freedom to implement priority/concurrency/multithreading/networking any way you like. Don't ditch objects for structs+functions. They help you. From yourself.
This comment should be called "I don't really have an argument so I'm going to call it bad".
***** It's difficult to present arguments against something which does not have any. Especially the first 18 minutes of the video. Tell me some points you regard as valid and I'll gladly refute them. Plz don't take his straw man arguments. i.e. "OO tells you to abstract everything, everywhere, all the time."
OO isn't some dogmatic religion you have to follow without questions. It's more of a structure, workflow and tool set intended to extend your work, not replace everything else.
The problem with his video is, that he basically takes the extreme ideas behind OOP, (like "everything is encapsulated") and rambles on about how bad ideas they are, without giving any real arguments to why they are bad (just some hints in that general direction)and without providing examples either.
Also he uses plain false information, e.g. that inheritance is generally viewed as bad practice. This is plainly wrong. Inheritance is viewed as both overused, potentially dangerous(hard to use correctly) and misused, but it is not bad. There are situations where it really helps, and sitatuions where it does nothing but hinder you, because you have to use a really ill-fitting abstraction to use it.
And finally, my last and biggest complaint:
He is treating this as if it was an Ideology! I don't really know how to treat someone who does this, because of how idiotic this is. This is just as valid as saying: "I am a carpenter, and using a Hammer is an Ideology!"
OOP, functional programming etc. are tools, not ideologies. The only valid point he briefly made, (just before he continued ignoring just that point) is: OOP and other styles do not exclude each other. They are like hammer, saw and screwdriver.
No carpenter in their right mind would ever proclaim: "From this day forth, I shall only use my screwdriver, for it is the most holy of tools, and all the other tool shall be banished from my domain, as I have no use for them".
Similarly, I have not met a single programmer worth their salt who thinks that a fanatic degree of OOP is needed to solve a problem. Btw, I mean real programmers, not people who can technically write in Java for 2 months and still have their training wheels on.
They see OOP as a tool in their collection, a tool they can use, as well as ignore, whenever they see fit.
TL;DR: The video uses a lot of strawman arguments, by treating OOP like an ideology, instead of the simple tool that it is.
thank you!
I love this comment so much
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.
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
45 minutes of someone with a nice voice telling me OOP is bad, I'm in
sounds like you just want to hear someone say something that you agree with to make you feel good, rather than actually think critically.
@@ChristopherGray00 I actually just like listening to people talk about how something sucks which I know nothing about.
rn I do know what OOP is about and its usecases and use it myself when needed
41:49
auto foo = [x, y]() {
// Code here
};
lambda in C++
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.
Thats why frontend code is more complex as backend code. But even on server there is so much algorithms and processing to do.
I had second hand experience with Java web developers back in my early day as a software engineer. I saw way too many static class methods to the point I thought to myself: Are they even doing OOP? Well I was still an OOP fanatic at that time -- my foolish younger self.
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.
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.
@@technoturnovers7072 Coding efficient game engines and game logic would also be a pain with only functional or procedural programming.
@@daedalus6433 not really, doom classic and quake 1 are those that were written in C very optimize and modable.
@@hongkyang7107 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.
@@hongkyang7107 Doom was written in Objective-C. Quake was written in QuakeC.
if a video itself states "this is the most important video you will ever watch" (twice) it's already super suspicious
so.. i did get some way into the video. what i found strange is that first you state that oop shouldn't get all the credit for java has done right since a lot of it is not fundamentally about oop but then you go on to criticise oop for some things which are not per se a problem of oop but rather how things are done in best practice. i am currently at 22:17 and you just complained about shared state and how you shouldn't pass references to other objects (although i dont see why this is a problem when done well. sometimes shared state can help coordination of classes). you could just structure your oop code to always just pass copies of your objects like you do in functional programming.
anyways, i wish you had used a different intro for your video, as it doesn't suggest that anything of non-subjective nature is going to follow..
@@homeXstone Joshua Bloch Effective Java third edition. Good read.
I have 35 years of software development experience. OO is a tool. A very effective tool when used correctly but not so much when you slavishly allow it to dictate every little decision you make. Leverage the strengths of OO (like polymorphism, high cohesion, low coupling) but minimize its pedantic usage (like unnecessarily complex inheritance trees for the sake of OO purity). Unless you are using a pure OO language like Smalltalk, most OO languages are flexible enough to be multi-paradigm. It's a poor workmen who blames his tools, unless of course it's VB.
Agree! In my simple understanding. Objects are stateful and most distributed and multithreading approaches assume stateless where data is separated from the handlers. OOP still is a working horse of all internal logic.
OO is a tool, but in language like Java uses OOP all over the places wherever it's not even necessary.
New programmer checking the codebase gets confused when OOP used in places when it's not even necessary, with inheritance its just nonsense abstraction.
Fixed title: How to write code as a normal person and not an ideology-possed programmer :)
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 :)
Me too!
same
@@mfilipe7778 Good to know there are others out there who do likewise :)
@@smoothbeak 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.
@@amadeusk525 I agree!
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.
@@Bayo106 not even close. engineers.
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.
Scientists don't know how to program, this is well known to software engineers...
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.
You must understand that every programming paradigm solves those problems, that other paradigms can't solve. And different tasks require different paradigms
This was amazing. I have programmed as a hobby for many years but now am pursing a CS degree. I've always had mixed feelings about Oop and you just validated so many concerns and philosophical issues I've had with this.
you're literally at the point where you know that your coal oven is working and now the city tells you "coal is now over we're using natural gas" and you're like "oh but I know my coal oven it works perfectly and I know how much I need to put in it when baking my pie ! I don't want of your gas it's obviously just a new trend that has no advantage"...
Seriously mate, don't listen to everything you find on the internet. Oop is fine when you use it properly without overdoing it. It's a skill to develop as much as functional programming. I'm sure you were with same with C struct at the start ! you were like "oh no ! I like putting my data as proper argument I don't see the point of allocating a struct to then give the pointer to my method ! doesn't make sense !". Guess what ... real world has real shitty problem that you answer to with data...
@@CrachOveride57 I appreciate this response, thank you. Sometimes I probably let random RUclips videos have too much weight on my opinions. This did seem quite thorough, however, and definitely resonated with me. I wouldn't let that stop me from learning OOP and pursuing whatever else I had to to become a proficient programmer though.
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.
You are doing testing wrong. Like 90% of the people in our industry. You should test larger module levels not class levels. On class level it's much more important to use lots of assert statements and invariant checks. And tests to run but they shouldn't neither be black box nor really result testing (thats left for asserts/invaraints). Unfortunately so few people have done Eiffel programming 20 years ago when it was still a thing.
@@llothar68 In the real world we are required to meet code coverage targets. Useless or not, it's more or less impossible to do without unit testing. I'm not going to do that if I am working for myself but something like 75% statement coverage will not fly with on a review, even if most of the missed statements are in fact checking for invariants and would not be triggered without there being a bug in the rest of the code. In fact those end up making testing more difficult because of code coverage % requirements (>90/95%)
@@AlbertoInselvini I think 90% coverage are good enough. Given that a lot is hypothetical pessimisation error checking.
And i'm not against unit testing but how it is done. At least for the algorithm part. For GUI i find it even total useless..
@@llothar68 Unit testing is absolutely useful, if you have complex logic with a lot of edgecases, and if you ever need to refactor that function again.
While writing a board game AI for my bachelor's thesis, unit tests were super valuable, once I realized a specific function was very slow, and had to redo it. Unit tests caught a ton of edgecases that would have been really cumbersome to test otherwise.
I feel like your comment is against only using unit tests. If so, I agree, integration tests are as, or even more neccessary, but I think if you write good code, unit tests are a very easy and fast way to add future proofing fast.
I found the best practice for me is whenever I track down a bug, I add a unit test to catch it, if I can. (Sometimes you can't, cause the bug is in the way bigger modules interact, not in a specific function, sure) That way, if we ever refactor, it won't take an enduser finding that weird edgecase again.
@@llothar68 I don't have to unit test GUIs fortunately
Your description of modelling real world things with OOP makes me think about a large corporation and all the pointless layers of middle management. Its like we found a way to replicate *that* relationship in our code.
Another manifestation of Conway’s law?
Middle management is a necessary “evil”
it's like taxation. we all hate it, but it's necessary
@@yousefabdelmonem3788 Well yeah. Furthermore, those necessary evils are a fundamental problems arising from scale. As the problems become bigger and harder to solve by one person, you need to make bigger and bigger compromises. It's also useful to remember when criticising governments as "less optimal" than corporations. They only have more clutter because they have harder problems to solve. Same goes for big code.
@@ekki1993 No. Thats not a fair comparison with the governments.
Some governments dont even use version control for their engineers when they make their software. People dont say governments are less optimal because of their messy solutions, people say governments are less optimal because bad managers are even harder to fire, and bad employees are the only ones that flex their worker rights. Its just inherently bad.
I think Gilfoyle did a great job narrating this epic story!
I LOVED that show. It was so weird seeing him in Spiderman, though...
@@hazevt04 Wow, never recognised him, I guess that's his real voice?
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).
Well, for the thing he proposed you just use capture by value, and the syntax is almost identical to his use: [x, y]() { doStuff(); }();
Using lambdas is also technically functional style.
Lambas in C++ came later, the video is older ig. Btw, I like this pattern (over just creating a scope with braces) because it allows early return (no if else gymanstics needed)
@@sanjarcodeThis Video is 2016, lambdas are C++11
A lambda "captures" the variables that it uses, but it can access some variables without capturing them. They're not necessarily trivial to factor out.
I completely agree. I have always gravitated towards languages that support OOP concepts (Perl, Python, C++, VFP) and features but didn't force you into the model wholesale. My own style leveraged classes and objects but I still maintained function libraries when practical rather than forcing those into classes.
Why is C such a rude language?
cos it has no class :V
Ba dum tiss!
C++ exposes the programmer to all variants of STDs. Versions prior to 17 make exceptions.
Who need class when you have (void*)?
With C you can shoot yourself in the foot. With C++ you can reuse the bullet. With Java you would have a Bullet factory. With C# you would have a bullet that would query the subject to harm itself.
Haha :v +10 lol
Most programmers are perfectly capable to make a mess of any project without oop, good programmers can make a gem with any style of programming.
Must admit that oop can rely boost the clusterfuckery of a project.
I like the name spacing iOOP provides but I don't think you should be hiding internals of an object unless you actually need to. Other developers just hide things by default and cringe when they are forced to add accessors to their private variables. :/ I go the other way around untill I see abuse I'll keep accessors to private variables and remove them if they start being abused.
😂🤣🤣😂
@@carlosgarza31 when you expose variables or methods they become part of your public API. removing them in big projects later when you discover that people abuse them (probably because you have exposed something you never intended to be used by someone else than you), then you have to mark those variables and methods as deprecated, release a new version and give time (depending on the size of the project or the user base that process might take years), and then finally you can mark them private to hide them again. information hiding is one of the key principles of oop and a powerful tool in the hands of the right programmer.
Good procedure code is much easier to understand than 'good' OOP code, whatever that means
@Minori Housaki Not necessarily. It's the difference between `queue_push(q, elem)` and `q.push(elem)`, or even `queue.push(q.elem)` if you put your queue handling functions in a module.
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.
@27:20 why do you start out in OO code with data types already defined (as well as the behaviours) then try to make these 2 components of your model that you designed separately work as one?
the “use” block is a c++ lambda
This year, I took the plunge and decided to write an entire project using just functions and interfaces, in TypeScript. I had to stop and regroup a few times along the way, but the exciting thing is, the stuff I've had to learn along the way really seems more generally applicable - whereas a lot of the OO patterns and principles often seems like (as he says) a workaround or a bandaid. What you learn by committing yourself to this is much more general - simple techniques that work every time, not just for one specific problem or scenario. I have 23 years of developer experience and pushing myself to go all in on this feels like leveling up - for the first time in a long while.
I was on the fence about this video in 2016. I knew there was something true to it, but I had no idea where to start. It does have something to do with the language you're using - I was using mainly PHP, where functions and interfaces aren't really practical or useful the way they are in TypeScript.
I don't agree with absolutely everything in this video. Part of me wonders if the author hasn't changed his mind about some of the finer points in this video over the years - we all grow and learn, right? I kind of wish he would post an updated version of this presentation. Anyhow, I gave it my like today, 5 years later. 😄
I also don't agree with everything stated, particularly about functional programming. Computers just don't work that way so will never be efficient enough. I was a true believer of OOP as a C++ game programmer for many years. One day a friend suggested I try writing a game engine in C instead of C++. I was skeptical as I loved my fancy C++ systems and templates etc, but in the end I found my code to be much simpler, smaller and more elegant. Unfortunately I still have to work on OOP game engines and nobody will believe me that procedural is better.
I've started coding in a more procedural style i think, but i like to slap most stuff into a class anyway ... just with more emphasis on making many methods pure functions that don't touch the object's properties. And i reduce the object dependencies. I find when my code is hard to test, it's hard to think about, and it's hard to maintain. I also make most stuff public because idk when i might need to mess with things.
Idk. I used to put a lot of weight into designing things perfectly for extensibility or whatever & talks like this (and moreso molly rocket) have lead me more toward just ... get it done, clean it up a little bit, and don't worry so much about design. I feel like I'm explaining myself poorly though
@@reed6514 I don't really understand the point of pure functions in a class.
@@aaronmacdougall if it's generally only used by other methods in that class
@@aaronmacdougall
in my experience, people know that namespaces are good, but they are used to classes being the way you do that.
I will come back to this video 5 years later and see if I'm able to understand the video.
Oftentimes I find that when a module gets to a certain size and complexity, my gut tells tells me it's time to refactor into several object classes. Sometimes it feels like I'm congealing the code I've written into separate piles, but over time I get an intuition about what data and functions belong to which classes. Fortunately, I learned the hard way to keep objects and calls strictly hierarchical.
For myself, I have found OOP generally to be the best way to organize code.
Having said that, I enjoyed your video and I should be able to find things I can use. Thank you.
"Kernels of good ideas have been taken to holistic extremes." That's a very succinct way of pointing out a bad tendency people exhibit in many areas not just coding. I'm adding that to my "great quotes" list and attributing it to Brian Will.
Yeah, I liked that line a lot, too. (When you do the quote, though, bear in mind that the word is 'holistic'.) 😉
@@SpiritmanProductions Corrected. My mistake.
It's 2021 and I have to restart my car to get the radio to work. Good job, software engineers.
The car object is unstable.
You are lucky then. Imagine having to restart your car to make it turn.
isnt this an electrical engineer's problem
@@warguy6474 Well, it's both, since it's an embedded systems problem. It needs both electronics and programming.
@@Evan490BC well.. not really? You just need the same process that interior car lights have. Supply power regardless of the car being started.
To those watching this video who are just learning how to code, THE AUTHOR IS MISSING A KEY POINT: OOP is just one of many tools in your tool set, just like several others in the comments here have said. The author is flat out wrong when he says that OOP is completely bad -- there are some types of projects, team sizes, and applications where it might not be a good fit, just like there are MANY projects where the author's style of coding would be an absolute disaster for maintainability. Similarly, when devs say that "OOP is better than functional" or that "functional is better than OOP" they are BOTH wrong -- combine the approaches and use each when they're appropriate for the problem you're solving.
Moreover, judging from the comments section on this video, it seems like I am in the minority here, but I haven't ever really had a problem with OOP. In every project, I just get a feel for how things should be abstracted and organized, and everything just flows. There are sometimes moments where I'm not sure where a certain behavior should "live" but it doesn't lead to paralysis -- I just put the behavior where it seems like it makes the most sense and then move the behavior later if I find it's not the best place for it. What's the big deal here?
I have 20+ years of experience and the first programming languages I learned were C, Pascal, and JavaScript before moving into PHP and then Java and C# in college. I will say that initially I didn't like how strict Java was compared to PHP, but object-orientedness felt extremely natural and after about a semester I preferred Java's strictness because it made things significantly easier to maintain than procedural C or PHP. Since college, I have written in Ruby, Python, JavaScript ES6, and now quite a bit of C++. I absolutely hated Ruby because it prioritizes aesthetics, individual expressiveness, and brevity over clarity, documentation, and productivity. If you were to ask me today what language and standard library I prefer, it would be Java, then PHP, then C#.
The biggest flaw with this video is ironically that it is the epitome of what it's criticizing -- it's TOO ABSTRACT. If the author wanted to make a strong point, they should have demonstrated the advantages of procedural code using one or two decently sized example programs with both OOP and procedural. Instead, the author explains he wants things to be tangible, relatable, and obvious, yet all the criticisms of OOP are only explained in abstract hypotheticals and posed as high-level system messaging designs. Not only do the "solutions" described in the "procedural code" chapter lead to mega-long functions with multiple responsibilities that are hard to test and hard to repurpose beyond the use case that they were written for, but they also don't clearly relate to the messaging challenges that the author set out to address during the discussion of OOP pitfalls. Is OOP perfect? No, but the author's point that because "perfect OOP" isn't possible the whole thing isn't useful just falls flat.
I have worked on extremely large projects (including payroll systems and information systems that have hundreds of integrations) as well as small projects, and I have not found the analysis paralysis that the author describes. I have found places where engineers have created a few too many layers of abstraction (usually facades) or places where devs are breaking through the abstraction to get data that should be exposed other ways (usually technical debt in the interest of just getting something working quickly). But... since the advent of dependency injection and coding-to-an-interface, the incedence of both of those things has gone way down.
Every project has to balance cleanness of design with performance, and you don't just write this code once -- you're going to iterate on it over time. Smaller, focused code with a single responsibility ages much better than longer code that does multiple things.
"should have demonstrated the advantages of procedural code using one or two decently sized example programs with both OOP and procedural" - cannot agree more!
you said my words ..
The man who created this video made two or three follow-up videos where he takes actual OOP codebases and rewrites them in the procedural style. He knows what he’s talking about. I have also been coding for a long time, and the older I get, the more I agree with this video.
No, unfortunately you are wrong.
@@Carofdoom1126 compelling argument.
use a class when it feels right and not because u feel u have to
41:55
C++ has a solution for this: lambda functions, so instead of doing "use x, y { ... }", you do "[x, y] { ... }". It won't have access to any other variable than x and y.
Edit: and it does exactly what you want, it makes clones of those variables, and if you really want to change them, you can pass them as reference for ex, with &x. It's really like having a function but without having to name one, and it can be placed anywhere.
lambda a simply nonamed function.. i.e: not reusable. why not simply make it a named function, and you can re-use it!
@@moestietabarnak C++ lambda is just an anonymous f() inside a normal f(). It can be reused inside it.
@@moestietabarnak C++ lambdas have a feature called CAPTURE. Basically they can capture variables in the scope as static values.
@@jukit3906 SO, it emulate a function with args passed by Value.. great
note : capture can also do references.
Still the same functionality as a named function, but the named function can be shared more , re-used more
and syntax is cryptic ..
@@moestietabarnak nope, it is more useful: it is dynamic (that is, a function can hold lambdas with different captures and function bodies)
Only virtual member functions are comparables.
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.
Your company problem stems from too many programmers who don't understand OOP.
@@pyhead9916 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.
@@Dovenchiko 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.
OP’s OOP beats OC’s PP as far as OO goes
My god, the naming conventions. I would hate to read code from yallz
@@unformedvoid2223 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.
You raise some excellent points. I find this extremely recognizable. Sure OOP and abstraction looks great when you have a simple example that itself is very concrete. But, like you said, real-world problems and programming deal with abstract concepts themselves.
I might have a go at implementing the "use" keyword in Rust using the macro system, although "use" is already a keyword for importing so it'd have to be called something else.
I imagine it would create a function parallel in scope to where it is used and call it immediately. Because Rust macros are evaluated at compile-time I don't think this would show up in documentation, and even if it was there's a way to ignore it that could be inserted by the macro.
Video should be called OOPs, my bad.
lol
In your country, you like to create "object," but in Java's "Inversion Of Control" paradigm, object create YOU!
nice one
OOPs i did it again
OOPsy poopsy
This is kind of weak. Riffing on Strict OOP's semantic shenanigans. Riffing on Java. Nothing new, no boundaries pushed. Although you present yourself as a fringe, I'd hardly consider you one. You're middle of the bell curve in your opinions - the only difference is that you can accurately point to what irks you and openly say that what you're doing is not really OOP. Most programmers that say they use OOP actually do stuff exactly as you suggest in this talk - they just fail at noticing it's not OOP anymore.
And then a purely syntactic proposal "I would like to have this, cause I can't read code". You do understand, that you could just as easily use an anonymous inner function, pass parameters to it and say "this is self-contained" in the comment, right? But I guess you're just too busy, trying to tell us what every practicing coder knows, to actually bother making the best of the tools you have. "Nooo, we need a _very specific_ hammer for this _very specific_ nail, cause a regular hammer just won't do..."
I am an average craftsman of the trade.
I hate OOP. I hate Java.
And I hate people in general.
Specifically I hate tech bloggers, that try to be edgy but just end up riding the mainstream.
+SGresponse 1) A comment noting an inner function is self-contained is an OK half-measure, but language-enforced guarantees are better.
2) If you conflate FP hype with anti-OOP, then it might seem anti-FP is middle of the road among recent tech blogging. But a large silent majority of programmers pay no attention to tech blogging, and most of them are at least nominally doing OOP. I'm explicitly advocating for procedural programming regardless of imperative vs. functional. That's not fringe, but it's definitely a minority position held by probably less than 10% of all coders.
3) Yes, a big chunk of supposedly OO code barely follows the prescribed principles in even their weakest forms. That's a good thing. Very often, though, these pseudo-OO code bases make gestures at following the principles because the programmers feel guilty for not making their code "proper" OO like they learned in school. The end result is not as overly complicated as full OO but still overly complicated. More programmers need to hear the message that they can stop feeling guilty and just program the more natural procedural way.
4) You're a dick.
+Brian Will
Addressing your response in no particular order:
*4:*
I indeed am a dick. Did I mention I hate people in general? That's a subtle hint. I am an absolute nightmare, cause I voice my criticism in such smug Dickness, that many people just see Dick and nothing else. Glad you're not one of them. I have gotten better over the years and raised my status from being an _intolerable fucking douche_ to just being a _dick_ , so this self-aware confession is not just means of avoiding the issue. I improve in small steps.
*2:*
The FP hype I don't conflate with anything because I stay as far away from any technology hype as possible. Every single thing that any larger group gets hyped-up about is ultimately totally impractical for non-edge-case use. This goes for OOP, FP, Prolog, Logo... anything.
I'm criticizing you for saying that you take a fringe position - not because currently "FP is on the rise and OOP is passe". I'd be criticizing your mistaken identity even if OOP was _the shizz_. Because ultimately everyone, that had ever experienced in practice the tenets of OOP as they were intended in theory, knows the stuff you say and adheres to it. _That_ makes your opinion middle of the bell curve - not the fact, that the hype train moved away from OOP.
Going Procedural is like using MS Windows - it's not glamorous, not glorious, doesn't push any boundaries, you won't write a thesis about it, nor a smug blog post that proves you are awesome because of using Windows. No - you may use Windows, because it has a low entry barrier or because you're used to it or it has all the functionality you need right now (and you don't care about what you'll need in 3 years time) - but mainly you use Windows because it works. Sometimes better, sometimes worse, usually "good enough" - still: it WORKS. And the same is true for Procedural programming - it's "good enough" to handle most cases you will ever need programming for.
And people know this on an intuitive level. Meaning, again, *many people agree with you. You are not fringe, nor 10% minority.* You're somewhere in the 40-80%, depending on which company employees you'd interview. And if you're going to argue specifics, then theoretically yes - less than 10% of people holding this position will ever express it openly. Usually out of lack of self-awareness, rather than out of fear of ostracism.
*1:*
Yeah, it's great when the compiler thinks for you. I love strong-typed languages (no irony here - this one's sincere). But this - this is not the way to go. There are two additional arguments against this I can give, besides the most solid "specific hammer" one I already gave:
Firstly
Context and scope are a finnicky concept. You will learn that everything that's in {} brackets knows all of its surroundings but anything outside of these brackets won't get in. And that's fine, that's enough, that is working knowledge you get engrained in yourself so deeply, that you don't even consciously notice this assumption in your thinking anymore.
And then comes some poorly written VB6 code, where no one bothered to dim the variables, so every single local "tempstr" variable is just a call for the global "tempstr", that god forbid you dare use in a subroutine and expect your local copy to be intact after you call that subroutine.
And then you see javascript callbacks where you can switch up the context by virtue of one parameter and you then don't actually know what the current function call can see outside of it. And then you try to use "this" in a standard event callback and it goes south so fast, you're chewing on Antarctic ice before the shift is over.
So in summary - don't mess with core concepts. It's unhealthy to have exceptions to rules when rules are the only thing, that can help you stay sane in an otherwise profoundly insane environment that any programming language is. And if your response is "if there already are exceptions - why not just throw in another one?" - please go read whatever your government currently uses as tax law. Go read it, understand it ALL and come back and tell me yet again, that exceptions to general rules are a good thing. I dare you.
Secondly
Languages are complex. When you said in your talk (paraphrasing) "Why can't we use something like _on this object I give you, enact function F_ ?" I was initially with you on this. "Yeah, why don't we?" I thought to myself. And then an answer flashed back to me: Parsers.
You need the language expressive enough to code complex concepts in it, structured enough for the machine to efficiently parse and simple enough for an average shmuck from accounting to learn the basics in a month. Each new keyword adds complexity and reduces the viabilty of the latter two aspects.
And while I may understand you're coming from some functional language where the list of keywords is roughly 30 items long, this notion will eventually sip into every popular language, adding to yet another intricacy to something like PHP (nearly 70 keywords) or C# (over 80).
After finding what the keyword "yield" means in C# (for those interested: it's a bastard child of _"pointers are too hard for the average accounting shmuck, so we'll use references everywhere"_ and _"our container implementations are slower than C++"_ ). Learning "yield" was one of the contributing factors in my conversion to Satanism. But I digress... after finding "yield" I say *NO* to the notion that we should expand our languages with new features. No! Complexity should be removed, obscure features should be cut from language syntax and, by Jove, never a feature should be added that LIMITS what you can do using the same effort and already existing tools. That is just backwards.
*3:*
Here's the meat of the subject. The concrete, the Agenda.
You see, I've dissed so much of your approach mainly because this is nothing new to me. And you seemed to be making a big deal out of it as if you were a Buddhist monk enlightening me about virtues of clean code and simplicity of life. But the stuff you said was nothing enlightening... Until.
This key sentence: _"More programmers need to hear the message that they can stop feeling guilty and just program the more natural procedural way."_ . This is an Agenda. This is Purpose. This is... never mentioned in the video... right? Did I miss it? Did it fall somewhere in the cracks between the Java riffs and the syntax rant?
But it is something new to me. Are there poor lost souls, that still think their code is crap just because one method has more than 30 lines in it? Or that their inheritance hierarchy is too weak, because it doesn't give space to every possible entity ever existing in the universe? And because of this they think they're unprofessional? Are there such people? If so - yes they need to be reached and slapped back into their senses. And I am fully in support of such an agenda.
But why wasn't it stated explicitly? Is it because for a tech blogger having an agenda is usually viewed as overzealous? Or cultist? Or... unprofessional? If so, then I think more tech bloggers should hear the message, that they can stop feeling guilty and ashamed of their agendas. And just blog and make videos the more natural way - openly stating their intents and allowing viewers more broader context on their position in that way.
PS: I should stop putting essays in YT comments. This is a chore to read.
+SGresponse Pffft...OP definitely ruffled some feathers...he's a feather ruffler.
+SGresponse Being in the middle of a bell curve means that you consider the perks of both sides and then you make rational decisions based in unbiased thinking, I hardly see how that is a problem.
*****
If you assume that the people that come in after you will be sensible - then the comment is enough. However if you assume that they're the stupids, then pretty much you have to concede that they will fuck something up regardless of the language constructs we put in. Your point supporting the new construct is invalidated either way.
And again: the visibility of the broader scope from the nested scope is NATURAL for all bracket-based languages. So making a keyword that will change this behavior would not only be pretty much useless - it would be detrimental.
Granted: I can actually see one good use for this in code. When someone is writing code that's so shitty you almost expect to see it cross-cut through all the variables at any point and change them willy-nilly. Then seeing the sandboxer in there would be a blessing. Or leveraging it to do some runtime analysis on that crap code.
But really: asking for a special syntax that _breaks general behavior_ (key problem for me), just because you're either shit at writing code or shit at reading it... I can't even express my feelings toward it properly - a mix of distaste and disappointment in one's craftsmanship. It's not even the fun kind of shit-in-code. It's the sad kind.
Corbin Crutchley
It wasn't both sides of the tale - you will see that in basic approaches to everyday coding Brian and me agree quite readily. If you really want a different side of the coin - look for someone who's into rigid OOP. I can't recommend anyone, cause I stay away from those zealots.
Anyway: thanks. I find it rewarding that at least one person read my essay through to the end.
Trevor Hart
Being middle of the bell curve isn't a problem - that's true. Posing as if you were the fringe while being the average - that's what I challenged Brian on. I still feel like I was right, but it's up to you to make your own opinion on this.
The little "code blocks" that you reference in the end exist in C++ in a form of a lambda. Usage could be almost exactly the same as you have depicted. Example:
int main(void)
{
int a = 10;
int b = 20;
int var = [a, b]()
{
return a + b;
}();
return 0;
}
"Bundle globals into structs/records/classes. But be careful, there's an art to how you bundle these things together. "
It's called object-oriented programming
Also, I have an issue with this advice "Don't be scared of long functions".
The reason why I generally have to avoid them is because I'll need to reuse the "components" of the function. There's a myriad of business areas with similar/overlapping business processes that needs to be mapped like this. And Brian's advice doesn't provide any solution to this. Is the solution to have copies of nested functions everywhere. How do you change your code later?
Generally I think he's on point with the problems of stateful, OOP. But I don't think he quite manages to point to any useful remedies. Programming is hard, because mapping complex domains is just hard. Real life is messy, and code that tries to reflect that will also, inevitably, be messy.
I think this is part of larger problem of adhering too strictly to a specific doctrine.
+djbanizza instead of searching for god
Yeah, it's a group think issue, as with so many other things.
I agree.....for instance one specific doctrine is OOP is bad.
Holy wars.
Object oriented programming has some good ideas, which applied intelligently can help produce good code. But when those ideas are reduced to formulas and applied blindly, you can get some very bad code. And the latter seems to be the norm for much of the industry.
41:00 This is exactly how C++ implements lambdas :)
Yes.
i like how rust is still at its core very procedural and functional. even when you want more object-oriented behaviour, it still has you separate behaviour from data in a way that is actually modular. you can still `impl MyStruct` to tie behaviour to data types, but this is a conscious decision of the programmer rather than being a limitation like it is in many natively OOP languages.
And you forgot to mention enums that can embed some data for the caller function... That helps a lot.
But yeah, defining objects as their behavior is (I think) easier than trying to get their true type...
I like how rust at its core is still worthless like every other opinionated language and C++ is still industry standard in 2024 because it's only opinion is about actually being usable in real world conditions.
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.
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.
@@davimendespimentel6849 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.
@@WowUrFcknHxC 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.
@@davimendespimentel6849 without abstractions we would be nowhere today
Abstraction is important because it makes programming easier. And even with this band aid we still don't have enough programmers
If every code monkey in the world needs sophisticated knowledge of the inner workings of a language the entire world will grind to a halt
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.
The complaints are valid but I can't agree with all the suggested fixes.
This is the story of humanity
For a while I thought I couldn't learn programming because people needlessly overcomplicate it on purpose.
After watching this video, I now realize that I can't learn programming because people needlessly overcomplicate it on purpose.
People dont overcomplicate on purpose, that just doesnt happen. No one in the world is inherently evil, theyre just doing what seems right from their perspective.
The problem isnt really overcomplication, it's that programming itself is complicated. Even with that, I dont think that being "unable to learn" it is ever correct.
If you just stay curious and learn a little bit at a time and keep experimenting, you can probably become so much more skilled at it over time than you thought you ever could be.
It takes effort but I think youre wrong in saying you cant.
Usually, it gets forced by some management, or some practices people learn. Extremely well designed object oriented programming is very easy to read. Much easier than functional or plain old C, because the functions are with the data.
Learn to program in C. It has a name of being hard, but that's incorrect imo. It's hard to write large software packages in C, but the language itself is pretty straightforward. And a great thing about learning that way is that sooner or later you will run into the limitations of the language, and then you will easily pick up on more abstract ideas like object-oriented programming. And you'll learn it not as the one true way, but as a technique that is in some cases helpful.
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.
I do apply that very frequently because I'm too lazy to write even the smallest repetitions
i would not really call myself a programmer because i'm a data analyst but literally this is exactly what I've started to do in my python code because I'm lazy as hell and there's things I need to do over and over again and it feels clever to wriet a function for it lmao
The whole problem with the industry right now in this point of history is the over abstratction, choosing speed ("don't reinvent the wheel") over quality.
It's actually not faster. Certainly not long term. hinking about the structure of your code may require extra time, but it saves time in the end. I'm currently adding features to legacy code. It can take an entire day to find a single line of code to change since there is no documentation and no structure.
I'll just grab some popcorn before reading the comments
Better grab a bucket.
Eatin’ some white cheddar flavored popcorn right now ... LOL