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!
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.
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.
given that requirements are always changing, a free form approach is more appropriate. If you start out with a rigid plan/structure you are in fact doing waterfall.
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.
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.
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!
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.' 😂
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
@@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... 😁
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.
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
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.
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.
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.
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'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?
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.)
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.
OOP is wonderful for large codebases. I have worked far too long on the IBM iSeries platform with its go-tos, and top-down programming. It doesn't work. It's nearly impossible to upgrade codebases that are gigantic and written top down quickly, and they're insanely error prone. Local versus global variables and isolating data in OPP makes life SO MUCH BETTER. I feel like you haven't ever worked on a gigantic codebase.
This is true, and i also feel like this video has nothing to do with areas of coding that arent database/website associated. Like simulations, or even game dev, where you dont need all data to be stored or returned somewhere. In that context youre not just "performing an action on data", youre using objects to capture behaviours, and having them split into classes with encapsulation allows that process to make sense, without ending up with a script thats 20000 lines of code. Entity-Component DOTS style coding is often a better choice, but its readability is atrocious compared to OOP, and thats important for quick testing and turn around times. The idea that a style as useful, flexible and readable as OOP is just blanket "bad", is really more just an admission that you dont know when to use it, or how to use it.
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!
He was saying that the inner scope should not be able to access any data that's not explicitly passed in to it. This would let the reader temporarily forget all about any variable which is not immediately necessary for the next logical step. I don't know about c++ but local anonymous functions / closures in both php and js are not restricted in this way. He also mentions that the data is always passed by copy - not by reference - ensuring immutability.
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.
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
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.
@@justgame5508 That's one of the reasons why I like C++, it's the whole toolbox of paradigms. Even if there are a couple weird dangerous tools in there that can prick your fingers (i.e. placement new), it's still nice to have 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.
@fetherfulbiped No. Nononononono no. You have it COMPLETELY backwards. It is infinitely easier to debug procedural code and reason about it when it is right there inlined for you. And figuring out a codebase is made HARDER by fragmentation it into 10,000 little pieces scattered everywhere. Your coworker can just as easily use a FUNCTION over some class with a built in method.
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.
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.
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.
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.
There is a programming tool that, when used incorrectly, causes compiling errors (and the code won't compile). No damage then. When used correctly, causes the debugger to be practically useless. Have you tried it? And yes, it is FP :-).
And the problem is there are too many purist that do exactly what you say it should not be done. I know a programmer and even have to work with that instead of making a single switch with 5 different settings will make 6 factories that will contain 15 classes to do it. If you are doing that just for a single switch you are bad on the head and heavily. And the switch on itself has only 1 or 2 lines of code. If you say "that is hard to read" trully cannot understand how compared to a total of 21 clases.
+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.
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.
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.
Agreed. In some domains there are natural relations between data and methods that are never going to change, so objects work well here. In others there are cross-cutting concerns, so standalone data structures and functions work better. It's not really so difficult if you take a pragmatic, undogmatic approach. All my apps end up with modules that contain objects, standalone data structures, and libraries of functions. Works for me. Seems to me that it's not objects that are the issue - they have their legitimate uses. It's dogmatic OO thinking that attempts to force every domain into the OO paradigm.
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.
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.
@@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
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.
That is the main problem the OOP programmers just use 80% time to refactor and only 20% (or less) of the time to make the program how can they not take 5 times more?
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
I watched the entire video and while it made me think I still can’t agree with the premise. To me a well thought out and designed OO program is easy to work on (whether you were the original programmer or not) and to extend. In my experience, the nightmares arise from programs that started as one thing and grew to something else or worse they were extended by a programmer who took shortcuts and no longer adhered to the original OO design. I’ve worked with both well designed OO and procedural programs and in my experience I have always found it so much easier and enjoyable if it’s OO.
What I like to do, is to basically fuck around and make some prototype , and then if I have the time, I draw up some random chart on how stuff is supposed to relate to eachother, and then organize it like that. It helps to be off a few adderal pills while at it. Im programming for fun, so i dont really know any of these industry level knowledge. Maybe people do that.
By that logic alone however, OO is difficult to extend because adhering to the original design plan while extending it in a meaningful way is exceedingly difficult.
@@CyrilCommando good luck changing thousands of lines of procedural code to a new design when it relies on the whole sequence of operations being maintained in an arbitrary order, otherwise your global state goes out of sync. What you'll have to do is rewrite the whole program.
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.
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.
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.
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
29:35 - Oh yes. I am yet to encounter an introduction to OOP with real world example, solving a real problem rather than being a 2d shape, animal or furniture.
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.
@TheJacrespo Uhhh- no? If your buffer is 256 bytes long and the user inputs 300 bytes, just increase the size of the buffer at runtime. This is how it is ALWAYS done- the difference is that OOP incurs a heavy performance cost by doing that stuff under the hood to account for all general cases. The garbage collector for example…
In the end, it all comes down to error handling. Monads do this at the expense of performance and cognitive overhead. I've always preferred simpler pragmatic approaches, and they seem to get the job done.
16:37 "What is the one abstraction bigger than a function and bigger than a data type?" Mathematical categories, of course. They provide an even higher level of abstraction than objects in OOP, since they are able to describe more than one object, and they remove the need to play the responsibility game that is referenced at 27:22. They can be most commonly implemented in software as a collection of data structures and a collection of pure functions that map between the data structures, with the additional constraint that functions are associative and data structures have some concept of persistent self-equality (so that there is a "do nothing" or "identity" operation that lets you leave a data structure alone without it changing its nature). This by itself is enough to meet the formal definition. You could implement categories as namespaces or as class constructs within code. Implementing a category using a namespace construct allows greater reuse across software projects, since homsets within the category can be stored within separate files. Since a homset captures a very small, perhaps even atomic aspect of interdependency, moving a single file across software projects will need only require importing the minimal set of other files needed to support it. If a category is implemented using a class construct, then there are many concepts within category theory that can be used to precisely describe many of the aspects of Object Oriented Programming that people actually like. For instance, categories often require other categories so that their behavior can be implemented. The categories that are used to implement another category can be tracked as dependencies passed to a constructor, which itself forms a category of categories, where objects are categories and arrows are constructors. This is similar to the way OOP makes use of dependency injection. In another example, certain kinds of functors within category theory can also be implemented using inheritance and interfaces. A design approach based around categories shows many of the positive attributes that people have found with OOP (dependency injection, code reuse, programming to interfaces) while eliminating many of the problematic attributes (state obscuration, state management, the banana-jungle problem), and it is based on a solid mathematical foundation that OOP lacks, which removes the need to discuss what it is we're even talking about, as is done for OOP starting at 1:01. The approach can be considered consistent with the "object oriented & functional" design approach mentioned at 6:12.
There seems to be a good reason why the term "abstract nonsense" is used about mathematical methods used with category theory... I just wonder how it is expected that the average Joe Coder - who may barely have grasped recursion as he drifted from HTML, CSS and copypasting and hacking JS by trial and error, to doing a little backend programming in Php - will understand category theory, and to what extent he should be expected to understand it?
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.
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.
1) in my university they tought us, that classes called -manager, -service, -handler, x-er and so on are considered to be bad for the reasons that you mentioned. They are actually bad practice and no contradiction to the use of the oop paradigm. 2) the "use" keyword that you suggested is basically the semantic of lambda expressions in pure functional languages like Haskell 3)even though you tried to give ideas, how to solve the problems instead, you did not give very concrete solutions. One main reason to impose a structure using oop is to avoid "spaghetti code", where everything is connected to everything and it is not really obvious what functions are called from what scope.
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)...
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.
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.
Domain Driven Design (DDD) addresses--and in my opinion eradicates--all the issues described. Now DDD is language agnostic, although Evans himself points out that OO languages are usually better suited for it. I think the issue is that most people confuse the paradigm of OOP (which has matured over the years) with Java's implementation of it. Now first I want to say I think this video makes excellent points about some of the shortcomings of old OOP paradigms, although I think the title of this video should be "Strict Encapsulation is Bad." There are, however, some points I think need to be addressed. (I've addressed test driven design in another comment). 1.) The analogy of the over-architected house is (pretty much by definition) describing a poorly planned application. He mentions walls that were prematurely established, but this is a planning flaw and not directly related to OOP. I could argue that procedural code is like a winding country road, it just randomly weaves and has no coherent sense of an actual destination. This is not a flaw with procedural programming, this is just poorly planned code. 2.) He states early on that he will ignore inheritance--rightly so--because even OO programmers warn against it. He then later references complex hierarchy graphs, which are due to inheritance. The modern approach to OOP is much more focused on dependency injection and interfaces. As far as complexity goes, the relations between objects in well designed software are only as complex as the domain requires. Any other complexity is almost certainly due to poor design choices and not the paradigm itself. 3.) "In procedural code there is only the call graph." I think this is very misleading because, in a complex domain, the call graph will only be decipherable by the software designers/engineers themselves. It is very unlikely that an "outsider" would understand the call graph outside the context of the software itself. This is why OOP is such a great tool for complex business domains. I worked on a healthcare application and one of the most valuable aspects of our design was that we could use the same graphs and flowcharts our developers were using to discuss the application with doctors (the domain experts). There was no intermediate translation needed to describe the business logic (interactions between objects) to the people who were actually in charge of implementing it (the developers). This is the point behind DDD's ubiquitous language. 4.) There definitely is a need for functionality that lives outside of objects. Anonymous functions now exist in most languages, as mentioned in many other comments. I would only like to add that creating a "container" for these functions is very much like a namespace and can actually be helpful in describing the context of certain functions and grouping them together in ways that are self-documenting. 5.) Abstraction is a term that has a specific meaning in computer science: it refers to the level at which the actual inner-workings of the computer itself are hidden from the client/programmer. For example, even a simple expression like "int y = x + 5;" is an abstraction that hides some of the implementation details (allocate a memory slot for an integer, add the value in the x memory slot with 5 and store it in the allocated memory). The abstraction of OOP is described properly in this video as "simplified interface over complex inner workings." But this is a GREAT thing! This means once an algorithm (business logic) is perfected (using test driven design) it can then be abstracted to an easier to understand concept. I'll concede that factory--and builder to a lesser extent--patterns can be sometimes hard to understand, but they are actually not meant to abstract away complexity; rather they are meant to enforce constraints. This may be unneeded complexity in small, data-driven domains with a small development team, but it is very helpful in larger teams dealing with complex domains as these patterns enforce constraints with public interfaces while hiding implementation details that only matter to the people working in that subdomain. This is similar to a business that contains forms for certain requests. The person filling out the form does not need to understand the details about how the information on the form is used, they just need to be able to fill out the form. Now, as mentioned in the video, it is definitely difficult to abstract away implementation details to the point that it can be described using real world concepts, but this is just the difficult nature of software design, not a shortcoming of OOP. This is analogous to saying it's hard to abstract away the mathematical complexity of structural mechanics, and therefore CAD software should just have the user input the center of mass and moment of inertia themselves. Abstractions and generality are probably the hardest things to master in computer science, but they are also extremely valuable when done correctly. 6.) Modularization is a great thing no matter what paradigm you use. Setting boundaries between responsibilities of your code minimizes the domino effect a change can have. The "fractionality" mentioned is actually a benefit in the long run. If you contain a big chunk of seemingly related functionality all in one place (rather than split it into smaller pieces), it becomes more likely that a small change in that big piece will bring the whole structure down. This idea of strict separation of responsibility is so fundamental to good design that you now have some of the greatest minds in software architecture (Martin Fowler, Chris Richardson, etc) focused on perfecting the microservice pattern. 7.) Lastly, "The kingdom of nouns" is no better than the kingdom of verbs that is procedural programming. The idea behind objects is that most verbs are attached to a noun--a doer if you will--or at least relate two objects together. For example, take the question posed in the video "should a message send itself?" No, a message service should send it, which describes the real world perfectly (be that the postal service, an email server, etc). I don't see what's so abstract or hard to understand about that. So the idea that OOP doesn't have verbs is utterly false, but I could argue that nouns are better described in OOP than they are in procedural code. Now I will concede that OOP is not always the right choice and I think this video addresses the issue of people always using OOP because that's what Java was designed to implement. It is often overkill for simple data-driven applications. But OOP is absolutely necessary for complex business domains. When the application becomes very difficult to reason about using basic control flow, it helps to construct objects that represent actual domain entities and then hide all the programming minutiae inside methods that represent actual business logic. It is also very beneficial when working with a large team to define public interfaces for objects and then delegate management of more detailed functionality to smaller teams that are able to master the concepts of their specific subdomain. This is similar to how every major business operates: your sales team is not responsible for accounting. They may at times need to interact with the accounting team, but there is no need for them to understand every detail of how the accounting department operates. The problem with procedural code when it comes to complex domains is that the entire team typically needs to understand the codebase in more detail. Most of the points in this video seem to pertain to a small codebase with functionality that is easily described using the basic control flow operations that have been around almost as long as computers. But this simplicity of design often breaks down once more complex logic is needed. Again, I want to say that this video makes some very good points about possible pitfalls in using OOP, but there are ways to avoid these pitfalls and it all comes down to taking the time to understand the problem (or domain) in great detail and carefully planning the structure of the application. If you don't want to put forth the effort to properly design the application then OOP will certainly fail you in all the ways mentioned in this video. If you're the kind of developer who gets an idea and wants to sit down and start coding immediately then OOP is not for you. But if you decide to take the time to apply an iterative, test-driven design process then OOP will reward you with a self-documenting, easy-to-understand, maintainable, and extensible codebase.
I also rue the epidemic incessant resistance to objective domain analysis that is occurring pandemically throughout humanity. You can see it in other areas of life too. Indeed more so! Money supply, politics, history, "education", mass media and blind acceptances of sinister, ever growing bureaucracies are the first examples that come to mind outside of engineering.
I feel like you missed some of the points. The problem with OOP is that most verbs are meant to attach to a noun. In the message example, a new coder doesn't know which class to check when it comes to finding out where messages are sent. Imagine you have the following classes: Message, Connection, MessageReader the new coder has no idea where to look exactly and any public methods in these classes will make them paranoid about side effects. In procedural you can still have namespaces/static classes/whatever to organize where the functions live. So now imagine you just have a "Messages" namespace. All actual business logic for messages is contained in this class. It has a function like "SendMessage(Connection, MessageReader, Message)". Bam you instantly know exactly what it's doing just from the parameters it takes. That's the FREEDOM of procedural. With Nouns (usually data) and verbs(business logic) you can now arbitrarily combine the nouns together with arbitrary verbs! Also if you like modularity pure Functions are THE MOST MODULAR thing in existence. In the above example SendMessage is pretty much a stand alone function (though not pure). But compared to OOP it way more modular. Someone could have programmed this so that it has a constructor Message(Connection). Now EVERY SINGLE METHOD in Message, might be using connection who the hell knows? That aint modular. Worse case it could be EDITING STATE in Connection. In the procedural example you know only that one SendMessage function could possibly be editing Connection. Lastly you can get all the same benefits you brought up with things like "business people readable flow charts" and have easy to follow call-graphs if you just name space and limit scope properly. Which is EASIER to do without OOP than with OOP because of the annoying noun.verb limitations.
@@sharp7j I don't understand how this is better than something like MessageService.Send(message) And as far as modularity goes, then you have a lot of options, like MessageService.SetConnection(connection).SendMessage(message) MessageService.SendTo(message, connection) MessageService.Send(message).To(connection) I'm also unclear as to the advantage of namespaces over static classes. And to be clear, I'm not an OOP fanatic. I use different paradigms in different scenarios and often find procedural to be the right choice for smaller applications. But it's rather dogmatic to argue that procedural code is always better than OOP. In large-scale applications, I think the encapsulation and expressiveness of OOP can be extremely valuable. The price you pay for this, as this video lays out, is that you have to be careful how you use it. But this video just lays out a bunch of problems that have been addressed (again, Domain Driven Design is a great book on this topic) and then asserts that procedural code must be the answer because OOP has flaws. I love programming in plain old C, but it's not the right choice for every project. I love messing around with functional languages like Haskell, but again it's not the right paradigm for every problem. OOP isn't the only way to code, but it is certainly a valid paradigm which is why Microsoft continues to put a lot of effort into maintaining C# (which is what a good OOP language looks like).
@@sharp7j Your example here is really nonsensical. Speaking just from an object modeling perspective, you've reversed the relationships between Message and Connection. Connections send Messages. Messages don't send themselves. Seeing Connection in a constructor for Message is an immediate code smell. If I ran across that in a code review I'd know immediately the developer didn't understand what they were doing. Whether your favor procedural code or OOP, single responsibility principals still apply. It's just as much a mistake for SendMessage to modify Connection's state as it is for Message to do so. I'm likewise perplexed where you get the notion that a procedural approach would give you a guarantee that only a given function could be responsible for modifying the state of a data structure since that structure could be passed to any number of functions any number of times. You'd have the same problem with each call to SendMessage as you would to each new Message the Connection was passed to. All you've demonstrated is that poor engineering can be carried out by anyone.
@20:55 "Where in the system of 10 objects all sharing the state is the coordination?" In the object that holds that state, and in the class that defines all valid state changes for that object. Each object is responsible for its own state, regardless of how many other objects have access to that state. I find myself disagreeing with some of your arguments, but you are forcing me to think deeply. And I also appreciate your clear definitions of terms.
There tend to be complicated cross-cutting concerns across shared, mutable objects in many circumstances. A simple example is a traffic light and a car. These could be two separate objects but, for correct/desirable behavior, cars should not cross the road when the light turns red. Now you have a cross-cutting design concern which requires you to look at the interaction of the objects, and not just the objects themselves, to reason about correctness. Even if you unit test the traffic light thoroughly, and unit test the car thoroughly, and they both pass their tests, they could be used incorrectly together. A recurring one that's similar is race conditions (including deadlocks) when objects are used in the wrong order across threads. Functional programming eliminates this completely by avoiding shared, mutable state. Procedural programming can sometimes simplify things a lot more than OOP by centralizing the mutations to shared state to the minimal number of functions instead of branching all over the place between complex object interactions.
@@darkengine5931 A 'traffic light' problem like this is an inherently stateful problem that involves interactions between multiple objects in the real world, so of course you'd have to have this interactions replicated in code if you wanted your program to work correctly. The trick is to establish these object relationships in a way that makes sense. If you're deciding whether or not a car should go or not, a car should have knowledge of what road it's on, you should be able to easily tell how far away the next traffic light is, what color it is, what other roads connect to the intersection, how many lanes those roads have, you should be able to tell what other cars are at, or are nearing, the intersection, what speed they are going, whether they have their turn signals on, etc. Trying to avoid complex relationships between objects when modeling a problem where those complexities exist in the real world, is futile, and trying to model a problem like that without objects is going to quickly turn into a tangled mess.
@@aliengenie8896 The difficulty I've found in my experience as a gamedev dealing with such simulations of the real world is that if we have so many stateful, mutable objects, we have a great deal of shared, mutable state. Even the most enthusiastic object-oriented designers understand, if they deal heavily with multithreading, the difficulty that shared, mutable state imposes on reasoning about the correctness of systems in multithreading contexts. >> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible. -- John Carmack Yet I would suggest such thread-safety concerns that arise from shared, mutable state are just one example in the broad category of integration hell where code that works fine in a single-threaded context, when integrated in a multithreaded context, fails unexpectedly due to data races. One common problem teams can encounter if they design codebases that consist of so many stateful, mutable objects is that their unit tests pass but they can still be plagued by edge cases that only reveal themselves in the context of integration. I've started to see many object-oriented developers starting to make arguments that integration tests provide more business value than than unit tests as a result. Yet embracing a more functional style eliminates integration hell almost entirely in all forms since it largely eliminates mutable state. An alternative that doesn't do quite as thorough of a job as functional is the ECS. The ECS tends to take on a more procedural design breaking encapsulation, but it tends to avoid the integration hell problems that can manifest in lots of heavily object-oriented systems by reducing the design to a handful of systems that transform data which are extremely explicit about exactly what data they transform. They don't eliminate shared, mutable state but they make it extremely clear and explicit exactly what is mutated and when/where.
@@aliengenie8896 Allow me to try another angle as well focusing on the tangled mess you mentioned. Hopefully both of us have seen at least some of the worse cases of object-oriented design to see that OOP is not immune to producing a tangled mess where we can no longer effectively predict what would happen by merely looking at individual things without getting loss in a tangled mess of other things through their complex and tangled relationships, and/or change something to suit a new design requirement cleanly without changing everything else involved in this tangled design mess. The first and foremost metric easiest to measure and address to untangle object-oriented designs is coupling. If we seek to decouple objects further (either loosening their coupling or completely decoupling them), our tangled designs start to become less tangled. When we can effectively produce the most independent object designs not interdependent on one another and without becoming too leaky in their abstractions, that's when I'd say OOP produces the maximum value for the buck as it avoids producing a tangled, highly-interdependent mess, with self-contained invariants easy to guarantee and maintain. That's when we get the maximum benefits of predictability, modularity, reusability, and I'm totally aligned with OO enthusiasts in utilizing encapsulated objects in these cases. The problem I see is that as we work towards higher-level design requirements in a sufficiently complex simulation of the real-world (which tends to involve so many cross-cutting concerns as Brian calls it), we can't help but produce tangled messes if we favor at least an eager or even purist style of object-oriented design. This is because the very nature of encapsulating state and methods that can exclusively access that state together tends to result in something we might analogically describe as a thousand teeny islands that give the illusion of being easy to comprehend in ways that provide a lot of business value. Yet they don't actually provide much business value on their own and end up having the most tangled and convoluted trade routes in between them, and we find too little valuable information to be comprehended and predicted as far as comprehending business/design requirements by looking at each individual island without fully comprehending the convoluted and tangled trade routes in between them. When the analogical trade routes in the above example become the ultimate source of tangled complexity and misunderstandings which makes things difficult to predictability change, and in isolation without changing surrounding things, the only scenario to further decouple and simplify such designs and untangle them is to start abandoning OOP on a small scale in favor of what John Carmack calls "medium-weight" to "heavyweight" encapsulated objects, and that's precisely what he did in the final stages before he largely abandoned object-oriented design all together in favor of functional programming which provides maximum comprehensibility, predictability, reusability, modularity, but largely eliminating mutable state outright and achieving the highest degrees of decoupling. He was doing the metaphorical equivalent of coalescing these teeny islands into larger landmasses whose individual requirements become a bit more complex to understand on their own, but whose trade routes between islands become substantially simplified. It's a decoupling mindset as well as a testability mindset (a small object which provides very little business value on its own provides very little business value in passing its unit tests regardless of the coverage). The analogical "TrafficLight", "Pedestrian", "Road", "Sidewalk", "Car", etc, turn into simple bundles of state whose traffic-oriented functions might move into something we might organize and bundle into "TrafficSystem". That is also what the ECS, as becoming increasingly favored for modern game engines, does. It would turn something like "TrafficLight" into a simple data-oriented component that bundles state but not its functions together.
@@aliengenie8896 If you'll forgive yet a third way of analyzing this which moves away from the most technical, we can focus on design in general. As beings of limited intellect and comprehension, and whose comprehension and capabilities for misunderstanding and miscommunication multiply with more team members between us and more lines of code, we tend to want sufficiently "meaty" designs to simplify our comprehension and communication. If our goal is to build a sand castle and focus on the artistry behind it, we will start to lose our way if we become obsessed with the functions of each individual grain of sand in producing that castle, or each individual drop of water, or each molecule (and further the atoms) of air. At some point we'll lose our artistic vision getting overwhelmed by the chemistry and physics. Yet OOP taken at least to extremities might start to want to model and design every single thing which intuitively resembles an object into an encapsulated object, such as a grain of sand, or an air molecule, or even the atoms that make up that molecule, or a water droplet, and test them all in isolation when our main focus is to design sand castles. OOP tends to want to work towards bottom-up ways of design when the design of a sand castle might not benefit much business-wise from being decomposed no further than walls and pillars and roofs and the like. Another example is digital art. If we're painting a 16x16 ultra low-res sprite or tile, then it makes sense to place a lot of focus on the design of each and every pixel of that pixel art. That doesn't become overwhelming with a total of only 256 pixels. Yet if we're painting a 4000x4000 pixel image with 16 million pixels, it starts to become downright counter-productive and thoroughly overwhelming even to a single human brain, let alone a team, to focus on and test the design of each and every pixel as well as the relationship of every single pixel to every other pixel. OOP doesn't tend to prioritize where to focus our design efforts for interfaces, maintaining invariants, effective polymorphism, etc, this way against the complexity of our design/business requirements. It tends to want to design and model anything that sounds intuitively like an object, as a single pixel in above example, as an object complete with its own carefully-designed public interface and private state. It also wants to test everything that sounds like an object in isolation. And when our business requirements are very complicated, that can start to become counter-productive in comprehending what we're doing from a bird's-eye view. This isn't necessarily a criticism of object-oriented features but how object-oriented design tends to be tackled, especially when we start moving into SOLID and principles like DIP.
Actually C++11 has the `use` feature that you show. In C++ lambdas doesn't capture (see) all variables from enclosing scope, you need to declare them explicitly in capture list. Instead of writing `use a, b { }` you end up writing `[a, b] {...}()`. Example: `const int a = 2, b = 3; const int c = [a, b] { return a + b; }();`
@@pcfreak1992 I missed that someone already said this and re-posted >.< My reply is a little more long winded though. I verified that Java and Ruby can't do anything close to what you can express in C++.
Rust comes pretty close to the use block. All blocks in Rust are expressions that create a scope and all expressions evaluate to something, so the sub-scope and return behaviors are checked off. Sub-scopes do have access to their parent scopes, however, so the parameter-specific behavior is out of the question. You can still have that effect though, via the method you yourself mentioned: make a separate function. That said, I do think Rust gets like 1/4 of a point for this because all functions and closures automatically implement one of three traits (similar to typeclasses in Haskell) which tells you about the function's operation. This use block you suggest would be equivalent to calling a function bound to the Fn trait, which means it can be called repeatedly without mutating state or consuming/deallocating data. You could theoretically write code using type generic syntax which enforces this Fn bound and makes a use block... maybe.
I clicked on this video with skepticism because the video title is so "black and white". But unlike the title, the contents of the video is not so black & white. I think a lot of people who thumbs-down this video actually aren't watching the full thing. For your convenience, the 1st half-hour or so is all background and setup and analyzing the problems. He gets to his list of proposed best-practices (which are quite reasonable) at time index 34:46.
His evidence is anecdotal and many of the issues can be attributed to incompetent programmers as opposed to their paradigm. Also some of the advice is really bad and I hope I don't have to maintain code by people who took that advice to heart. Nested functions in favour of-you know- non-nested ones? Relying on comments? Like anyone writes those where they're needed. Properly named functions are the natural comments and make things more readable in the process. For the love of Zeus don't use large nested functions just because you "shouldn't be afraid of large functions". Give my scroll wheel a break.
It's hard to take anyone seriously when they start with this is the best video ever. It doesn't help when having decades of dealing with people who say that and you find out most of them are blowing smoke. It ruins any attempt at trying to make a change when he starts with a victory lap.
@@Kinglink He didn't say it's the best video ever. He says it's the most important programming video you are ever going to watch, and he's right. The fact of the matter is that the majority is not always right. Sometimes all of society can collectively make a mistake, and that's exactly what Java, and OOP was.
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.
"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.
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 appreciate your insight, this has allowed me to view my code from another perspective. Thank you for taking your time to express and share these ideas.
I can agree with most of the things you say in this video, except for the part about large functions. If you inline all code into large functions and just separate it by comments, you force me to read all this code or to constantly skip over it when I try to understand the higher-ranking logic of a function. The idea to split code into many small functions is that I don't have to read all that code unless I have to touch it for some reason and then I only need to read the code I want to touch. If the name of a function tells me exactly what this function does and I have no reason to assume that this function does not work correctly, I won't look at its code at all! Even if just called once in the entire program, why would I want a base64 decoder to be inline instead of having a call to "base64decode(...)"? I know that it does. Base64 data goes in, decoded data comes out, no need to see its code.
Yes, this. Using functions to spread apart your code can make it so much easier to read, when done correctly. Sure, if you're looking for a particular functionality, you will need to CTRL+F to find it. But if each function is longer than 5 lines of code, leafing through pages of functions to find exactly what the application is even _doing_ on the high level is annoying and inefficient. To add to this, you should NOT be afraid to make functions with long names, there is no real downside as long as it's smaller than ~10 words. A long and descriptive function name means that anyone who reads it knows exactly what it's doing, without needing to read some long extra sentence/paragraph in a comment. Abstract function names like "Build()" force a reviewer to actually look in multiple places to figure out exactly what the duck the code does. Both of these ideas complement each-other and lead to code that is both categorized neatly and quickly understood on the high level. However, you still need to use your own discretion on deciding what kinds of code to split up into functions like this. Sometimes it's just not worth it, as the video author describes.
@@LordOfLemon I don't have professional experience with coding yet so I might be wrong but I haven't seen situations that work better without separate functions outside smaller pieces of code. For a program that does multiple things, separating methods and commenting makes it much easier to read and understand. If you have an example of a long code where functions would be the worse option please do share
@@mistzzz4683 I also find myself disagreeing with the video's suggestion, but one place I prefer inlining is when the function in question is tiny, obvious, and only called in one or two places. For example, it's way less readable to see a call like "n = timesThree(n)" instead of just "n *= 3". I've seen real examples almost that bad. I love small functions, but at the point where the function name is just an English transcription of it's entire one-line body, I'm actually going to stop and read it because I'll be wondering what was so hard about this that you had to define a function.
@Mist zzz I have professional experience, and the answer is just that there are a lot of bad coders out there. I once spent an entire summer refactoring A SINGLE FUNCTION. It was thousands of lines long, and it meant I had to constantly delve deep into various levels of logic to understand the code. Some flows of code are long and complex. In this case it was the handling of a submission for a new user in a specific system. If you were A, you were gonna get Y and Z, if you were B, you were gonna get X. If you were C you were gonna get X and Z. And then with A B and C you were gonna do some common setup. Now, I was originally only going to add a new case D, but I couldn't. The code was so messy, I couldn't interject W into the code, because everything was mangled. That's why you want a function that describes what you're doing. submitForm() { createUser(); setupUser(); giveUserStuff(); sendOutMessagesToUser(); }. If I am going to give a new type of user new stuff, I need to change giveUserStuff() function. This is how you can see that you can drill down into the depth of complexity a lot better. Comments do not do this in the same way, because the code is still there. Good code is also comment enough. Show me what you're trying to do, then show me how you're doing it. Even when you're doing it, show me what you're drying to do, then show me at the deepest most complex level what you're doing. In my case, there was an API that was being used, so all over this original function, there were these extremely complex API-calls that were being set up in complex ways. Instead of saying giveUserASubscription(subscriptionType), there was a huge chunk that set up an API-call and just used the result. When it's my first time opening that code, I am not able to quickly scan that and ascertain that this part of the code is the API-call that's giving a user a subscription. I have to scan through low-level API-setup and see that the API call is something related to a subscription. That's why you first show what you're doing, THEN in a new function, show how you do that. That means that if I am giving the new userType D a new subscriptionType N, then I don't need to care about how you giveUserASubscription, I can just call giveUserASubscription(N). This means that it's not only good at showing you in coarse terms what the code is doing, you're also allowing me to not have to even relate to the lower levels of the code, if I don't need to. Say that later someone needs to implement a newer version of the API-call, then they can just find where all those API calls are used, and change how they're called. Then you don't need to relate to what you're trying to do. That's why abstracting code makes all tasks besides a complete rewrite a lot more easy. Maintaining code means that you should have to deal with as little as code as possible when you're doing a change. That way you lower cognitive load, which in turn means less chance of error. You also touch fewer lines of code, again making it less error-prone.
Yes. And smaller functions make the code better testable. If you have assumptions about the state of the relevant variables while entering a certain code block, and the desired result after passing it, it is testable if that code block has a name. Finding descriptive names, which make a longer comment superflous, is often time consuming but it teaches you in reflecting upon your code and what the parts of it do. If you are able to leave a helpfull comment, deriving a name from that should be possible.
"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.
7:56 You shouldn't take as a reliable guide a history of why (mainstream) OOP became mainstream which focuses on the rise of Java but (AFAICT) doesn't mention Smalltalk or C++ at all.
@Shailendra Nath I'd argue that if a function doesn't have a meaningful association with a data type and you're using OOP, then the mistake was using OOP for that task. That doesn't invalidate the paradigm, it just means it's not the holy grail. And to be clear, there is no holy grail. That's why these types of videos are always hilarious. They operate on the premise "this isn't useful for me, therefore it's wrong and can't be useful for anyone". The bottom line with OOP is that it isn't a set of specific patterns and techniques: it's an approach to object modeling. If the domain you're working in doesn't demand that kind of modeling, the fault is yours for selecting the wrong too. His video could have just as easily been titled "Hammers are bad and here's why."
@@nancykerrigan1335 I think your point is well taken, but actually this video is a bit more nuanced than you seem to give it credit for. I think Brian Wall would actually agree with you 100%, and that is why he suggests using some encapsulation, but simply at a higher level of granularity - around the module level, or around cases when the class (data+actions on that data) are actually logical. What he is suggesting is exactly what you suggest - its not the holy grail, and attempting to square every circle into OO will often create more problems than it solves.
I really don't see how huge functions with only comments to break up logic are any more readable and, more importantly, easily testable. I would much rather modular functions that can be separately tested and read quickly rather than just a huge column that I have to memorize the components of. Also why wouldn't you just put the same comments you suggest in your longer function before the function calls?
I watched the video with an open mind... but then he said we don't need functions, we need inline functions. No matter how "good" the code you write is, it will break at some point. I fear debugging an unnecessary inline functions as much as a dependency hierarchy that is too deep. Debug a 2000 line function and you'll see.
It’s more readable because the sections are lexically contiguous, instead of being scattered around the source file. Wanting modular, separately testable functions is really just wanting the unit tests to automatically localize any bugs that occur. If the large function fails its test, you still know something’s wrong with it, you just have to manually examine more code to find exactly what. Writing code so that its tests can localize bugs is optimizing for the wrong thing.
@@richardblain4783 The separation into smaller functions does not imply testing all the little functions separately. A module can be broken in 15-20 functions instead of a huge pile of 2000 spaghetti code, and still you would test the same behavior. I'm working on a pile of functions that are thousands of lines long, with no tests. I can not refactor because well, there are no tests for the big function either. The auto refactor failed because it is written in the 'C' style with 'goto cleanup;' instructions. If the programmers had split the code into smaller pieces it would be easier to reuse the logic AND to write unit tests for them step by step instead of testing a 1000 logic (which is way beyond my timeline). While I agree with most of the things said in this video I'm totally against having long 1000 lines functions
Also, I think longer functions makes the code harder to read because it implies that all the details are in one place. You start seeing things at a high level of abstraction. Ex "makePayment" entangled with ultra annoying details like a for loop over char*. You start reading code that is like 4 levels of abstraction in just 10 lines. which makes the cognitive load way higher than just see nice separated subroutines.
I was afraid that this video will just "hate all the classes, polymorphism, inheritance; everything should be done in pure C", but fortunately, I was wrong. Most important thing I noticed from this video: The definition of OOP I was taught (and probbaly many are, or at least think this way) is wrong. I guess most ppl think that OOP = classes + inheritance + polymorphism, while actually OOP = classes that react to each other in a very non-stanarized way (eg no parent-child tree). There is no problem with classes and inheritance themselves (in fact, I would rate them as one of the best mile-stoning features of programming), the problem lies how ppl use and comunicate acrosss objects of different type One Note: Windows API in C IS NOT a good example. That's not a C fault, that's the faut of the API authors that made the code full with abbreviations, macros etc. It's heavily void* flooded, and every C++ programmer will tell you not to use them unless neccessary Later you talk about features like memory management, exceptions while comparing C to Java. Why not C++? Wasn't it available in that time? Sure, C++ wasn't as good as it is now (and this could be the cause that ppl were very attracted to Java), but hey, this video is made in 2016, you should know that C++ has all these features too (exceptions, smart pointers - no GC, templates, cross-platform code) - this should be mentioned Overall I am impressed with the video 21:07 - Yes, thats a very good point. That's not a good idea how to use classes 21:20 is definietly as it should be 22:07 - I definietly agree. Most modern (not from 1990s) C++ tutorials I find recommend this way. 25:10 - Well, kinda common sense but true. Nothing is perfect 26:34 - That's how I start every project. Start with complete mess, a lot of refactoring multiple times, but over time the whole project goes based on better and better "class-tree-skeleton" untill no more refactoring is needed - and then, adding new feature to the program is simpe as f***, just add a method/child object and everything works perfectly 28:39 - well, as a C++ programmer I can be proud that I had never need to do a "do-er" class 34:05 - I'm happy that all tutorials I have used mentioned this tip - I definietly agree. A method is a method (not a free function) for a reason 35:10 - 38:52 - again, I agree with everything; I am wondering what are you really complaining about? Or I am just lucky that all projects/people I met use the proper pattern? 41:30 - C++ lambda expressions are exactly what you need/are talking about. They have even more functionality than you mentioned. And they exists already for 5 years
What I definietly agree - { } and ( ) are one of the most important programming language improvements. Today, I literally can't stand looking at code with words procedure, begin, end [somehow RUclips displays "unknown error" when trying to edit comment above]
I think you are just lucky to be working in the modern programming world when people are realizing that OO has much less value than promised and everyone is starting to look into functional approaches, which necessarily means more procedural ones. That, or you've been blessed to avoid OO fanatics through the dark times.
+flow in I give Sun credit for the things they did bring us. Java did have some improvements over C and C++ that really did help things. I think I blame whoever popularized C++ more than Sun; Sun was just following the times.
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.
I tried procedural programming a while back - I think I still have the punchcard decks in my attic. I find long subroutines annoyingly hard to navigate, so much scrolling. Yes, 10,000 subroutines of 10 lines is hard to deal with, but so is 1 subroutine of 100,000 lines.
This sounds more an indictment of lack of design than OOP. I programmed both procedural and OOP. Having learned OOP using Smalltalk and Lisp, by the time I learned C++ and Java, I came at OOP programming very differently than those who started with the latter. Harlan Mills repeatedly demonstrated the value of mathematically proven design, yet the business call for creating a prototypes eventually overwhelmed the idea in the industry. Agile methodology further allows the programmer to really skip design and figure the whole thing out later. Early Java libraries and even MFC went a bit overboard on the use of inheritance and that started to turn programmers off to the idea. Nowadays, I see more code written with a procedural ideal, but using objects. Component frameworks like Spring and entity frameworks like Hibernate helped feed the creation of discrete objects, instead of the OOP concepts that actual delivery the power. The fallacy of his argument is the "truth" that a strictly OO coded program is a tree with only descending communication. The whole concept is that any two objects can communicate, each deciding whether to respond or not. His arguments are what lead C++ to have friend methods. Encapsulation is broken for convenience.
+Bryon Lape , I agree with the video content and also with your comments. The idea of class instances containing references to other instances for communication is obsolete. In essence there is no need for a complex tree of instances that are limited in their ability to interact with other code. Because there is not a reference availble. The idea I used long time was to implement Runtime Contexts (thread, request, session, application instance, server side instance, cluster instance) which can be used by any class. So any piece of code can be easily accessed. Even a procedure (static function) might hide where the reference to the instance is stored for further retrieval. So omni directional communication is possible.
exactly Dad Bryon Lape - exactly. Except one thing I'll add is that a cyclical object graph driven by some reactive data bindings is an industry standard at this point. Formula for making this video: come up with the worst OO design possible, use this to criticize the whole paradigm, ignore all problems in your alternative suggestions, rinse and repeat.
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.
No one should say whether or jot you should use object-oriented programming. This isn't what you should be focussing on, anyway. What you should be focussing on is what's most important: actually solving the problem. Procederal does not actually self problems on its own, nor does, for that matter, Object-Oriented. They're both tools used to help solve problems. As long as you solved the problem, doesn't matter which one you've used otherwise. There's always advantages and disadvantages to using anything. For example, Onject-Oriented tends to lead onto a lot of bloat (especially when done wrong), while Procederal has a reputation for being incredibly complex as well as relatively insecure. Besides all of this, no one things naturally in terms of rules. This is why they tend to cause a lot of headaches. Rules are meant more as guidelines than anything serious. This is why people often say they're meant to be broken. Those who don't stick to Object Oriented completely? Them having the right idea; Those who try to stick completely are not only missing the point of Object-Oriented programming, but also all programming in general.
Tom Ashley I'm not going to refute anything you've said, since I don't really need to. All this useless squabbling is the same as fussing over the following of rules, which, in turn, misses the entire point of programming. It doesn't really matter which one you prefer; What only matters is actually solving the problem. Tools like Object-Oriented and Procederal are meant to be used whatever what their users intended. Heck, they can even follow the pure approaches, if they so choose. It all depends on their perceived needs. Besides, even if the video, itself, isn't so flawed in its arguments, that doesn't mean you'd be convincing many. It just means someone like me will come and try refuting your claims/
KarjamP Sure except that's a really spacious thing to say as the video isn't useless squabbling and isn't speaking to preferential trivialities. What matters isn't just that you've solved the problem. It also matters that you've solved it well. Otherwise, there would be no abstraction from the metal on up to speak of much less multiple abstract paradigms to program in and paradigms for how to program in them.
Tom Ashley Why are you trying to argue? Do you honestly expect me to be convinced with your words? People are stubbornnous by nature. Even if the facts they've been presented happen to be true, if they don't agree with it, they'll try to rationalize it away, even coming up with excuses, if so be it. This is what tends to happen when Cognititive Dissonance comes into play. In any case, I am not of the notions rules should actually be adhered to, or at least not as strictly as many one else. They are, after all, supposed to be mere guidelines. I believe this sort of attitude is actually what many professionals have as well, hens them using those workarounds in the first place. It was the kind of advocate that proclaims rules-as-absolute that chased me away from C++. Yeag, you should only use a subset, but many seem to believe I should be using features I might not want to use, and they're try to persuade me otherwise, if I were to show that code to the public, or otherwise ask for help.
"As long as you're able to solve the problem itself, it doesn't matter what you used and how you got there." I can't disagree more. Your code needs to be maintainable, which is almost more important than it working, because maintainable code will soon stop working too.
41:20: "I want an anonymous function that doesn't know anything about its enclosing scope, where you have to explicitly state what you want to pass to the function" Interestingly enough, this is precisely how C++ does anonymous functions.
I was looking through the comment section specifically to see if someone had already commented this. I also love how C++ gives you the option whether you want to be clean and manually specify what - if anything - you want to capture (e.g. [&xyz, abc]) or to decide that you don't really care (because you are e.g. just writing a prototype/small test case etc.) and simply want to capture everything ([=] and [&]). On the other hand, when writing lambda-heavy code, my #1 compiler error is "xyz has not been captured" xD
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
The problem you are really addressing is: misunderstood and wrongly used object-oriented programming. Just like in functional programming you can do really stupid and superfluous things. Programmers need to learn what's useful and what isn't, which is less obvious than you might think.
Myst I think you might have missed the point. What you said is correct, but not in context. what the author of the video states is : It is much easier to make mistakes when dealing with many programming idioms that OO presents, than it is with simple procedural languages. In fact, in my opinion, I would always favor languages that can fully be learnt in small time, than other languages which are hard to entirely grasp easily. One example to assess my discussion is C++ templates. Boost uses templates to bring some extra ordinary behaviour to its packages. Although powerful, they require a novice C++ developer to understand the source code of boost, and thus efficiently use it. Hope I added value here
37:15 (Long functions are fine!) Brian says that breaking functions up into smaller functions "Just Because" is wrong. That is right. However, he then goes on to say that long functions are fine. There are legitimate reasons to break a function up into smaller functions: 1. Re-usability 2. Modularity 3. You only want each function to accomplish 1 thing and nothing more
Reusability is a myth, anything reusable and modular is already in a reusable modular library. Functions can accomplish one thing while using multiple subfunctions, you dont have to make every function to lowest level possible, that would be absurd.
Fantastic. And brave. I started with BASIC and machine code (Z80) in the eighties. We knew freedom. I write apps for Android in Java these days. I hate Java.
I have my complaints about Java. For instance, not having unsigned primitives is almost a deal breaker to me. However, It has some amazing features that you can't get from other languages without convoluted workarounds.
I hate Java too. I was in a Java User's Group for a while in the 90s when it seemed like the language was changing every week. Then I found other there were other web programming languages like PHP which didn't require a half dozen XML files to write a Hello World.
21:30 I ran into this when writing a video editor in an object-oriented way: Timeline has a list of Track which has a list of Clip; if a clip wants to be created, the track does it automatically. But now if you only have access to the clip but want to remove it, the clip needs to access the track. It gets super messy and annoying having to manage the references, and also having to add error checking in case of a missing track reference (bug)
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..
1. pissing on OOP without actually presenting a TESTABLE alternative (no functions with 100s/1000s lines of code are not unit-testable) does not seem real live oriented. 2. your "alternative" basically copies OOP schemas,by creating "packages" or "namespaces" and encapsulate logic into anonymous functions, instead of creating objects, oh wow a /* this part of my function does y */comment is so much cleaner then a service class with a doc block and unit tests which can verify and describe the intendet behavior of the code. 3. global state is a problem in every language and programming style except fully functional programms. Actually using dependency injection vs. global variables or containers is debatable, but complaining about OOP because you have to use common ancestors to achieve functionality and then recommending parameterizing most of data in a procedual way actually leaves you with a call tree where the top branch has to pass dozens of parameters through multiple stages of your programm. But your solution to this is using global variables (which will polute global state) or writing large functions. The large functions are then poluted with a lot of local variables as you say, so you have to encapsulate them again with anonymous functions or namespaces. So you end up with the same problems as in OOP except: * your encapsulations have no clear API as you have local anonymous functions. * unit testing those encapsulations is not possible / very hard todo. * actually reading a 500-2000 line function with multiple local namespaces and anonymous functions is not as convenient as you say, atleast not for me. * refactoring is either hard because the call tree is gigantic and the passing of parameters has to be adjusted in multiple places or you have to refactor one giant function, again, with no way to verify regressions / bugs by using unit tests. So the real "benefits" I'm getting here are: * I don't have to think about naming stuff because it's hidden in one giant function. * I don't have to navigate through multiple files (which is very easy todo when using an ide or proper vim extensions) * I don't have to worry about unit tests, because I don't even have to bother writing them for functions with a n-path-complexity > 1.000.000 Also 44:00 - use block exists in php.
I used to write Structured programs in PL/1 and in COBOL, then moved on to NATURAL, and then Visual Basic and Java, and finally Python. I use Objects sometimes, inheritance rarely, parameterised calls often. MY overall perspective is that functions/procedures need not be tiny (a screen or less) and that larger functions/procedures can serve a system very well. The trouble is that many of the junior programmers leap into complex object hierarchies immediately and because one must work with a team and many members of the team will be recent graduates with almost nothing but OO languages at their command systems get stuck in the morass of huge object hierarchies. It is not easy to avoid.
The thing whit OOP is that you need to use Objects when they are supposed to be used. You shouldn't overdo it, but you shouldn't write a whole game in 2 classes either.
I'd say, learn Python. Program without objects for a while. Try objects when functions will not quite do what you need. Put emphasis on need. Objects are a fashion for many and lead to fashionable "design patterns" which often do not fit the problem one is seeking to solve. So resist the temptation to create complex object hierarchies when simple functions will suffice.
Python was my first language and I intend to return to Iron Python once I have enough experience with mainstream programming of Java and C# to accomplish my current goals. Kudos to you for your excellent tastes.
41:24 I think lambda expressions in C++11 can do exactly that. In order to use things from the enclosing scope you have to add them to the capture block.
In Rust, you can have anonymous functions that are called "closures", and they are allowed to capture the environment, or you can define a function block inside of your function and it isn't allowed to do that. This does require naming the function, but you do get the isolation of scope and return-safety.
Ahh the internet... the place where if you look hard enough you'll find someone who will agree with anything you can come up with. No one programming paradigm is perfect or suitable for all tasks. If you need raw performance speed you might use one paradigm, if you need to write a proprietary API you might use another; or you can do something in between. It is called "the right tool for the job".
performance rarely does come into it, cmpilers are smart enough these days that this doesnt matter unless you have a really hard problem and at that point no paradigm will save your ass from having to think
@@omniphage9391 Yeah, right. This is why you now need a 5ghz machine to run a web browser. Keep thinking "performance rarely comes into it" like the rest of industry, its worked great so far. Also, compilers are dumb as fuck. Try actually looking at some of the shit ASM they output. I would rather have a "stupid" compiler from the 90s literally any day over the BS compilers pass themselves off for these days. At least then I am not spending 95% of my time stressing over weather or not what I am writing is "undefined behavior" or not.
@@omniphage9391 I am also very confused at both of your replies because they both have nothing to do with what I was originally talking about. Undefined behavior is when you tell the compiler to do one thing and it does something entirely different. The code compiles, it executes, but its not guaranteed to do what you tell it to do. Modern smart compilers don't actually listen to you, which is the problem. They take what you tell them and consider it a "lose guideline" then output something that's often entirely different than what you tell them to do, and sometimes with an entirely different result or behavior. Thus, these days you are always trying to avoid doing something that will make the compiler shit itself rather than just focusing on getting the job done in an optimal manner. I don't want to have to trick the compiler into doing what I want it to do, I just want it to do what I tell it and not have it second guess me and think it knows better.
Maybe I haven't spent enough time looking at other people's code bases, but I've never seen anyone code like his OOP examples. And everything he said in the end about how to program better is exactly what I was taught to do with Java since day one of high school programming, 14 years ago. Have I missed something somewhere?
@Andrew Onymous I think this video does make sense though, he's saying use classes and objects when there is clear ties between the data and methods (e.g. queues), but dont design an entire application around classes and objects. If he's tips are things you already do then congrats, that means you are likely writing more readable code
@@ConnorForbes25 Okay, but then it's not an indictment against OOP programming. This video should've been titled "over-compartmentalization is bad and here's why" or some shit.
Once in a while I come back to this vid. Now, since the last time I understood some things I've never read in any tutorial before. Most of the OOP basics have nothing to do with programming, they crop up everywhere in engineering. When designing a complex system, you basically divide the big system into sub-systems fit for one task. When making the layout of the whole in this way, you forget about the implementation of the sub-systems - you use an ABSTRACTION. Of course, the sub-systems can interfere with each other, you need to separate them & make self-contained - you need ENCAPSULATION. But then your systems must communicate somehow to achieve anything, so you define some common interfaces between them - for example, communication protocols, electric signal characteristics, etc. After this, you can simply play some LEGO with your building blocks. When there are different similar components implementing (mostly) the same interface - you can swap them and do not have to redesign everything else - you have POLYMORPHISM. Inheritance, in the other hand, arises naturally when you try to apply those in programming - you reuse code. KISS & DRY are just common engineering-wisdom that help you keep your sanity. YAGNI refers to the habit of being greedy on features we don't really need. Most of those just arise naturally when you face bigger & more complex problems and try to conquer it. Design patters, on the other hand, are mostly a workaround on fully-OOP design - the need of an object to do anything. Small systems rarely need any, and most of them arise kind of naturally when trying to solve bigger problems. Still, I get some of your points. OOP is often badly-taught, can be abused, and not fit for everything - especially very small programs. It's just a tool that can be quite useful...
Thanks! Definitely a tool, and there are systems for which I would definitely would not go back to procedural and imperative programming. Yes, it can be done, but it would be way more difficult.
its all theory. Just like SOLID, sounds like great idea, but every time I read something like this I have feeling that author never wrote real world application, more complex than some foo bar example from msdn docs. Encapsulation have another assumption/big lie - there was good blog or vid about it I cant remember source but general message is that you can never trust other object, and in real world you have to know HOW it works, and encapsulation assumes that it shoulodn't interest you because it's 'private' part, or 'inner working' of that object - and thats just theoretical nonsesne that doesn't apply to real world AT ALL. ;
@@Angry-Lynx I do not agree. Separation of implementations is pretty darn useful. What would you do if a 0day junior dev wrote a module that logs some values and also modifies the database randomly? You need to protect your system from effects like those - and a way for this is a language mechanism that forbids the modification of some values by everyone else. Also, do you know the internal working of everything you ever used? Do you know how your HTTP libaray processes requests, and how does SSL encrypt your data? No? That'd mean you do not know their intenal workings! You only care about their interface, and NOT their implementations! Here's encapsulation and abstraction for you!
@@HA7DN medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 Good read, especially conclusion about oo lies in classes and tutorials. I dont think oop is bad in general. But those theoretical 'promises' of patterns like solid and perfect encapsulation are toxic because they are big stinky lies we were all told when we were learning oop, just to be burned badly and realize that real world coding isnt as simple and pure and so on as Cat : Animal 😁😂 Again encapsulation itself isnt bad, its just general consensus about it is a dream-land/eden nothing more, because in real program classes are never 'really' encapsulated. Its about honesty in the end. Or rather lack of it should i say;
@@Angry-Lynx Thanks for the interesting read! I can not agree with everything it this article - like complaining about the performance hit of something I can not undersand why he says we need, but than saying functional is better, but I have to agree with him on one thing: blindly following tutorials & paradignms is anything but good. Don't ever make design decisions ONKY based on what somebady said on the interned. Sit down and think about how YOU think it'd be better. Later you can refactor! Now, I've been studying functional programming for a bit now. I'd never call myself an expert, as I only know the very basics (no mutable variables, no sideeffects, pure functions), but all of those already have a few bad effects. No mutable variables are a HUUUGE disaster in terms of performance, especially if you want to modify arrays. Of course fancy workarounds DO exist but then you critisized OOP for needing workarounds. (the only difference is that in functional, usually the language hides those workarounds from you). Side-effect free functions... Yea, how do you do anything, like IO, network, displaying images or beeping without those? You simply can't. You NEED side-effects, and next you have to use fancy workarounds like monads and other stuff just to do this in the functional way. Or you just say "I mostly program in a functional style" and just give up you fancy paradignm when it becomes inconvinient - and that's what you should do if you can! Look at everything as it's a tool!
8 years since this masterpiece. I’ve progressed with simple procedural code to the point where I physically cringe reading others peoples OOP code labyrinths
I know how to use a chef's knife, I have a chef's knife, so I should never use a butter knife, because everyone uses butter knives. It seems to me like that's what your argument amounts to. I'll use a chef's knife when it's appropriate to use a chef's knife, and I'll use a butter knife when it's appropriate to use a butter knife. If you overcomplicate your use of a system, that's not the fault of the system - it's the same trap Hilbert fell into: you can't define literally everything, some things have to be left open to interpretation and intuition, or else you're going to end up contradicting yourself.
NOBODY should ever use a table saw to cut vegetables, is his argument. He was arguing that OO programming is ineffective at its goals whether used as intended or not used as intended, thus unlike a butter knife that has things it's best at, if his argument is correct, then there just wouldn't be any proper programming use of OO at all / it wouldn't be best at anything, thus the analogy should be something totally not belonging in the kitchen in the first place, even if it could feasibly do the job, badly and awkwardly.
In what way does he misrepresent? Claims seemed accurate from my coding background, but I'm a researcher who just uses code, not a guy who has degrees in it by itself.
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.
"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.
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.
“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.
As long as you don’t abandon structuring in lieu of working code later on 😐
@@life_score Indeed. That’s why it’s “Start with a free form structure” and not “Only use a free form structure”.
@@atalhlla yeah, but that usually ends up being a trap. Most people don’t take time to improve code once it’s in working condition!
given that requirements are always changing, a free form approach is more appropriate. If you start out with a rigid plan/structure you are in fact doing waterfall.
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
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.
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!
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.' 😂
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?
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
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.
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.
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
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.
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.
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 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.
41:49
auto foo = [x, y]() {
// Code here
};
lambda in C++
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?
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
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? 😨
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.
OOP is wonderful for large codebases. I have worked far too long on the IBM iSeries platform with its go-tos, and top-down programming. It doesn't work. It's nearly impossible to upgrade codebases that are gigantic and written top down quickly, and they're insanely error prone.
Local versus global variables and isolating data in OPP makes life SO MUCH BETTER. I feel like you haven't ever worked on a gigantic codebase.
This is true, and i also feel like this video has nothing to do with areas of coding that arent database/website associated. Like simulations, or even game dev, where you dont need all data to be stored or returned somewhere. In that context youre not just "performing an action on data", youre using objects to capture behaviours, and having them split into classes with encapsulation allows that process to make sense, without ending up with a script thats 20000 lines of code.
Entity-Component DOTS style coding is often a better choice, but its readability is atrocious compared to OOP, and thats important for quick testing and turn around times.
The idea that a style as useful, flexible and readable as OOP is just blanket "bad", is really more just an admission that you dont know when to use it, or how to use it.
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. ;-)
42:51 C++:
int a = [x,y]() -> (int) {
..
return 3;
} ();
It does exactly what you are looking for..
;) ...
and javascript:
var a = 3, b = 4;
var c = function(d, e){
return d + e;
}(a, b);
console.log(c);
php also...
@@zegarek840525 Even easier in ES 6 with a pointer function!
In C++14, you don't even have to specify the return type yourself :)
He was saying that the inner scope should not be able to access any data that's not explicitly passed in to it. This would let the reader temporarily forget all about any variable which is not immediately necessary for the next logical step. I don't know about c++ but local anonymous functions / closures in both php and js are not restricted in this way.
He also mentions that the data is always passed by copy - not by reference - ensuring immutability.
@@zegarek840525 No... You have the outside scope inside the function and thus not the same thing. Did you even watch the video?
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.
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
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.
When you only have a hammer, then everything looks like a nail right?
That’s why as programmers we should have a range of tools. Hammers have their uses
@@justgame5508 That's one of the reasons why I like C++, it's the whole toolbox of paradigms.
Even if there are a couple weird dangerous tools in there that can prick your fingers (i.e. placement new), it's still nice to have 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.
@fetherfulbiped No. Nononononono no. You have it COMPLETELY backwards.
It is infinitely easier to debug procedural code and reason about it when it is right there inlined for you. And figuring out a codebase is made HARDER by fragmentation it into 10,000 little pieces scattered everywhere. Your coworker can just as easily use a FUNCTION over some class with a built in method.
Procedural programming doesn’t mean write everything in a single function. You can still build single responsibility functions and test them.
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?
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.
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.
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.
No, some tools really are garbage.
There is a programming tool that, when used incorrectly, causes compiling errors (and the code won't compile). No damage then. When used correctly, causes the debugger to be practically useless. Have you tried it? And yes, it is FP :-).
And the problem is there are too many purist that do exactly what you say it should not be done. I know a programmer and even have to work with that instead of making a single switch with 5 different settings will make 6 factories that will contain 15 classes to do it. If you are doing that just for a single switch you are bad on the head and heavily. And the switch on itself has only 1 or 2 lines of code. If you say "that is hard to read" trully cannot understand how compared to a total of 21 clases.
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
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.
the “use” block is a c++ lambda
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!
This is exactly how I do OOP... in Haskell.
Agreed. In some domains there are natural relations between data and methods that are never going to change, so objects work well here. In others there are cross-cutting concerns, so standalone data structures and functions work better. It's not really so difficult if you take a pragmatic, undogmatic approach.
All my apps end up with modules that contain objects, standalone data structures, and libraries of functions. Works for me.
Seems to me that it's not objects that are the issue - they have their legitimate uses. It's dogmatic OO thinking that attempts to force every domain into the OO paradigm.
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.
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
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
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.
That is the main problem the OOP programmers just use 80% time to refactor and only 20% (or less) of the time to make the program how can they not take 5 times more?
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
I watched the entire video and while it made me think I still can’t agree with the premise. To me a well thought out and designed OO program is easy to work on (whether you were the original programmer or not) and to extend. In my experience, the nightmares arise from programs that started as one thing and grew to something else or worse they were extended by a programmer who took shortcuts and no longer adhered to the original OO design. I’ve worked with both well designed OO and procedural programs and in my experience I have always found it so much easier and enjoyable if it’s OO.
Code debt makes all issues clear.
What I like to do, is to basically fuck around and make some prototype , and then if I have the time, I draw up some random chart on how stuff is supposed to relate to eachother, and then organize it like that. It helps to be off a few adderal pills while at it.
Im programming for fun, so i dont really know any of these industry level knowledge. Maybe people do that.
By that logic alone however, OO is difficult to extend because adhering to the original design plan while extending it in a meaningful way is exceedingly difficult.
"programs that start as one thing and grew to something else" pretty much describes every piece of commercial code ever written :-)
@@CyrilCommando good luck changing thousands of lines of procedural code to a new design when it relies on the whole sequence of operations being maintained in an arbitrary order, otherwise your global state goes out of sync.
What you'll have to do is rewrite the whole program.
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.
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.
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.
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.
29:35 - Oh yes. I am yet to encounter an introduction to OOP with real world example, solving a real problem rather than being a 2d shape, animal or furniture.
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.
lol, idiots trying to run from state, must be in a state of fear
@TheJacrespo Uhhh- no? If your buffer is 256 bytes long and the user inputs 300 bytes, just increase the size of the buffer at runtime.
This is how it is ALWAYS done- the difference is that OOP incurs a heavy performance cost by doing that stuff under the hood to account for all general cases. The garbage collector for example…
In the end, it all comes down to error handling. Monads do this at the expense of performance and cognitive overhead. I've always preferred simpler pragmatic approaches, and they seem to get the job done.
16:37 "What is the one abstraction bigger than a function and bigger than a data type?" Mathematical categories, of course.
They provide an even higher level of abstraction than objects in OOP, since they are able to describe more than one object, and they remove the need to play the responsibility game that is referenced at 27:22. They can be most commonly implemented in software as a collection of data structures and a collection of pure functions that map between the data structures, with the additional constraint that functions are associative and data structures have some concept of persistent self-equality (so that there is a "do nothing" or "identity" operation that lets you leave a data structure alone without it changing its nature). This by itself is enough to meet the formal definition.
You could implement categories as namespaces or as class constructs within code. Implementing a category using a namespace construct allows greater reuse across software projects, since homsets within the category can be stored within separate files. Since a homset captures a very small, perhaps even atomic aspect of interdependency, moving a single file across software projects will need only require importing the minimal set of other files needed to support it.
If a category is implemented using a class construct, then there are many concepts within category theory that can be used to precisely describe many of the aspects of Object Oriented Programming that people actually like. For instance, categories often require other categories so that their behavior can be implemented. The categories that are used to implement another category can be tracked as dependencies passed to a constructor, which itself forms a category of categories, where objects are categories and arrows are constructors. This is similar to the way OOP makes use of dependency injection. In another example, certain kinds of functors within category theory can also be implemented using inheritance and interfaces.
A design approach based around categories shows many of the positive attributes that people have found with OOP (dependency injection, code reuse, programming to interfaces) while eliminating many of the problematic attributes (state obscuration, state management, the banana-jungle problem), and it is based on a solid mathematical foundation that OOP lacks, which removes the need to discuss what it is we're even talking about, as is done for OOP starting at 1:01. The approach can be considered consistent with the "object oriented & functional" design approach mentioned at 6:12.
I'm going to need a reminder to read this reply in full...
@@nullpoint3346 same
@@nullpoint3346 yeah
@@nullpoint3346 I hereby remind you
There seems to be a good reason why the term "abstract nonsense" is used about mathematical methods used with category theory...
I just wonder how it is expected that the average Joe Coder - who may barely have grasped recursion as he drifted from HTML, CSS and copypasting and hacking JS by trial and error, to doing a little backend programming in Php - will understand category theory, and to what extent he should be expected to understand it?
The complaints are valid but I can't agree with all the suggested fixes.
This is the story of humanity
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.
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?
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.
1) in my university they tought us, that classes called -manager, -service, -handler, x-er and so on are considered to be bad for the reasons that you mentioned. They are actually bad practice and no contradiction to the use of the oop paradigm.
2) the "use" keyword that you suggested is basically the semantic of lambda expressions in pure functional languages like Haskell
3)even though you tried to give ideas, how to solve the problems instead, you did not give very concrete solutions. One main reason to impose a structure using oop is to avoid "spaghetti code", where everything is connected to everything and it is not really obvious what functions are called from what scope.
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)...
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.
41:00 This is exactly how C++ implements lambdas :)
Yes.
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
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.
Domain Driven Design (DDD) addresses--and in my opinion eradicates--all the issues described. Now DDD is language agnostic, although Evans himself points out that OO languages are usually better suited for it. I think the issue is that most people confuse the paradigm of OOP (which has matured over the years) with Java's implementation of it.
Now first I want to say I think this video makes excellent points about some of the shortcomings of old OOP paradigms, although I think the title of this video should be "Strict Encapsulation is Bad." There are, however, some points I think need to be addressed. (I've addressed test driven design in another comment).
1.) The analogy of the over-architected house is (pretty much by definition) describing a poorly planned application. He mentions walls that were prematurely established, but this is a planning flaw and not directly related to OOP. I could argue that procedural code is like a winding country road, it just randomly weaves and has no coherent sense of an actual destination. This is not a flaw with procedural programming, this is just poorly planned code.
2.) He states early on that he will ignore inheritance--rightly so--because even OO programmers warn against it. He then later references complex hierarchy graphs, which are due to inheritance. The modern approach to OOP is much more focused on dependency injection and interfaces. As far as complexity goes, the relations between objects in well designed software are only as complex as the domain requires. Any other complexity is almost certainly due to poor design choices and not the paradigm itself.
3.) "In procedural code there is only the call graph." I think this is very misleading because, in a complex domain, the call graph will only be decipherable by the software designers/engineers themselves. It is very unlikely that an "outsider" would understand the call graph outside the context of the software itself. This is why OOP is such a great tool for complex business domains. I worked on a healthcare application and one of the most valuable aspects of our design was that we could use the same graphs and flowcharts our developers were using to discuss the application with doctors (the domain experts). There was no intermediate translation needed to describe the business logic (interactions between objects) to the people who were actually in charge of implementing it (the developers). This is the point behind DDD's ubiquitous language.
4.) There definitely is a need for functionality that lives outside of objects. Anonymous functions now exist in most languages, as mentioned in many other comments. I would only like to add that creating a "container" for these functions is very much like a namespace and can actually be helpful in describing the context of certain functions and grouping them together in ways that are self-documenting.
5.) Abstraction is a term that has a specific meaning in computer science: it refers to the level at which the actual inner-workings of the computer itself are hidden from the client/programmer. For example, even a simple expression like "int y = x + 5;" is an abstraction that hides some of the implementation details (allocate a memory slot for an integer, add the value in the x memory slot with 5 and store it in the allocated memory). The abstraction of OOP is described properly in this video as "simplified interface over complex inner workings." But this is a GREAT thing! This means once an algorithm (business logic) is perfected (using test driven design) it can then be abstracted to an easier to understand concept. I'll concede that factory--and builder to a lesser extent--patterns can be sometimes hard to understand, but they are actually not meant to abstract away complexity; rather they are meant to enforce constraints. This may be unneeded complexity in small, data-driven domains with a small development team, but it is very helpful in larger teams dealing with complex domains as these patterns enforce constraints with public interfaces while hiding implementation details that only matter to the people working in that subdomain. This is similar to a business that contains forms for certain requests. The person filling out the form does not need to understand the details about how the information on the form is used, they just need to be able to fill out the form. Now, as mentioned in the video, it is definitely difficult to abstract away implementation details to the point that it can be described using real world concepts, but this is just the difficult nature of software design, not a shortcoming of OOP. This is analogous to saying it's hard to abstract away the mathematical complexity of structural mechanics, and therefore CAD software should just have the user input the center of mass and moment of inertia themselves. Abstractions and generality are probably the hardest things to master in computer science, but they are also extremely valuable when done correctly.
6.) Modularization is a great thing no matter what paradigm you use. Setting boundaries between responsibilities of your code minimizes the domino effect a change can have. The "fractionality" mentioned is actually a benefit in the long run. If you contain a big chunk of seemingly related functionality all in one place (rather than split it into smaller pieces), it becomes more likely that a small change in that big piece will bring the whole structure down. This idea of strict separation of responsibility is so fundamental to good design that you now have some of the greatest minds in software architecture (Martin Fowler, Chris Richardson, etc) focused on perfecting the microservice pattern.
7.) Lastly, "The kingdom of nouns" is no better than the kingdom of verbs that is procedural programming. The idea behind objects is that most verbs are attached to a noun--a doer if you will--or at least relate two objects together. For example, take the question posed in the video "should a message send itself?" No, a message service should send it, which describes the real world perfectly (be that the postal service, an email server, etc). I don't see what's so abstract or hard to understand about that. So the idea that OOP doesn't have verbs is utterly false, but I could argue that nouns are better described in OOP than they are in procedural code.
Now I will concede that OOP is not always the right choice and I think this video addresses the issue of people always using OOP because that's what Java was designed to implement. It is often overkill for simple data-driven applications. But OOP is absolutely necessary for complex business domains. When the application becomes very difficult to reason about using basic control flow, it helps to construct objects that represent actual domain entities and then hide all the programming minutiae inside methods that represent actual business logic. It is also very beneficial when working with a large team to define public interfaces for objects and then delegate management of more detailed functionality to smaller teams that are able to master the concepts of their specific subdomain. This is similar to how every major business operates: your sales team is not responsible for accounting. They may at times need to interact with the accounting team, but there is no need for them to understand every detail of how the accounting department operates. The problem with procedural code when it comes to complex domains is that the entire team typically needs to understand the codebase in more detail. Most of the points in this video seem to pertain to a small codebase with functionality that is easily described using the basic control flow operations that have been around almost as long as computers. But this simplicity of design often breaks down once more complex logic is needed.
Again, I want to say that this video makes some very good points about possible pitfalls in using OOP, but there are ways to avoid these pitfalls and it all comes down to taking the time to understand the problem (or domain) in great detail and carefully planning the structure of the application. If you don't want to put forth the effort to properly design the application then OOP will certainly fail you in all the ways mentioned in this video. If you're the kind of developer who gets an idea and wants to sit down and start coding immediately then OOP is not for you. But if you decide to take the time to apply an iterative, test-driven design process then OOP will reward you with a self-documenting, easy-to-understand, maintainable, and extensible codebase.
I also rue the epidemic incessant resistance to objective domain analysis that is occurring pandemically throughout humanity.
You can see it in other areas of life too. Indeed more so!
Money supply, politics, history, "education", mass media and blind acceptances of sinister, ever growing bureaucracies are the first examples that come to mind outside of engineering.
I feel like you missed some of the points. The problem with OOP is that most verbs are meant to attach to a noun. In the message example, a new coder doesn't know which class to check when it comes to finding out where messages are sent. Imagine you have the following classes: Message, Connection, MessageReader the new coder has no idea where to look exactly and any public methods in these classes will make them paranoid about side effects.
In procedural you can still have namespaces/static classes/whatever to organize where the functions live. So now imagine you just have a "Messages" namespace. All actual business logic for messages is contained in this class. It has a function like "SendMessage(Connection, MessageReader, Message)". Bam you instantly know exactly what it's doing just from the parameters it takes. That's the FREEDOM of procedural. With Nouns (usually data) and verbs(business logic) you can now arbitrarily combine the nouns together with arbitrary verbs!
Also if you like modularity pure Functions are THE MOST MODULAR thing in existence. In the above example SendMessage is pretty much a stand alone function (though not pure). But compared to OOP it way more modular. Someone could have programmed this so that it has a constructor Message(Connection). Now EVERY SINGLE METHOD in Message, might be using connection who the hell knows? That aint modular. Worse case it could be EDITING STATE in Connection. In the procedural example you know only that one SendMessage function could possibly be editing Connection.
Lastly you can get all the same benefits you brought up with things like "business people readable flow charts" and have easy to follow call-graphs if you just name space and limit scope properly. Which is EASIER to do without OOP than with OOP because of the annoying noun.verb limitations.
@@sharp7j I don't understand how this is better than something like MessageService.Send(message)
And as far as modularity goes, then you have a lot of options, like
MessageService.SetConnection(connection).SendMessage(message)
MessageService.SendTo(message, connection)
MessageService.Send(message).To(connection)
I'm also unclear as to the advantage of namespaces over static classes. And to be clear, I'm not an OOP fanatic. I use different paradigms in different scenarios and often find procedural to be the right choice for smaller applications. But it's rather dogmatic to argue that procedural code is always better than OOP. In large-scale applications, I think the encapsulation and expressiveness of OOP can be extremely valuable. The price you pay for this, as this video lays out, is that you have to be careful how you use it. But this video just lays out a bunch of problems that have been addressed (again, Domain Driven Design is a great book on this topic) and then asserts that procedural code must be the answer because OOP has flaws. I love programming in plain old C, but it's not the right choice for every project. I love messing around with functional languages like Haskell, but again it's not the right paradigm for every problem. OOP isn't the only way to code, but it is certainly a valid paradigm which is why Microsoft continues to put a lot of effort into maintaining C# (which is what a good OOP language looks like).
@@sharp7j Your example here is really nonsensical. Speaking just from an object modeling perspective, you've reversed the relationships between Message and Connection. Connections send Messages. Messages don't send themselves. Seeing Connection in a constructor for Message is an immediate code smell. If I ran across that in a code review I'd know immediately the developer didn't understand what they were doing. Whether your favor procedural code or OOP, single responsibility principals still apply. It's just as much a mistake for SendMessage to modify Connection's state as it is for Message to do so.
I'm likewise perplexed where you get the notion that a procedural approach would give you a guarantee that only a given function could be responsible for modifying the state of a data structure since that structure could be passed to any number of functions any number of times. You'd have the same problem with each call to SendMessage as you would to each new Message the Connection was passed to. All you've demonstrated is that poor engineering can be carried out by anyone.
I had the same feeling watching nthis video.
@20:55 "Where in the system of 10 objects all sharing the state is the coordination?"
In the object that holds that state, and in the class that defines all valid state changes for that object. Each object is responsible for its own state, regardless of how many other objects have access to that state.
I find myself disagreeing with some of your arguments, but you are forcing me to think deeply. And I also appreciate your clear definitions of terms.
There tend to be complicated cross-cutting concerns across shared, mutable objects in many circumstances. A simple example is a traffic light and a car. These could be two separate objects but, for correct/desirable behavior, cars should not cross the road when the light turns red. Now you have a cross-cutting design concern which requires you to look at the interaction of the objects, and not just the objects themselves, to reason about correctness. Even if you unit test the traffic light thoroughly, and unit test the car thoroughly, and they both pass their tests, they could be used incorrectly together. A recurring one that's similar is race conditions (including deadlocks) when objects are used in the wrong order across threads.
Functional programming eliminates this completely by avoiding shared, mutable state. Procedural programming can sometimes simplify things a lot more than OOP by centralizing the mutations to shared state to the minimal number of functions instead of branching all over the place between complex object interactions.
@@darkengine5931 A 'traffic light' problem like this is an inherently stateful problem that involves interactions between multiple objects in the real world, so of course you'd have to have this interactions replicated in code if you wanted your program to work correctly. The trick is to establish these object relationships in a way that makes sense. If you're deciding whether or not a car should go or not, a car should have knowledge of what road it's on, you should be able to easily tell how far away the next traffic light is, what color it is, what other roads connect to the intersection, how many lanes those roads have, you should be able to tell what other cars are at, or are nearing, the intersection, what speed they are going, whether they have their turn signals on, etc. Trying to avoid complex relationships between objects when modeling a problem where those complexities exist in the real world, is futile, and trying to model a problem like that without objects is going to quickly turn into a tangled mess.
@@aliengenie8896 The difficulty I've found in my experience as a gamedev dealing with such simulations of the real world is that if we have so many stateful, mutable objects, we have a great deal of shared, mutable state. Even the most enthusiastic object-oriented designers understand, if they deal heavily with multithreading, the difficulty that shared, mutable state imposes on reasoning about the correctness of systems in multithreading contexts.
>> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible. -- John Carmack
Yet I would suggest such thread-safety concerns that arise from shared, mutable state are just one example in the broad category of integration hell where code that works fine in a single-threaded context, when integrated in a multithreaded context, fails unexpectedly due to data races.
One common problem teams can encounter if they design codebases that consist of so many stateful, mutable objects is that their unit tests pass but they can still be plagued by edge cases that only reveal themselves in the context of integration. I've started to see many object-oriented developers starting to make arguments that integration tests provide more business value than than unit tests as a result.
Yet embracing a more functional style eliminates integration hell almost entirely in all forms since it largely eliminates mutable state. An alternative that doesn't do quite as thorough of a job as functional is the ECS. The ECS tends to take on a more procedural design breaking encapsulation, but it tends to avoid the integration hell problems that can manifest in lots of heavily object-oriented systems by reducing the design to a handful of systems that transform data which are extremely explicit about exactly what data they transform. They don't eliminate shared, mutable state but they make it extremely clear and explicit exactly what is mutated and when/where.
@@aliengenie8896 Allow me to try another angle as well focusing on the tangled mess you mentioned.
Hopefully both of us have seen at least some of the worse cases of object-oriented design to see that OOP is not immune to producing a tangled mess where we can no longer effectively predict what would happen by merely looking at individual things without getting loss in a tangled mess of other things through their complex and tangled relationships, and/or change something to suit a new design requirement cleanly without changing everything else involved in this tangled design mess.
The first and foremost metric easiest to measure and address to untangle object-oriented designs is coupling. If we seek to decouple objects further (either loosening their coupling or completely decoupling them), our tangled designs start to become less tangled. When we can effectively produce the most independent object designs not interdependent on one another and without becoming too leaky in their abstractions, that's when I'd say OOP produces the maximum value for the buck as it avoids producing a tangled, highly-interdependent mess, with self-contained invariants easy to guarantee and maintain. That's when we get the maximum benefits of predictability, modularity, reusability, and I'm totally aligned with OO enthusiasts in utilizing encapsulated objects in these cases.
The problem I see is that as we work towards higher-level design requirements in a sufficiently complex simulation of the real-world (which tends to involve so many cross-cutting concerns as Brian calls it), we can't help but produce tangled messes if we favor at least an eager or even purist style of object-oriented design.
This is because the very nature of encapsulating state and methods that can exclusively access that state together tends to result in something we might analogically describe as a thousand teeny islands that give the illusion of being easy to comprehend in ways that provide a lot of business value. Yet they don't actually provide much business value on their own and end up having the most tangled and convoluted trade routes in between them, and we find too little valuable information to be comprehended and predicted as far as comprehending business/design requirements by looking at each individual island without fully comprehending the convoluted and tangled trade routes in between them.
When the analogical trade routes in the above example become the ultimate source of tangled complexity and misunderstandings which makes things difficult to predictability change, and in isolation without changing surrounding things, the only scenario to further decouple and simplify such designs and untangle them is to start abandoning OOP on a small scale in favor of what John Carmack calls "medium-weight" to "heavyweight" encapsulated objects, and that's precisely what he did in the final stages before he largely abandoned object-oriented design all together in favor of functional programming which provides maximum comprehensibility, predictability, reusability, modularity, but largely eliminating mutable state outright and achieving the highest degrees of decoupling.
He was doing the metaphorical equivalent of coalescing these teeny islands into larger landmasses whose individual requirements become a bit more complex to understand on their own, but whose trade routes between islands become substantially simplified. It's a decoupling mindset as well as a testability mindset (a small object which provides very little business value on its own provides very little business value in passing its unit tests regardless of the coverage). The analogical "TrafficLight", "Pedestrian", "Road", "Sidewalk", "Car", etc, turn into simple bundles of state whose traffic-oriented functions might move into something we might organize and bundle into "TrafficSystem". That is also what the ECS, as becoming increasingly favored for modern game engines, does. It would turn something like "TrafficLight" into a simple data-oriented component that bundles state but not its functions together.
@@aliengenie8896 If you'll forgive yet a third way of analyzing this which moves away from the most technical, we can focus on design in general. As beings of limited intellect and comprehension, and whose comprehension and capabilities for misunderstanding and miscommunication multiply with more team members between us and more lines of code, we tend to want sufficiently "meaty" designs to simplify our comprehension and communication.
If our goal is to build a sand castle and focus on the artistry behind it, we will start to lose our way if we become obsessed with the functions of each individual grain of sand in producing that castle, or each individual drop of water, or each molecule (and further the atoms) of air. At some point we'll lose our artistic vision getting overwhelmed by the chemistry and physics. Yet OOP taken at least to extremities might start to want to model and design every single thing which intuitively resembles an object into an encapsulated object, such as a grain of sand, or an air molecule, or even the atoms that make up that molecule, or a water droplet, and test them all in isolation when our main focus is to design sand castles. OOP tends to want to work towards bottom-up ways of design when the design of a sand castle might not benefit much business-wise from being decomposed no further than walls and pillars and roofs and the like.
Another example is digital art. If we're painting a 16x16 ultra low-res sprite or tile, then it makes sense to place a lot of focus on the design of each and every pixel of that pixel art. That doesn't become overwhelming with a total of only 256 pixels. Yet if we're painting a 4000x4000 pixel image with 16 million pixels, it starts to become downright counter-productive and thoroughly overwhelming even to a single human brain, let alone a team, to focus on and test the design of each and every pixel as well as the relationship of every single pixel to every other pixel.
OOP doesn't tend to prioritize where to focus our design efforts for interfaces, maintaining invariants, effective polymorphism, etc, this way against the complexity of our design/business requirements. It tends to want to design and model anything that sounds intuitively like an object, as a single pixel in above example, as an object complete with its own carefully-designed public interface and private state. It also wants to test everything that sounds like an object in isolation. And when our business requirements are very complicated, that can start to become counter-productive in comprehending what we're doing from a bird's-eye view. This isn't necessarily a criticism of object-oriented features but how object-oriented design tends to be tackled, especially when we start moving into SOLID and principles like DIP.
Actually C++11 has the `use` feature that you show. In C++ lambdas doesn't capture (see) all variables from enclosing scope, you need to declare them explicitly in capture list. Instead of writing `use a, b { }` you end up writing `[a, b] {...}()`. Example: `const int a = 2, b = 3; const int c = [a, b] { return a + b; }();`
It's almost as if "OOB == Java" was a bad premise for the video...
avoid temptation to [&] :(
+1! I was scrolling through the comments just to see if someone posted this.
@@pcfreak1992 I missed that someone already said this and re-posted >.< My reply is a little more long winded though. I verified that Java and Ruby can't do anything close to what you can express in C++.
@@kitten-inside Java is kind of a bad language by oop standards.
Rust comes pretty close to the use block. All blocks in Rust are expressions that create a scope and all expressions evaluate to something, so the sub-scope and return behaviors are checked off. Sub-scopes do have access to their parent scopes, however, so the parameter-specific behavior is out of the question. You can still have that effect though, via the method you yourself mentioned: make a separate function. That said, I do think Rust gets like 1/4 of a point for this because all functions and closures automatically implement one of three traits (similar to typeclasses in Haskell) which tells you about the function's operation. This use block you suggest would be equivalent to calling a function bound to the Fn trait, which means it can be called repeatedly without mutating state or consuming/deallocating data. You could theoretically write code using type generic syntax which enforces this Fn bound and makes a use block... maybe.
I clicked on this video with skepticism because the video title is so "black and white". But unlike the title, the contents of the video is not so black & white. I think a lot of people who thumbs-down this video actually aren't watching the full thing. For your convenience, the 1st half-hour or so is all background and setup and analyzing the problems. He gets to his list of proposed best-practices (which are quite reasonable) at time index 34:46.
His evidence is anecdotal and many of the issues can be attributed to incompetent programmers as opposed to their paradigm.
Also some of the advice is really bad and I hope I don't have to maintain code by people who took that advice to heart. Nested functions in favour of-you know- non-nested ones? Relying on comments? Like anyone writes those where they're needed. Properly named functions are the natural comments and make things more readable in the process. For the love of Zeus don't use large nested functions just because you "shouldn't be afraid of large functions". Give my scroll wheel a break.
The tl;dr of this video is no one even does the crap he says is bad about OOP. At least no one any good does.
He's saying OOP is bad. Sometimes things genuinely are black and white.
It's hard to take anyone seriously when they start with this is the best video ever.
It doesn't help when having decades of dealing with people who say that and you find out most of them are blowing smoke. It ruins any attempt at trying to make a change when he starts with a victory lap.
@@Kinglink He didn't say it's the best video ever. He says it's the most important programming video you are ever going to watch, and he's right.
The fact of the matter is that the majority is not always right. Sometimes all of society can collectively make a mistake, and that's exactly what Java, and OOP was.
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.
"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.
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 appreciate your insight, this has allowed me to view my code from another perspective. Thank you for taking your time to express and share these ideas.
Whether I agree or not is unimportant. This was very thought provoking indeed. Many thanks!
I can agree with most of the things you say in this video, except for the part about large functions. If you inline all code into large functions and just separate it by comments, you force me to read all this code or to constantly skip over it when I try to understand the higher-ranking logic of a function. The idea to split code into many small functions is that I don't have to read all that code unless I have to touch it for some reason and then I only need to read the code I want to touch. If the name of a function tells me exactly what this function does and I have no reason to assume that this function does not work correctly, I won't look at its code at all! Even if just called once in the entire program, why would I want a base64 decoder to be inline instead of having a call to "base64decode(...)"? I know that it does. Base64 data goes in, decoded data comes out, no need to see its code.
Yes, this. Using functions to spread apart your code can make it so much easier to read, when done correctly. Sure, if you're looking for a particular functionality, you will need to CTRL+F to find it. But if each function is longer than 5 lines of code, leafing through pages of functions to find exactly what the application is even _doing_ on the high level is annoying and inefficient.
To add to this, you should NOT be afraid to make functions with long names, there is no real downside as long as it's smaller than ~10 words. A long and descriptive function name means that anyone who reads it knows exactly what it's doing, without needing to read some long extra sentence/paragraph in a comment. Abstract function names like "Build()" force a reviewer to actually look in multiple places to figure out exactly what the duck the code does.
Both of these ideas complement each-other and lead to code that is both categorized neatly and quickly understood on the high level. However, you still need to use your own discretion on deciding what kinds of code to split up into functions like this. Sometimes it's just not worth it, as the video author describes.
@@LordOfLemon I don't have professional experience with coding yet so I might be wrong but I haven't seen situations that work better without separate functions outside smaller pieces of code. For a program that does multiple things, separating methods and commenting makes it much easier to read and understand. If you have an example of a long code where functions would be the worse option please do share
@@mistzzz4683 I also find myself disagreeing with the video's suggestion, but one place I prefer inlining is when the function in question is tiny, obvious, and only called in one or two places. For example, it's way less readable to see a call like "n = timesThree(n)" instead of just "n *= 3". I've seen real examples almost that bad. I love small functions, but at the point where the function name is just an English transcription of it's entire one-line body, I'm actually going to stop and read it because I'll be wondering what was so hard about this that you had to define a function.
@Mist zzz I have professional experience, and the answer is just that there are a lot of bad coders out there. I once spent an entire summer refactoring A SINGLE FUNCTION. It was thousands of lines long, and it meant I had to constantly delve deep into various levels of logic to understand the code. Some flows of code are long and complex. In this case it was the handling of a submission for a new user in a specific system. If you were A, you were gonna get Y and Z, if you were B, you were gonna get X. If you were C you were gonna get X and Z. And then with A B and C you were gonna do some common setup. Now, I was originally only going to add a new case D, but I couldn't. The code was so messy, I couldn't interject W into the code, because everything was mangled.
That's why you want a function that describes what you're doing. submitForm() { createUser(); setupUser(); giveUserStuff(); sendOutMessagesToUser(); }. If I am going to give a new type of user new stuff, I need to change giveUserStuff() function. This is how you can see that you can drill down into the depth of complexity a lot better. Comments do not do this in the same way, because the code is still there. Good code is also comment enough. Show me what you're trying to do, then show me how you're doing it. Even when you're doing it, show me what you're drying to do, then show me at the deepest most complex level what you're doing.
In my case, there was an API that was being used, so all over this original function, there were these extremely complex API-calls that were being set up in complex ways. Instead of saying giveUserASubscription(subscriptionType), there was a huge chunk that set up an API-call and just used the result. When it's my first time opening that code, I am not able to quickly scan that and ascertain that this part of the code is the API-call that's giving a user a subscription. I have to scan through low-level API-setup and see that the API call is something related to a subscription. That's why you first show what you're doing, THEN in a new function, show how you do that. That means that if I am giving the new userType D a new subscriptionType N, then I don't need to care about how you giveUserASubscription, I can just call giveUserASubscription(N). This means that it's not only good at showing you in coarse terms what the code is doing, you're also allowing me to not have to even relate to the lower levels of the code, if I don't need to. Say that later someone needs to implement a newer version of the API-call, then they can just find where all those API calls are used, and change how they're called. Then you don't need to relate to what you're trying to do. That's why abstracting code makes all tasks besides a complete rewrite a lot more easy. Maintaining code means that you should have to deal with as little as code as possible when you're doing a change. That way you lower cognitive load, which in turn means less chance of error. You also touch fewer lines of code, again making it less error-prone.
Yes. And smaller functions make the code better testable. If you have assumptions about the state of the relevant variables while entering a certain code block, and the desired result after passing it, it is testable if that code block has a name.
Finding descriptive names, which make a longer comment superflous, is often time consuming but it teaches you in reflecting upon your code and what the parts of it do. If you are able to leave a helpfull comment, deriving a name from that should be possible.
"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.
7:56 You shouldn't take as a reliable guide a history of why (mainstream) OOP became mainstream which focuses on the rise of Java but (AFAICT) doesn't mention Smalltalk or C++ at all.
@Shailendra Nath I'd argue that if a function doesn't have a meaningful association with a data type and you're using OOP, then the mistake was using OOP for that task. That doesn't invalidate the paradigm, it just means it's not the holy grail. And to be clear, there is no holy grail. That's why these types of videos are always hilarious. They operate on the premise "this isn't useful for me, therefore it's wrong and can't be useful for anyone". The bottom line with OOP is that it isn't a set of specific patterns and techniques: it's an approach to object modeling. If the domain you're working in doesn't demand that kind of modeling, the fault is yours for selecting the wrong too. His video could have just as easily been titled "Hammers are bad and here's why."
@@nancykerrigan1335 My CD's always break when I try to play them with my hammer 😢
@Shailendra Nath this is so true but does not render OOP any less valid approach
+Leo Comerford
Because nobody care about smalltalk fucking morons so he criticize what OOP means for people and why it is problematic !
@@nancykerrigan1335 I think your point is well taken, but actually this video is a bit more nuanced than you seem to give it credit for. I think Brian Wall would actually agree with you 100%, and that is why he suggests using some encapsulation, but simply at a higher level of granularity - around the module level, or around cases when the class (data+actions on that data) are actually logical. What he is suggesting is exactly what you suggest - its not the holy grail, and attempting to square every circle into OO will often create more problems than it solves.
I really don't see how huge functions with only comments to break up logic are any more readable and, more importantly, easily testable. I would much rather modular functions that can be separately tested and read quickly rather than just a huge column that I have to memorize the components of. Also why wouldn't you just put the same comments you suggest in your longer function before the function calls?
I watched the video with an open mind... but then he said we don't need functions, we need inline functions. No matter how "good" the code you write is, it will break at some point. I fear debugging an unnecessary inline functions as much as a dependency hierarchy that is too deep. Debug a 2000 line function and you'll see.
I disagree with the idea of long functions, we need a way to test our code by unit instead of a bunch of logic at the same time
It’s more readable because the sections are lexically contiguous, instead of being scattered around the source file. Wanting modular, separately testable functions is really just wanting the unit tests to automatically localize any bugs that occur. If the large function fails its test, you still know something’s wrong with it, you just have to manually examine more code to find exactly what. Writing code so that its tests can localize bugs is optimizing for the wrong thing.
@@richardblain4783 The separation into smaller functions does not imply testing all the little functions separately. A module can be broken in 15-20 functions instead of a huge pile of 2000 spaghetti code, and still you would test the same behavior.
I'm working on a pile of functions that are thousands of lines long, with no tests. I can not refactor because well, there are no tests for the big function either. The auto refactor failed because it is written in the 'C' style with 'goto cleanup;' instructions. If the programmers had split the code into smaller pieces it would be easier to reuse the logic AND to write unit tests for them step by step instead of testing a 1000 logic (which is way beyond my timeline).
While I agree with most of the things said in this video I'm totally against having long 1000 lines functions
Also, I think longer functions makes the code harder to read because it implies that all the details are in one place. You start seeing things at a high level of abstraction. Ex "makePayment" entangled with ultra annoying details like a for loop over char*. You start reading code that is like 4 levels of abstraction in just 10 lines. which makes the cognitive load way higher than just see nice separated subroutines.
I was afraid that this video will just "hate all the classes, polymorphism, inheritance; everything should be done in pure C", but fortunately, I was wrong.
Most important thing I noticed from this video: The definition of OOP I was taught (and probbaly many are, or at least think this way) is wrong. I guess most ppl think that OOP = classes + inheritance + polymorphism, while actually OOP = classes that react to each other in a very non-stanarized way (eg no parent-child tree). There is no problem with classes and inheritance themselves (in fact, I would rate them as one of the best mile-stoning features of programming), the problem lies how ppl use and comunicate acrosss objects of different type
One Note:
Windows API in C IS NOT a good example. That's not a C fault, that's the faut of the API authors that made the code full with abbreviations, macros etc. It's heavily void* flooded, and every C++ programmer will tell you not to use them unless neccessary
Later you talk about features like memory management, exceptions while comparing C to Java. Why not C++? Wasn't it available in that time? Sure, C++ wasn't as good as it is now (and this could be the cause that ppl were very attracted to Java), but hey, this video is made in 2016, you should know that C++ has all these features too (exceptions, smart pointers - no GC, templates, cross-platform code) - this should be mentioned
Overall I am impressed with the video
21:07 - Yes, thats a very good point. That's not a good idea how to use classes 21:20 is definietly as it should be
22:07 - I definietly agree. Most modern (not from 1990s) C++ tutorials I find recommend this way.
25:10 - Well, kinda common sense but true. Nothing is perfect
26:34 - That's how I start every project. Start with complete mess, a lot of refactoring multiple times, but over time the whole project goes based on better and better "class-tree-skeleton" untill no more refactoring is needed - and then, adding new feature to the program is simpe as f***, just add a method/child object and everything works perfectly
28:39 - well, as a C++ programmer I can be proud that I had never need to do a "do-er" class
34:05 - I'm happy that all tutorials I have used mentioned this tip - I definietly agree. A method is a method (not a free function) for a reason
35:10 - 38:52 - again, I agree with everything; I am wondering what are you really complaining about? Or I am just lucky that all projects/people I met use the proper pattern?
41:30 - C++ lambda expressions are exactly what you need/are talking about. They have even more functionality than you mentioned. And they exists already for 5 years
What I definietly agree - { } and ( ) are one of the most important programming language improvements. Today, I literally can't stand looking at code with words procedure, begin, end
[somehow RUclips displays "unknown error" when trying to edit comment above]
I think you are just lucky to be working in the modern programming world when people are realizing that OO has much less value than promised and everyone is starting to look into functional approaches, which necessarily means more procedural ones. That, or you've been blessed to avoid OO fanatics through the dark times.
the dark times. brought to us by SUN
+flow in
I give Sun credit for the things they did bring us. Java did have some improvements over C and C++ that really did help things. I think I blame whoever popularized C++ more than Sun; Sun was just following the times.
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.
I tried procedural programming a while back - I think I still have the punchcard decks in my attic.
I find long subroutines annoyingly hard to navigate, so much scrolling. Yes, 10,000 subroutines of 10 lines is hard to deal with, but so is 1 subroutine of 100,000 lines.
With modern tools 10,000 subroutines of 10 lines each are actually easier to deal with. A lot easier.
@@RockBrentwood lol what are you even talking about
people have a hard time with the idea of a "middle ground"
@@RockBrentwood bro man thinks he's like the jason statham of programming
I never trust some infant who cowers behind a fake name!
This sounds more an indictment of lack of design than OOP. I programmed both procedural and OOP. Having learned OOP using Smalltalk and Lisp, by the time I learned C++ and Java, I came at OOP programming very differently than those who started with the latter. Harlan Mills repeatedly demonstrated the value of mathematically proven design, yet the business call for creating a prototypes eventually overwhelmed the idea in the industry. Agile methodology further allows the programmer to really skip design and figure the whole thing out later. Early Java libraries and even MFC went a bit overboard on the use of inheritance and that started to turn programmers off to the idea. Nowadays, I see more code written with a procedural ideal, but using objects. Component frameworks like Spring and entity frameworks like Hibernate helped feed the creation of discrete objects, instead of the OOP concepts that actual delivery the power.
The fallacy of his argument is the "truth" that a strictly OO coded program is a tree with only descending communication. The whole concept is that any two objects can communicate, each deciding whether to respond or not. His arguments are what lead C++ to have friend methods. Encapsulation is broken for convenience.
+Bryon Lape , I agree with the video content and also with your comments. The idea of class instances containing references to other instances for communication is obsolete. In essence there is no need for a complex tree of instances that are limited in their ability to interact with other code. Because there is not a reference availble. The idea I used long time was to implement Runtime Contexts (thread, request, session, application instance, server side instance, cluster instance) which can be used by any class. So any piece of code can be easily accessed. Even a procedure (static function) might hide where the reference to the instance is stored for further retrieval. So omni directional communication is possible.
You can't design so future changes don't ultimately destroy decoupling.
exactly Dad Bryon Lape - exactly.
Except one thing I'll add is that a cyclical object graph driven by some reactive data bindings is an industry standard at this point.
Formula for making this video: come up with the worst OO design possible, use this to criticize the whole paradigm, ignore all problems in your alternative suggestions, rinse and repeat.
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'll just grab some popcorn before reading the comments
Better grab a bucket.
Eatin’ some white cheddar flavored popcorn right now ... LOL
No one should say whether or jot you should use object-oriented programming. This isn't what you should be focussing on, anyway. What you should be focussing on is what's most important: actually solving the problem.
Procederal does not actually self problems on its own, nor does, for that matter, Object-Oriented. They're both tools used to help solve problems. As long as you solved the problem, doesn't matter which one you've used otherwise.
There's always advantages and disadvantages to using anything. For example, Onject-Oriented tends to lead onto a lot of bloat (especially when done wrong), while Procederal has a reputation for being incredibly complex as well as relatively insecure.
Besides all of this, no one things naturally in terms of rules. This is why they tend to cause a lot of headaches. Rules are meant more as guidelines than anything serious. This is why people often say they're meant to be broken. Those who don't stick to Object Oriented completely? Them having the right idea; Those who try to stick completely are not only missing the point of Object-Oriented programming, but also all programming in general.
None of what you just said deconstructs any of the points on OOP made in the video.
Tom Ashley
I'm not going to refute anything you've said, since I don't really need to. All this useless squabbling is the same as fussing over the following of rules, which, in turn, misses the entire point of programming. It doesn't really matter which one you prefer; What only matters is actually solving the problem.
Tools like Object-Oriented and Procederal are meant to be used whatever what their users intended. Heck, they can even follow the pure approaches, if they so choose. It all depends on their perceived needs. Besides, even if the video, itself, isn't so flawed in its arguments, that doesn't mean you'd be convincing many. It just means someone like me will come and try refuting your claims/
KarjamP Sure except that's a really spacious thing to say as the video isn't useless squabbling and isn't speaking to preferential trivialities. What matters isn't just that you've solved the problem. It also matters that you've solved it well. Otherwise, there would be no abstraction from the metal on up to speak of much less multiple abstract paradigms to program in and paradigms for how to program in them.
Tom Ashley
Why are you trying to argue? Do you honestly expect me to be convinced with your words?
People are stubbornnous by nature. Even if the facts they've been presented happen to be true, if they don't agree with it, they'll try to rationalize it away, even coming up with excuses, if so be it. This is what tends to happen when Cognititive Dissonance comes into play.
In any case, I am not of the notions rules should actually be adhered to, or at least not as strictly as many one else. They are, after all, supposed to be mere guidelines. I believe this sort of attitude is actually what many professionals have as well, hens them using those workarounds in the first place.
It was the kind of advocate that proclaims rules-as-absolute that chased me away from C++. Yeag, you should only use a subset, but many seem to believe I should be using features I might not want to use, and they're try to persuade me otherwise, if I were to show that code to the public, or otherwise ask for help.
"As long as you're able to solve the problem itself, it doesn't matter what you used and how you got there."
I can't disagree more. Your code needs to be maintainable, which is almost more important than it working, because maintainable code will soon stop working too.
41:20: "I want an anonymous function that doesn't know anything about its enclosing scope, where you have to explicitly state what you want to pass to the function"
Interestingly enough, this is precisely how C++ does anonymous functions.
I was looking through the comment section specifically to see if someone had already commented this. I also love how C++ gives you the option whether you want to be clean and manually specify what - if anything - you want to capture (e.g. [&xyz, abc]) or to decide that you don't really care (because you are e.g. just writing a prototype/small test case etc.) and simply want to capture everything ([=] and [&]).
On the other hand, when writing lambda-heavy code, my #1 compiler error is "xyz has not been captured" xD
I was thinking the same thing...
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
Unity DOTS is an ECS framework which represent the phrase _"composition over inheritance."_ I don't use Unity, btw.
The problem you are really addressing is: misunderstood and wrongly used object-oriented programming.
Just like in functional programming you can do really stupid and superfluous things.
Programmers need to learn what's useful and what isn't, which is less obvious than you might think.
Myst I think you might have missed the point. What you said is correct, but not in context. what the author of the video states is : It is much easier to make mistakes when dealing with many programming idioms that OO presents, than it is with simple procedural languages. In fact, in my opinion, I would always favor languages that can fully be learnt in small time, than other languages which are hard to entirely grasp easily. One example to assess my discussion is C++ templates. Boost uses templates to bring some extra ordinary behaviour to its packages. Although powerful, they require a novice C++ developer to understand the source code of boost, and thus efficiently use it. Hope I added value here
37:15 (Long functions are fine!) Brian says that breaking functions up into smaller functions "Just Because" is wrong. That is right. However, he then goes on to say that long functions are fine. There are legitimate reasons to break a function up into smaller functions:
1. Re-usability
2. Modularity
3. You only want each function to accomplish 1 thing and nothing more
Reusability is a myth, anything reusable and modular is already in a reusable modular library. Functions can accomplish one thing while using multiple subfunctions, you dont have to make every function to lowest level possible, that would be absurd.
@@SumoCumLoudly sometimes i reuse functions a lot ;) its not a myth
Fantastic. And brave. I started with BASIC and machine code (Z80) in the eighties. We knew freedom.
I write apps for Android in Java these days. I hate Java.
Then do something else. Is someone forcing you to use high level languages with strict compilers?
I have my complaints about Java. For instance, not having unsigned primitives is almost a deal breaker to me. However, It has some amazing features that you can't get from other languages without convoluted workarounds.
I hate Java too. I was in a Java User's Group for a while in the 90s when it seemed like the language was changing every week. Then I found other there were other web programming languages like PHP which didn't require a half dozen XML files to write a Hello World.
@@MrCmon113 Yes, it's called having to go to work to earn money to feed your family and eating whatever shit your boss throws at you.
you can always use Kotlin, it's like java but better
21:30 I ran into this when writing a video editor in an object-oriented way: Timeline has a list of Track which has a list of Clip; if a clip wants to be created, the track does it automatically. But now if you only have access to the clip but want to remove it, the clip needs to access the track. It gets super messy and annoying having to manage the references, and also having to add error checking in case of a missing track reference (bug)
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.
1. pissing on OOP without actually presenting a TESTABLE alternative (no functions with 100s/1000s lines of code are not unit-testable) does not seem real live oriented.
2. your "alternative" basically copies OOP schemas,by creating "packages" or "namespaces" and encapsulate logic into anonymous functions, instead of creating objects, oh wow a /* this part of my function does y */comment is so much cleaner then a service class with a doc block and unit tests which can verify and describe the intendet behavior of the code.
3. global state is a problem in every language and programming style except fully functional programms. Actually using dependency injection vs. global variables or containers is debatable, but complaining about OOP because you have to use common ancestors to achieve functionality and then recommending parameterizing most of data in a procedual way actually leaves you with a call tree where the top branch has to pass dozens of parameters through multiple stages of your programm.
But your solution to this is using global variables (which will polute global state) or writing large functions. The large functions are then poluted with a lot of local variables as you say, so you have to encapsulate them again with anonymous functions or namespaces.
So you end up with the same problems as in OOP except:
* your encapsulations have no clear API as you have local anonymous functions.
* unit testing those encapsulations is not possible / very hard todo.
* actually reading a 500-2000 line function with multiple local namespaces and anonymous functions is not as convenient as you say, atleast not for me.
* refactoring is either hard because the call tree is gigantic and the passing of parameters has to be adjusted in multiple places or you have to refactor one giant function, again, with no way to verify regressions / bugs by using unit tests.
So the real "benefits" I'm getting here are:
* I don't have to think about naming stuff because it's hidden in one giant function.
* I don't have to navigate through multiple files (which is very easy todo when using an ide or proper vim extensions)
* I don't have to worry about unit tests, because I don't even have to bother writing them for functions with a n-path-complexity > 1.000.000
Also 44:00 - use block exists in php.
Lol, there are still some people hanging on to unit testing, when are they going to fucking learn? Lol I bet you $5 it's either JavaScript or java
I used to write Structured programs in PL/1 and in COBOL, then moved on to NATURAL, and then Visual Basic and Java, and finally Python. I use Objects sometimes, inheritance rarely, parameterised calls often. MY overall perspective is that functions/procedures need not be tiny (a screen or less) and that larger functions/procedures can serve a system very well. The trouble is that many of the junior programmers leap into complex object hierarchies immediately and because one must work with a team and many members of the team will be recent graduates with almost nothing but OO languages at their command systems get stuck in the morass of huge object hierarchies. It is not easy to avoid.
The thing whit OOP is that you need to use Objects when they are supposed to be used. You shouldn't overdo it, but you shouldn't write a whole game in 2 classes either.
Wire Rubbish Bin what about Traits?
So what would you say to somebody who is still studying? What to do to avoid that?
I'd say, learn Python. Program without objects for a while. Try objects when functions will not quite do what you need. Put emphasis on need. Objects are a fashion for many and lead to fashionable "design patterns" which often do not fit the problem one is seeking to solve. So resist the temptation to create complex object hierarchies when simple functions will suffice.
Python was my first language and I intend to return to Iron Python once I have enough experience with mainstream programming of Java and C# to accomplish my current goals.
Kudos to you for your excellent tastes.
41:24 I think lambda expressions in C++11 can do exactly that. In order to use things from the enclosing scope you have to add them to the capture block.
Yeah! Python and Java have them as well
In Rust, you can have anonymous functions that are called "closures", and they are allowed to capture the environment, or you can define a function block inside of your function and it isn't allowed to do that. This does require naming the function, but you do get the isolation of scope and return-safety.
Ahh the internet... the place where if you look hard enough you'll find someone who will agree with anything you can come up with.
No one programming paradigm is perfect or suitable for all tasks. If you need raw performance speed you might use one paradigm, if you need to write a proprietary API you might use another; or you can do something in between. It is called "the right tool for the job".
performance rarely does come into it, cmpilers are smart enough these days that this doesnt matter unless you have a really hard problem and at that point no paradigm will save your ass from having to think
@@omniphage9391 Yeah, right. This is why you now need a 5ghz machine to run a web browser. Keep thinking "performance rarely comes into it" like the rest of industry, its worked great so far. Also, compilers are dumb as fuck. Try actually looking at some of the shit ASM they output.
I would rather have a "stupid" compiler from the 90s literally any day over the BS compilers pass themselves off for these days. At least then I am not spending 95% of my time stressing over weather or not what I am writing is "undefined behavior" or not.
you spend 95% of your time stressing about getting your code to compile?
I dont know what to tell you.
I hope you get better soon.
@@omniphage9391 Compile? No, of course not. Do you even know what undefined behavior is?
@@omniphage9391 I am also very confused at both of your replies because they both have nothing to do with what I was originally talking about. Undefined behavior is when you tell the compiler to do one thing and it does something entirely different. The code compiles, it executes, but its not guaranteed to do what you tell it to do.
Modern smart compilers don't actually listen to you, which is the problem. They take what you tell them and consider it a "lose guideline" then output something that's often entirely different than what you tell them to do, and sometimes with an entirely different result or behavior.
Thus, these days you are always trying to avoid doing something that will make the compiler shit itself rather than just focusing on getting the job done in an optimal manner. I don't want to have to trick the compiler into doing what I want it to do, I just want it to do what I tell it and not have it second guess me and think it knows better.
Maybe I haven't spent enough time looking at other people's code bases, but I've never seen anyone code like his OOP examples. And everything he said in the end about how to program better is exactly what I was taught to do with Java since day one of high school programming, 14 years ago. Have I missed something somewhere?
Agreed. His “tips” are not usually specific to OOP either. I don’t really get the idea behind the video in general.
Thank you!
His tips are just how I've always done OOP. It sounded like he had too rigid an understanding of the rules and what encapsulation meant.
seems pretty on target to me.
@Andrew Onymous I think this video does make sense though, he's saying use classes and objects when there is clear ties between the data and methods (e.g. queues), but dont design an entire application around classes and objects. If he's tips are things you already do then congrats, that means you are likely writing more readable code
@@ConnorForbes25 Okay, but then it's not an indictment against OOP programming. This video should've been titled "over-compartmentalization is bad and here's why" or some shit.
Once in a while I come back to this vid.
Now, since the last time I understood some things I've never read in any tutorial before.
Most of the OOP basics have nothing to do with programming, they crop up everywhere in engineering.
When designing a complex system, you basically divide the big system into sub-systems fit for one task. When making the layout of the whole in this way, you forget about the implementation of the sub-systems - you use an ABSTRACTION.
Of course, the sub-systems can interfere with each other, you need to separate them & make self-contained - you need ENCAPSULATION.
But then your systems must communicate somehow to achieve anything, so you define some common interfaces between them - for example, communication protocols, electric signal characteristics, etc. After this, you can simply play some LEGO with your building blocks.
When there are different similar components implementing (mostly) the same interface - you can swap them and do not have to redesign everything else - you have POLYMORPHISM.
Inheritance, in the other hand, arises naturally when you try to apply those in programming - you reuse code.
KISS & DRY are just common engineering-wisdom that help you keep your sanity. YAGNI refers to the habit of being greedy on features we don't really need.
Most of those just arise naturally when you face bigger & more complex problems and try to conquer it.
Design patters, on the other hand, are mostly a workaround on fully-OOP design - the need of an object to do anything. Small systems rarely need any, and most of them arise kind of naturally when trying to solve bigger problems.
Still, I get some of your points. OOP is often badly-taught, can be abused, and not fit for everything - especially very small programs. It's just a tool that can be quite useful...
Thanks! Definitely a tool, and there are systems for which I would definitely would not go back to procedural and imperative programming. Yes, it can be done, but it would be way more difficult.
its all theory. Just like SOLID, sounds like great idea, but every time I read something like this I have feeling that author never wrote real world application, more complex than some foo bar example from msdn docs.
Encapsulation have another assumption/big lie - there was good blog or vid about it I cant remember source but general message is that you can never trust other object, and in real world you have to know HOW it works, and encapsulation assumes that it shoulodn't interest you because it's 'private' part, or 'inner working' of that object - and thats just theoretical nonsesne that doesn't apply to real world AT ALL. ;
@@Angry-Lynx I do not agree. Separation of implementations is pretty darn useful. What would you do if a 0day junior dev wrote a module that logs some values and also modifies the database randomly?
You need to protect your system from effects like those - and a way for this is a language mechanism that forbids the modification of some values by everyone else.
Also, do you know the internal working of everything you ever used? Do you know how your HTTP libaray processes requests, and how does SSL encrypt your data?
No? That'd mean you do not know their intenal workings! You only care about their interface, and NOT their implementations!
Here's encapsulation and abstraction for you!
@@HA7DN medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
Good read, especially conclusion about oo lies in classes and tutorials. I dont think oop is bad in general. But those theoretical 'promises' of patterns like solid and perfect encapsulation are toxic because they are big stinky lies we were all told when we were learning oop, just to be burned badly and realize that real world coding isnt as simple and pure and so on as Cat : Animal 😁😂
Again encapsulation itself isnt bad, its just general consensus about it is a dream-land/eden nothing more, because in real program classes are never 'really' encapsulated. Its about honesty in the end. Or rather lack of it should i say;
@@Angry-Lynx Thanks for the interesting read!
I can not agree with everything it this article - like complaining about the performance hit of something I can not undersand why he says we need, but than saying functional is better, but I have to agree with him on one thing: blindly following tutorials & paradignms is anything but good.
Don't ever make design decisions ONKY based on what somebady said on the interned. Sit down and think about how YOU think it'd be better. Later you can refactor!
Now, I've been studying functional programming for a bit now. I'd never call myself an expert, as I only know the very basics (no mutable variables, no sideeffects, pure functions), but all of those already have a few bad effects.
No mutable variables are a HUUUGE disaster in terms of performance, especially if you want to modify arrays. Of course fancy workarounds DO exist but then you critisized OOP for needing workarounds.
(the only difference is that in functional, usually the language hides those workarounds from you).
Side-effect free functions... Yea, how do you do anything, like IO, network, displaying images or beeping without those? You simply can't. You NEED side-effects, and next you have to use fancy workarounds like monads and other stuff just to do this in the functional way.
Or you just say "I mostly program in a functional style" and just give up you fancy paradignm when it becomes inconvinient - and that's what you should do if you can! Look at everything as it's a tool!
8 years since this masterpiece. I’ve progressed with simple procedural code to the point where I physically cringe reading others peoples OOP code labyrinths
I know how to use a chef's knife, I have a chef's knife, so I should never use a butter knife, because everyone uses butter knives. It seems to me like that's what your argument amounts to.
I'll use a chef's knife when it's appropriate to use a chef's knife, and I'll use a butter knife when it's appropriate to use a butter knife.
If you overcomplicate your use of a system, that's not the fault of the system - it's the same trap Hilbert fell into: you can't define literally everything, some things have to be left open to interpretation and intuition, or else you're going to end up contradicting yourself.
Well put.
+notoriouswhitemoth The greatest lesson of software development: Tools, not rules.
NOBODY should ever use a table saw to cut vegetables, is his argument.
He was arguing that OO programming is ineffective at its goals whether used as intended or not used as intended, thus unlike a butter knife that has things it's best at, if his argument is correct, then there just wouldn't be any proper programming use of OO at all / it wouldn't be best at anything, thus the analogy should be something totally not belonging in the kitchen in the first place, even if it could feasibly do the job, badly and awkwardly.
Gavin Jenkins But he misrepresents what a table saw and a vegetable is.
In what way does he misrepresent? Claims seemed accurate from my coding background, but I'm a researcher who just uses code, not a guy who has degrees in it by itself.