And its what happens in real life. Requested is a Giant Featureset where, after everything is finished and released etc. you realize none of the features are actually ever used or used in the way they should be used. Its like "Hey, we want giant logs displaying everything" and then after a year you see those logs with just thousands upon thousands of exceptions. Turns out noone reads the logs anyways, but its ok to waste time on those logs. not only your time but also CPU/IO etc. time...
The problem is that the strengths of OOP require non-trivial examples -- however that's almost always out of scope of UA-cam videos and presentations. So, yeah, of course they're going to find overengineered solutions. Like, no sane software engineer would go that approach for merely flipping a coin. However, once you add in needs to extend the game to use other types of 'coins', maybe more players, maybe changing the AI for each player which could be dynamically instanced -- say you want it to become more sophisticated over time - then an OOP approach begins to make sense. But it's all wayyyyy beyond the scope of these demonstrations.
He is missing the point. Object oriented code is not about classes, data encapsulation, and inheritance. At its heart, is all about interaction and message passing between replaceable entities representing traits of the system, each implementing public interfaces. Therefore, object oriented code is all about interfaces compliance, polymorphism, dynamic binding, delegation, and composition in a safer and cleaner way, leading to greater flexibility. Good object oriented design relies on patterns to allows one to delay critical decisions, do interface implementation swapping (thus reducing risk o vendor locking), and to add new features with minimal work, therefore is suited for big and complex systems, when you may not know ahead of time what the final features are.
This isn't an argument against OOP it's an argument against making extremely complicated solutions to trivial problems. Classes are powerful but not always necessary.
The fact that people respected enough to be giving talks are making these same decisions *across different talks* and teaching them to younger devs kind of does point out something against OOP. OOP is being taught as a tool to solve all problems when it is not necessary, and to me that points to some disconnect between the problem at hand and the tool people use to solve it. And they *will* use the tool they are told to use, especially if its the only thing they have ever been told about. If you were taught from day 1 that *everything* is an Object, then your entire problem solving toolset is based in that idea. OOP and the people teaching it are not teaching how to solve problems, they are teaching how to use OOP. Obviously OOP has uses, and plenty of software is written using that paradigm, but the OOP *mindset* has a tendency to leak its gooey goop into places it shouldn't go.
@@nice_sprite5285 True. And I believe FP is the solution. Sum type, typeclasses and HOF are far superior than whatever those factories and singletons are.
@@alexho5769 I havent experimented much with FP, but from what little I do know about it I think it definitely provides a good way to solve problems with good perf and design. I've had the thought for a long time that what we do in OOP-land seems sort of silly and masturbatory at times, but only more recently had the chance to reform the way I write code to be better. Would you say rust's functional features are a good way to start writing FP? Or if I wanted to learn FP, would i be better off with a "true" or "pure" FP lang like Haskell? Your comment is making me consider branching into that domain a bit
@@nice_sprite5285 Yes I do believe rust is fantastic. It's not pure FP but it does provide a sophisticated type system and FP-like features such as pattern matching and traits, and it's bloody fast ;). I'd say if you want to build something "real" and you're not looking to learn the deep theories behind FP, definitely start with things like Rust, Scala or OCaml. And if you're still interested after that, it's also very beneficial to learn Haskell since it's essentially the Occam's razor of functional languages (but it's harder to build something "real", like a REST API). And if you're still interested after learning these, it's also fun to dive into the deeply "nerdy" aspects of FP by learning languages (proof assistants) such as Coq, Agda and Lean (but these are highly specialised languages that will definitely require knowledge of Haskell), there you'll learn about type theories and the art of proving program correctness. Note that these are *definitely* not required to understand FP. Hope this comment helps :)
I've been programming for 44 years. Classical, non-object oriented (mainly years ago) and fully OOP. Currently, I manage a system that was 1.5 Million lines of code that I have down to 750,000 lines (that's HALF) - all thru applying OOP techniques. You have to use the right tool for the job (ask any handyman, mechanic or woodworker). OOP isn't the answer in trivial programs. But in big systems and systems that have to adapt to new business rules, it's invaluable. To just say OOP is bad is a total misunderstanding of OOP. You have to LEARN the tools - not just dismiss what you don't understand. You need to study the OOP subject further before you dismiss it.
OOP also isnt the answer in a lot of other things that are insanely popular and useful related to AI/ML. I wouldn't call that trivial. As far as enterprise applications...I get your point. But to call anything else trivial? And also...what would the architecture look like in F# for instance? Still a million lines?
What you say about OOP may be true, the problem is not every software company is made of engineers with 44 years of experience. The OOP I've seen devs write is not great. Mainly the cognitive complexity is high. That's the real issue with OOP IMHO. It's complex. There are still to this day some OOP patterns that simply don't make sense to me. The benefits of which I just haven't seen yet. To me clean code is understandable and testable. I think OOP with DI is great for testing, so it nails one of the requirements.. but it's not always very understandable. Maybe someday when I've been in the industry for as long as you have I'll circle back around and enjoy OOP
You're right. Use the right tool for the right job. But he has a point, to many people think that oop is the best tool for everything. Even Bjarne Stroustrup have said that oop is a bad choice in may cases.
@@_mr_andersson by most you mean most in python? While those libraries are certainly constructed that way for convenience, I haven't really seen any data scientists build their data pipelines I'm an OO way much (in their day-to-day) work. What I've seen and used mostly ends up being a mix of functional/array or procedural
I could give 100's examples, since I have been working as a developer for over 25 years. But one that pops to mind was back in 2003 or 2004, in a start up company, we developed an extensive video processing, video cataloguing, and video emission platform and the boss wanted a plugin vumeter for the sound volumes for one of the video players. He assigned the task to someone of the team. He took about 2 months to design the complex vumeter with a queue system for the sound samples, etc.etc. and of course all done in OOP C++. The team member was also working simultaneously on other projects, so he did not spend the entire 2 months on just the vumeter. Even after this, the vumeter never worked properly, and was overcomplex and difficult to debug. The volume levels were all over the place, and obviously did not match the volume in realtime of the video. Even so the boss alloted a big chunk of resourses(2 months of one of the team members) that he was going to ride the sinking ship to the bottom of the ocean, and just kept trying to fix the vumeter to no end. I secretly took some of my own time, and wrote a vumeter dll in pure C using direct win32 calls(to capture the windows of the app, draw,etc..) and no queue, and no OOP. My vumeter when compiled was 64 kilobytes and had no external dependencies(and probably was even smaller but Windows has a cap due to alighment on PE sizes) My team member's vumeter was well into the megabytes and had various dependencies on third party dlls, sdks, etc. In the end, my vumeter worked perfectly and the company had to use my version. My boss took me to the side, and was extraordinarly pissed off at me, almost screaming, yelling: why the hell did you make a vumeter, taking time you shouldn't or you could have just helped with the main vumeter project etc.etc.. I have never seen him so mad. Even so the main vumeter project was completely trashed and they only used mine for years to come. The reason I did not participate in the main project, and just went off and did mine, is that every time I spoke up about overly complex code, and OPP, I was pushed down and ridiculed directly, so the was no reason to argue with people and their devout dogma, I just did what needed to be done.
The problem seems not to be with the OOP vs. procedural approach, but with the architecture and design. You could very well end up with a bad vumeter written in C or any FP language. The people deciding on the technology and design are the issue, not the technology.
@@ShazeAnIn my first job (I just turned 20) I criticized the boss's "3 years in basement" work on a "execution environment" (executing our own programming language in industrial automation equipment, programs downloadable over serial comms) of a new breed of PLC system. "Shut up. You are new here, and besides it exists and it works!". I convinced the other two 20 year olds that what I had in mind was superior, and I argued "let's remove his main argument [it works] by also having 'it exists and it works'". So, on a weekend from Friday to Monday morning, we made a byte code interpreter from scratch, faster, smaller and easier to maintain (all in assembly, btw). On Monday, we assumed that we would need to "stand our ground" to convince the boss. I came a bit a late, and urged the others to "let's go and talk to the boss", and got the answer "We already did. It took less than 5 minutes and the only thing he said was 'Ok. Now finish it.'". I have heard that, that effort was replaced ~25 years later with new implementation in C/C++.
lol, this is why i never just do something that my boss didnt ask for. Im not getting recognition for it, and the extra effort is just going to some big corporation who really couldn't give a shit about you anyway. Why step out of your bounds to help a meaningless project for people who are more concerned with paradigms and the micro management of its employees just to risk your own ass for almost 0 benefit
@@rosek6585 Oh, trust me, I don't need to try to write bad code. The point, though, is that object-oriented programming produces bad code more often than some alternatives when you're trying to write good code.
There are a lot of really bad develops, OOP enables them to cause too much damage, like giving a gun to a retard. On the other hand, good programmers can (almost) do perfectly well without oop. Maybe only people with 5+ YEARS of solid C programming experience should be trusted with OOP
@@ptechlead I agree, most devs these days should not be able to write code. They are way too careless with their code and produce problems more often than the rest.
Object-Oriented Programming is not some omnipotent tool that makes every bit of code it touches better. OOP is just a tool in your toolbox of patterns. Saying we shouldn't use a pattern is as wrong as saying we should use it everywhere. Forcing any pattern is generally not a good idea except it can be a good learning experience. Use the pattern that matches your problem.
Couldn't disagree more. OOP is actively terrible, and is never a good idea, and should be avoided. Even in cases of ADT's. Especially in cases of ADT's where OOP propaganda makes ADT's nearly impossible to maintain... No seriously, try writing a gui dialog, the best use case of OOP, it is easier to to with procedural code, even though OOP has "solved" this issue for 30 years. OOP has basically failed to deliver even in its most fundamental use cases.
There are no use cases for OOP, period. It only makes the problem more complicated by building a tower of useless abstractions and by forcing everything to be an object. In my experience, people who are claiming that OOP has any benefits at all simply didn't have enough exposure to the alternatives (i.e. functional programming)
+suckmynobs Actually not quite, every type is based on Object, but Java is based on "Everything is object" principle more than C# is. Look at the difference in "events" in Java and C#.
this sums up both the video + comment section quite perfectly.. as a student, as we all are, we can learn from all methods of solving problems ~ expanding not only our toolkits but also our minds that must first conceptualize the solution before solving it ~ in the end, all are tools to be utilized ~ different tools for different jobs ~ some problems may require a single function, others require an entire model/representation ~ rarely is anything "wrong" in life, just maybe not the *right* place or time..
There are a lot of things I like about OOP. But yes, I see your point. People seem to shoehorn a lot of code into objects when they really don't need to.
I've known people who started learning programming and lost interest/gave up as soon as they had to apply OO concepts to solve problems/assignment questions. In other words, they were able to solve those very problems outside of the OO space. This is concerning because they could be adding value to the industry. I wonder if this is a symptom of what the video argues.
@@SimonWoodburyForget fun stuff is most oop programmers now go away from oop basis. What do you think dto's been made for? Or what about ECS pattern in game development? Speaking of ECS, it's adding new entities made easy and mostly bug-free. I think that OOP will stop being a paradigm in a future and will become a side feature which still can be used (interfaces and such) but not as a architecture framework. And you can see it even now in web development where most used patterns like factories, dto's domain driven design and other shit intentionally strays away from old and rusty oop.
@@PerryGrewal My brother gave up on that. He couldn't understand that bunch of stupid things. And I would say to him .. "calm, that's the way" ... But I was wrong. We really don't need it all!
IMO there is a big difference between programming with objects and orienting all of your code toward objects. If all you see are objects, then of course you're going to shoehorn all kinds of things into objects that have no business being there. OOP it's a design philosophy that teaches you to think exclusively in terms of objects. It's an inherently bad design philosophy.
@BringerOfTheTruth so not only did you not make any points. But you made a blatant assumption and then used THAT to claim he is unqualified to talk about this. I dont give a shit WHICH paradigm is better, your comment was probably the most retarded argument ive ever seen. Like at that point why dont you just say "OOP bad FP good I'm right youre wrong and unqualified cuz i say so. Bye stupid fanboy kid".
That's the guy who wrote "refacotring, improving the design of existing code". I've read it and some of the improvements make sense, but others are just cutting code into confetti, like extracting methods that you only use once.
@@1Maklak It increases readability and you lose barely any performance. Most code can be extracted to be a method which has a meaningful name and purpose, which makes your code much more readable and understandable. It also makes sure that you do not have to know the details of what the method does unless that specific method is relevant to you. Extracting pieces of code to a method which you only use once reduce complexity and the amount you have to understand about the code.
@@13b78rug5h To me it decreases readability, as described in this video. I prefer having a pretty long, but segmented function. After method extraction, I get a bunch of smaller function scattered around and possibly even in their own classes. But like I said, much of Fowler's advice is sound, for example that you can make small incremental changes to existing code as you go along doing other stuff with it.
@@1Maklak smaller functions are easier to test than larger functions in my opinion, thats also a reason for single responsability design. But I like to see other opinions as well as this video. Rethinking the way you code and listen to others is always usefull. I also think in Oo you can end up really fast in overcomplicating things.
@@Alx-gj2uz Ah, right, that's true. I never had to do unit testing. It may be that the way people think is wired in different ways, so different approaches are "natural" to different people. For example some people are good with mathematical formulas, while others look for a geometric interpretation, so there's that. I also got reasonably good at procedural style in C before being forced to learn object-oriented (and even then it still didn't make sense to me to put every function inside an object). Some things, like making lots of small classes, design patterns and self-commenting code newer made sense to me, so I was wondering why and then I saw this guy's lectures and everything he says works for me. Those objects, constructors, inheritance, factories and all that other stuff is mostly bloat and noise code that gets in the way of what I'm trying to do. I can put some data and functions manipulating that data together for encapsulation and separation of concerns, but it will be large classes with long and often static functions and it just works. I also usually end up with an "Util" class that's a namespace for static functions that don't have a good place to put them in. Funny think is, when you get people like me and OO people working on the same project, you'll end up with a refactoring war.
After just taking an OOP class at college, and appreciating what it is does, the majority of our coursework was small examples that could easily be done procedurally including the final that I felt force to complicate with classes I can respect what he is saying but I also can see the large scale use cases.
Your understanding here is heading in the right direction. OO, especially with languages like Java, just suck for small things because of all the overhead. However, I love Java for large systems, in large part because of its strong typing, but also because you have lots of options on how you can organize your code and that organization makes dealing with these large code bases so much easier. I am now working with microservices using JavaScript and for these tiny bits of code, a both weak typed language and language not requiring all the OO structure is nice. However, even for these microservices I wish it were TypeScript (strong typed) because it is really hard to understand the data structures being handed around. Just this last week I was working on some code where, if it had been strongly typed I would have had it done in a couple minutes. However it was JavaScript and now I have to wait until I can run it in QA to see the actual data flowing across the wire before I can complete the code. Very annoying.
Same thing happened to me, although my graduation project was medium sized ,it would've taken way longer and been too complicated if I made it with procedural, glad I did it with OOP
I don't understand, most OOP languages are multi-paradigm programming languages anyways. You aren't obligated to use classes all the time. You can use struct, enums, static classes, etc. There are multiple options. So many people are hating on OOP languages while in fact they aren't even aware that those languages can do way more than pure OOP.
I wrote code professionally for 40 years and this type of argument is as old as Fortran. IMHO, OO has its place for certain classes of problems - modern GUIs for just one example. But as with every "new" programming paradigm that comes along there are people who embrace it and promote it as the one and only "truth". The same thing happened with Dijkstra's "Goto less programming"... while structured code is generally a very good idea, there are times when a simple branch instruction can replace a lot of convoluted nested logic and eliminate a lot of cpu cycles popping return addresses off the stack, etc. The same arguments can be found in Relational vs Heirgraphical databases, and even DBM databases. They all have their strengths and weaknesses. Learning when one method is advantageous and when it only adds complexity is part of becoming a good programmer... and being dogmatic (either for or against) any one style in all instances holds one back from being a good programmer IMHO.
I'm curious as to why you think OOP is particularly suited for GUIs when functional reactive programming is used extensively in modern frontend frameworks like React and Elm.
Agreed, this vid is nonsense. There’s more than one way to skin a cat. I constantly write and switch between object based and procedural code. Why write a thesis on this and labour the point. Life is just too short and why the beef?
@@GBGOLC The issue is youngbloods are taught "this is the one true way" (hello agile/oop/rust etc.), you have to grow a greybeard before you learn to recognise 90% of this is bunkem, and someone trying to sell you something, and the only one true way is to have the experience to identify the right tool for the job (and learn how to tell your project manager they are wrong committing to the next new shiny).
Goto statements can always be avoided by just calling methods and should never be used. Good code does not have 3 or more levels of nesting. Once you need more, you just extract a method.
@@tabularasa0606 Makes zero sense. A Goto is an unconditional branch, it is not required (nor desired) to return like an OOP Method. Furthermore, a Goto simply changes the Program Counter and takes a few machine cycles while calling a Method at a minimum must push a return addresses on the stack, and do various initialization tasks that can take HUNDREDS of machine cycles. Why would I waste hundreds of machine cycles for something I could do in less than half a dozen? I think you are confusing a Goto statement with a function call... two very different animals.
I'm not sure you can just say "OOP is bad", the examples you are showing are a bad use of OOP. Doesn't mean that the idea is just null and shouldn't be used.
OOP has very fundamental problems, so much so that OOP best practices (composition over inheritance, dependency injection, ...) can pretty much be boiled down to: "Don't use all the cool features that OOP promises on the blurp". What most people actually find useful about the whole OOP idea is little things like data carrying its own function namespace - foo.doSomething() as opposed to someNamespace.doSomething(foo). And OOP isn't even particularly good at the things it's designed for, for example an ECS is much better at sharing abstract behaviours over different "classes" of "objects" and doesn't require constant reimagining of a class hierarchy when new aspects are implemented. And it'll probably run faster. Maybe the biggest sin of OOP is that it pretends that elegant code is the goal of software development while making writing elegant code incredibly hard (if not impossible, because all that complexity is actually only elegant within an OOP context). But I've been there, I also tried to defend OOP back in the day. In fact it took me a deep dive into Rust to finally cure me completely.
@@swapode i did OOP for over 30years (since the times of GangOfFour), still using it for my largest project yet - over 250k LOC of java now, and have no idea what you are talking about here, care to give specifics? Been using functions and procedures since my school days via pascal and assembly, but once discovered OOP, i never looked back, because disparate functions accessing any data willy-nilly is the opposite of elegance, unless you're hacking some adhoc 100-line-long shell scripts. For how long have you personally used OOP, how large/complex the project was and how did you learn OOP?
@@Alejandro388 for most object oriented approaches we figured out ways to write cleaner code. For example, we want data to be data, so we have DAOs for that and we want classes which does nothing but computations/utility functions (they are the classes with mostly static methods, if they are associated with some resource+state we might go for singleton pattern, etc etc). But, if you pause for a minute, zoom out and take a look. When I see a dao, isn't that just a map with key value pairs. When I see the classes with just a bunch of static methods, isn't that just a collection of nice functions organized inside a namespace. Unrestricted bad OOP design leads to spaghetti code, so we have design patterns (constraints for not writing bad code). Brian is just trying to highlight that (but the language could have been better). - (new to Clojure and loving it)
@@codekomali1760 initially i was hyped about design patterns, but in practice i never really think in terms of them - but very likely i end up using them or variations of them without even knowing. As for DAOs and statics - these are fine, they just prove how you can still do functional/procedural stuff in OOP languages (but you cant do OOP in functinal langs like Clojure), but in my own practice, i rarely need to resolve to such non-OOP technicalities like DAOs, most of my business-case code is nicely encapsulated into classes. I do have buckets of utility functions as statics and some generic-data sturctures for ad-hoc reuse, some nice generic lambadas, and i love them and use them, but they're just small part of the big cake, which is largely driven by OOP
I wouldn't call it "bad OOP", they're just using simple programs to demonstrate the principles. Of course if you JUST wanted to make these programs OOP is overkill, but that's missing the point.
This title made soooooo many people "hate" him by giving a view, 4 comments in heated discussions and even a rating..... This followup wasnt made to prove a point, but to capitalize on the topic that made his channel explode once already
@@XfStef Why performance? OOP is more or less a higher level abstraction of procedural languages like C. I always say that C can just as well be object-oritented, since classes are nothing more than a bit of memory holding data, and then many functions taking in the reference to that memory as the first argument. Features like accessors, interfaces, or generally not having to manually pass the reference to that bit of data as the first argument to begin with are all abstractions of the needs one gets when the code base gets too large and follows such patterns. OOP is not a hell spawn, but it's also not an all hail. Understand what the benefits of OOP are and stop being toxic. Btw, in more complex business logic, OOP tends to be more readable than procedural on average.
A useful programming mindset that tends toward Brian's style, I've experienced, is to write code that minimizes the number of questions that could be asked about it.
There is no point using OOD for a very simple scenario. But using a complex scenario for teaching is not a good idea. So taking a simple scenario made for teaching, and saying "OOD is garbage" is pretty ignorant
But just like you say, using a complex scenario for teaching is not a good idea. That's why he's using simple examples in this video. His arguments against OOP in this video and the previous one stand on their own, but if you really need to see a large example before taking him seriously here's the next video in the series: ua-cam.com/video/V6VP-2aIcSc/v-deo.html
@@patricklangan950 Thanks, but that is still a simple scenario. It is just more lines of code, not more complex. I agree that OOD is not very efficient for simple problems. But I think it is very useful for more complex systems.
@@Soremwar The lesson does not necessarily need to prove that the method is optimal. Since it would be cumbersome to setup a school scenario involving hundreds of branches, and thousands of engineers, it is better to use a simple scenario to teach. The method will seem over complicated and not optimal, but the students will still learn how to use it. And when they find themselves part of a large project, they will be better prepared.
@@BroddeB The problem is they are convincing the students that this is the right way of coding, literally like: Do it otherwise and you'd be doing a huge mistake And BTW, they gotta prove the method is optimal. Otherwise there is no point in showing two pieces of code that do exactly the same thing and saying This is better, do it
A central thesis of OOP is that you should put everything into objects. Object-Oriented. Plus, he has a whole video going over the abstracts of why Object-Oriented Programming is bad. The video is called _Object-Oriented Programming is Bad._
Half the commenters seem to think that "object-oriented programming" means "code that uses classes." Brian Will was pretty clear that he wasn't saying "don't use classes." He could have been a little more explicit about this, but I think he defines OOP as having three main properties: (i) all of a program's functionality is contained in class methods; (ii) all of a program's data is contained in class instances; and (iii) class properties are all private, or predominantly private, so that classes can only ever directly manage their own internal state (i.e. classes are used to "encapsulate" state). Two things about that: First, that's a pretty reasonable way to define OOP. It's pretty much what I learned in university when they were teaching Java and C++. Second, defined in that way, OOP absolutely is terrible.
Very fascinating thought process. It seems clear that you don't despise the use of classes and objects, but that, to use them there must be a reason for them to be used. Much of (if not all) the OOP examples you've picked apart here are quite clearly unnecessarily complicated, not because the author thought that the problem needed to be solved by OOP, but simply because they were trying to give a demo of OO concepts. Unsure if you've already made a followup to this yet or not, but I'd love to see you pick apart real OO projects like you'd mentioned in the video. (namely a small game) Those projects *should* contain OOP examples in which the developer felt that OOP actually offered something.
Beware of anyone who pushes a dogma on you in programming. OO is a box of tools you can use to make your code more flexible, easier to understand, and easier to use. However, you shouldn't blindly use it for everything, just as you shouldn't throw it away due to examples of bad code.
@@joshodom9046 It's like that in every aspect of civilized life. There are rules and laws made to achieve some higher order goal or purpose. But you have to be aware and keep in mind these higher "meta" goals to see when it's reasonable to break the rules. There are traffic laws for example in place in order to prevent accidents. But occasionally there are situations in which in order to prevent an accident you have to break some traffic laws. So you must not blindly follow the rules. And it's the same with programming, you have to keep in mind the higher order, meta goals or laws: You want to write efficient, bug free code that is preferably readable. This is the most important goal, if the suggestions or principles of OOP occasionally compromise this goal, you might want to let it go, in that particular case.
@@freedomgoddess Correct, the *first* response of a java-dev when asked about 'I want to jump from anywhere in a program, to anywhere else in a program' with 'that sounds like a bad idea', and for good reasons. If your response is 'walking away and go complaining to others, how sad their value-judgement made you' instead of asking the follow-up question: 'I wasn't looking for your value-judgement, I was looking for your reasoning *behind* that value judgement. Could you elaborate?' Then the fault lies with you. As for "easier to understand is subjective"..... well key part in the sentence was "tools you *can* use to...": well written Java, is easier to read than terrible written C. well written C, is easier to read than terrible written Java. (regardless of which language the reader is more proficient in.)
The thing is that where ever you look for examples of OOP, you'll find vastly over-engineered code. This isn't because OOP itself is bad and leads to bad practices, it's actually because the examples don't play to the strengths of OOP. And understandably so, since oop is meant to be used in large codebases so you can keep everything modular in case you need to change something. And by the nature of an example, the code for it can't be a huge codebase or program. The conclusion you should draw from this is that both styles of programming have their place where they work best. There isn't a one-size-fits-all solution. OOP is a tool, not a way of life.
No, that's exactly what it means. And because it means that, inherently, you are then taught that you need 'patterns'. Not in the sense of idioms, actual magical patterns that, akin to incantations, must be used in a particular way in particular situations. When the usage of those patterns leads to even worse results, you are told that you did them wrong and you need workshops/lectures/books/tantric yoga to use them properly. It's turtles all the way down.
@@karaloop9544 why? Killing a single cockroach using all the tools from an exterminator would most definitely overcomplicate things. Does that mean it would be simpler for an exterminator to clear an infested house with a can of spray and a flipflop?
You ask the question multiple times, "why is this a class?" And the answer is, ideally, "because it's a highly cohesive unit of behavior that is going to be injected into another unit as a dependency." This allows clean separation of concerns into units that can be tested independently using O(n) tests for the functionality of unit N and O(m) tests for the functionality of unit M, and not O(n*m) tests for the functionality of both those units together where you have to test the cartesian product of all code paths both units could take. OOP doesn't have a lock on this. You can do the same thing in functional programming by taking dependencies as functions and implementing those dependencies as closures over any necessary inputs. Hell, you can do the same in procedural code by using function pointers. The benefit you get, that you're erasing in your rewritten examples, is the inversion of control which requires a callee to be able to dispatch to a method specified by its caller. None of your examples do that, which means none of your methods that have dependencies can be tested independently. It also means you can't pick and choose between implementations of cross-cutting concerns. You couldn't swap in an HTTP file reader in place of the FTP, you couldn't swap in an XML file parser in place of CSV.
Thank you. It seems like his premise (that OOP leads to spaghetti code) is fundamentally undermined by the fact that the examples he gives aren't practical. If you're trying to do something very specific and think that a fully engineered solution will never be used - then by all means, ignore a clean seperation of concerns, and just get the job done. If you're building a full-scale solution to something that is meant to live in a production environment for years to come, then ensuring that the inversion of control principle isn't violated allows you to quickly maintain your code when shifts in your application architecture and environment demand it. As you said, it's not like these things are owned by OOP, but his response to example code trying to implement clean coding practices was to make the code dirty and quick. It should be obvious to anyone who has worked on large projects why doing this can be a very bad thing.
@Nigel Kipling So you agree that inversion of control is a good principle, but you removed it from all your rewritten examples to make them look simpler but be harder to extend? Go's use of structs, interfaces, and receiver functions is basically just OOP without polymorphism. "Should this be a struct?" in Go is the same question with the same answer as "should this be a class?" in Java or Ruby.
Do you really just swap-in things ? Don't you really consider what you swap-in ? Or the fact that same methods can be used is enough, let's say you're swapping mysql with mongodb, good luck with that
@@HowT0Code The data persistence layer needs to understand the differences between MySQL vs MongoDB of course, but any layer above that should be able to operate on the model abstractly without knowledge of what persistent store I'm using. The interface allows me to define what the contract is for those abstract operations, and then the persistence layer only needs to care about conforming to that contract, and any layers above only need to care about using that contract. Even if you aren't swapping anything in or out, even when you have only a single implementation of any given unit, there is still value in separating these concerns into different units, because it lets you test them independently. I can write test cases for the logic of my patent parser without having to stand up an actual FTP server for it to contact, by injecting a mock implementation of the "downloader" dependency that just returns a set of records I define in-memory. I can simulate abstract error conditions without having to cause an actual network error to happen. And frankly the work isn't done if your code isn't tested
I've been a software developer for over 30 years now .... currently I work with C# a lot ... which I love because it lends itself to both procedural and OO paradigms really easily. If I'm cobbling together a little in-house utility I will always use a procedural style ... it's quicker and I'm not expecting the code to need to be scaled up in any way. For anything bigger and anything that customers will use it will always be OO. As other people have commented ... OO is scaleable in a way procedural code is not. I always think there's oceans of difference between a "software scientist" giving opinions on small and contrived programming examples and actually getting stuck deep into countless thousands or millions of lines real world code.
either way you will have to go back and edit the code. classes can be just as hard (if not harder, especially at my current job) to manipulate if you need to add/remove specific features
Yea I came to say this, interfaces and dependency injection could save 10s of hours refactoring code. Wanna switch from SQL server to MySQL? Good thing you used a provider, repository and service classes. Just need to update one file
I agree, the examples went to absurd lengths to make everything an object: when your objects are actions like 'job', or 'marshaler' there's a problem. ... I sat down to eat breakfast with my bow and arrow but couldn't really get the cornflakes on my broad head.
I'm self taught in C++ and through the years I've learned that when you don't need OOP you shouldn't try to force it. However if you do have an object that has several fields and you to keep the data encapsulated (protected or private) from the user and just provide an interface then yes by all means it is worth it in that sense.
The odd thing about C++ and its standard library.. It doesn't embrace encapsulation. Everything is container -> iterator -> algorithm -> iterator -> container or some combination of that pattern. Its odd that a object oriented language would design its standard library without embracing one of the corner stones of OOP.
@Hamad Al Marri Yes, and while the traffic light is red, it does not stop you from driving through the intersection. In both cases you are doing something wrong.
there's a balance which is very hard to strike and very hard to show on examples. in the terms of real production code all those examples are insanely, absurdly overengineered, the last one even in a very weird and hostile way. but in terms of real production code you need a text that primarily preserves and presents the logic, principles, mindset behind the program, so the next programmer can understand and extend those principles for new cases with relative ease... what you propose in all the cases is "specific minimal elegant code to solve the precise given solution". what OOP is about is "the problem presented is an example of a problem set that will expand, catch the principle and make logic that will be easy to expand and relatively easy to comprehend in general even when in almost constant state of flux. (disclaimer: i say "functions". we are not talking about functional programming, yes. we're talking about procedural. when I say functions, i mean procedures, methods, whatever you call it. for me a function is a block of code optionally accepting parameters and returning value. method/procedure i'm used to think of as a block of code optionally accepting parameters and directly manipulating data within parent (i.e. global, or object) scope, not returning a value. you knew what I mean, this is just defense against nitpicking :-D) object oriented thinking is just more akin to how our minds model the world and events within it, therefore people will be better at using it more readily for larger problems. it is also more suitable for solving/simulating complex interconnected systems. you prefer to think of data as data, and functions as functions, "the program", "what is being done to the data". i prefer to think of data as "data program was made to manipulate", and functions, objects, code as "data that describes what to do, how to transform the target data". so that makes me think of a function/method as a type of variable/object. lambdas, delegates, reflection. all the examples are shit, though. any example any talk or OOP design tutorial ever gave is total shit. until you are sat in front of a corporate solution with 2 milion loc, 150k of it autogenerated, divided in 8 projects (database access lib, webservice libs on top of it, and several apps (from MVC through silverlight through MS CRM extension lib to angular SPA) some using the DA libs directly, some connecting to webservices, some connecting to crm and webservices and creating another webservice for a different system with the combined data...)... until you encounter a beast like this, and after the initial mortal dread and the first stressful month you realize that you can already work within that code with relative effectivity... THAT'S when you start to understand: a) what is the point of; b) how to correctly use OOP. but of course there's boatloads of shit and shitloads of bloat in app architecture in any area... also, procedural-oriented creates hideous function names. example: windows api. c api :-D still, I understand most of your points and I've agreed with them for a long time. OOP is interesting that most of its features seem useless unless you specifically encounter a case where one of them helps you (sometimes to a ridiculous degree) reduce code complexity and increase readability. after that, you start seeing potential application of that feature everywhere, even where it's not necessary. when you again realize where it really is necessary, and where it isn't you've mastered that feature :-D most of that features, at least in recent years, were made with huge corporate systems in mind, therefore to truly understand them, you need to encounter a huge corporate system scenario.
Isn't the purpose of all those examples you go through to teach OO programming? Sure, they can be simplified and optimized into less and arguably more readable code. But i think they abstract them out further than most would in practice, for the sake of simplifying their teaching points.
What really got me was his coin flip implementation. The OOP version steps through the literal actions of a coin flip game, like a simulation. The procedural version just models the results with the understanding that the output will be a random player winning with a random coin. But the point of the OOP one wasn't just to output the result of the game. The point was for the game to clearly be played, with the idea that the same techniques apply to much more complicated "games" or systems. So by writing code that doesn't even play the game (or "plays" it in an implicit, non-literal manner), he did that example an injustice, imo.
He had to show 4 examples in one video so it's understandable that the examples were very simple and made for the purpose of teaching, that's why at the beginning he says that he'll rewrite a few thousands lines long OO code to prove his point. That aside, this kind of teaching leads developers to believe that they need to use objects everywhere and, trust me, it happens and it's a real mess. I'm not very experienced, having only worked as a developer for 2 years, but the code some of my workmates have written for the sake of it being purely OO is terribly absurd, long, incomprehensible... OOP is not bad but it needs to be used wisely, otherwise you'll end up with a pretty big mess of a code. That's what I believe this video wants to illustrate.
@@Andy-wv2xj OOP is bad. It’s bad and it teaches devs really bad habits. Especially with java. Some of the java devs I work with are hopeless as after almost 10 years a few of them can’t NOT code everything like the joke OOP examples from the other video. One of my main projects at work has been to chunk pieces of an old bloated javaapp off into microservices. It took a freaking YEAR to sort through the spaghetti of thousands of classes in this single javaapp to the point where some functionalities in it could begin to be isolated. Thus far, I’ve been refactoring about 100-500 or so lines of hardcore OOP java into 20-100 mostly procedural python. The examples being teaching examples makes this WORSE, not better. Unless you’ve drank the OOP koolaid I guess.
I am an OO programmer and never had a problem with absurd examples like these. A class is not always a data object, for example, a service. A service, like "logger," for instance is just that: A logger. Classes to me are ways of grouping and organizing your code. Consider that all Microsoft and Java frameworks and libraries are OO. For example, a String class is an object that both represents a string and contains methods related to manipulating strings, etc. If OO programming is so bad, then the Java and MS languages/frameworks themselves are likewise nonsensical as well and its no wonder that we're able to use them at all. I mean, in procedural programming, it's not uncommon to have a procedure named something like "ProcessOrder" for instance and it usually performs all the steps needed to process the order, but you are often not sure what that all entails. If you ever need to isolate and find the code that specifically performs a certain action like determining the tax rate, would that be in the ProcessOrder procedure or did we load that value when we say chose our state? Or maybe we were able to determine it upon initialization. I can't tell you how many times I've had to search entire applications searching for where a certain piece of logic lived. It just makes sense to place tax logic in a "Tax" class. It keeps us from trying to guess whether or not we decided to put a certain function in a module that we named "GlobalMethods" or if it's in the module where its being used, etc. It just makes more intuitive sense because that's how all frameworks, controls and packages that I've ever used were organized.
@@struki84 In game development OOP isn't used due to performance overhead, in game development real programmers/studios (AAA quality) use plane data group by type (like relational databases structure style) commonly addressed as data-oriented design.
@@AndersenCastaneda depends on the scale of the game. Most indie developers use OOP, but i guess they arent "real programmers". Its just quicker to prototype and test ideas for a single developer using OOP, especially if he uses Unity or another game engine developed with OOP in mind. There is alot less setting up and planning required for OOP than for many other paradigms such as ECS.
Well I think it's more the fucking college teachers who hold on to their theoretical nonsense. The actual software engineers will ultimately experience what is practical and what is not.
The usefulness of UML is only limited to helping you communicate your idea clearer. It's not that useful to design code. It's just for communication. It's most useful when you want to present your idea to your client. That's it.
I was there in the early 90's when OOP started to emerge. I loved it. OOP encouraged developers to better analyse the problem and define clear structures. With the finer grained modules that resulted, version control (exclusive locking - which is all that was available at the time), became more manageable. Who remembers Borland Delphi? The early Gurus were at pains to point out that OOP isn't anything new, it is what you should have been doing all along (but nobody was) with some extra features. Fast forward 20 years, it seems programmers had all been moved to the "Work Prevention Department" en masse. The utterly irrational and insatiable need for 'gurus' to patternize, abstractize, distribute and XMLize everything had me shaking my head. The equally irrational and insatiable need for developers to follow the Gurus effectively ended any possibility that IT projects could host productive teams never mind there being any danger of them delivering robust, effective and performant software. In the latter stages of my career I was involved as a decision maker in various projects under various hats with titles like project manager, technical lead or architect. Invariably I managed to steer the teams away from the trends and managed through constant evangelising to get them to produce as little code as possible, concerned only with delivering functionality and performance for which there was actually a requirement. I found it easy to create productive teams who always delivered. I never understood why other managers were at the mercy of their tech heads, who clearly forgot what they were there for - to deliver software.
@Adam Richard No, you still have goto statements... Of course, these days you can count the legitimate uses for them on the fingers of one foot ; ) It's actually not THAT bad, I'm simplifying. I've used them properly, in situations where it's perfectly acceptable... in ring-zero, mainly bootstraps and kernel drivers.
From my experience, all OOP implementation ends up using as little OOP as the language allows, and this actually creates a ton of issues, for example Java Streams is essentially a functional closure. However, because Java's OOP structure, there are pretty weird rules they had to implement with regards to side-effects
@Adam Richard They are still there in several languages, but except for the complex bail out of branches and loops case, there is very little reason to use them.
@rerunturbografx Not always, there are still a few legitimate uses... But then, when I started some 40 years ago, you needed ASM to do anything in a reasonable time... and goto's and JMPs weren't just a kludge against poor planning. In fact, I still use goto in c, but only for specific use cases in ring-0 code.
7:00 pretty much is something i love about this vid. I mean, i dont agree with the overall idea that OOP is embarrassing, but lets be honest: that class was being used as if it was a namespace, and thats a problem many classes fall into... thats why i think it is very important to think of classes as structs with functions that do stuff to the data they contain. Its like having a struct to contain stuff and a function to affect it, but instead of having the function be external, you have the function inside of the class so you know it is associated to that kind of data. Cases like the one in 7:00 are displays of why overly complicating code really makes no sense. Why would you need a class to do all of the work that class is doing? all of that stuff is far better off as individual functions, put them inside of a namspace if you want to make it even more clear that they are related somehow.
*[...] that class was being used as if it was a namespace [...]* Yes, that class is just a mini-namespace. In C# one might consider making the class and functions static. You'd never have to create an instance of it, since there is no instance related data used anywhere. Which would also save you the (very small) overhead of object creation. But wait ... not creating instances sounds a lot like never creating actual objects from the 'object template' that a class definition usually provides. That's not really OOP anymore, right? Oh wow! That almost sounds, as if an mostly OOP language like C# allows the use of procedural code, if you actually want to use it. *[...] Cases like the one in **7:00** are displays of why overly complicating code really makes no sense. [...]* Well, the overly complicated code boils down to ... public static class BunchOfProceduralStuff { /*Methods go here*/ } I can live with that. ;-) *[...] far better off as individual functions, put them inside of a namspace if you want [...]* Assuming you have a big enough project, you will naturally end with about a dozen methods called Parse(...), Print(...), Convert(...) or such. So yes, you should group methods together that Parse, Print or Convert XML data for example. Maybe another group of methods should handle our JSON data. Yes, that sounds about right. It seems we need a certain type of method to handle these two cases. It's almost, as if two different sets? ... or types? ... or .... classes? of methods might be needed to solve our problem.
@@lupf5689 it feels like you're trying to argue against what i said but somehow ended up saying the exact same things. Are you sure you understand what i said?
@@AlFredo-sx2yy I sure hope so. Basically I was trying to point out that, what was shown in the video was a pretty bad example to demonstrate the flaws of OOP, since, as you already noted, there are no object instances involved anywhere ... so why would you use an OOP approach at all? Maybe it just disturbed me, that you didn't seem to separate the concept of "class" as a template for a container having data and/or methods from the concept of object instances that may be created using that container structure? I'm not sure anymore. Also, it's friday afternoon, there was nothing usefull to do at work anymore and I was bored. Sry :-/
@@lupf5689 dont worry, i mean, that is basically what my comment was about, that the video's example is just showing a situation where using a class makes no sense, which is what i was pointing out. That OOP is not bad, its just that misusing OOP can lead to nonsensical code like what is shown in this video.
You can see on what they relate to, by inspecting the arguments of a function. OO basically just anyway translates to an arguments that is passed as an argument but hidden by many languages. object.function(a) is the same as function(object,a). But somehow OO thinks that one piece of the argument is somehow more important than other. Just as an example: You write a function that concatenates an array with strings together. So your function takes string and array. Do you attach that function to the string or to the array? How about turning an array to a list. Is this a List function because list must turn your function to an array. or is it an array function as the array must know how to "build" itself? How about a function that takes a Hero, an Enemy and a Place. Now you want different logic for all different combinations. Where do you put your "damage" function that calculates the damage? To the Hero, Enemy or to the Place? Now consider just a "damage" function that takes three arguments. A function named "list->array" or a function named "join". If you like you maybe can put them into namespaces or modules. Game.damage() maybe?
"Nobody would actually ever do that." I have. I worked at a company with ~1 million lines of code written in Node.js with a functional style. We rewrote the entire codebase in an object-oriented style using TypeScript. Not only did it help us find and fix many bugs but it made the code more maintainable and let the company scale when previously development had slowed to a halt. The main thing I observed was that allowed us to separate concerns, more easily share code, and eliminate side effects.
Do you mean functional or procedural? Not the same. Your mention of side effect make me think you had an imperative/procedural codebase, not a functional one. I’ve taken “great OO code” and halved its length and reduced side effects by moving to functional paradigm. (Not that I think OOP doesn’t have a place. It’s sometimes useful. Sometimes.)
It has been known for a while that OOP is superfluous when it comes to simple programs with less than ~1000 lines. The entire point of OOP is to make things more accessible. You cannot argue that the java developers did not use OOP properly. Seriously, can you even imagine the java API existing in it's current state if OOP was not a feature of java??
No, without OOP I can't imagine such a bloated, confusing mess of an API where every verb must be phrased as a noun and you have no idea which of 700 Factory classes churns out the functionality you need.
Oh how I miss “FILE *” sometimes. As in, the thing returned by fopen or popen in C. I don’t miss malloc (or new), though. But memory management is orthogonal to OOP.
In fairness, much of the evil that I and others attribute to OOP is really just C++ and Java being such a train wrecking into a burning dumpster. Borland’s Pascal extensions, or something like Eiffel, or even (now) Go seem pretty pragmatic. But yeah, comparing something like the Java.io package to say stdio.h makes you wonder what the hell they were thinking, despite the issues with error checking in the C API.
For the first example, you said “you need to instantiate classes”. What about static methods in classes? They could have work in that case and as you said the class would have served only as a namespace for code separation ( so it won’t be in the global scope )
I had this exact thought, although I do wonder, if you've got a class that only contains static methods, what benefit do you get from having them inside a class.
@@danieldavies765 I do not say one thing is better than the other, I think everything is a tool that fits to solve one problem or another and just like everything-everyone has their own preference. Im just giving a simple example to answer your question. A quick thing that comes to mind from reading the comment: Same reason you would have a normal non-static class- encapsulation. Because you might have some static functions that should be accessible from the public static methods, but you might have some private static methods that should not be available to the outside world. Same thing with properties, you may have some static properties that should not be accessible from the outside world or that only the class itself should be able to change. Im sure someone more experienced could probably give you more and better examples. Those same things would be hard to achieve if you didnt have classes and everything has to be global functions that everyone can access
@@danieldavies765 In Java, the entire Math class is made-up of static methods! It's one place to store them all for easy use by multiple programs, projects and programmers. You could ask the question: 'Why do languages use common "libraries?"
Wow, nice! This is great. Large systems, let's say Salesforce Commerce Cloud, are written in Java and have a rich OOP design, BUT when we write code to use the system it's 100% procedural because we don't need to re-write the object model, we just need to use it do work with code. This idea has greatly democratized development and allows simple, fast solutions to problems.
When pursuing dogma, you inevitably find a plethora of examples where that dogma fails to accomplish. Data analysis should give way to action precisely when it needs to.
as a regular user of Java, i can see where you’re coming from and why you’re saying OOP is bad. i use Java for bigger projects in which it is nice to have objects and such for the organization of the large codebase. as many people have said in these comments, OOP is terrible for small projects and wayyy more useful for bigger projects.
What you want isn't OOP, it's a proper module system. Classical OOP is pretty terrible at modularity. Robert Harper, a CMU professor, famously called OOP "anit-modular", a fact which is obvious to most, but still manages to elicit a violent reaction from kids indoctrinated in the OOP way in the late 90's/early 2000's. I presume it's because it makes them very uncomfortable. The three pillars of OOP -- inheritance, encapsulation, and polymorphism -- have all long sense fallen. No one even defends those any more. Inheritance as the primary means of reuse is unthinkable today, but it was orthodoxy not long ago! That's always been a problem with OOP. It was never clearly defined. It was more a vague mix of ideas that never really came together in to a coherent concept. It's probably why we found ourselves with a new trend within OOP every couple years. Each time promising that this is the one idea that'll finally allow OOP to deliver. Fortunately, the hype finally seems to have died and the majority are starting to look at OOP with a critical eye. I expect the next trend to be more measured. Probably a mix of functional and structured programming.
@@recompile There's no single best way to implement anything. I think you're expecting too much. And I have to wonder how long you've been writing software if you've never found something as simple as encapsulation useful.
@@recompile Wow, you are not using inheritance, encapsulation, and polymorphism ? Well maybe you are just not implementing the right kind of software. Sometimes you just need 2-3 services classes and a main class. Good programmers should know when to use functionnal programming, procedural programming and OOP. Alone they will look messy but together you can build beautiful and maintainable code.
recompile Modules with OOP is easy. You have a module that accomplishes a specific group of tasks, such as working with a database. It contains defined objects for interfacing with the module, like an API. Then, it has objects hidden to the user of the module that help carry out those tasks. The module may be dependent upon other modules, such as those that define basic data types. This adds abstraction that makes the higher level programming much easier. It makes debugging easier, etc. This could be done without OOP, but OOP can make this easier and more readable for larger projects.
@@Austin1990 What about something like pattern matching and type algebras vs polymorphism with inheritance and interfaces? Do you think it is easier to handle those situations with dynamic dispatching or a visitor pattern rather than having a built-in language abstraction to do that (I am talking about old school OO, not modern OO languages such as C# where now you have pattern matching, like Java for example)? And what do you think about advanced type systems that support higher-kinded polymorphism that mainstream OO languages generally lack?
For me it is just a matter of maintainability, readbility, and a little of reliabilty (a.k.a don't write code unnecessarily hacky). If you prefer procedural, fp, or oop, go for it as long as I can undesrtand what you had on your mind when you wrote that, or better, as long as a junior can understand what's going on. Personally I don't take it too seriously, sometimes I would use oop just to encapsulate methods, other times to encapsulate state, or just use procedural, fp or whatever feels more convenient. What I would not want is a soup of miscelaneous functions which do a lot of unrelated things, since in that case you would need to memorize all code to know what to touch and what code breaks what.
If you trained your mind to think that spaghetti code is "readable and reliable", then look a simplified procedural variations of your pasta code and declare them as being "unreadable" - congratulations, your mind has been shattered.
4 роки тому+226
I once maintained a project that was developed by a guy with exactly this same philosophy. It was hell. Nothing but long, mono-classes with godlike powers. What you advocate here makes sense - for small examples/apps. Once the project gets to a certain size, the 'embarrassing' separation comes very handy.
You know you can separate responsability without being oop, right? That's what he's advocating know the difference between when you need an object, vs static class, vs. procedural.
@@nobytes2 He questions why a data-less class exists as it (allegedly) should just be static and the concept of instantiation an instance makes no sense. The problem with that assertion is that it completely shuts out the possibility of mocking (and thus unit testing), and having interchangeable implementations (e.g. different CSV parsing approaches), as you cannot derive or swap out static methods. It simply cannot be achieved without containing the behavior in an instance (and therefore class). Using global scope is NOT equivalent, nor does it provide the exact same benefits.
More hell it is if the code is separated in tiny classes, and you have to look for the definition in another file, and then you forgot what the original problem was. I rather prefer mono classes. Functions should do the separation.
@@samuellourenco9526 yeah, so typically when someone talks trash about other person pick of language or style, it's typically some fanatic, not a professional, who cannot take a look for another perspective than his own, and judge the benefits/drawback of other languages/approaches. Especially it shows when someone advocates smth. using oversimplified examples and extrapolating it to whole world. Just an example. I have here mono class, which was written by mono-classes fanatic. That bloody thing has 20k LOC, almost 2MB. It takes several second for IDE just to open it and highligh it. By default intellij will not provide intellisense features for file >2.5M, so we're close. Navigation in it is nightmare, worse than thousands of files. In normally decomposed project, you can navigate by package by type of class or functionality you working on. Here, you can navigate only by line number, or searching for function by name. Theoretically by named code blocks. But it's significantly worse than any other approach.
Here is what you did wrong: You chose examples that were made specifically to showcase OOP. Of course they are over engineered. OOP becomes useful when you need repeating patterns in large programs. Or when you need to access the same objects/data from multiple places. This will never be necessary in 100 lines of code.
"You chose examples that were made specifically to showcase OOP. Of course they are over engineered." There is a problem when every demonstration of how to make elegant, simplified, maintainable code using a particular architecture results in inelegant, complicated, unmaintainable code. Essentially, you're saying his mistake was using it as directed...
Personal experience is that OOP is beneficial over procedural for most general, non-trivial and non-throwaway programs that aren't better solved with alternatives such as a functional or logic programming language; the problem here is with trivial problems that were tackled in a badly engineered way, making it easy to find fault though this is not with the tools but with those who used them. There is definitely a knack to OO design, asking oneself the right questions, imagining what concepts and kinds of things would be useful to have exist in a solution, what questions those things should be able to answer and what behaviours they should have. Done well, a solution can then fall into place easily, be straightforward to understand by others, grow and maintain. When posing on the spot OO design thought experiments to undergrads, some can do this quite easily but most struggle or even fail entirely, suggesting that the way of thinking required is not nurtured and developed at Uni. An OO solution will then very likely seem awkward, confusing and even frustrating to develop, with the resultant code being contrived, muddled and relatively hard to understand.The methodology is sound, but does require good training to use it well unless it is something that one just grasps naturally.
@trollnerd You've missed my point, and being unnecessarily rude. UE is not a *demonstration* of OO -- it is a piece of software. My point is that when people deliberately attempt to demonstrate the principles of OO, they almost universally produce examples of inelegant, complicated, unmaintainable code. This indicates a problem in their thinking regarding OO. I have never looked at the UE source code, but I would be very surprised if it was a hardcore objects-everywhere architecture... even if we disregard certain 3D rendering stages which are highly unlikely to be OO. Strict OO means never using structs, because structs separate data and code logic. I would be surprised if UE didn't have a single struct in its codebase...
This isn't an argument against data / objects which are being used and reused within a service. You can easily just make global data holders and a simple mutex system to handle multiple calls to them.
The first time I intentionally used OOP was around 1986, when I wrote a base driver class for a printer server, then immediately created sub-classes for serial and parallel ports which could reuse 95% of the base class, with just a few extra lines added for the different ways to do IO port communication, before calling the parent method. Some time later I got an 8-port serial card, which could reuse nearly all of the base serial code, just extending it to poll all 8 ports on each interrupt/poll interval. Since then pretty much _all_ my polymorphic code has used the classic function pointer approach. :-)
You can always take an example and say "uh, I don't need all those classes I could just do this" And that's the issue with examples: they're just that, examples that can't possibly represent the whole picture of what you'd actually be doing in a real code base. Take the coin flipping game program for example: in itself, it's really simple and I would argue that even YOUR code was already too complicated, you could have written everything in the main just fine. To which you'd probably reply something like "yes, but as soon as I need to be able to play from somewhere else in my code it gets hard to read..." and you'd be absolutely right, that's why we have functions. Now imagine that you're using a game engine, with a player, a myriad of other types of entities etc... The developpers who made the engine didn't just have your little coing flipping game in mind. In an actual non-trivial game, even the player becomes a potentially really complex entity, with a lot more data to handle, and a lot more interfaces to handle that data. You need somewhere to store said data, and functions to interact with it, a class provides both at the same time in a single place. And then there's inheritance, abstract types and all these things I won't even try to discuss here because it would get way too long. Case and point being that a limited set of really simple examples (however well chosen they might be) is going to fall a little short for demonstrating how powerful OOP can be. Over engineering is bad, that's something we can agree on. But if you want to make simple example, obviously you'll have to do a fair bit of it, because I think you'd be equally as confused if the example consisted of a super complex library that actually takes advantage of what OOP has to offer. It's a tradeoff. Of course we can write simpler code, but that's completely besides the point.
@@NoeLPZC Yeah, if you just shoved a complex ass problem down a student's throat, then you are probably going to lost them. It is good to inch them toward more complex code with examples that are simple enough to not need OOP to teach them how to do it.
Huh. But isn’t all computer memory nothing but a 1-dimensional sequence of bytes, and doesn’t the cpu work through a program 1 instruction after another?
@@Grunchy005 You're right, but code doesn't always run top-to-bottom down the page. There are loops, conditions and functions that point the processor at different lines than the one directly underneath it.
Hey man! I've just seen the dislikes... I've been watching your stuff for a few days and I was like YES this is exactly how I feel and how I do things. (The Bad Way) Thanks for all the vids. I've been learning DOD for a while now, and I gotta say I just love coding way way more right now. I just get shit done instead of preparing for the fucking apocalypse with 4 abstract classes, 14 use cases I fucking imagined out of my ass and 3 more interfaces I have to implement. Slow is smooth, smooth is fast should be simple is smooth, smooth is fast. for us
As a hobbyist I appreciate this video. Recently I "converted" some of my scripts to include classes, because surface level research suggests I should use classes, objects, methods. And the result is that I create a single use class that does the exact same thing the function did and is never called again in the entire script. "Objects" are useful with actual objects. When I want to build a GUI for my script, it's nice to have a button class that handles the button name, the display text and the function it calls and I can define everything in a single line. But for the config files I think I need only two basic functions: load it and save it. Whatever happens in between these two actions can also be done with functions. Maybe if my script required 5 or 10 config files it would make sense, but that would no longer be a script, it would be an actual program.
Yeah pretty much the same process I went through. I started as a data scientist so in school you didn't exactly get taught how to code, but just how to use code to get the results you need. Therefore, most of what I wrote was (ugly) procedural code. As I got better I also started reading up on stuff and was like you "oh I need to use classes and stuff". Then years later I look at code I wrote when I started using OOP paradigm and in 9 out of 10 cases I'm like "wtf this is so dumb and overengineered".
Not said in the video is that when you have the classes there you could further abstracting that into an interface. If you have interfaces you can have different implementations of something that does a job. That way you separate that responsibility into the object and when someone else goes to add functionality or fix a bug, they don't need to know what the other part specifically does, only that it outputs still follow the interface. Of course, procedurally coding to solve the specific issue at hand nets simpler and more specific code. Well designed OOP is a complexity trade off you do so that in the future it is easier to change bits and maintain the code, specially by other people.
The example where you refactor the polymorphic solution into a switch statement is a good example of cleaning up code. However, I don't think this is strictly an issue with OO; rather, it is an issue of expressivity. In essence, Item is a typed function. That is, it's an interface (a base class since this is Ruby) with a single method. This switch statement solution is a closed system because the only way to change it is to modify the code. This is an example of the expression problem. Polymorphism is one way to deal with this because instead of hardcoding the cases, the caller is required to provide the case they're interested in. I agree that this is overkill for this small example, but I think it's important to point out that this is very useful in scenarios where programmers do not control this code and need to be able to extend it. The same thing is true for the argument parser example. You're taking a general solution and making it specific. This is all well and good, but defeats the point of making the solution general. I agree that general solutions are not always useful, but they still are useful. And they don't have to be implemented in an OO-style. These issues transcend OO design patterns, which is why I brought them up.
+Jeremy Heiler This video focus on "How to rewrite OOP as procedural", and not on "How to make more reusable and extensible code by using procedural over OOP". All of his examples actually fall shorter on extensibility.
Jeremy, I think your objection supports Brian's point... the exception proves the rule. A slavish devotion to extendability is the hobgoblin of OOP minds. Yes, polymorphism can be applied to provide extendability, but it is usually not a worthwhile complication to the system.
I think you are always going to be able to find examples like this. OOP's strengths are in its ability to scale and to have abstractions. Small toy examples will always look better as procedural code because they don't need to leverage those strengths.
There are plenty of large non-OOP projects that have no problem with organization like the Linux kernel, and there are plenty of large OOP projects that are horribly disorganized, showing it's up to the lead architect's skill, not the paradigm, to keep code organized in large systems. That's how OOP sells itself (that it helps keeps code organized when systems become large), but that's not actually what OOP excels at. OOP excels at interfaces. Say I write a library for users to interact with. Creating an interface can make it easy for them to use my library. OOP is not required here, eg Python libraries are written in C, but OOP a well suited tool when it comes to this kind of development. Furthermore OOP excels at creating natural types. A natural type is a type that acts how you would expect it to, as if it came with the programming language itself. So, int is a natural type. String is a natural type, but barely. BigInt is a natural type. class UtilityWorker is not a natural type. The problem is, natural types require operator overloading, and arguably zero cost abstractions, so only Rust and C++ have this ability. But if you need it OOP excels at this too. (Though technically this is just another kind of interface.)
Inheritance is what makes OOP really bad if you need to change some of your UML diagrams. When you write OO code you are encouraged to extract the same logic into smaller abstract classes, then you inherit that behavior in a couple of derived classes. When you need to change that structure somewhere along the inheritance chain, the entire thing becomes a mess. It's better to use composition over inheritance to make it more maintainable in the future, for the cost of a little bit more boilerplate code. When you write in OO style you tend to write absolutely everything with classes. Even the "toy examples" which could be done with a couple of functions. It introduces a lot of unnecessary complexity and makes it harder to reason about.
Don't think it scales very well really. The web of objects, inheritance, factories and design patterns in general makes it a complete mess after some time. Seen it so many times.
27:06 👏👏👏👏👏 I agree 100% with you Brian. In my years of software development, I continue seeing efforts made to "make programming easy" and hearing claims that "programming is not hard". These two beliefs are pervasive and affirmed by the industry to lower the bar of entry to just anyone. Books, weekend bootcamps, "Hour of Code", etc. all contribute to flood the software development market with low quality workers. Tool, library and framework makers work tirelessly to abstract complexity away (typically just moving it elsewhere) so programmers "don't have to understand" what or why they are doing what they do. When asked, they'll parrot: "Industry standard", "there's a tutorial", "experts agree", etc. Scary times we work in.
you make it sound like what they are doing is irrational when it's not. in the absolute gluttony of computing power we live in, lowering the standards means more workers means less wages
You could make a video like this about EVERY programming paradigm. Bottom line: They are all tools in the toolbox. OOP has a place. Procedural has a place. AOP has a place. They all have strengths and weaknesses, and ultimately work best in tandem with each other.
Indomitus1973 True, but when I went to university OOP was taught as the modern, superior way of programming which were more maintainable and readable than procedural code and you should ALWAYS prefer it maybe except for writing an OS. Possible that it's different now or at other universities, but I think if you had such an education and see the flaws of OOP for many problems, you appreciate such a video.
@@storerestore The level of inexperience and ignorance in that statement is dumb-founding. This is why I engage the equivalent of flat-Earther technologists.
I largely agree, but I have two objections: 1. Specialized types enable compile time checking. Having a CommandLineArgDefs type (sorry for that name, there's probably a better one) instead of a hash map makes it possible to check whether you accidentally are using some other hash map (with the same key/value types) in that context. Of course OOP doesn't do much to help you with that - something like Haskell's newtype is much more appropriate. 2. The use of polymorphism as shown by you is a matter of taste. You don't like it to do the things you've shown here and that's fine, others feel differently and that's also fine. But polymorphism has another advantage: It allows someone else to expand upon your code without having them change it. As an example, take a language that has a more complex notion of what a number may be (and sees operators just as functions with infix notation). It already has '+' defined and at a place where a programmer cannot change it (and thus cannot add to a large switch statement). If the programmer adds Complex Numbers or Surreal Numbers or anything like that without polymorphic functions would need to define a new function, like "add" maybe. With polymorphic functions the can define a new version of '+' for all relevant combinations of differently typed numbers. This has the added benefit that, in a language with proper type inference, a whole host of other functions defined on top of '+' now also may work correctly on these newly defined number types. The same goes for libraries.
There's a lot of negative comments and dislikes for this video, so I just wanted to say thank you. This was definitely helpful for me. Everyone's defending OOP by saying 'well you're not supposed to use OOP for everything'. I've never actually encountered learning material that mentions that, though. Just like the lectures you roasted, everyone says OOP is great, and uses narrow scope examples to demonstrate how to use it. So people go out and use OOP how they were shown to use it, and you get the problems you've talked about. You download a project, and you spend hours just trying to build a mental map of how everything flows because simple code was divided up into a million pieces to make it 'eXteNSiBle'
14:17 the same argument you make that visual representation of code is only good for small amount of cases... is actually the same argument for object oriented code and against procedural code with larger functions. How do you miss that?
I can say that OO design has helped me tremendously throughout my career. Simple patterns such as Factory, Strategy, State, help sooooo much when dealing with complex problems.
@@paulie-g Or, you hold a minority opinion for a reason :) By the way, treat people with respect. I was stating a simple opinion, and you were disrespectful. I'm sure your coworkers love you.
@@123214matt It's a minority opinion because ability is normally distributed ('bell curve' to you). OO, the misappropriation of pre-existing idioms as novel 'OO design patterns', and 'patterns' created solely to deal with deficiencies in and unnecessary complexities introduced by OO, are the creations of first-order monkeys to help second-order monkeys produce something that has a chance of working and not being complete trash. That's why you found it 'helped you tremendously'. Incidentally, also why this channel isn't for you. Yes, there is value in helping those in the middle of the bell curve be ~useful, primarily from my perspective in relieving us from writing code for banks and all the other soul-destroyingly boring garbage. If OO were the optimal, or even anywhere near optimal way to do that, I'd advocate for it. It isn't. It fails even at this and it fails *hard*. My co-workers appreciate my candour and if they do not, they do not remain co-workers. I run an LKML-style meritocracy - something people with non-zero clue and chops are very comfortable with, while those without are not, emitting a bothersome constant whining sound and handing out unsolicited life advice.
Your talking about learning basic algorithmic structures and stratagies. This isn't about oops, it's about learning the basics of coding. With a good grounding in the basics you don't need oops or any other paradigm to implement these and other algorithms, Just sufficient knowledge of the language you're coding in. I'm not sure if you're saying you had issues grasping some of these algo's, but found how oops implemented them helped, or you simply didn't learn them prior.
@@kaseyboles30 I was just saying it helped keep complex situations simple. I haven't used other paradigms extensively though, so I can't say how OOP stacks up against functional, procedural, etc.
Write about 20k lines of code (LoC) for an initial release with 3-5 devs and a formal scrum/kanban team, expect another 50-70k LoC over 5 years from 20+ developers of various competency. For your code contract, write unit tests, component tests, contract tests, and integration tests. Let's also consider exposing the API, versioning, documentation for the end user and the developer, performance and logging. What if we want to extract functionality from the app for use in other projects or maybe convert it into a library or smaller (micro)services (because now you have the budget for horizontal scaling)? There is a balance between ease of development, maintainability, testable code, and performance. Procedural code is fine in the scope of one-off scripts. When it comes to releasing an real app into the wild... I'll stick with OOP as part of the development procedure.
Linus Torvalds and Linux says hi... (a very large colaborative code base all in C and low level, 90% will never make something that hard in our lifes - ok C can replicate some OO concepts but it is not OO by nature - just to say that it all depends in the quality of the developer, it is about the carpenter not the hammer). But I agree that for a team of inexperienced junior developers OO can help making life easier, so a senior can keep things under control more easly (and it all depends on the project, e.g. videogames and OO love each other, but in other areas it is overkill).
@Nigel Kipling sorry did you just copy and paste 100 lines of code and add a suffix to the function name to add some more functionality. Go home you utter peice of ignorance
I love how so many comments fall back on truisms: "choose the right tool for the job" (usually in looong form). That statement is worthless. It doesn't pass the "not-test": "Do not choose the right tool for the job". Noone would ever agree to that. Therefore its negation (the truism) is also a completely general and meaningless statement to highly specific critique...
because you cant give highly specific critique to discredit a highly general tool. to say "you should never use x" is extremely general, but naturally you dont critique that ridiculous generalization, but the comments pointing out a very context dependent approach to determining solutions to problems (which is literally all that works) are what is illogical here. thats the only general statement that is true. if the answer doesnt start with "it depends", or "compared to what", its the wrong answer
A lot of critics of this video appear to be arguing that of COURSE the procedural code looked simpler, because these were simple examples to begin with that were used to make the object oriented solutions easier to understand. That's a reasonable point, but I disagree. I deal with absurdly complex object oriented code on a regular basis. Typically, it's not complex because what it is doing is complex, it's complex because the compartmentalized code is all over the place. For maintenance purposes, I've gone in and created Helper classes to move sets of changes that typically go together all into the same file, so it's clear to whatever newbie developer where all the pieces are (they're in this one file!), so they don't miss anything. In so doing, I've done exactly what Brian predicts: I've created yet another class without improving functionality, but only to meet a particular vision of where the code should be contained. The useful unit of work is typically NOT whatever classes people dream up when writing code. Command objects, manager objects, controller objects, factory objects, etc., don't have any conceptual basis in the code, except as blocks of code that hold other blocks of code. Most classes, as typically coded, are just namespaces, not actual entities that you'd use to accomplish tasks. The command/manager/controller object merely contains the methods that actually do the commanding/managing/controlling. And in turn these objects reference and call still other objects that do the same thing. In most of the cases where there are very complicated workings of code, and we are worried about the code being maintainable in the long run, procedural code that lets us read what is being called and how it is being called and what kind of side effects it might have at the top level (or close to the top level). When it's split up into objects, supposedly to be more maintainable, all that has been done is to obscure how the code really works, and obscures all the potential bugs. Yes, the "var result = command.Run();" is delightfully short, and you know that the command got run, but without knowing the state of the command or what the Run() method does, you've got a few hours of testing to figure out why and how that error that keeps appearing in the logs is being caused. If instead, it were just a method such as "updateInventoryEquipment(inventoryId, equipmentList);" suddenly there is no state, just arguments. I can test with whatever arguments I'd like without instantiating the entire IoC framework, and debug the problem in minutes instead of hours. People keep on saying that if the OO is designed right, then it really is simpler than procedural. Well, I can make the same argument in reverse: if the procedural code is designed right, it really is better than OO. That's NOT my argument, I'm pointing out that saying "if OO is done right, it works", while a reasonable statement, completely fails as an argument, for the same reason that Socialists always say that whatever Socialist system that has collapsed simply wasn't done right, never mind that "not really Socialist" appears to describe all real-world Socialism. So if an OO system that is too complicated to work with can always be described as "it wasn't done right", why does that seem to describe all OO systems? So, in my real world of real world OO systems, I see only "it wasn't done right" OO systems, your ideal of "OO done right" doesn't really exist. And Brian's argument is valid, not just for these trivial OO examples, but pretty much every real life OO example I have ever encountered. This isn't to argue that OO is "bad". Objects are useful. The argument here is that making objects the primary building blocks of code results in worse code than making procedural methods the primary building blocks of code. You end up with lots of objects that you really don't need, and those objects in turn tend to hide what the code is really doing. Maybe there is some ideal OO approach that is utterly beautiful and disproves my arguments, but if it is so very rarely encountered in real life (never, in my experience), then I have to agree with Brian that a mixed procedural/object approach is better, where objects exist, but are secondary entities, not primary ones.
I don't really think the problem is that the examples were simple. The problem is that they were just, IMHO, terrible. I'm not criticizing Brian for choosing them. But they don't do OOP any favours simply because they're terrible. I don't really have a problem with having to stick everything into classes. Yes, you end up with classes that are essentially code modules. Even if they have some state. While it might not be ideal, that's not really the problem. The problem is taking OOP too far. And I'm certainly guilty of writing convoluted OO code. Typically as a result of the constrains of the language or platform. I wasn't keen on scratching my left ear using my right hand while standing on the left leg, squinting my right eye and singing the anthem. But if it's what I have to do to get what I want, then I sometimes do it. I also don't agree that UML is useless. It's just a tool. Yes, like 15 years ago I tried doing the full monty, everything by the book, and I just felt like a bureaucrat. Most of the models were simply useless, waste of time. I would hate having to completely model a project. But it can be a useful tool. However, it's just a tool. It won't miraculously make a poor design great. And it doesn't guarantee you'll arrive at a great design. It just allows you to show what's going on which can give you insight. Back at the university, I also created a library for argument parsing. Much more ambitious than the one presented here. Including comments, it ended up over 100 kB. :-) It was OO and most of the methods were written in a functional style (a lot of data processing). And it contained some of the aforementioned overhead ear scratching because I was trying to achieve a great user experience (I set the bar almost impossibly high) which proved challenging. And the assistant that graded my code was like: This is not how you write C#. But it's the most readable C# I have ever seen. :-) And it had plenty of methods with triple digit line counts. I also made use of operator overloading which often isn't popular. I'm certainly not afraid to break the rules. It's like in other fields. You have to learn the rules to break them. Successfully following them should give you something usable. Breaking them, on the other hand, can give you greatness. Or trash.
I think critics also come from confirmation bias. In few years ago, I actually watched this video and thought that it came from a guy who doesn't know how to do OOP correctly. At that time, I learned SOLID, Design Patterns, Domain Driven Designs, etc and I considered OOP is the best tool for building software. But now I think I became an OOP hater because of data oriented design and functional programming =)))) And one of my favorite programming language: Rust even enforce not to code in OOP style :)))) And now I think the best way to model real world is through relational modeling (use database or embed it into code), not through some kind of object graphs.
I personally find UML sequence diagrams very useful when faced with undocumented, unknown code and trying to find out how it communicates with the rest of the system.
kippers12isOG Or UML may be used for documenting code so that reverse engineering is not necessary. Anyone who bashes UML has obviously never worked on anything appreciably complex and/or has no regard for understandable code. OOP provides abstraction that is most useful for making code more understandable. Not everyone uses it as such, but someone who disregards that aspect of it already has discredited their criticism of OOP. Namespaces can be used to group things, but namespaces may quickly become cumbersome and verbose. Think of APIs made to accomplish larger jobs. OOP is great for making such tools. And, in larger projects, OOP may be used to construct encapsulated machines with their own APIs. It’s great for working on teams because one sub-team just needs the defined interface of the API to use it. In turn, it makes debugging and refactoring easier as well.
In closing you're referring to the OOP concept of encapsulation I think. I think this is possible because we do it with third-party libraries. Most programmers that program in a high-level language use several third-party libraries that handle things that would be a whole project in their own right like parsing and creating Excel spreadsheet files. You don't have an in-depth knowledge of what these libraries do to use them. You also can't harm them in any way by changes you make to your project code.
He says exactly that, and gives a good explanation of his reasoning, in the video he mentioned at the beginning... His focus in the reasoning was almost exclusively on the encapsulation part. I disagree that oop is bad, however i agree with other comments here and there that adhering to any set of rules too strictly is bad. The best programmer can use many different approaches, in different contexts. The more i see these sorts of things, the more thankful i am to be self taught, and as a consequence, not stuck in with any particular dogma.
Encapsulation at the module or library level is not specific to OOP. Everybody supports that. The debate is whether the more fine-grained encapsulation at the object level is useful.
I'm actually glad you put out these videos. I feel sane now. when i was learning OOP there was this little voice in the back of my head whispering, and I was experiencing some very uncomfortable cognitive dissonance as I simply did what I was taught while simultaneously thinking, "I know this is the right way, why does it still feel like bullshit?". Now I have a little peace of mind.
Great stuff!! I graduated from college in 1978 with a Masters in Computer Science which was when the first Apple I was showing up. All languages were procedural then and rather incomprehensible when coders overused the infamous _GoTo_ statement. The introduction of structured coding techniques, in which coders wrote code with only one entrance and one exit, was a necessary godsend. Object oriented coding was a natural when creating Graphical User Interfaces within an event driven context. But I agree with Brian that their overuse can simply be confusing. Where I think Object Oriented Programming really shines is when code has to be modified and updated. If it's initially done right, OOP can be a great deal easier to change and maintain over time. The commercial computer programmer is always in an environment where the legitimate business needs of his employer are changing faster than the needs can be specified, much less having the additional time to design, code, and test such updates. And my favorite programming language is still C. It really is the closest we can come to having a high level assembler language. And for many applications, the additional runtime overhead of using OOP practices can not be justified. I really do believe that well written C code will be easier to understand by new coders on any given project than most any other programming language. The power of being able to create abstractions at will is what separates the poor programmer from the savants,.. but then the question becomes what's the easiest means to understand, implement, and maintain such abstractions in actual practice. The less abstractions one has to deal with initially, the faster the learning curve, but also the more work to create higher abstractions as later necessities demand. No one would create a single map than can simultaneously serve all the functions that a map can serve. That would simply make the original map incomprehensible. It's much the same with any intellectual tool. One more thought. As a commercial computer programmer, I always thought the most important piece of documentation I should write was what was the business need being served by the software I was writing. It always amazed me how much software was lost, not due to technical reasons, but because management changed,... and the new managers had no idea what the software was still being used for.
Great points! I have long thought that applications should come with a short document of intended use. This document would be like a "Quick Start" document stating how the main features are used, what is the intended workflow using these features, and exactly how this addresses customer needs. This is analogous to market a hammer as a hammer and not as a Swiss army tool.
@@xpusostomos Given I graduated back in 1978, I believe my Masters of Computer Science was worthy for the time. If I had to pick one favorite Computer Language today,.. it would probably be Python,.. although I don't know as much about Python as I would like,.. it seems to be exceptionally well thought of,.. even if it is interpreted rather than compiled.
I've heard a lot of people say "OOP is a mistake". Maybe there are better paradigms, but I don't think this video does a very good job of proving it. The author is too derisive of viewpoints he doesn't hold or understand. He complains about not understanding single-responsibility, then immediately and unironically explains it using different words. In case 1: I'm not sure the author understands what a "class" is. Classes don't have to be existentially deconstructed representations of physical objects; there is no problem in a class being a simple container for logic. You can also have classes (POCOs/POJOs) that are pure data. Classes are just places to put (related) logic and/or data. You might put your 3 patent functions in a "patents.ruby" (?) file that loads into the global namespace; I would put mine in a Patents.cs file, with one extra line declaring the file to "be" a static class. I have more characters to type when I want to invoke my functions, but my global namespace is nice and partitioned, and if there is some intricacy or translation involved in parsing/loading the config, I have a nice private place to put that logic. I would write a Config class that contains a CreateConfig function, and that function would return a Configuration object*. You would write a global function that still returns an object/hashtable. There is almost no difference here. So in my case, yes, I _might_ have an object to dispose of**, but the trade off is less polluted global namespace. I think having code separated into classes makes it a lot easier to mentally parse, rather than a wall of global functions. *My Configuration object would have strongly-typed properties, no need to guess what's in the hashtable at runtime. **If my class is static, I don't even have to instantiate, handle, or dispose of the object. I _am_ interested in learning more about why OOP is a mistake, but so far it has been difficult to find arguments that have weight. It seems like the author and his peers value one form of thinking to the exclusion of everything else, while OOP programmers are perfectly happy using procedural code inside a class function. It seems like OOP can do everything that Procedural programming can do, but is the reverse true?
You can do everything you just said in C without using classes or objects. Object oriented programming can be done in C using structs. Most C kernel driver APIs tend to be closer to OOP. The problem is people design their software around object oriented design instead of OOP being a tool to use when you need it.
@@cbot3400 That's interesting about C, I wonder how much is OOP-like vs actual OOP (like polymorphism). I think I would describe the issue as "people design their software using _inappropriate paradigms_" or even just "incorrectly", rather than pinning it all on OOP.
the true problem with OOP is that you will end up with _state_ everywhere. it's kind of like using global variables instead of locals. it's not that classes are bad, there are use cases for them (containers for example) but writing your whole program in an OOP style actually makes it very hard to reason about what your program is actually doing and in which state it currently is in. what you should do instead is use pure functions where possible (meaning a function that does not depend on any global state, only an its explicit imputs), because they are the best at composition. and move any state as far up the call stack as possible. also try to avoid mutation of state when possible.
@@youareliedtobythemedia That's what I also was thinking. The video didn't do much to address that aspect, which I do believe is the most important point especially when dealing with threads or objects in memory/leaks...etc.
I've done very little OOP and am likely the least experienced person here, but a hybrid approach seemed best for my current project. I'm using an array of structs for my "objects" (in C), and I could have included in each struct a function pointer to further emulate the OOP scheme, but it just seemed to complicate matters. This will be a CLI application. But when I write a companion program with a gui it will definitely be object oriented to handle "events" and certain drawing elements and styles on the canvas.
You can design around state and "objects" (in this case I just mean a bundle of fields) without making your program object oriented. I was like you once, before I realized how trivial it is to not make everything a class and just use plain old functions and structs. I unlearned it by trying to see what it would be like to make a game in pure C, and it wasn't difficult at all.
You can handle events using function pointers in C. All languages have ways to pass functions as parameters. We have had that in lisp since 1958. If your language does not allow you to do that, use a better language
@@PixelThorn one of the advantages of oop is good encapsulation. You change code and the rest of the code stays the same. Also, I don't know how well maintaining a clear flow is possible with procedural, but this code needs globals which can be modified anywhere, making it very hard to understand what is going on at any given time.
@@Watcher-of-Forms Not In today's computer world... I work in CGI and the programs handle Gigabyte size files like"Zbrush, Maya, Blender... they all use python. so your old day's argument is shit in today's world.
Objects are a way of combining a data container together with the actions that can be carried out on that data. That's kinda it. You could just have a standalone data container and then some separate functions that do things with that data, but you'd still be doing object oriented programming, except you're in denial about it. Sure, there are a lot of abuses of OOP and it is good that people are pointing them out. But to say OOP is bad and to be avoided is a bit extreme. P.S. Yes, i know this video is 3 years old, but it popped in my recommended and my inner keyboard warrior was triggered!
Your definition of OOP reads like just "doing things with structured data", which describes all programming in general. C becomes an OOP language. Prolog does too. Unless I'm missing something you meant, why give a new name to "programming" at all? And then how is it meaningful to say OOP is a good way to program?
@@erichardy6013 Because OOP adds those levels of polymorphism, inheritance, etc. Those are not easily achieved with traditional programming (depending on the language). And OOP is a good way to program in the same way that it is a good idea to keep your tools well sorted. A method attached to an object is only meant to work on that object. When changes are made to the data structure, it is easy to identify the methods that need to be updated. If you just have standalone procedures meant to work on a certain data structure, there's nothing actually forcing you to respect that convention. It's all implied. It's a disjointed procedure. Not to mention how hard it may be to understand that it needs to keep up with changes to the main data structure. For most things, yes, you can replace OOP with normal procedural programming. But depending on complexity, your program is going to be a confusing mess. OOP keeps everything in one place and easy to understand.
@@CristiNeagu so the people who are "in denial about using OOP" aren't actually using OOP just because they have structured data and functions that operate on that data. There are a set of other principles like inheritance (polymorphism is a separate point as it can be achieved in many other ways) that make up OOP and people can agree/disagree with their values without lying to themselves
@@erichardy6013 No, they are in denial because they have procedures meant to work only on certain data, they are grouped together with the data structure, except they are not in the same object.
When I start OOP, I was like you, I hated it, I hope that after 4 years, you finally discover why OOP is that powerful in manner of time, concept, conception and project management. I mean, for a really big project, you can't end up with imperative code without using OO concepts (creating a big structure containing related values is totally an OO concept, it's a data object, add function pointers and it's basically an object...). This video... man it's that : 1. Take a school case from a class meant to introduce a parallel concept to OOP 2. Take it as if it was a OOP representative example 3. Pretend that this is ugly code and you can do better without OOP 4. Give a bad coded (sorry :/) equivalent without OOP (or with a worse version using OOP anyway) 5. Repeat 3 times 6. Pretend not to use OOP is better than OOP because of these 4 example Well... I suppose you were not really good with OOP 4 years ago... You were lacking of a lot of knowledge on OOP and on medium programming concepts. So I guess it's ok (and btw sorry if I've been too harsh on this comment, I'm french and I'm not always good with language register)
Well yes, if you define OO as everything using lists, structs and arrays then OO is universal, and even C is OO. But that's not what people mean when they talk about OO.
Brian, I think I kinda agree with you. Thanks for the techniques that you had given in this video. They are really awesome. I think I get what you really mean, it is not about object or class that matter but it is more about 'object-oriented' that gives damaging and false hopes in many ways. That's why it leads to over abstractions and too much thinking on maintainability that leads to too many classes for such small solutions. Now I think we should be careful about the notion of 'object-oriented'. It should be a guideline and not a religion. We should embrace procedural where possible but still we could maintain clean code and SOLID. Thanks.
I was just skimming through the video and I think some of the arguments are a very silly. For example at 13:45 a OO-based code is replaced by a shorter non-OO code and then it is claimed: "I don't have to make the argument why his code is so absurd". That's some strange logic. His code was absurd if it was written for that specific purpose. But it was a simple toy-example to teach certain concepts in OO-programming that might be very stupid to use in this example, but might be very useful in much more complex codes. My day job is a theoretical/mathematical physicist and I do research within theoretical physics. Whenever I want to teach somebody a highly advanced and abstract piece of math, I use the simplest possible example to illustrate the concepts. It's very easy to counter argue: "I can solve this simple math problem with simple mathematics and with fewer calculations, do I need to argue why your advanced machinery is absurd and stupid?". Sure, but for more complex problems you need the more complex tools. The simple absurd example is only for teaching purposes. You didn't argue anything by rewriting simple toy-examples into simpler code, as they were by design not meant to be the best way to write that particular code. But a simple way to illustrate OO-design, which might not be useful unless you have the correct level of complexity and application. I am not saying that OO-design is good, I'm just saying that some of the arguments presented against it here are silly and unserious.
THIS! This video is rather idiotic. The whole "UML is shit".... this is an EXAMPLE. In a real world scenario you cant just write 100.000 little functions all over the place, even if each one is simple. In the real world, with complex systems you HAVE to plan, which is UML for. YOu HAVE to structure your code, which is OOP for. The whole video is just a pointless rant against OOP from someone who seems to never got in contact with a real complex system with more than 1,000 lines of code.
Couple of points: You don't need to manage an instance if it doesn't need a "life-cycle", just make it static. Better yet, let something else manage it for you (DI patterns - not just used for wiring things together like you mention). You sure do want to abstract (using OOP) data persistency for example (stemming from the first example). We have microservices that can be used on premise, or in the cloud for example. Good luck having the same code targeting different data stores without OOP (and testable at that). For the abstract class, maybe he allows you to create functionality that subclasses can implement or override, probably does it in his 3 concrete classes.
I am looking forward to hearing ur experience of proceduralizing the bigger projects (over 10k lines).
4 роки тому
@Sergey Zykov While it's true that the kernel is written in C you need to consider that it's a very low level software, using OOP it's not even an option in this kinds of scenarios.
I'm with you 100%. Using a function is basically saying "Do [something] to this data", where [something] is described by the function name. So functions are readable as hell. Put your branching logic in one place, and then for every if-then or switch that isn't trivial, call a function. Such code is readable, understandable, maintainable, and compact. You know exactly what happened to the data just by looking at it. You know exactly where to go to extend the code or fix a bug. The thing is, when you're working in a corporate environment, you're probably not the one who maintains the code you write (and are probably didn't write the code you maintain). I dread stepping into someone else's OO code... it's a shot in the dark, and you DO need to understand the whole system, or you can't prevent bugs, much less easily find them. OTOH, you can just step through a procedure and understand it quickly. Every time I've seen someone tout the advantages of OOP, they trot out a piece of procedural -- but not functional -- programming with heavy logic in the control structures; so it looks far more complicated than it needs to be.
An object-oriented language doesn't require everything to be in objects. Sometimes I think objects are an extremely intuitive way of thinking, and make structuring your code in an understandable way an easy task. However, if one is writing e.g. Java or C#, that doesn't mean that every bit of logic must use the concept of objects. E.g. in the coin flipping game, as you yourself demonstrated it is possible to write a better way of running the coin game in Java, which is an OOP language. And that fact is what this all comes down to... These examples are simply BAD CODE. You can't make your argument by showing examples that clearly weren't meant to implement objects, and then state that OOP is simply bad. All that you have proven is that sometimes it's bad to think in terms of objects, but that doesn't mean that an OOP language can not be used with another mindset. Objects are just one of the many tools of the languages.
Wrong. Java e.g. requires everything to be objects. And unnecessarily axiomatically so. And no, static isn't it. If you're using static in your Java you're most likely doing something wrong or irresponsibly lazy.
I would like to elaborate one thing about the example given in 14:50. Imagine a situation where this code is in a closed environment, for example on a disc. You, as a programmer, want to extend this functionality. Say you want to add a new item type. Now if the code on the disc was written in an object-oriented fashion, you could easily add a new item by importing the item class, extend it and override the tick behaviour. In don't see how you could do this more easily with the procedural code you have written (using the switch statement). It all boils down to the fact that OOP is not a better way to write more readable code. It makes your code more maintainable, testable and extendable (like the example I gave) because it encapsulates behaviour. And like everything in programming, different situations needs a different solutions. You should always apply the solution that fits the problem and the situation the best. This implies that object-oriented design is not always the way to go.
How often does one extend classes that they have no access to? I've never even considered doing that in over a decade of professional software development...
Late to the party here, but I found your question interesting. Unless I'm misunderstanding your point about a "closed environment", you could extend this functionality by simply adding a new branch to handle the next case. If what you are saying is we don't have access to this method, by that logic, how would we be able to "import the item class"? Irrespective, writing an API that allows developers to add their own items with a given name and values for the various variables (days remaining for example) and then storing items in an appropriate data structure, such as a hashmap, seems like a reasonable solution to extending this functionality procedurally. Better yet, you could provide a callback function in such an API with the appropriate variables exposed as arguments.
10:10 would love to see how all those functions scale in a huge project and how messy that project would be compared to OOP based project. It's unnecessary to use classes until it becomes a necessity.
In what way would it become messy? Once the code grows you split it into multiple modules, exporting only few functions, having many supporting functions. OOP makes members basically become global functions within the scope of its methods and you have no idea what will happen to them
@@kim15742 OOP makes sure you have your functions/methods where they belong. You will never create a class Vehicle that has method meow() in OOP. In functional programming that's way easier to mix up (to put functions in wrong modules for example). Also, OOP has many other techniques to organise the code and logic. "OOP makes members basically become global functions within the scope of its methods and you have no idea what will happen to them" - ? Can you elaborate with examples?
@@coolemur976 In procedural programming each procedure has defined inputs and outputs (in functional programming this is even more strict). In OOP, a method has, in addition to its parameters and return values, full reign on implicit variables outside its scope (member variables). This is the same behavior as global variables and to me behavior of a method is harder to understand than of a procedure
Member variables is better than having some global variables scattered all over the place and used all over the place. "to me behavior of a method is harder to understand than of a procedure". So for you it's harder to understand method behaviour? Perhaps this is the problem? My point was: if you understand OOP and use it right, it scales better than functional in big projects. Is it harder to understand? Maybe. That's subjective. Also, there is a reason why people take OOP studies at universities.
@@coolemur976 Yes, exactly. That's why you don't use global variables in procedural programming. You have a lot more control to make it understandable and well-structured for yourself. And why is the university thing an argument? OOP is compulsory, as is functional programming and procedural programming
OOP has its uses, especially for large scale, complex projects, but I'm sure everyone here knows it. These examples definitely show the power of simplicity. Paradigms have their place, OOP is moreso for a nice way to group things, provide protections and interfaces. There's a lot to love, but sometimes functional is the way to go. That's why I like C++ and other multi-paradigm languages that give you a choice to use whatever paradigm you think is valuable for the situation. Also, on the point of UML, these diagrams are very useful for SRS documents and large-scale projects where certain parts of the system need to be examined. For a coin flip game however, stick with the functional approach haha.
@@martinn.6082 No need to be static. Depending on your language and needs you might want to make it a singleton. The IO classes are usually wrappers around the low level client which is injected. So even if you instantiate multiple you should still be injecting the same client instance. There's nothing instantiated in the business logic. The functions should be passed all the data that they need to produce a transformation and they shouldn't have outside side effects like IO. In Java I've used static classes for this before and I got that from someone doing the same in C#. IO -> transform -> IO -> transform -> IO is what I try to follow. For me it's organized everything in nice separate areas of concern.
You have demonstrated in a very concise way my own journey in adhering to the design principles of OOP. When I attempted I found myself getting lost and making things less readable and concise just to fit the patterns of these expected principles.
Did you stop to ask yourself why you would try to comply with the cult of OOP when you knew that you could have written the program in a few short lines to achieve the desired result? :)
The thing is, when learning OOP, people tend to overuse it, just for the sake of learning it. That's not a bad thing at all. Once you have a solid grasp on OOP, you can use it more efficiently and effectivel
22:37 I would rather use a single hashmap of the sum type of integer, bool and string. That way you avoid scattering across 3 different hashmaps keys that must not duplicate. The sum type should be familiar to anyone doing functional programming, and it can in fact be just as helpful in imperative programming.
I'm not learning anything here expect "when making choices, try not to be an idiot". Well duh! Also, learning examples often teach hard or complex concepts in overly simple examples where the complex concept is not really required. This is because using the complex techniques should be acessible WHILE the new student is a bit confused. After all the student is new to this. Best let them only have one new complex thing at a time. And that is rather hard to set up. If you don't understand why education examples of code are so weird, it might be that you are good at code and bad at teaching.
A common theme in all of these comments is that, "OOP isn't bad, how people tend to approach OOP is bad," but how people approach OOP is also due to how OOP actually works. As was explained in the previous video, using OOP will result in more complexity, restrictions, and rule-breaking than is necessary. You can use classes to create ADTs, for example, but you should then remain procedural and avoid using a superclass. There is no reason to use OOP because your method calls will use object references that result in shared state despite creating a restrictive hierarchy specifically for the purpose of separating state.
As an honest question, Brian (me being a computer science student), don't you think high-level reasoning (statistical modelling) is much easier using OO programming? Many mathematical concepts like graphs can be best expressed through sometimes complicated OO models. Simply said, do you agree that OO programming is the best solution for problems that are already expressed in the OO domain?
The problem with your analogy is that a good language should never be a single tool -- it should be a toolbox containing multiple tools. The problem is that most OO languages make OO mandatory, and you find yourself with a single tool instead of a whole box.
Niall Tracey your explanation lacks logic on so many levels. Use multi paradigm language like C++ then... Should a oop language follow non oop rules? Nonsense
@@wierzba1992 My point is that there shouldn't be such a thing as an OO language, as every production-level app will have features that don't make sense in OO.
@@nialltracey2599 If you don't need OO in your code, you can do it in an OO language (eg: programming everything in a single class, which I'd kill you for on a code review, but it's possible, and for very very simple tasks)
7:10 1) It is trivial to pass objects around and call those methods elsewhere, instead of some nondescriptive function pointers; this could be part of an interface. Otherwise, yes, just use functions. Nobody would argue that. 8:05 2) Hashmaps are (compareatively) slow, not typesafe ("stringly typed"), genereally don't have code completion (IDE support), they are hard to debug, and cannot be checked by code checkers. I am not sure how ruby represents objects, but in any compiled language, yaml or json should get deserialized into native objects. 8:55 3) Yes, that indeed is a fair point. Sometimes, it is easiest to just use a function. Then again: If you use that function in several places, it can get tiresome, or if you have more than one config for different events, then this approach could eliminate errors; or if you need the config object and download method as parameters, then again, an object might be easier to handle. 17:10 4) In that case, you have a point, but in many other cases, this is very undesirable. First, you lose type information (can't say what kind of item you have got), and second, string comparison is very slow. Especially for exceptions, one should never use strings.
1. It is equally trivial to pass around functions. In fact, most OOP languages allow to pass functions as first class objects. 2. Hashmaps are not comparatively slow nor is it not typesafe. It depends on the implementation and language of choice. Code completion/IDE debuggers are generally not a good argument for or against paradigms because they can create these features, and oftentimes I find IDE auto-code changes more annoying than not (Jonathan blow has a video to demonstrate the issues) 3. Config object doesn't need to be an object even as part of parameters. Data is just data, which is what this video is demonstrating. 4. He used string comparison because that was the original code example. Also, re-think what types mean, losing type definition is a valid case in every kind of programming paradigm (for example, OOP allows for recasting and implicit casting, C lang treats pointers and blocks of data simply as block of data, and you can type it to do anything, etc, etc). I think what people misunderstand about this video is that none of this should be surprising or new. You really can't argue against non-OOP implementation because C is such a strong non-OOP language that it alone debunks any argument you can make against people who do not like OOP. The argument is just a reminder of how a more C-like thinking to program construction has advantages over a more Java-like thinking of a program, and that there's almost (and I believe) no advantage for a Java-like implementation using OOP over C-like implementation
String compares in most modern languages are practically free. Do a search for "string interning". You have some very confused and outdated ideas in that rant.
You completely miss the point of OOP and take the worst examples to show how "bad" it is. Of course, small examples can be easily implemented with procedural programming. I wonder if you ever tried writing a bigger program. At some point you definitely start thinking in an OO way eventhough you don't explicitly use OOP language features. I am glad that I am working with OOP projects, when I see single classes that are 2000 lines of code and there are dozens of those in the project.
+theSomething As I explained in the previous video, I don't eschew encapsulation entirely. I just think proper modules of encapsulation are much larger than the typical class. Anywhere from a couple thousand lines to up and beyond 100k. Large non-OOP code bases do exist, e.g. look at git or the Linux kernel.
+theSomething Yes the given examples are extremely bad. I don't program in strict OOP but I use classes/interfaces and so on for most things. Now here - if this is their solution to a OOP program - they failed to execute it. There is SO MUCH redundant code I'm not even starting on the rest. The "days_remaining -=1" part at 16:15 alone drives me nuts. And the solution given in the video has the same kind of redundancy aswell. As far as I'm concerned - both solutions are bad. There are way cleaner and better maintainable solutions to these kind of problems.
+Brian Will the fact that you point to linux kernel as an example of non oop (hint, it's actually oop, just in a non oop language) without mentioning the reasons.. you just confirmed that you are just rambling emptily and have no idea about proper use of oop.
This sounds like less like he's dissing OOP itself and more like he's dissing people who use OOP. So what I got from this is use Objects when you actually need them like at the end where he ultimately wrote things into a constructor and called an Object so I understand what people say when they think the title is misleading or clickbaity.
I agree with a lot of what you’re saying, although I will say that objects are to be used when you need persistence for property values and I’ve re-written a lot of procedural code due to this
According to my professors, that last argument you touched on (about OO making it so you don’t need to know everything to use code) is the only real point of OO. That said, it’s an extremely valuable benefit and I couldn’t disagree more with your take that you should need to know how literally every part your software works. That’s totally unrealistic with any large-scale codebase, and nowhere did I realize this more than at my AWS internship. My first instinct was to try and understand HOW everything worked before I did anything, but you can’t move at a pace acceptable to customers if you try to do that. You absolutely must be able to have as many segments of your code as possible that you can just think of as a black boxes with inputs and outputs and just assume that they do as described. Being able to get by with only knowing WHAT a piece of code does without needing to know HOW is crucial to working at the pace that customer focused firms require. In other words: yes, OO can make it so your code is way harder for others to understand, but that’s because the point is to make it so others don’t have to understand it at all. Function based programming is a much better redress to some of the issues you raised with OO because you can still get this crucial “black-boxing” ability, but don’t have to contort everything around OO dogma. Great discussion to have though, even if I don’t agree with all your points.
> You absolutely must be able to have as many segments of your code as possible that you can just think of as a black boxes with inputs and outputs and just assume that they do as described Functions. They are called Functions. What you are referring to is called abstraction. OO is not the only or even remotely the first way to abstraction. What we do is Class Oriented Programming anyway. Its not OO as Alan Kay (the inventor of OO) imagined
Yes. But there's nothing about the OO paradigm that makes it better at abstraction than good procedural code. Nothing good can come from blurring the distinction between data and algorithms.
With OOP you just pass bundles of closures on bundles of closures on bundles of data everywhere. It's hard to read, hard to debug, and it's always worse for performance with all those layers of indirection. OOP is combining the worst of functional programming with the worst of simple imperative procedural (classless/objectless) programming. OOP is only good for writing and selling books about software "engineering".
Honestly, the only thing I regret about learning Haskell is that it makes using any other language painful in comparison. Rust and Scala are nice but Haskell will always hold a special place in my heart.
@@karlwithak. Binary code is better than any language. Is there any better than binary code? Only local splashes of energy on the space-time comtinuum we called particles.
Actual title: "Overengineered solutions to simple problems are bad."
And its what happens in real life. Requested is a Giant Featureset where, after everything is finished and released etc. you realize none of the features are actually ever used or used in the way they should be used. Its like "Hey, we want giant logs displaying everything" and then after a year you see those logs with just thousands upon thousands of exceptions. Turns out noone reads the logs anyways, but its ok to waste time on those logs. not only your time but also CPU/IO etc. time...
The problem is that the strengths of OOP require non-trivial examples -- however that's almost always out of scope of UA-cam videos and presentations. So, yeah, of course they're going to find overengineered solutions. Like, no sane software engineer would go that approach for merely flipping a coin. However, once you add in needs to extend the game to use other types of 'coins', maybe more players, maybe changing the AI for each player which could be dynamically instanced -- say you want it to become more sophisticated over time - then an OOP approach begins to make sense. But it's all wayyyyy beyond the scope of these demonstrations.
@@ZeruelB Yeah lol, crazy.
deanolium
In the flipping game video, I believe it was specified that the code was overkill but merely an example of the principles.
He is missing the point. Object oriented code is not about classes, data encapsulation, and inheritance. At its heart, is all about interaction and message passing between replaceable entities representing traits of the system, each implementing public interfaces. Therefore, object oriented code is all about interfaces compliance, polymorphism, dynamic binding, delegation, and composition in a safer and cleaner way, leading to greater flexibility. Good object oriented design relies on patterns to allows one to delay critical decisions, do interface implementation swapping (thus reducing risk o vendor locking), and to add new features with minimal work, therefore is suited for big and complex systems, when you may not know ahead of time what the final features are.
This isn't an argument against OOP it's an argument against making extremely complicated solutions to trivial problems. Classes are powerful but not always necessary.
The fact that people respected enough to be giving talks are making these same decisions *across different talks* and teaching them to younger devs kind of does point out something against OOP. OOP is being taught as a tool to solve all problems when it is not necessary, and to me that points to some disconnect between the problem at hand and the tool people use to solve it. And they *will* use the tool they are told to use, especially if its the only thing they have ever been told about. If you were taught from day 1 that *everything* is an Object, then your entire problem solving toolset is based in that idea. OOP and the people teaching it are not teaching how to solve problems, they are teaching how to use OOP. Obviously OOP has uses, and plenty of software is written using that paradigm, but the OOP *mindset* has a tendency to leak its gooey goop into places it shouldn't go.
@@nice_sprite5285 True. And I believe FP is the solution. Sum type, typeclasses and HOF are far superior than whatever those factories and singletons are.
@@alexho5769 I havent experimented much with FP, but from what little I do know about it I think it definitely provides a good way to solve problems with good perf and design. I've had the thought for a long time that what we do in OOP-land seems sort of silly and masturbatory at times, but only more recently had the chance to reform the way I write code to be better. Would you say rust's functional features are a good way to start writing FP? Or if I wanted to learn FP, would i be better off with a "true" or "pure" FP lang like Haskell? Your comment is making me consider branching into that domain a bit
@@nice_sprite5285 Yes I do believe rust is fantastic. It's not pure FP but it does provide a sophisticated type system and FP-like features such as pattern matching and traits, and it's bloody fast ;). I'd say if you want to build something "real" and you're not looking to learn the deep theories behind FP, definitely start with things like Rust, Scala or OCaml. And if you're still interested after that, it's also very beneficial to learn Haskell since it's essentially the Occam's razor of functional languages (but it's harder to build something "real", like a REST API).
And if you're still interested after learning these, it's also fun to dive into the deeply "nerdy" aspects of FP by learning languages (proof assistants) such as Coq, Agda and Lean (but these are highly specialised languages that will definitely require knowledge of Haskell), there you'll learn about type theories and the art of proving program correctness. Note that these are *definitely* not required to understand FP.
Hope this comment helps :)
i think the point is that the Bad OOP is the one beeing taught in classes and the one mostly found in programs
I've been programming for 44 years. Classical, non-object oriented (mainly years ago) and fully OOP. Currently, I manage a system that was 1.5 Million lines of code that I have down to 750,000 lines (that's HALF) - all thru applying OOP techniques. You have to use the right tool for the job (ask any handyman, mechanic or woodworker). OOP isn't the answer in trivial programs. But in big systems and systems that have to adapt to new business rules, it's invaluable. To just say OOP is bad is a total misunderstanding of OOP. You have to LEARN the tools - not just dismiss what you don't understand. You need to study the OOP subject further before you dismiss it.
OOP also isnt the answer in a lot of other things that are insanely popular and useful related to AI/ML. I wouldn't call that trivial. As far as enterprise applications...I get your point. But to call anything else trivial? And also...what would the architecture look like in F# for instance? Still a million lines?
What you say about OOP may be true, the problem is not every software company is made of engineers with 44 years of experience. The OOP I've seen devs write is not great. Mainly the cognitive complexity is high. That's the real issue with OOP IMHO. It's complex. There are still to this day some OOP patterns that simply don't make sense to me. The benefits of which I just haven't seen yet. To me clean code is understandable and testable. I think OOP with DI is great for testing, so it nails one of the requirements.. but it's not always very understandable. Maybe someday when I've been in the industry for as long as you have I'll circle back around and enjoy OOP
@@MaxRunia excellent point
You're right. Use the right tool for the right job. But he has a point, to many people think that oop is the best tool for everything. Even Bjarne Stroustrup have said that oop is a bad choice in may cases.
@@_mr_andersson by most you mean most in python? While those libraries are certainly constructed that way for convenience, I haven't really seen any data scientists build their data pipelines I'm an OO way much (in their day-to-day) work. What I've seen and used mostly ends up being a mix of functional/array or procedural
I could give 100's examples, since I have been working as a developer for over 25 years. But one that pops to mind was back in 2003 or 2004, in a start up company, we developed an extensive video processing, video cataloguing, and video emission platform and the boss wanted a plugin vumeter for the sound volumes for one of the video players. He assigned the task to someone of the team. He took about 2 months to design the complex vumeter with a queue system for the sound samples, etc.etc. and of course all done in OOP C++. The team member was also working simultaneously on other projects, so he did not spend the entire 2 months on just the vumeter.
Even after this, the vumeter never worked properly, and was overcomplex and difficult to debug. The volume levels were all over the place, and obviously did not match the volume in realtime of the video. Even so the boss alloted a big chunk of resourses(2 months of one of the team members) that he was going to ride the sinking ship to the bottom of the ocean, and just kept trying to fix the vumeter to no end.
I secretly took some of my own time, and wrote a vumeter dll in pure C using direct win32 calls(to capture the windows of the app, draw,etc..) and no queue, and no OOP. My vumeter when compiled was 64 kilobytes and had no external dependencies(and probably was even smaller but Windows has a cap due to alighment on PE sizes) My team member's vumeter was well into the megabytes and had various dependencies on third party dlls, sdks, etc.
In the end, my vumeter worked perfectly and the company had to use my version. My boss took me to the side, and was extraordinarly pissed off at me, almost screaming, yelling: why the hell did you make a vumeter, taking time you shouldn't or you could have just helped with the main vumeter project etc.etc.. I have never seen him so mad. Even so the main vumeter project was completely trashed and they only used mine for years to come.
The reason I did not participate in the main project, and just went off and did mine, is that every time I spoke up about overly complex code, and OPP, I was pushed down and ridiculed directly, so the was no reason to argue with people and their devout dogma, I just did what needed to be done.
The problem seems not to be with the OOP vs. procedural approach, but with the architecture and design. You could very well end up with a bad vumeter written in C or any FP language. The people deciding on the technology and design are the issue, not the technology.
Crazy part is that instead of rewarding you, he went off at you
That's exactly what jealous boss does, a good leader doesn't. I guess thats how boss vs leader is differentiated.
@@ShazeAnIn my first job (I just turned 20) I criticized the boss's "3 years in basement" work on a "execution environment" (executing our own programming language in industrial automation equipment, programs downloadable over serial comms) of a new breed of PLC system. "Shut up. You are new here, and besides it exists and it works!". I convinced the other two 20 year olds that what I had in mind was superior, and I argued "let's remove his main argument [it works] by also having 'it exists and it works'". So, on a weekend from Friday to Monday morning, we made a byte code interpreter from scratch, faster, smaller and easier to maintain (all in assembly, btw). On Monday, we assumed that we would need to "stand our ground" to convince the boss. I came a bit a late, and urged the others to "let's go and talk to the boss", and got the answer "We already did. It took less than 5 minutes and the only thing he said was 'Ok. Now finish it.'". I have heard that, that effort was replaced ~25 years later with new implementation in C/C++.
lol, this is why i never just do something that my boss didnt ask for. Im not getting recognition for it, and the extra effort is just going to some big corporation who really couldn't give a shit about you anyway. Why step out of your bounds to help a meaningless project for people who are more concerned with paradigms and the micro management of its employees just to risk your own ass for almost 0 benefit
“Polymorphic dispatch in this example is overkill, therefore all polymorphic dispatch is bad.” This video should just be called “Bad code is bad.”
Object-oriented programming produces bad code.
@@JellyMyst Most of the time... yeah... BUT you can write even more shitty oo code if you try.
@@rosek6585 Oh, trust me, I don't need to try to write bad code.
The point, though, is that object-oriented programming produces bad code more often than some alternatives when you're trying to write good code.
There are a lot of really bad develops, OOP enables them to cause too much damage, like giving a gun to a retard. On the other hand, good programmers can (almost) do perfectly well without oop. Maybe only people with 5+ YEARS of solid C programming experience should be trusted with OOP
@@ptechlead I agree, most devs these days should not be able to write code. They are way too careless with their code and produce problems more often than the rest.
Object-Oriented Programming is not some omnipotent tool that makes every bit of code it touches better. OOP is just a tool in your toolbox of patterns.
Saying we shouldn't use a pattern is as wrong as saying we should use it everywhere.
Forcing any pattern is generally not a good idea except it can be a good learning experience.
Use the pattern that matches your problem.
Captain R. WITTEREL can u plz tell me the story for ur profile pic i seen it every where ?!!
@@majedhk5460 Oh yeah yeah.
ua-cam.com/video/C0sjsSq84QU/v-deo.html
Tell that to Ruby
Couldn't disagree more. OOP is actively terrible, and is never a good idea, and should be avoided. Even in cases of ADT's. Especially in cases of ADT's where OOP propaganda makes ADT's nearly impossible to maintain... No seriously, try writing a gui dialog, the best use case of OOP, it is easier to to with procedural code, even though OOP has "solved" this issue for 30 years. OOP has basically failed to deliver even in its most fundamental use cases.
There are no use cases for OOP, period. It only makes the problem more complicated by building a tower of useless abstractions and by forcing everything to be an object. In my experience, people who are claiming that OOP has any benefits at all simply didn't have enough exposure to the alternatives (i.e. functional programming)
I do like object but i treat them as a feature of a language rather than "EVERYTHING MUST BE AN OBJECT!"
+suckmynobs static!
+Artur K Here's a sane person.
+suckmynobs Actually not quite, every type is based on Object, but Java is based on "Everything is object" principle more than C# is. Look at the difference in "events" in Java and C#.
+suckmynobs Ou, and second thing, if everything is based on Object that will make life easier when you use Reflection
+Artur K Yes thank you! I use Pascal for larger projects and it's entirely common to mix procedural with OO when a class isn't needed.
As a student, I learn a lot from these videos and especially the discussions in the comments. Thank you all for your insights
this sums up both the video + comment section quite perfectly.. as a student, as we all are, we can learn from all methods of solving problems ~ expanding not only our toolkits but also our minds that must first conceptualize the solution before solving it ~ in the end, all are tools to be utilized ~ different tools for different jobs ~ some problems may require a single function, others require an entire model/representation ~ rarely is anything "wrong" in life, just maybe not the *right* place or time..
There are a lot of things I like about OOP. But yes, I see your point. People seem to shoehorn a lot of code into objects when they really don't need to.
Samuel Clemens They have been teaching you wrong then the most classic example being the square and rectangle example.
I've known people who started learning programming and lost interest/gave up as soon as they had to apply OO concepts to solve problems/assignment questions. In other words, they were able to solve those very problems outside of the OO space. This is concerning because they could be adding value to the industry. I wonder if this is a symptom of what the video argues.
@@SimonWoodburyForget fun stuff is most oop programmers now go away from oop basis. What do you think dto's been made for? Or what about ECS pattern in game development? Speaking of ECS, it's adding new entities made easy and mostly bug-free. I think that OOP will stop being a paradigm in a future and will become a side feature which still can be used (interfaces and such) but not as a architecture framework. And you can see it even now in web development where most used patterns like factories, dto's domain driven design and other shit intentionally strays away from old and rusty oop.
@@PerryGrewal My brother gave up on that. He couldn't understand that bunch of stupid things. And I would say to him .. "calm, that's the way" ... But I was wrong. We really don't need it all!
IMO there is a big difference between programming with objects and orienting all of your code toward objects. If all you see are objects, then of course you're going to shoehorn all kinds of things into objects that have no business being there. OOP it's a design philosophy that teaches you to think exclusively in terms of objects. It's an inherently bad design philosophy.
"Hammers are bad because not everything is a nail; here are some examples of people hitting screws with hammers to prove why hammers are terrible."
LOL
@@niccster1061 Wow, this is the perfect metaphor.
Always be on team Depends...... I start every conversation with this caveat.
@BringerOfTheTruth so not only did you not make any points. But you made a blatant assumption and then used THAT to claim he is unqualified to talk about this. I dont give a shit WHICH paradigm is better, your comment was probably the most retarded argument ive ever seen. Like at that point why dont you just say "OOP bad FP good I'm right youre wrong and unqualified cuz i say so. Bye stupid fanboy kid".
@BringerOfTheTruth Are you really suggesting that we should never use object oriented programming?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
"
- Martin Fowler
That's the guy who wrote "refacotring, improving the design of existing code". I've read it and some of the improvements make sense, but others are just cutting code into confetti, like extracting methods that you only use once.
@@1Maklak It increases readability and you lose barely any performance. Most code can be extracted to be a method which has a meaningful name and purpose, which makes your code much more readable and understandable. It also makes sure that you do not have to know the details of what the method does unless that specific method is relevant to you. Extracting pieces of code to a method which you only use once reduce complexity and the amount you have to understand about the code.
@@13b78rug5h To me it decreases readability, as described in this video. I prefer having a pretty long, but segmented function. After method extraction, I get a bunch of smaller function scattered around and possibly even in their own classes. But like I said, much of Fowler's advice is sound, for example that you can make small incremental changes to existing code as you go along doing other stuff with it.
@@1Maklak smaller functions are easier to test than larger functions in my opinion, thats also a reason for single responsability design. But I like to see other opinions as well as this video. Rethinking the way you code and listen to others is always usefull. I also think in Oo you can end up really fast in overcomplicating things.
@@Alx-gj2uz Ah, right, that's true. I never had to do unit testing. It may be that the way people think is wired in different ways, so different approaches are "natural" to different people. For example some people are good with mathematical formulas, while others look for a geometric interpretation, so there's that. I also got reasonably good at procedural style in C before being forced to learn object-oriented (and even then it still didn't make sense to me to put every function inside an object). Some things, like making lots of small classes, design patterns and self-commenting code newer made sense to me, so I was wondering why and then I saw this guy's lectures and everything he says works for me. Those objects, constructors, inheritance, factories and all that other stuff is mostly bloat and noise code that gets in the way of what I'm trying to do. I can put some data and functions manipulating that data together for encapsulation and separation of concerns, but it will be large classes with long and often static functions and it just works. I also usually end up with an "Util" class that's a namespace for static functions that don't have a good place to put them in. Funny think is, when you get people like me and OO people working on the same project, you'll end up with a refactoring war.
After just taking an OOP class at college, and appreciating what it is does, the majority of our coursework was small examples that could easily be done procedurally including the final that I felt force to complicate with classes I can respect what he is saying but I also can see the large scale use cases.
Your understanding here is heading in the right direction. OO, especially with languages like Java, just suck for small things because of all the overhead. However, I love Java for large systems, in large part because of its strong typing, but also because you have lots of options on how you can organize your code and that organization makes dealing with these large code bases so much easier. I am now working with microservices using JavaScript and for these tiny bits of code, a both weak typed language and language not requiring all the OO structure is nice. However, even for these microservices I wish it were TypeScript (strong typed) because it is really hard to understand the data structures being handed around. Just this last week I was working on some code where, if it had been strongly typed I would have had it done in a couple minutes. However it was JavaScript and now I have to wait until I can run it in QA to see the actual data flowing across the wire before I can complete the code. Very annoying.
@@aaronbono4688 strong typing exists outside of OOP
@@walrustrent2001 right, that's why I mentioned typescript.
Same thing happened to me, although my graduation project was medium sized ,it would've taken way longer and been too complicated if I made it with procedural, glad I did it with OOP
I don't understand, most OOP languages are multi-paradigm programming languages anyways. You aren't obligated to use classes all the time. You can use struct, enums, static classes, etc. There are multiple options. So many people are hating on OOP languages while in fact they aren't even aware that those languages can do way more than pure OOP.
I wrote code professionally for 40 years and this type of argument is as old as Fortran. IMHO, OO has its place for certain classes of problems - modern GUIs for just one example. But as with every "new" programming paradigm that comes along there are people who embrace it and promote it as the one and only "truth". The same thing happened with Dijkstra's "Goto less programming"... while structured code is generally a very good idea, there are times when a simple branch instruction can replace a lot of convoluted nested logic and eliminate a lot of cpu cycles popping return addresses off the stack, etc. The same arguments can be found in Relational vs Heirgraphical databases, and even DBM databases. They all have their strengths and weaknesses. Learning when one method is advantageous and when it only adds complexity is part of becoming a good programmer... and being dogmatic (either for or against) any one style in all instances holds one back from being a good programmer IMHO.
I'm curious as to why you think OOP is particularly suited for GUIs when functional reactive programming is used extensively in modern frontend frameworks like React and Elm.
Agreed, this vid is nonsense. There’s more than one way to skin a cat. I constantly write and switch between object based and procedural code. Why write a thesis on this and labour the point. Life is just too short and why the beef?
@@GBGOLC The issue is youngbloods are taught "this is the one true way" (hello agile/oop/rust etc.), you have to grow a greybeard before you learn to recognise 90% of this is bunkem, and someone trying to sell you something, and the only one true way is to have the experience to identify the right tool for the job (and learn how to tell your project manager they are wrong committing to the next new shiny).
Goto statements can always be avoided by just calling methods and should never be used. Good code does not have 3 or more levels of nesting. Once you need more, you just extract a method.
@@tabularasa0606 Makes zero sense. A Goto is an unconditional branch, it is not required (nor desired) to return like an OOP Method. Furthermore, a Goto simply changes the Program Counter and takes a few machine cycles while calling a Method at a minimum must push a return addresses on the stack, and do various initialization tasks that can take HUNDREDS of machine cycles. Why would I waste hundreds of machine cycles for something I could do in less than half a dozen? I think you are confusing a Goto statement with a function call... two very different animals.
I'm not sure you can just say "OOP is bad", the examples you are showing are a bad use of OOP. Doesn't mean that the idea is just null and shouldn't be used.
OOP has very fundamental problems, so much so that OOP best practices (composition over inheritance, dependency injection, ...) can pretty much be boiled down to: "Don't use all the cool features that OOP promises on the blurp". What most people actually find useful about the whole OOP idea is little things like data carrying its own function namespace - foo.doSomething() as opposed to someNamespace.doSomething(foo).
And OOP isn't even particularly good at the things it's designed for, for example an ECS is much better at sharing abstract behaviours over different "classes" of "objects" and doesn't require constant reimagining of a class hierarchy when new aspects are implemented. And it'll probably run faster.
Maybe the biggest sin of OOP is that it pretends that elegant code is the goal of software development while making writing elegant code incredibly hard (if not impossible, because all that complexity is actually only elegant within an OOP context).
But I've been there, I also tried to defend OOP back in the day. In fact it took me a deep dive into Rust to finally cure me completely.
@@swapode i did OOP for over 30years (since the times of GangOfFour), still using it for my largest project yet - over 250k LOC of java now, and have no idea what you are talking about here, care to give specifics? Been using functions and procedures since my school days via pascal and assembly, but once discovered OOP, i never looked back, because disparate functions accessing any data willy-nilly is the opposite of elegance, unless you're hacking some adhoc 100-line-long shell scripts. For how long have you personally used OOP, how large/complex the project was and how did you learn OOP?
@@Alejandro388 for most object oriented approaches we figured out ways to write cleaner code. For example, we want data to be data, so we have DAOs for that and we want classes which does nothing but computations/utility functions (they are the classes with mostly static methods, if they are associated with some resource+state we might go for singleton pattern, etc etc). But, if you pause for a minute, zoom out and take a look. When I see a dao, isn't that just a map with key value pairs. When I see the classes with just a bunch of static methods, isn't that just a collection of nice functions organized inside a namespace. Unrestricted bad OOP design leads to spaghetti code, so we have design patterns (constraints for not writing bad code). Brian is just trying to highlight that (but the language could have been better). - (new to Clojure and loving it)
@@codekomali1760 initially i was hyped about design patterns, but in practice i never really think in terms of them - but very likely i end up using them or variations of them without even knowing. As for DAOs and statics - these are fine, they just prove how you can still do functional/procedural stuff in OOP languages (but you cant do OOP in functinal langs like Clojure), but in my own practice, i rarely need to resolve to such non-OOP technicalities like DAOs, most of my business-case code is nicely encapsulated into classes. I do have buckets of utility functions as statics and some generic-data sturctures for ad-hoc reuse, some nice generic lambadas, and i love them and use them, but they're just small part of the big cake, which is largely driven by OOP
You cant say OOP is BAD but you can say procedural is BAD .. the code he suggests is close to unmaintainable!
if this had the title "Roasting Bad OOP", you'd have 100% likes and an empty comments section
I wouldn't call it "bad OOP", they're just using simple programs to demonstrate the principles. Of course if you JUST wanted to make these programs OOP is overkill, but that's missing the point.
This title made soooooo many people "hate" him by giving a view, 4 comments in heated discussions and even a rating.....
This followup wasnt made to prove a point, but to capitalize on the topic that made his channel explode once already
All OOP is bad.
It's bad conceptually. It's bad when you implement it. It's bad on performance and code readibility.
@@NoeLPZC exactly. so much waht you said.
@@XfStef Why performance? OOP is more or less a higher level abstraction of procedural languages like C. I always say that C can just as well be object-oritented, since classes are nothing more than a bit of memory holding data, and then many functions taking in the reference to that memory as the first argument. Features like accessors, interfaces, or generally not having to manually pass the reference to that bit of data as the first argument to begin with are all abstractions of the needs one gets when the code base gets too large and follows such patterns.
OOP is not a hell spawn, but it's also not an all hail. Understand what the benefits of OOP are and stop being toxic.
Btw, in more complex business logic, OOP tends to be more readable than procedural on average.
"Unified Modelling Language, Universal Modelling Language, whatever who cares... it's f*cking garbage" - that line killed me. You're right, UML is definitely garbage.
ahh leave UML alone, it's okay for quickly modelling a handful of tables in a relational db.
A useful programming mindset that tends toward Brian's style, I've experienced, is to write code that minimizes the number of questions that could be asked about it.
There is no point using OOD for a very simple scenario. But using a complex scenario for teaching is not a good idea. So taking a simple scenario made for teaching, and saying "OOD is garbage" is pretty ignorant
But just like you say, using a complex scenario for teaching is not a good idea. That's why he's using simple examples in this video. His arguments against OOP in this video and the previous one stand on their own, but if you really need to see a large example before taking him seriously here's the next video in the series: ua-cam.com/video/V6VP-2aIcSc/v-deo.html
@@patricklangan950 Thanks, but that is still a simple scenario. It is just more lines of code, not more complex. I agree that OOD is not very efficient for simple problems. But I think it is very useful for more complex systems.
Following your logic, taking a simple scenario made for teaching and saying "OOD is the best" is equally as ignorant
@@Soremwar The lesson does not necessarily need to prove that the method is optimal. Since it would be cumbersome to setup a school scenario involving hundreds of branches, and thousands of engineers, it is better to use a simple scenario to teach. The method will seem over complicated and not optimal, but the students will still learn how to use it. And when they find themselves part of a large project, they will be better prepared.
@@BroddeB The problem is they are convincing the students that this is the right way of coding, literally like: Do it otherwise and you'd be doing a huge mistake
And BTW, they gotta prove the method is optimal. Otherwise there is no point in showing two pieces of code that do exactly the same thing and saying This is better, do it
This seems like more of a "don't put crap into objects when you don't need to" than a case against OOP.
Yeah, there's some food for thought here, but it doesn't seem to criticize OOP so much as it criticizes how people use it
A central thesis of OOP is that you should put everything into objects. Object-Oriented. Plus, he has a whole video going over the abstracts of why Object-Oriented Programming is bad. The video is called _Object-Oriented Programming is Bad._
This dude is just sad really. He obviously cannot seem to be able to design good OOP, then rather than blame himself somehow ends up blaming OOP.
@@pee-buddy i dont think thats the case
@@LanPodder If you know OOP well enough, it would be clear as day that the guy really is hopelessly lost
Half the commenters seem to think that "object-oriented programming" means "code that uses classes." Brian Will was pretty clear that he wasn't saying "don't use classes." He could have been a little more explicit about this, but I think he defines OOP as having three main properties: (i) all of a program's functionality is contained in class methods; (ii) all of a program's data is contained in class instances; and (iii) class properties are all private, or predominantly private, so that classes can only ever directly manage their own internal state (i.e. classes are used to "encapsulate" state). Two things about that:
First, that's a pretty reasonable way to define OOP. It's pretty much what I learned in university when they were teaching Java and C++.
Second, defined in that way, OOP absolutely is terrible.
Very fascinating thought process. It seems clear that you don't despise the use of classes and objects, but that, to use them there must be a reason for them to be used.
Much of (if not all) the OOP examples you've picked apart here are quite clearly unnecessarily complicated, not because the author thought that the problem needed to be solved by OOP, but simply because they were trying to give a demo of OO concepts. Unsure if you've already made a followup to this yet or not, but I'd love to see you pick apart real OO projects like you'd mentioned in the video. (namely a small game) Those projects *should* contain OOP examples in which the developer felt that OOP actually offered something.
Unfortunately the start to all of his oop videos and/or the titles are either extremely clickbait or evidence of just how much he hates oop
I started programming almost two years ago this was one of the first videos I found.
I come back to it every six months to see if I understand it yet.
Beware of anyone who pushes a dogma on you in programming. OO is a box of tools you can use to make your code more flexible, easier to understand, and easier to use. However, you shouldn't blindly use it for everything, just as you shouldn't throw it away due to examples of bad code.
@@joshodom9046 It's like that in every aspect of civilized life. There are rules and laws made to achieve some higher order goal or purpose.
But you have to be aware and keep in mind these higher "meta" goals to see when it's reasonable to break the rules.
There are traffic laws for example in place in order to prevent accidents. But occasionally there are situations in which in order to prevent an accident you have to break some traffic laws.
So you must not blindly follow the rules.
And it's the same with programming, you have to keep in mind the higher order, meta goals or laws:
You want to write efficient, bug free code that is preferably readable.
This is the most important goal, if the suggestions or principles of OOP occasionally compromise this goal, you might want to let it go, in that particular case.
And you now understand it? Cuz i have around 4 years and lets say that this is the first rime i see ruby code and went "welp, this makes sense?"
@@YanYanicantbelievethistakenffs Haha getting there.
@@freedomgoddess Correct, the *first* response of a java-dev when asked about 'I want to jump from anywhere in a program, to anywhere else in a program' with 'that sounds like a bad idea', and for good reasons.
If your response is 'walking away and go complaining to others, how sad their value-judgement made you' instead of asking the follow-up question: 'I wasn't looking for your value-judgement, I was looking for your reasoning *behind* that value judgement. Could you elaborate?' Then the fault lies with you.
As for "easier to understand is subjective"..... well key part in the sentence was "tools you *can* use to...":
well written Java, is easier to read than terrible written C.
well written C, is easier to read than terrible written Java. (regardless of which language the reader is more proficient in.)
The thing is that where ever you look for examples of OOP, you'll find vastly over-engineered code. This isn't because OOP itself is bad and leads to bad practices, it's actually because the examples don't play to the strengths of OOP. And understandably so, since oop is meant to be used in large codebases so you can keep everything modular in case you need to change something. And by the nature of an example, the code for it can't be a huge codebase or program. The conclusion you should draw from this is that both styles of programming have their place where they work best. There isn't a one-size-fits-all solution. OOP is a tool, not a way of life.
No, that's exactly what it means. And because it means that, inherently, you are then taught that you need 'patterns'. Not in the sense of idioms, actual magical patterns that, akin to incantations, must be used in a particular way in particular situations. When the usage of those patterns leads to even worse results, you are told that you did them wrong and you need workshops/lectures/books/tantric yoga to use them properly. It's turtles all the way down.
Modularity is independent of language paradigm.
@@kaseyboles30 agreed. What I want to see is someone demonstrate that OOP gives you some kind of modularity that a procedural approach can't.
Well, if OOP complicates simple examples to the point of semi-obfuscation then that doesn't exactly bode well for actually complex programs, does it?
@@karaloop9544 why? Killing a single cockroach using all the tools from an exterminator would most definitely overcomplicate things. Does that mean it would be simpler for an exterminator to clear an infested house with a can of spray and a flipflop?
Some people may fear they will lose their jobs if the code is too easy to understand.
Obbb-vio-us.
I insist:
Classes are made to HIDE what is behind.
Now they train there AIs to create bad OO code.
You ask the question multiple times, "why is this a class?" And the answer is, ideally, "because it's a highly cohesive unit of behavior that is going to be injected into another unit as a dependency."
This allows clean separation of concerns into units that can be tested independently using O(n) tests for the functionality of unit N and O(m) tests for the functionality of unit M, and not O(n*m) tests for the functionality of both those units together where you have to test the cartesian product of all code paths both units could take.
OOP doesn't have a lock on this. You can do the same thing in functional programming by taking dependencies as functions and implementing those dependencies as closures over any necessary inputs. Hell, you can do the same in procedural code by using function pointers.
The benefit you get, that you're erasing in your rewritten examples, is the inversion of control which requires a callee to be able to dispatch to a method specified by its caller. None of your examples do that, which means none of your methods that have dependencies can be tested independently. It also means you can't pick and choose between implementations of cross-cutting concerns. You couldn't swap in an HTTP file reader in place of the FTP, you couldn't swap in an XML file parser in place of CSV.
I was looking for this to see if someone explained it to his simple ass.
Thank you. It seems like his premise (that OOP leads to spaghetti code) is fundamentally undermined by the fact that the examples he gives aren't practical. If you're trying to do something very specific and think that a fully engineered solution will never be used - then by all means, ignore a clean seperation of concerns, and just get the job done. If you're building a full-scale solution to something that is meant to live in a production environment for years to come, then ensuring that the inversion of control principle isn't violated allows you to quickly maintain your code when shifts in your application architecture and environment demand it.
As you said, it's not like these things are owned by OOP, but his response to example code trying to implement clean coding practices was to make the code dirty and quick. It should be obvious to anyone who has worked on large projects why doing this can be a very bad thing.
@Nigel Kipling So you agree that inversion of control is a good principle, but you removed it from all your rewritten examples to make them look simpler but be harder to extend?
Go's use of structs, interfaces, and receiver functions is basically just OOP without polymorphism. "Should this be a struct?" in Go is the same question with the same answer as "should this be a class?" in Java or Ruby.
Do you really just swap-in things ? Don't you really consider what you swap-in ? Or the fact that same methods can be used is enough, let's say you're swapping mysql with mongodb, good luck with that
@@HowT0Code The data persistence layer needs to understand the differences between MySQL vs MongoDB of course, but any layer above that should be able to operate on the model abstractly without knowledge of what persistent store I'm using. The interface allows me to define what the contract is for those abstract operations, and then the persistence layer only needs to care about conforming to that contract, and any layers above only need to care about using that contract.
Even if you aren't swapping anything in or out, even when you have only a single implementation of any given unit, there is still value in separating these concerns into different units, because it lets you test them independently. I can write test cases for the logic of my patent parser without having to stand up an actual FTP server for it to contact, by injecting a mock implementation of the "downloader" dependency that just returns a set of records I define in-memory. I can simulate abstract error conditions without having to cause an actual network error to happen.
And frankly the work isn't done if your code isn't tested
I think the main point is: "Know your tools and how to use them. Less is more."
I've been a software developer for over 30 years now .... currently I work with C# a lot ... which I love because it lends itself to both procedural and OO paradigms really easily. If I'm cobbling together a little in-house utility I will always use a procedural style ... it's quicker and I'm not expecting the code to need to be scaled up in any way. For anything bigger and anything that customers will use it will always be OO. As other people have commented ... OO is scaleable in a way procedural code is not. I always think there's oceans of difference between a "software scientist" giving opinions on small and contrived programming examples and actually getting stuck deep into countless thousands or millions of lines real world code.
@Marcus - The universe is written in Objective - C
either way you will have to go back and edit the code. classes can be just as hard (if not harder, especially at my current job) to manipulate if you need to add/remove specific features
Yea I came to say this, interfaces and dependency injection could save 10s of hours refactoring code. Wanna switch from SQL server to MySQL? Good thing you used a provider, repository and service classes. Just need to update one file
@@steamdecklife agreed. Although my old company called them dats access layers.
@@brodyyucan the universe is written in binary, and how it gets there is a matter of logic
I agree, the examples went to absurd lengths to make everything an object: when your objects are actions like 'job', or 'marshaler' there's a problem. ... I sat down to eat breakfast with my bow and arrow but couldn't really get the cornflakes on my broad head.
Everything is just an action. action operating on data and transforming data.
I'm self taught in C++ and through the years I've learned that when you don't need OOP you shouldn't try to force it. However if you do have an object that has several fields and you to keep the data encapsulated (protected or private) from the user and just provide an interface then yes by all means it is worth it in that sense.
The odd thing about C++ and its standard library.. It doesn't embrace encapsulation. Everything is container -> iterator -> algorithm -> iterator -> container or some combination of that pattern. Its odd that a object oriented language would design its standard library without embracing one of the corner stones of OOP.
@Hamad Al Marri Yes, and while the traffic light is red, it does not stop you from driving through the intersection. In both cases you are doing something wrong.
Seeing by the replies self taught programming wasn't enough
@@gerardgauthier4876 C++ is not an object oriented language.
@@MidnightBloomDev Well you clearly have your head up your ass.
there's a balance which is very hard to strike and very hard to show on examples. in the terms of real production code all those examples are insanely, absurdly overengineered, the last one even in a very weird and hostile way. but in terms of real production code you need a text that primarily preserves and presents the logic, principles, mindset behind the program, so the next programmer can understand and extend those principles for new cases with relative ease... what you propose in all the cases is "specific minimal elegant code to solve the precise given solution". what OOP is about is "the problem presented is an example of a problem set that will expand, catch the principle and make logic that will be easy to expand and relatively easy to comprehend in general even when in almost constant state of flux.
(disclaimer: i say "functions". we are not talking about functional programming, yes. we're talking about procedural. when I say functions, i mean procedures, methods, whatever you call it. for me a function is a block of code optionally accepting parameters and returning value. method/procedure i'm used to think of as a block of code optionally accepting parameters and directly manipulating data within parent (i.e. global, or object) scope, not returning a value.
you knew what I mean, this is just defense against nitpicking :-D)
object oriented thinking is just more akin to how our minds model the world and events within it, therefore people will be better at using it more readily for larger problems. it is also more suitable for solving/simulating complex interconnected systems. you prefer to think of data as data, and functions as functions, "the program", "what is being done to the data". i prefer to think of data as "data program was made to manipulate", and functions, objects, code as "data that describes what to do, how to transform the target data". so that makes me think of a function/method as a type of variable/object. lambdas, delegates, reflection.
all the examples are shit, though. any example any talk or OOP design tutorial ever gave is total shit. until you are sat in front of a corporate solution with 2 milion loc, 150k of it autogenerated, divided in 8 projects (database access lib, webservice libs on top of it, and several apps (from MVC through silverlight through MS CRM extension lib to angular SPA) some using the DA libs directly, some connecting to webservices, some connecting to crm and webservices and creating another webservice for a different system with the combined data...)... until you encounter a beast like this, and after the initial mortal dread and the first stressful month you realize that you can already work within that code with relative effectivity... THAT'S when you start to understand: a) what is the point of; b) how to correctly use OOP.
but of course there's boatloads of shit and shitloads of bloat in app architecture in any area...
also, procedural-oriented creates hideous function names. example: windows api. c api :-D
still, I understand most of your points and I've agreed with them for a long time. OOP is interesting that most of its features seem useless unless you specifically encounter a case where one of them helps you (sometimes to a ridiculous degree) reduce code complexity and increase readability. after that, you start seeing potential application of that feature everywhere, even where it's not necessary. when you again realize where it really is necessary, and where it isn't you've mastered that feature :-D
most of that features, at least in recent years, were made with huge corporate systems in mind, therefore to truly understand them, you need to encounter a huge corporate system scenario.
Isn't the purpose of all those examples you go through to teach OO programming? Sure, they can be simplified and optimized into less and arguably more readable code. But i think they abstract them out further than most would in practice, for the sake of simplifying their teaching points.
What really got me was his coin flip implementation. The OOP version steps through the literal actions of a coin flip game, like a simulation. The procedural version just models the results with the understanding that the output will be a random player winning with a random coin.
But the point of the OOP one wasn't just to output the result of the game. The point was for the game to clearly be played, with the idea that the same techniques apply to much more complicated "games" or systems. So by writing code that doesn't even play the game (or "plays" it in an implicit, non-literal manner), he did that example an injustice, imo.
@@Twosies20 Sure. from that moment I knew this video has a big garbage
He had to show 4 examples in one video so it's understandable that the examples were very simple and made for the purpose of teaching, that's why at the beginning he says that he'll rewrite a few thousands lines long OO code to prove his point. That aside, this kind of teaching leads developers to believe that they need to use objects everywhere and, trust me, it happens and it's a real mess. I'm not very experienced, having only worked as a developer for 2 years, but the code some of my workmates have written for the sake of it being purely OO is terribly absurd, long, incomprehensible... OOP is not bad but it needs to be used wisely, otherwise you'll end up with a pretty big mess of a code. That's what I believe this video wants to illustrate.
@@JerryO1995 Yes, but for those bad code and designs, he ends up by saying OOP is bad is the thing that i CAN do the same with FP.
@@Andy-wv2xj OOP is bad. It’s bad and it teaches devs really bad habits. Especially with java. Some of the java devs I work with are hopeless as after almost 10 years a few of them can’t NOT code everything like the joke OOP examples from the other video. One of my main projects at work has been to chunk pieces of an old bloated javaapp off into microservices. It took a freaking YEAR to sort through the spaghetti of thousands of classes in this single javaapp to the point where some functionalities in it could begin to be isolated. Thus far, I’ve been refactoring about 100-500 or so lines of hardcore OOP java into 20-100 mostly procedural python.
The examples being teaching examples makes this WORSE, not better. Unless you’ve drank the OOP koolaid I guess.
I am an OO programmer and never had a problem with absurd examples like these. A class is not always a data object, for example, a service. A service, like "logger," for instance is just that: A logger. Classes to me are ways of grouping and organizing your code. Consider that all Microsoft and Java frameworks and libraries are OO. For example, a String class is an object that both represents a string and contains methods related to manipulating strings, etc. If OO programming is so bad, then the Java and MS languages/frameworks themselves are likewise nonsensical as well and its no wonder that we're able to use them at all. I mean, in procedural programming, it's not uncommon to have a procedure named something like "ProcessOrder" for instance and it usually performs all the steps needed to process the order, but you are often not sure what that all entails. If you ever need to isolate and find the code that specifically performs a certain action like determining the tax rate, would that be in the ProcessOrder procedure or did we load that value when we say chose our state? Or maybe we were able to determine it upon initialization. I can't tell you how many times I've had to search entire applications searching for where a certain piece of logic lived. It just makes sense to place tax logic in a "Tax" class. It keeps us from trying to guess whether or not we decided to put a certain function in a module that we named "GlobalMethods" or if it's in the module where its being used, etc. It just makes more intuitive sense because that's how all frameworks, controls and packages that I've ever used were organized.
Not to mention that certain development is much easier when handling objects. Like game development.
@@struki84 In game development OOP isn't used due to performance overhead, in game development real programmers/studios (AAA quality) use plane data group by type (like relational databases structure style) commonly addressed as data-oriented design.
@@AndersenCastaneda "real programmers"
@@AndersenCastaneda We don't talk about the Error 404 Quality not found examples
@@AndersenCastaneda depends on the scale of the game. Most indie developers use OOP, but i guess they arent "real programmers". Its just quicker to prototype and test ideas for a single developer using OOP, especially if he uses Unity or another game engine developed with OOP in mind. There is alot less setting up and planning required for OOP than for many other paradigms such as ECS.
"UML is just fucking garbage" -- You're my hero, Mr Brian Will.
Well I think it's more the fucking college teachers who hold on to their theoretical nonsense. The actual software engineers will ultimately experience what is practical and what is not.
I am a CS tutor. I am always wondering why teachers are teaching this garbage to the next generation of programmers.
The usefulness of UML is only limited to helping you communicate your idea clearer. It's not that useful to design code. It's just for communication. It's most useful when you want to present your idea to your client. That's it.
I was there in the early 90's when OOP started to emerge. I loved it. OOP encouraged developers to better analyse the problem and define clear structures. With the finer grained modules that resulted, version control (exclusive locking - which is all that was available at the time), became more manageable. Who remembers Borland Delphi? The early Gurus were at pains to point out that OOP isn't anything new, it is what you should have been doing all along (but nobody was) with some extra features.
Fast forward 20 years, it seems programmers had all been moved to the "Work Prevention Department" en masse. The utterly irrational and insatiable need for 'gurus' to patternize, abstractize, distribute and XMLize everything had me shaking my head. The equally irrational and insatiable need for developers to follow the Gurus effectively ended any possibility that IT projects could host productive teams never mind there being any danger of them delivering robust, effective and performant software.
In the latter stages of my career I was involved as a decision maker in various projects under various hats with titles like project manager, technical lead or architect. Invariably I managed to steer the teams away from the trends and managed through constant evangelising to get them to produce as little code as possible, concerned only with delivering functionality and performance for which there was actually a requirement. I found it easy to create productive teams who always delivered. I never understood why other managers were at the mercy of their tech heads, who clearly forgot what they were there for - to deliver software.
How bout multi paradigm programming, everything has it's place... A pure anything would probably not be the best way
THENewTubez this sounds very rational
@Adam Richard No, you still have goto statements...
Of course, these days you can count the legitimate uses for them on the fingers of one foot ; )
It's actually not THAT bad, I'm simplifying. I've used them properly, in situations where it's perfectly acceptable... in ring-zero, mainly bootstraps and kernel drivers.
From my experience, all OOP implementation ends up using as little OOP as the language allows, and this actually creates a ton of issues, for example Java Streams is essentially a functional closure. However, because Java's OOP structure, there are pretty weird rules they had to implement with regards to side-effects
@Adam Richard They are still there in several languages, but except for the complex bail out of branches and loops case, there is very little reason to use them.
@rerunturbografx Not always, there are still a few legitimate uses...
But then, when I started some 40 years ago, you needed ASM to do anything in a reasonable time... and goto's and JMPs weren't just a kludge against poor planning. In fact, I still use goto in c, but only for specific use cases in ring-0 code.
7:00 pretty much is something i love about this vid. I mean, i dont agree with the overall idea that OOP is embarrassing, but lets be honest: that class was being used as if it was a namespace, and thats a problem many classes fall into... thats why i think it is very important to think of classes as structs with functions that do stuff to the data they contain. Its like having a struct to contain stuff and a function to affect it, but instead of having the function be external, you have the function inside of the class so you know it is associated to that kind of data. Cases like the one in 7:00 are displays of why overly complicating code really makes no sense. Why would you need a class to do all of the work that class is doing? all of that stuff is far better off as individual functions, put them inside of a namspace if you want to make it even more clear that they are related somehow.
*[...] that class was being used as if it was a namespace [...]*
Yes, that class is just a mini-namespace. In C# one might consider making the class and functions static. You'd never have to create an instance of it, since there is no instance related data used anywhere. Which would also save you the (very small) overhead of object creation. But wait ... not creating instances sounds a lot like never creating actual objects from the 'object template' that a class definition usually provides. That's not really OOP anymore, right? Oh wow! That almost sounds, as if an mostly OOP language like C# allows the use of procedural code, if you actually want to use it.
*[...] Cases like the one in **7:00** are displays of why overly complicating code really makes no sense. [...]*
Well, the overly complicated code boils down to ...
public static class BunchOfProceduralStuff {
/*Methods go here*/
}
I can live with that. ;-)
*[...] far better off as individual functions, put them inside of a namspace if you want [...]*
Assuming you have a big enough project, you will naturally end with about a dozen methods called Parse(...), Print(...), Convert(...) or such. So yes, you should group methods together that Parse, Print or Convert XML data for example. Maybe another group of methods should handle our JSON data. Yes, that sounds about right. It seems we need a certain type of method to handle these two cases. It's almost, as if two different sets? ... or types? ... or .... classes? of methods might be needed to solve our problem.
@@lupf5689 it feels like you're trying to argue against what i said but somehow ended up saying the exact same things. Are you sure you understand what i said?
@@AlFredo-sx2yy I sure hope so. Basically I was trying to point out that, what was shown in the video was a pretty bad example to demonstrate the flaws of OOP, since, as you already noted, there are no object instances involved anywhere ... so why would you use an OOP approach at all?
Maybe it just disturbed me, that you didn't seem to separate the concept of "class" as a template for a container having data and/or methods from the concept of object instances that may be created using that container structure? I'm not sure anymore.
Also, it's friday afternoon, there was nothing usefull to do at work anymore and I was bored.
Sry :-/
@@lupf5689 dont worry, i mean, that is basically what my comment was about, that the video's example is just showing a situation where using a class makes no sense, which is what i was pointing out. That OOP is not bad, its just that misusing OOP can lead to nonsensical code like what is shown in this video.
You can see on what they relate to, by inspecting the arguments of a function. OO basically just anyway translates to an arguments that is passed as an argument but hidden by many languages. object.function(a) is the same as function(object,a). But somehow OO thinks that one piece of the argument is somehow more important than other.
Just as an example: You write a function that concatenates an array with strings together. So your function takes string and array. Do you attach that function to the string or to the array?
How about turning an array to a list. Is this a List function because list must turn your function to an array. or is it an array function as the array must know how to "build" itself?
How about a function that takes a Hero, an Enemy and a Place. Now you want different logic for all different combinations.
Where do you put your "damage" function that calculates the damage? To the Hero, Enemy or to the Place?
Now consider just a "damage" function that takes three arguments. A function named "list->array" or a function named "join".
If you like you maybe can put them into namespaces or modules. Game.damage() maybe?
"Nobody would actually ever do that."
I have. I worked at a company with ~1 million lines of code written in Node.js with a functional style. We rewrote the entire codebase in an object-oriented style using TypeScript.
Not only did it help us find and fix many bugs but it made the code more maintainable and let the company scale when previously development had slowed to a halt.
The main thing I observed was that allowed us to separate concerns, more easily share code, and eliminate side effects.
Chris Seltzer isn’t the whole point of functional programming to eliminate sideeffects?
Wouldn't rewriting a codebase have that effect regardless of the paradigms used?
@@steven1671 In my opinion yes. A rewrite is almost always going to be better no matter what.
@@steven1671 given that "charitability" to a disagreeing comment but not to the video showing bad code regardless of paradigm?
Do you mean functional or procedural? Not the same. Your mention of side effect make me think you had an imperative/procedural codebase, not a functional one. I’ve taken “great OO code” and halved its length and reduced side effects by moving to functional paradigm. (Not that I think OOP doesn’t have a place. It’s sometimes useful. Sometimes.)
It has been known for a while that OOP is superfluous when it comes to simple programs with less than ~1000 lines.
The entire point of OOP is to make things more accessible. You cannot argue that the java developers did not use OOP properly.
Seriously, can you even imagine the java API existing in it's current state if OOP was not a feature of java??
No, without OOP I can't imagine such a bloated, confusing mess of an API where every verb must be phrased as a noun and you have no idea which of 700 Factory classes churns out the functionality you need.
@@JellyMyst That sums up my experience with Java.
Oh how I miss “FILE *” sometimes. As in, the thing returned by fopen or popen in C.
I don’t miss malloc (or new), though. But memory management is orthogonal to OOP.
In fairness, much of the evil that I and others attribute to OOP is really just C++ and Java being such a train wrecking into a burning dumpster.
Borland’s Pascal extensions, or something like Eiffel, or even (now) Go seem pretty pragmatic.
But yeah, comparing something like the Java.io package to say stdio.h makes you wonder what the hell they were thinking, despite the issues with error checking in the C API.
@@JellyMyst at least "HTTPRequestSingletonFactory" is more readable than "r_x *"
For the first example, you said “you need to instantiate classes”. What about static methods in classes? They could have work in that case and as you said the class would have served only as a namespace for code separation ( so it won’t be in the global scope )
Still orthopedic.
I had this exact thought, although I do wonder, if you've got a class that only contains static methods, what benefit do you get from having them inside a class.
@@danieldavies765
I do not say one thing is better than the other, I think everything is a tool that fits to solve one problem or another and just like everything-everyone has their own preference. Im just giving a simple example to answer your question.
A quick thing that comes to mind from reading the comment:
Same reason you would have a normal non-static class- encapsulation.
Because you might have some static functions that should be accessible from the public static methods, but you might have some private static methods that should not be available to the outside world.
Same thing with properties, you may have some static properties that should not be accessible from the outside world or that only the class itself should be able to change.
Im sure someone more experienced could probably give you more and better examples.
Those same things would be hard to achieve if you didnt have classes and everything has to be global functions that everyone can access
Generally you can use a file as a namespace instead of a class in this situation. (ymmv)
@@danieldavies765 In Java, the entire Math class is made-up of static methods! It's one place to store them all for easy use by multiple programs, projects and programmers. You could ask the question: 'Why do languages use common "libraries?"
Wow, nice! This is great. Large systems, let's say Salesforce Commerce Cloud, are written in Java and have a rich OOP design, BUT when we write code to use the system it's 100% procedural because we don't need to re-write the object model, we just need to use it do work with code. This idea has greatly democratized development and allows simple, fast solutions to problems.
When pursuing dogma, you inevitably find a plethora of examples where that dogma fails to accomplish. Data analysis should give way to action precisely when it needs to.
as a regular user of Java, i can see where you’re coming from and why you’re saying OOP is bad. i use Java for bigger projects in which it is nice to have objects and such for the organization of the large codebase. as many people have said in these comments, OOP is terrible for small projects and wayyy more useful for bigger projects.
What you want isn't OOP, it's a proper module system. Classical OOP is pretty terrible at modularity. Robert Harper, a CMU professor, famously called OOP "anit-modular", a fact which is obvious to most, but still manages to elicit a violent reaction from kids indoctrinated in the OOP way in the late 90's/early 2000's. I presume it's because it makes them very uncomfortable.
The three pillars of OOP -- inheritance, encapsulation, and polymorphism -- have all long sense fallen. No one even defends those any more. Inheritance as the primary means of reuse is unthinkable today, but it was orthodoxy not long ago!
That's always been a problem with OOP. It was never clearly defined. It was more a vague mix of ideas that never really came together in to a coherent concept. It's probably why we found ourselves with a new trend within OOP every couple years. Each time promising that this is the one idea that'll finally allow OOP to deliver.
Fortunately, the hype finally seems to have died and the majority are starting to look at OOP with a critical eye. I expect the next trend to be more measured. Probably a mix of functional and structured programming.
@@recompile There's no single best way to implement anything. I think you're expecting too much. And I have to wonder how long you've been writing software if you've never found something as simple as encapsulation useful.
@@recompile Wow, you are not using inheritance, encapsulation, and polymorphism ? Well maybe you are just not implementing the right kind of software. Sometimes you just need 2-3 services classes and a main class. Good programmers should know when to use functionnal programming, procedural programming and OOP. Alone they will look messy but together you can build beautiful and maintainable code.
recompile
Modules with OOP is easy. You have a module that accomplishes a specific group of tasks, such as working with a database. It contains defined objects for interfacing with the module, like an API. Then, it has objects hidden to the user of the module that help carry out those tasks. The module may be dependent upon other modules, such as those that define basic data types. This adds abstraction that makes the higher level programming much easier. It makes debugging easier, etc. This could be done without OOP, but OOP can make this easier and more readable for larger projects.
@@Austin1990 What about something like pattern matching and type algebras vs polymorphism with inheritance and interfaces? Do you think it is easier to handle those situations with dynamic dispatching or a visitor pattern rather than having a built-in language abstraction to do that (I am talking about old school OO, not modern OO languages such as C# where now you have pattern matching, like Java for example)? And what do you think about advanced type systems that support higher-kinded polymorphism that mainstream OO languages generally lack?
Brian sounds like me while revising my own code after a few months.
Nothing more depressing than seeing what code I wrote 2 years ago. And that works for every year.
For me it is just a matter of maintainability, readbility, and a little of reliabilty (a.k.a don't write code unnecessarily hacky). If you prefer procedural, fp, or oop, go for it as long as I can undesrtand what you had on your mind when you wrote that, or better, as long as a junior can understand what's going on. Personally I don't take it too seriously, sometimes I would use oop just to encapsulate methods, other times to encapsulate state, or just use procedural, fp or whatever feels more convenient. What I would not want is a soup of miscelaneous functions which do a lot of unrelated things, since in that case you would need to memorize all code to know what to touch and what code breaks what.
If you trained your mind to think that spaghetti code is "readable and reliable", then look a simplified procedural variations of your pasta code and declare them as being "unreadable" - congratulations, your mind has been shattered.
I once maintained a project that was developed by a guy with exactly this same philosophy. It was hell. Nothing but long, mono-classes with godlike powers.
What you advocate here makes sense - for small examples/apps. Once the project gets to a certain size, the 'embarrassing' separation comes very handy.
You know you can separate responsability without being oop, right? That's what he's advocating know the difference between when you need an object, vs static class, vs. procedural.
@@nobytes2 He questions why a data-less class exists as it (allegedly) should just be static and the concept of instantiation an instance makes no sense. The problem with that assertion is that it completely shuts out the possibility of mocking (and thus unit testing), and having interchangeable implementations (e.g. different CSV parsing approaches), as you cannot derive or swap out static methods.
It simply cannot be achieved without containing the behavior in an instance (and therefore class). Using global scope is NOT equivalent, nor does it provide the exact same benefits.
More hell it is if the code is separated in tiny classes, and you have to look for the definition in another file, and then you forgot what the original problem was. I rather prefer mono classes. Functions should do the separation.
@@samuellourenco9526 yeah, so typically when someone talks trash about other person pick of language or style, it's typically some fanatic, not a professional, who cannot take a look for another perspective than his own, and judge the benefits/drawback of other languages/approaches. Especially it shows when someone advocates smth. using oversimplified examples and extrapolating it to whole world. Just an example. I have here mono class, which was written by mono-classes fanatic. That bloody thing has 20k LOC, almost 2MB. It takes several second for IDE just to open it and highligh it. By default intellij will not provide intellisense features for file >2.5M, so we're close. Navigation in it is nightmare, worse than thousands of files. In normally decomposed project, you can navigate by package by type of class or functionality you working on. Here, you can navigate only by line number, or searching for function by name. Theoretically by named code blocks. But it's significantly worse than any other approach.
@@flater420 In the video he was talking about classes, not mock objects, not interfaces. Interfaces do not have to be classes.
Here is what you did wrong:
You chose examples that were made specifically to showcase OOP.
Of course they are over engineered.
OOP becomes useful when you need repeating patterns in large programs. Or when you need to access the same objects/data from multiple places.
This will never be necessary in 100 lines of code.
wasn't this already addressed in this video
"You chose examples that were made specifically to showcase OOP.
Of course they are over engineered."
There is a problem when every demonstration of how to make elegant, simplified, maintainable code using a particular architecture results in inelegant, complicated, unmaintainable code.
Essentially, you're saying his mistake was using it as directed...
Personal experience is that OOP is beneficial over procedural for most general, non-trivial and non-throwaway programs that aren't better solved with alternatives such as a functional or logic programming language; the problem here is with trivial problems that were tackled in a badly engineered way, making it easy to find fault though this is not with the tools but with those who used them. There is definitely a knack to OO design, asking oneself the right questions, imagining what concepts and kinds of things would be useful to have exist in a solution, what questions those things should be able to answer and what behaviours they should have. Done well, a solution can then fall into place easily, be straightforward to understand by others, grow and maintain. When posing on the spot OO design thought experiments to undergrads, some can do this quite easily but most struggle or even fail entirely, suggesting that the way of thinking required is not nurtured and developed at Uni. An OO solution will then very likely seem awkward, confusing and even frustrating to develop, with the resultant code being contrived, muddled and relatively hard to understand.The methodology is sound, but does require good training to use it well unless it is something that one just grasps naturally.
@trollnerd You've missed my point, and being unnecessarily rude. UE is not a *demonstration* of OO -- it is a piece of software. My point is that when people deliberately attempt to demonstrate the principles of OO, they almost universally produce examples of inelegant, complicated, unmaintainable code. This indicates a problem in their thinking regarding OO.
I have never looked at the UE source code, but I would be very surprised if it was a hardcore objects-everywhere architecture... even if we disregard certain 3D rendering stages which are highly unlikely to be OO.
Strict OO means never using structs, because structs separate data and code logic. I would be surprised if UE didn't have a single struct in its codebase...
This isn't an argument against data / objects which are being used and reused within a service. You can easily just make global data holders and a simple mutex system to handle multiple calls to them.
The first time I intentionally used OOP was around 1986, when I wrote a base driver class for a printer server, then immediately created sub-classes for serial and parallel ports which could reuse 95% of the base class, with just a few extra lines added for the different ways to do IO port communication, before calling the parent method.
Some time later I got an 8-port serial card, which could reuse nearly all of the base serial code, just extending it to poll all 8 ports on each interrupt/poll interval.
Since then pretty much _all_ my polymorphic code has used the classic function pointer approach. :-)
You can always take an example and say "uh, I don't need all those classes I could just do this"
And that's the issue with examples: they're just that, examples that can't possibly represent the whole picture of what
you'd actually be doing in a real code base. Take the coin flipping game program for example: in itself, it's really simple and I would argue that even YOUR code was already too complicated, you could have written everything in the main just fine.
To which you'd probably reply something like "yes, but as soon as I need to be able to play from somewhere else in my code it gets hard to read..." and you'd be absolutely right, that's why we have functions. Now imagine that you're using a game engine, with a player, a myriad of other types of entities etc... The developpers who made the engine didn't just have your little coing flipping game in mind. In an actual non-trivial game, even the player becomes a potentially really complex entity, with a lot more data to handle, and a lot more interfaces to handle that data.
You need somewhere to store said data, and functions to interact with it, a class provides both at the same time in a single place.
And then there's inheritance, abstract types and all these things I won't even try to discuss here because it would get way too long.
Case and point being that a limited set of really simple examples (however well chosen they might be) is going to fall a little short for
demonstrating how powerful OOP can be. Over engineering is bad, that's something we can agree on. But if you want to make simple example,
obviously you'll have to do a fair bit of it, because I think you'd be equally as confused if the example consisted of a super complex
library that actually takes advantage of what OOP has to offer. It's a tradeoff. Of course we can write simpler code, but that's completely
besides the point.
this is underrated comment
Nah, look at a programming language that uses modules and types to organize code. You can still expose a public interface without dumb OOP rituals.
The examples do not prove that OOP is bad, but simply that the examples themselves are badly coded.
Not even that. These simple programs are just showing the structure of OOP so you can apply it to bigger programs that WOULD benefit from it.
@@NoeLPZC Yeah, if you just shoved a complex ass problem down a student's throat, then you are probably going to lost them. It is good to inch them toward more complex code with examples that are simple enough to not need OOP to teach them how to do it.
Huh. But isn’t all computer memory nothing but a 1-dimensional sequence of bytes, and doesn’t the cpu work through a program 1 instruction after another?
@@Grunchy005 You're right, but code doesn't always run top-to-bottom down the page. There are loops, conditions and functions that point the processor at different lines than the one directly underneath it.
@@Grunchy005 No. There are multiple cores in the CPU and the GPU accept jobs in batches.
There is a common English saying "Can't see the wood for the trees". I think it sums up this video nicely.
Hey man! I've just seen the dislikes... I've been watching your stuff for a few days and I was like YES this is exactly how I feel and how I do things. (The Bad Way)
Thanks for all the vids. I've been learning DOD for a while now, and I gotta say I just love coding way way more right now. I just get shit done instead of preparing for the fucking apocalypse with 4 abstract classes, 14 use cases I fucking imagined out of my ass and 3 more interfaces I have to implement. Slow is smooth, smooth is fast should be simple is smooth, smooth is fast. for us
As a hobbyist I appreciate this video. Recently I "converted" some of my scripts to include classes, because surface level research suggests I should use classes, objects, methods. And the result is that I create a single use class that does the exact same thing the function did and is never called again in the entire script. "Objects" are useful with actual objects. When I want to build a GUI for my script, it's nice to have a button class that handles the button name, the display text and the function it calls and I can define everything in a single line. But for the config files I think I need only two basic functions: load it and save it. Whatever happens in between these two actions can also be done with functions. Maybe if my script required 5 or 10 config files it would make sense, but that would no longer be a script, it would be an actual program.
Yeah pretty much the same process I went through. I started as a data scientist so in school you didn't exactly get taught how to code, but just how to use code to get the results you need. Therefore, most of what I wrote was (ugly) procedural code.
As I got better I also started reading up on stuff and was like you "oh I need to use classes and stuff". Then years later I look at code I wrote when I started using OOP paradigm and in 9 out of 10 cases I'm like "wtf this is so dumb and overengineered".
Not said in the video is that when you have the classes there you could further abstracting that into an interface. If you have interfaces you can have different implementations of something that does a job. That way you separate that responsibility into the object and when someone else goes to add functionality or fix a bug, they don't need to know what the other part specifically does, only that it outputs still follow the interface.
Of course, procedurally coding to solve the specific issue at hand nets simpler and more specific code. Well designed OOP is a complexity trade off you do so that in the future it is easier to change bits and maintain the code, specially by other people.
coin flipper:
console.log(Math.random() > 0.5 ? "tails" : "heads")
www.ripleys.com/weird-news/coin-toss-or-not/ ;)
If you want a 50:50 chance, the condition should be "< 0.5". Your version slightly favors tails, because
Math.Random might return 0.0 but not 1.0 ;)
@@derDrache1988 fprint(rand()%1?"twins":"tails");
Instead of % could be &
Random.nextBoolean()?"tails":"heads"
@@overloader7900 %1 would always give tails
The example where you refactor the polymorphic solution into a switch statement is a good example of cleaning up code. However, I don't think this is strictly an issue with OO; rather, it is an issue of expressivity. In essence, Item is a typed function. That is, it's an interface (a base class since this is Ruby) with a single method. This switch statement solution is a closed system because the only way to change it is to modify the code. This is an example of the expression problem. Polymorphism is one way to deal with this because instead of hardcoding the cases, the caller is required to provide the case they're interested in. I agree that this is overkill for this small example, but I think it's important to point out that this is very useful in scenarios where programmers do not control this code and need to be able to extend it.
The same thing is true for the argument parser example. You're taking a general solution and making it specific. This is all well and good, but defeats the point of making the solution general. I agree that general solutions are not always useful, but they still are useful. And they don't have to be implemented in an OO-style.
These issues transcend OO design patterns, which is why I brought them up.
Exactly!
+Jeremy Heiler This video focus on "How to rewrite OOP as procedural", and not on "How to make more reusable and extensible code by using procedural over OOP". All of his examples actually fall shorter on extensibility.
+Dejaime Neto yeah, because there was never the case that code had to be extended in any point of time.
Jeremy, I think your objection supports Brian's point... the exception proves the rule. A slavish devotion to extendability is the hobgoblin of OOP minds. Yes, polymorphism can be applied to provide extendability, but it is usually not a worthwhile complication to the system.
Polymorphism can be implemented procedurally with a table (array or hashmap) of function pointers.
I think you are always going to be able to find examples like this. OOP's strengths are in its ability to scale and to have abstractions. Small toy examples will always look better as procedural code because they don't need to leverage those strengths.
There are plenty of large non-OOP projects that have no problem with organization like the Linux kernel, and there are plenty of large OOP projects that are horribly disorganized, showing it's up to the lead architect's skill, not the paradigm, to keep code organized in large systems. That's how OOP sells itself (that it helps keeps code organized when systems become large), but that's not actually what OOP excels at.
OOP excels at interfaces. Say I write a library for users to interact with. Creating an interface can make it easy for them to use my library. OOP is not required here, eg Python libraries are written in C, but OOP a well suited tool when it comes to this kind of development.
Furthermore OOP excels at creating natural types. A natural type is a type that acts how you would expect it to, as if it came with the programming language itself. So, int is a natural type. String is a natural type, but barely. BigInt is a natural type. class UtilityWorker is not a natural type. The problem is, natural types require operator overloading, and arguably zero cost abstractions, so only Rust and C++ have this ability. But if you need it OOP excels at this too. (Though technically this is just another kind of interface.)
rlbond Did you watch the video? He starts off covering exactly what you said about toy examples.
Inheritance is what makes OOP really bad if you need to change some of your UML diagrams. When you write OO code you are encouraged to extract the same logic into smaller abstract classes, then you inherit that behavior in a couple of derived classes. When you need to change that structure somewhere along the inheritance chain, the entire thing becomes a mess. It's better to use composition over inheritance to make it more maintainable in the future, for the cost of a little bit more boilerplate code.
When you write in OO style you tend to write absolutely everything with classes. Even the "toy examples" which could be done with a couple of functions. It introduces a lot of unnecessary complexity and makes it harder to reason about.
Don't think it scales very well really. The web of objects, inheritance, factories and design patterns in general makes it a complete mess after some time. Seen it so many times.
it definitely does not scale well from my experience. Its probably the antithesis of scaling
27:06 👏👏👏👏👏 I agree 100% with you Brian. In my years of software development, I continue seeing efforts made to "make programming easy" and hearing claims that "programming is not hard". These two beliefs are pervasive and affirmed by the industry to lower the bar of entry to just anyone. Books, weekend bootcamps, "Hour of Code", etc. all contribute to flood the software development market with low quality workers. Tool, library and framework makers work tirelessly to abstract complexity away (typically just moving it elsewhere) so programmers "don't have to understand" what or why they are doing what they do. When asked, they'll parrot: "Industry standard", "there's a tutorial", "experts agree", etc. Scary times we work in.
you make it sound like what they are doing is irrational when it's not. in the absolute gluttony of computing power we live in, lowering the standards means more workers means less wages
You could make a video like this about EVERY programming paradigm.
Bottom line: They are all tools in the toolbox. OOP has a place. Procedural has a place. AOP has a place. They all have strengths and weaknesses, and ultimately work best in tandem with each other.
Indomitus1973 True, but when I went to university OOP was taught as the modern, superior way of programming which were more maintainable and readable than procedural code and you should ALWAYS prefer it maybe except for writing an OS. Possible that it's different now or at other universities, but I think if you had such an education and see the flaws of OOP for many problems, you appreciate such a video.
You actually could not make such a video about procedural programming.
@@rwxrobfun "It's embarrassing how our CPUs ultimately execute the code we write!"
@@storerestore The level of inexperience and ignorance in that statement is dumb-founding. This is why I engage the equivalent of flat-Earther technologists.
I largely agree, but I have two objections:
1. Specialized types enable compile time checking. Having a CommandLineArgDefs type (sorry for that name, there's probably a better one) instead of a hash map makes it possible to check whether you accidentally are using some other hash map (with the same key/value types) in that context. Of course OOP doesn't do much to help you with that - something like Haskell's newtype is much more appropriate.
2. The use of polymorphism as shown by you is a matter of taste. You don't like it to do the things you've shown here and that's fine, others feel differently and that's also fine. But polymorphism has another advantage: It allows someone else to expand upon your code without having them change it.
As an example, take a language that has a more complex notion of what a number may be (and sees operators just as functions with infix notation). It already has '+' defined and at a place where a programmer cannot change it (and thus cannot add to a large switch statement). If the programmer adds Complex Numbers or Surreal Numbers or anything like that without polymorphic functions would need to define a new function, like "add" maybe. With polymorphic functions the can define a new version of '+' for all relevant combinations of differently typed numbers. This has the added benefit that, in a language with proper type inference, a whole host of other functions defined on top of '+' now also may work correctly on these newly defined number types.
The same goes for libraries.
Why not just have operator overloading? Then you don't need run-time polymorphism :)
I like your comment and agree with it to some degree at least.
There's a lot of negative comments and dislikes for this video, so I just wanted to say thank you. This was definitely helpful for me. Everyone's defending OOP by saying 'well you're not supposed to use OOP for everything'. I've never actually encountered learning material that mentions that, though. Just like the lectures you roasted, everyone says OOP is great, and uses narrow scope examples to demonstrate how to use it. So people go out and use OOP how they were shown to use it, and you get the problems you've talked about. You download a project, and you spend hours just trying to build a mental map of how everything flows because simple code was divided up into a million pieces to make it 'eXteNSiBle'
Smart uploader was early, 7 years ago. Thats probably why the dislike ratio is high. Good video.
14:17 the same argument you make that visual representation of code is only good for small amount of cases... is actually the same argument for object oriented code and against procedural code with larger functions.
How do you miss that?
I can say that OO design has helped me tremendously throughout my career. Simple patterns such as Factory, Strategy, State, help sooooo much when dealing with complex problems.
The badge of the monkey. Also, bad news: what you call a career is years of malpractice.
@@paulie-g Or, you hold a minority opinion for a reason :)
By the way, treat people with respect. I was stating a simple opinion, and you were disrespectful. I'm sure your coworkers love you.
@@123214matt It's a minority opinion because ability is normally distributed ('bell curve' to you). OO, the misappropriation of pre-existing idioms as novel 'OO design patterns', and 'patterns' created solely to deal with deficiencies in and unnecessary complexities introduced by OO, are the creations of first-order monkeys to help second-order monkeys produce something that has a chance of working and not being complete trash. That's why you found it 'helped you tremendously'. Incidentally, also why this channel isn't for you.
Yes, there is value in helping those in the middle of the bell curve be ~useful, primarily from my perspective in relieving us from writing code for banks and all the other soul-destroyingly boring garbage. If OO were the optimal, or even anywhere near optimal way to do that, I'd advocate for it. It isn't. It fails even at this and it fails *hard*.
My co-workers appreciate my candour and if they do not, they do not remain co-workers. I run an LKML-style meritocracy - something people with non-zero clue and chops are very comfortable with, while those without are not, emitting a bothersome constant whining sound and handing out unsolicited life advice.
Your talking about learning basic algorithmic structures and stratagies. This isn't about oops, it's about learning the basics of coding. With a good grounding in the basics you don't need oops or any other paradigm to implement these and other algorithms, Just sufficient knowledge of the language you're coding in. I'm not sure if you're saying you had issues grasping some of these algo's, but found how oops implemented them helped, or you simply didn't learn them prior.
@@kaseyboles30 I was just saying it helped keep complex situations simple. I haven't used other paradigms extensively though, so I can't say how OOP stacks up against functional, procedural, etc.
Write about 20k lines of code (LoC) for an initial release with 3-5 devs and a formal scrum/kanban team, expect another 50-70k LoC over 5 years from 20+ developers of various competency. For your code contract, write unit tests, component tests, contract tests, and integration tests. Let's also consider exposing the API, versioning, documentation for the end user and the developer, performance and logging. What if we want to extract functionality from the app for use in other projects or maybe convert it into a library or smaller (micro)services (because now you have the budget for horizontal scaling)?
There is a balance between ease of development, maintainability, testable code, and performance.
Procedural code is fine in the scope of one-off scripts. When it comes to releasing an real app into the wild... I'll stick with OOP as part of the development procedure.
Linus Torvalds and Linux says hi... (a very large colaborative code base all in C and low level, 90% will never make something that hard in our lifes - ok C can replicate some OO concepts but it is not OO by nature - just to say that it all depends in the quality of the developer, it is about the carpenter not the hammer). But I agree that for a team of inexperienced junior developers OO can help making life easier, so a senior can keep things under control more easly (and it all depends on the project, e.g. videogames and OO love each other, but in other areas it is overkill).
banana gorilla problem
@Nigel Kipling dude you have no idea shut the fuck up. The poster was soooooo right
@Nigel Kipling sorry did you just copy and paste 100 lines of code and add a suffix to the function name to add some more functionality. Go home you utter peice of ignorance
I love how so many comments fall back on truisms: "choose the right tool for the job" (usually in looong form). That statement is worthless. It doesn't pass the "not-test": "Do not choose the right tool for the job". Noone would ever agree to that. Therefore its negation (the truism) is also a completely general and meaningless statement to highly specific critique...
because you cant give highly specific critique to discredit a highly general tool. to say "you should never use x" is extremely general, but naturally you dont critique that ridiculous generalization, but the comments pointing out a very context dependent approach to determining solutions to problems (which is literally all that works) are what is illogical here. thats the only general statement that is true. if the answer doesnt start with "it depends", or "compared to what", its the wrong answer
They never specify what the job would be. Fact is, OOP has no "right" job to be the "right" tool for.
A lot of critics of this video appear to be arguing that of COURSE the procedural code looked simpler, because these were simple examples to begin with that were used to make the object oriented solutions easier to understand.
That's a reasonable point, but I disagree. I deal with absurdly complex object oriented code on a regular basis. Typically, it's not complex because what it is doing is complex, it's complex because the compartmentalized code is all over the place. For maintenance purposes, I've gone in and created Helper classes to move sets of changes that typically go together all into the same file, so it's clear to whatever newbie developer where all the pieces are (they're in this one file!), so they don't miss anything.
In so doing, I've done exactly what Brian predicts: I've created yet another class without improving functionality, but only to meet a particular vision of where the code should be contained.
The useful unit of work is typically NOT whatever classes people dream up when writing code. Command objects, manager objects, controller objects, factory objects, etc., don't have any conceptual basis in the code, except as blocks of code that hold other blocks of code. Most classes, as typically coded, are just namespaces, not actual entities that you'd use to accomplish tasks. The command/manager/controller object merely contains the methods that actually do the commanding/managing/controlling. And in turn these objects reference and call still other objects that do the same thing.
In most of the cases where there are very complicated workings of code, and we are worried about the code being maintainable in the long run, procedural code that lets us read what is being called and how it is being called and what kind of side effects it might have at the top level (or close to the top level). When it's split up into objects, supposedly to be more maintainable, all that has been done is to obscure how the code really works, and obscures all the potential bugs. Yes, the "var result = command.Run();" is delightfully short, and you know that the command got run, but without knowing the state of the command or what the Run() method does, you've got a few hours of testing to figure out why and how that error that keeps appearing in the logs is being caused. If instead, it were just a method such as "updateInventoryEquipment(inventoryId, equipmentList);" suddenly there is no state, just arguments. I can test with whatever arguments I'd like without instantiating the entire IoC framework, and debug the problem in minutes instead of hours.
People keep on saying that if the OO is designed right, then it really is simpler than procedural. Well, I can make the same argument in reverse: if the procedural code is designed right, it really is better than OO. That's NOT my argument, I'm pointing out that saying "if OO is done right, it works", while a reasonable statement, completely fails as an argument, for the same reason that Socialists always say that whatever Socialist system that has collapsed simply wasn't done right, never mind that "not really Socialist" appears to describe all real-world Socialism.
So if an OO system that is too complicated to work with can always be described as "it wasn't done right", why does that seem to describe all OO systems?
So, in my real world of real world OO systems, I see only "it wasn't done right" OO systems, your ideal of "OO done right" doesn't really exist. And Brian's argument is valid, not just for these trivial OO examples, but pretty much every real life OO example I have ever encountered.
This isn't to argue that OO is "bad". Objects are useful. The argument here is that making objects the primary building blocks of code results in worse code than making procedural methods the primary building blocks of code. You end up with lots of objects that you really don't need, and those objects in turn tend to hide what the code is really doing. Maybe there is some ideal OO approach that is utterly beautiful and disproves my arguments, but if it is so very rarely encountered in real life (never, in my experience), then I have to agree with Brian that a mixed procedural/object approach is better, where objects exist, but are secondary entities, not primary ones.
I don't really think the problem is that the examples were simple. The problem is that they were just, IMHO, terrible. I'm not criticizing Brian for choosing them. But they don't do OOP any favours simply because they're terrible.
I don't really have a problem with having to stick everything into classes. Yes, you end up with classes that are essentially code modules. Even if they have some state. While it might not be ideal, that's not really the problem. The problem is taking OOP too far. And I'm certainly guilty of writing convoluted OO code. Typically as a result of the constrains of the language or platform. I wasn't keen on scratching my left ear using my right hand while standing on the left leg, squinting my right eye and singing the anthem. But if it's what I have to do to get what I want, then I sometimes do it.
I also don't agree that UML is useless. It's just a tool. Yes, like 15 years ago I tried doing the full monty, everything by the book, and I just felt like a bureaucrat. Most of the models were simply useless, waste of time. I would hate having to completely model a project. But it can be a useful tool. However, it's just a tool. It won't miraculously make a poor design great. And it doesn't guarantee you'll arrive at a great design. It just allows you to show what's going on which can give you insight.
Back at the university, I also created a library for argument parsing. Much more ambitious than the one presented here. Including comments, it ended up over 100 kB. :-) It was OO and most of the methods were written in a functional style (a lot of data processing). And it contained some of the aforementioned overhead ear scratching because I was trying to achieve a great user experience (I set the bar almost impossibly high) which proved challenging. And the assistant that graded my code was like: This is not how you write C#. But it's the most readable C# I have ever seen. :-) And it had plenty of methods with triple digit line counts. I also made use of operator overloading which often isn't popular. I'm certainly not afraid to break the rules. It's like in other fields. You have to learn the rules to break them. Successfully following them should give you something usable. Breaking them, on the other hand, can give you greatness. Or trash.
uumlau bjj
@@jobicek did you switch to an alt?
Cool
I think critics also come from confirmation bias. In few years ago, I actually watched this video and thought that it came from a guy who doesn't know how to do OOP correctly. At that time, I learned SOLID, Design Patterns, Domain Driven Designs, etc and I considered OOP is the best tool for building software.
But now I think I became an OOP hater because of data oriented design and functional programming =))))
And one of my favorite programming language: Rust even enforce not to code in OOP style :))))
And now I think the best way to model real world is through relational modeling (use database or embed it into code), not through some kind of object graphs.
I personally find UML sequence diagrams very useful when faced with undocumented, unknown code and trying to find out how it communicates with the rest of the system.
It seems to me that the best use case for UML is reverse engineering code lol
kippers12isOG
Or UML may be used for documenting code so that reverse engineering is not necessary. Anyone who bashes UML has obviously never worked on anything appreciably complex and/or has no regard for understandable code. OOP provides abstraction that is most useful for making code more understandable. Not everyone uses it as such, but someone who disregards that aspect of it already has discredited their criticism of OOP. Namespaces can be used to group things, but namespaces may quickly become cumbersome and verbose. Think of APIs made to accomplish larger jobs. OOP is great for making such tools. And, in larger projects, OOP may be used to construct encapsulated machines with their own APIs. It’s great for working on teams because one sub-team just needs the defined interface of the API to use it. In turn, it makes debugging and refactoring easier as well.
UML is good for analysis. A way of stating the actual problem and the required solution.
@Jumpy Cat I have a pre release copy of the standard that I got back when I was designing with OMT.
UML are so useful, it sucks that not many people use it
"Im just gonna use a small example to demonstrate this OOP concept"
"oMg YoU uSe AlL tHeSe ClAsSeS fOr SoMeThInG sO sImPlE??"
In closing you're referring to the OOP concept of encapsulation I think. I think this is possible because we do it with third-party libraries. Most programmers that program in a high-level language use several third-party libraries that handle things that would be a whole project in their own right like parsing and creating Excel spreadsheet files. You don't have an in-depth knowledge of what these libraries do to use them. You also can't harm them in any way by changes you make to your project code.
He says exactly that, and gives a good explanation of his reasoning, in the video he mentioned at the beginning... His focus in the reasoning was almost exclusively on the encapsulation part.
I disagree that oop is bad, however i agree with other comments here and there that adhering to any set of rules too strictly is bad. The best programmer can use many different approaches, in different contexts. The more i see these sorts of things, the more thankful i am to be self taught, and as a consequence, not stuck in with any particular dogma.
If someone tells you how to use a tool, it becomes far more difficult to think of other ways to use it.
Encapsulation at the module or library level is not specific to OOP. Everybody supports that. The debate is whether the more fine-grained encapsulation at the object level is useful.
I'm actually glad you put out these videos. I feel sane now. when i was learning OOP there was this little voice in the back of my head whispering, and I was experiencing some very uncomfortable cognitive dissonance as I simply did what I was taught while simultaneously thinking, "I know this is the right way, why does it still feel like bullshit?". Now I have a little peace of mind.
Great stuff!! I graduated from college in 1978 with a Masters in Computer Science which was when the first Apple I was showing up. All languages were procedural then and rather incomprehensible when coders overused the infamous _GoTo_ statement. The introduction of structured coding techniques, in which coders wrote code with only one entrance and one exit, was a necessary godsend. Object oriented coding was a natural when creating Graphical User Interfaces within an event driven context. But I agree with Brian that their overuse can simply be confusing.
Where I think Object Oriented Programming really shines is when code has to be modified and updated. If it's initially done right, OOP can be a great deal easier to change and maintain over time. The commercial computer programmer is always in an environment where the legitimate business needs of his employer are changing faster than the needs can be specified, much less having the additional time to design, code, and test such updates.
And my favorite programming language is still C. It really is the closest we can come to having a high level assembler language. And for many applications, the additional runtime overhead of using OOP practices can not be justified. I really do believe that well written C code will be easier to understand by new coders on any given project than most any other programming language.
The power of being able to create abstractions at will is what separates the poor programmer from the savants,.. but then the question becomes what's the easiest means to understand, implement, and maintain such abstractions in actual practice. The less abstractions one has to deal with initially, the faster the learning curve, but also the more work to create higher abstractions as later necessities demand. No one would create a single map than can simultaneously serve all the functions that a map can serve. That would simply make the original map incomprehensible. It's much the same with any intellectual tool.
One more thought. As a commercial computer programmer, I always thought the most important piece of documentation I should write was what was the business need being served by the software I was writing. It always amazed me how much software was lost, not due to technical reasons, but because management changed,... and the new managers had no idea what the software was still being used for.
Great points! I have long thought that applications should come with a short document of intended use. This document would be like a "Quick Start" document stating how the main features are used, what is the intended workflow using these features, and exactly how this addresses customer needs. This is analogous to market a hammer as a hammer and not as a Swiss army tool.
C is not bad, how about Scheme (LISP)?
Simula : 1962, Smalltalk: 1972... Better get your money back for that computer science degree
@@xpusostomos Given I graduated back in 1978, I believe my Masters of Computer Science was worthy for the time. If I had to pick one favorite Computer Language today,.. it would probably be Python,.. although I don't know as much about Python as I would like,.. it seems to be exceptionally well thought of,.. even if it is interpreted rather than compiled.
@@davidhunt7427 not a fan of python, the lisp languages are better thought out... And older too
I've heard a lot of people say "OOP is a mistake". Maybe there are better paradigms, but I don't think this video does a very good job of proving it. The author is too derisive of viewpoints he doesn't hold or understand. He complains about not understanding single-responsibility, then immediately and unironically explains it using different words.
In case 1: I'm not sure the author understands what a "class" is. Classes don't have to be existentially deconstructed representations of physical objects; there is no problem in a class being a simple container for logic. You can also have classes (POCOs/POJOs) that are pure data. Classes are just places to put (related) logic and/or data. You might put your 3 patent functions in a "patents.ruby" (?) file that loads into the global namespace; I would put mine in a Patents.cs file, with one extra line declaring the file to "be" a static class. I have more characters to type when I want to invoke my functions, but my global namespace is nice and partitioned, and if there is some intricacy or translation involved in parsing/loading the config, I have a nice private place to put that logic.
I would write a Config class that contains a CreateConfig function, and that function would return a Configuration object*. You would write a global function that still returns an object/hashtable. There is almost no difference here. So in my case, yes, I _might_ have an object to dispose of**, but the trade off is less polluted global namespace. I think having code separated into classes makes it a lot easier to mentally parse, rather than a wall of global functions.
*My Configuration object would have strongly-typed properties, no need to guess what's in the hashtable at runtime.
**If my class is static, I don't even have to instantiate, handle, or dispose of the object.
I _am_ interested in learning more about why OOP is a mistake, but so far it has been difficult to find arguments that have weight. It seems like the author and his peers value one form of thinking to the exclusion of everything else, while OOP programmers are perfectly happy using procedural code inside a class function. It seems like OOP can do everything that Procedural programming can do, but is the reverse true?
You can do everything you just said in C without using classes or objects. Object oriented programming can be done in C using structs. Most C kernel driver APIs tend to be closer to OOP. The problem is people design their software around object oriented design instead of OOP being a tool to use when you need it.
@@cbot3400 That's interesting about C, I wonder how much is OOP-like vs actual OOP (like polymorphism).
I think I would describe the issue as "people design their software using _inappropriate paradigms_" or even just "incorrectly", rather than pinning it all on OOP.
Yea, it's pretty embarrassing that he doesn't even mention/understand that methods can be static... lol.
the true problem with OOP is that you will end up with _state_ everywhere. it's kind of like using global variables instead of locals. it's not that classes are bad, there are use cases for them (containers for example) but writing your whole program in an OOP style actually makes it very hard to reason about what your program is actually doing and in which state it currently is in. what you should do instead is use pure functions where possible (meaning a function that does not depend on any global state, only an its explicit imputs), because they are the best at composition. and move any state as far up the call stack as possible. also try to avoid mutation of state when possible.
@@youareliedtobythemedia That's what I also was thinking. The video didn't do much to address that aspect, which I do believe is the most important point especially when dealing with threads or objects in memory/leaks...etc.
I've done very little OOP and am likely the least experienced person here, but a hybrid approach seemed best for my current project. I'm using an array of structs for my "objects" (in C), and I could have included in each struct a function pointer to further emulate the OOP scheme, but it just seemed to complicate matters. This will be a CLI application. But when I write a companion program with a gui it will definitely be object oriented to handle "events" and certain drawing elements and styles on the canvas.
You can design around state and "objects" (in this case I just mean a bundle of fields) without making your program object oriented. I was like you once, before I realized how trivial it is to not make everything a class and just use plain old functions and structs. I unlearned it by trying to see what it would be like to make a game in pure C, and it wasn't difficult at all.
You can handle events using function pointers in C. All languages have ways to pass functions as parameters. We have had that in lisp since 1958. If your language does not allow you to do that, use a better language
In your Python code, just type:
import this
Run the code and that's all you'll need.
Unless you need performance. Then you're screwed with Python.
Also if you have a big project. I am maintaining a procedurally written software and boy oh boy do you not want to maintain this stuff.
@@Watcher-of-Forms you mean maintaining procedurally written software is a chore?
@@PixelThorn one of the advantages of oop is good encapsulation. You change code and the rest of the code stays the same. Also, I don't know how well maintaining a clear flow is possible with procedural, but this code needs globals which can be modified anywhere, making it very hard to understand what is going on at any given time.
@@Watcher-of-Forms Not In today's computer world... I work in CGI and the programs handle Gigabyte size files like"Zbrush, Maya, Blender... they all use python. so your old day's argument is shit in today's world.
Objects are a way of combining a data container together with the actions that can be carried out on that data. That's kinda it. You could just have a standalone data container and then some separate functions that do things with that data, but you'd still be doing object oriented programming, except you're in denial about it.
Sure, there are a lot of abuses of OOP and it is good that people are pointing them out. But to say OOP is bad and to be avoided is a bit extreme.
P.S. Yes, i know this video is 3 years old, but it popped in my recommended and my inner keyboard warrior was triggered!
Your definition of OOP reads like just "doing things with structured data", which describes all programming in general. C becomes an OOP language. Prolog does too. Unless I'm missing something you meant, why give a new name to "programming" at all? And then how is it meaningful to say OOP is a good way to program?
@@erichardy6013 Because OOP adds those levels of polymorphism, inheritance, etc. Those are not easily achieved with traditional programming (depending on the language).
And OOP is a good way to program in the same way that it is a good idea to keep your tools well sorted. A method attached to an object is only meant to work on that object.
When changes are made to the data structure, it is easy to identify the methods that need to be updated. If you just have standalone procedures meant to work on a certain data structure, there's nothing actually forcing you to respect that convention. It's all implied. It's a disjointed procedure. Not to mention how hard it may be to understand that it needs to keep up with changes to the main data structure.
For most things, yes, you can replace OOP with normal procedural programming. But depending on complexity, your program is going to be a confusing mess. OOP keeps everything in one place and easy to understand.
@@CristiNeagu so the people who are "in denial about using OOP" aren't actually using OOP just because they have structured data and functions that operate on that data. There are a set of other principles like inheritance (polymorphism is a separate point as it can be achieved in many other ways) that make up OOP and people can agree/disagree with their values without lying to themselves
@@erichardy6013 No, they are in denial because they have procedures meant to work only on certain data, they are grouped together with the data structure, except they are not in the same object.
@odd135 That's why polymorphism is a thing. Or, of it requires the exact same function, inheritance.
When I start OOP, I was like you, I hated it, I hope that after 4 years, you finally discover why OOP is that powerful in manner of time, concept, conception and project management. I mean, for a really big project, you can't end up with imperative code without using OO concepts (creating a big structure containing related values is totally an OO concept, it's a data object, add function pointers and it's basically an object...). This video... man it's that :
1. Take a school case from a class meant to introduce a parallel concept to OOP
2. Take it as if it was a OOP representative example
3. Pretend that this is ugly code and you can do better without OOP
4. Give a bad coded (sorry :/) equivalent without OOP (or with a worse version using OOP anyway)
5. Repeat 3 times
6. Pretend not to use OOP is better than OOP because of these 4 example
Well... I suppose you were not really good with OOP 4 years ago... You were lacking of a lot of knowledge on OOP and on medium programming concepts. So I guess it's ok
(and btw sorry if I've been too harsh on this comment, I'm french and I'm not always good with language register)
Well yes, if you define OO as everything using lists, structs and arrays then OO is universal, and even C is OO. But that's not what people mean when they talk about OO.
Brian, I think I kinda agree with you. Thanks for the techniques that you had given in this video. They are really awesome. I think I get what you really mean, it is not about object or class that matter but it is more about 'object-oriented' that gives damaging and false hopes in many ways. That's why it leads to over abstractions and too much thinking on maintainability that leads to too many classes for such small solutions. Now I think we should be careful about the notion of 'object-oriented'. It should be a guideline and not a religion. We should embrace procedural where possible but still we could maintain clean code and SOLID. Thanks.
I was just skimming through the video and I think some of the arguments are a very silly. For example at 13:45 a OO-based code is replaced by a shorter non-OO code and then it is claimed: "I don't have to make the argument why his code is so absurd".
That's some strange logic. His code was absurd if it was written for that specific purpose. But it was a simple toy-example to teach certain concepts in OO-programming that might be very stupid to use in this example, but might be very useful in much more complex codes.
My day job is a theoretical/mathematical physicist and I do research within theoretical physics. Whenever I want to teach somebody a highly advanced and abstract piece of math, I use the simplest possible example to illustrate the concepts. It's very easy to counter argue: "I can solve this simple math problem with simple mathematics and with fewer calculations, do I need to argue why your advanced machinery is absurd and stupid?". Sure, but for more complex problems you need the more complex tools. The simple absurd example is only for teaching purposes.
You didn't argue anything by rewriting simple toy-examples into simpler code, as they were by design not meant to be the best way to write that particular code. But a simple way to illustrate OO-design, which might not be useful unless you have the correct level of complexity and application. I am not saying that OO-design is good, I'm just saying that some of the arguments presented against it here are silly and unserious.
THIS! This video is rather idiotic. The whole "UML is shit".... this is an EXAMPLE. In a real world scenario you cant just write 100.000 little functions all over the place, even if each one is simple. In the real world, with complex systems you HAVE to plan, which is UML for. YOu HAVE to structure your code, which is OOP for.
The whole video is just a pointless rant against OOP from someone who seems to never got in contact with a real complex system with more than 1,000 lines of code.
Completely agree with you
While oop tendency towards overengineering requires revision, I don't think attacking toy examples is the way to go
Couple of points:
You don't need to manage an instance if it doesn't need a "life-cycle", just make it static. Better yet, let something else manage it for you (DI patterns - not just used for wiring things together like you mention).
You sure do want to abstract (using OOP) data persistency for example (stemming from the first example). We have microservices that can be used on premise, or in the cloud for example. Good luck having the same code targeting different data stores without OOP (and testable at that).
For the abstract class, maybe he allows you to create functionality that subclasses can implement or override, probably does it in his 3 concrete classes.
I am looking forward to hearing ur experience of proceduralizing the bigger projects (over 10k lines).
@Sergey Zykov While it's true that the kernel is written in C you need to consider that it's a very low level software, using OOP it's not even an option in this kinds of scenarios.
I'm with you 100%. Using a function is basically saying "Do [something] to this data", where [something] is described by the function name. So functions are readable as hell. Put your branching logic in one place, and then for every if-then or switch that isn't trivial, call a function. Such code is readable, understandable, maintainable, and compact. You know exactly what happened to the data just by looking at it. You know exactly where to go to extend the code or fix a bug. The thing is, when you're working in a corporate environment, you're probably not the one who maintains the code you write (and are probably didn't write the code you maintain). I dread stepping into someone else's OO code... it's a shot in the dark, and you DO need to understand the whole system, or you can't prevent bugs, much less easily find them. OTOH, you can just step through a procedure and understand it quickly. Every time I've seen someone tout the advantages of OOP, they trot out a piece of procedural -- but not functional -- programming with heavy logic in the control structures; so it looks far more complicated than it needs to be.
An object-oriented language doesn't require everything to be in objects. Sometimes I think objects are an extremely intuitive way of thinking, and make structuring your code in an understandable way an easy task. However, if one is writing e.g. Java or C#, that doesn't mean that every bit of logic must use the concept of objects.
E.g. in the coin flipping game, as you yourself demonstrated it is possible to write a better way of running the coin game in Java, which is an OOP language. And that fact is what this all comes down to... These examples are simply BAD CODE. You can't make your argument by showing examples that clearly weren't meant to implement objects, and then state that OOP is simply bad. All that you have proven is that sometimes it's bad to think in terms of objects, but that doesn't mean that an OOP language can not be used with another mindset. Objects are just one of the many tools of the languages.
Wrong. Java e.g. requires everything to be objects. And unnecessarily axiomatically so. And no, static isn't it. If you're using static in your Java you're most likely doing something wrong or irresponsibly lazy.
I would like to elaborate one thing about the example given in 14:50. Imagine a situation where this code is in a closed environment, for example on a disc. You, as a programmer, want to extend this functionality. Say you want to add a new item type. Now if the code on the disc was written in an object-oriented fashion, you could easily add a new item by importing the item class, extend it and override the tick behaviour. In don't see how you could do this more easily with the procedural code you have written (using the switch statement).
It all boils down to the fact that OOP is not a better way to write more readable code. It makes your code more maintainable, testable and extendable (like the example I gave) because it encapsulates behaviour. And like everything in programming, different situations needs a different solutions. You should always apply the solution that fits the problem and the situation the best. This implies that object-oriented design is not always the way to go.
How often does one extend classes that they have no access to? I've never even considered doing that in over a decade of professional software development...
@@neko6 it happens very often when modding games, for example
Late to the party here, but I found your question interesting.
Unless I'm misunderstanding your point about a "closed environment", you could extend this functionality by simply adding a new branch to handle the next case.
If what you are saying is we don't have access to this method, by that logic, how would we be able to "import the item class"?
Irrespective, writing an API that allows developers to add their own items with a given name and values for the various variables (days remaining for example) and then storing items in an appropriate data structure, such as a hashmap, seems like a reasonable solution to extending this functionality procedurally.
Better yet, you could provide a callback function in such an API with the appropriate variables exposed as arguments.
10:10 would love to see how all those functions scale in a huge project and how messy that project would be compared to OOP based project. It's unnecessary to use classes until it becomes a necessity.
In what way would it become messy? Once the code grows you split it into multiple modules, exporting only few functions, having many supporting functions. OOP makes members basically become global functions within the scope of its methods and you have no idea what will happen to them
@@kim15742 OOP makes sure you have your functions/methods where they belong. You will never create a class Vehicle that has method meow() in OOP. In functional programming that's way easier to mix up (to put functions in wrong modules for example).
Also, OOP has many other techniques to organise the code and logic.
"OOP makes members basically become global functions within the scope of its methods and you have no idea what will happen to them" - ? Can you elaborate with examples?
@@coolemur976 In procedural programming each procedure has defined inputs and outputs (in functional programming this is even more strict). In OOP, a method has, in addition to its parameters and return values, full reign on implicit variables outside its scope (member variables). This is the same behavior as global variables and to me behavior of a method is harder to understand than of a procedure
Member variables is better than having some global variables scattered all over the place and used all over the place.
"to me behavior of a method is harder to understand than of a procedure".
So for you it's harder to understand method behaviour? Perhaps this is the problem? My point was: if you understand OOP and use it right, it scales better than functional in big projects. Is it harder to understand? Maybe. That's subjective. Also, there is a reason why people take OOP studies at universities.
@@coolemur976 Yes, exactly. That's why you don't use global variables in procedural programming. You have a lot more control to make it understandable and well-structured for yourself. And why is the university thing an argument? OOP is compulsory, as is functional programming and procedural programming
14:51 the control flow structures look like a sine wave.
OOP has its uses, especially for large scale, complex projects, but I'm sure everyone here knows it. These examples definitely show the power of simplicity.
Paradigms have their place, OOP is moreso for a nice way to group things, provide protections and interfaces. There's a lot to love, but sometimes functional is the way to go. That's why I like C++ and other multi-paradigm languages that give you a choice to use whatever paradigm you think is valuable for the situation.
Also, on the point of UML, these diagrams are very useful for SRS documents and large-scale projects where certain parts of the system need to be examined. For a coin flip game however, stick with the functional approach haha.
I would argue that OOP does not have its use, especially in complex projects. So "I'm sure everyone here knows it" does not speak for me.
Classes for IO, "structures" for data and functions for business logic. I've found this to work out pretty well.
You don't know what you are talking about though, but anyway...
@@trollflix "You are wrong, but I'll never explain why teehee..."
that's a good thumb rule. nothing beats having a testable, injectable class/interface as a client.
Classes for IO? Probably static, right? Or how many TCP clients do you instantiate in your business logic functions?
@@martinn.6082 No need to be static. Depending on your language and needs you might want to make it a singleton. The IO classes are usually wrappers around the low level client which is injected. So even if you instantiate multiple you should still be injecting the same client instance. There's nothing instantiated in the business logic. The functions should be passed all the data that they need to produce a transformation and they shouldn't have outside side effects like IO. In Java I've used static classes for this before and I got that from someone doing the same in C#. IO -> transform -> IO -> transform -> IO is what I try to follow. For me it's organized everything in nice separate areas of concern.
You have demonstrated in a very concise way my own journey in adhering to the design principles of OOP. When I attempted I found myself getting lost and making things less readable and concise just to fit the patterns of these expected principles.
Did you stop to ask yourself why you would try to comply with the cult of OOP when you knew that you could have written the program in a few short lines to achieve the desired result? :)
The thing is, when learning OOP, people tend to overuse it, just for the sake of learning it. That's not a bad thing at all. Once you have a solid grasp on OOP, you can use it more efficiently and effectivel
22:37
I would rather use a single hashmap of the sum type of integer, bool and string. That way you avoid scattering across 3 different hashmaps keys that must not duplicate. The sum type should be familiar to anyone doing functional programming, and it can in fact be just as helpful in imperative programming.
It bothered me how his final solution had half camelcase half snakecase
I'm not learning anything here expect "when making choices, try not to be an idiot". Well duh!
Also, learning examples often teach hard or complex concepts in overly simple examples where the complex concept is not really required. This is because using the complex techniques should be acessible WHILE the new student is a bit confused. After all the student is new to this. Best let them only have one new complex thing at a time. And that is rather hard to set up.
If you don't understand why education examples of code are so weird, it might be that you are good at code and bad at teaching.
Nailed it.
Can confirm, I am bad at teaching.
A common theme in all of these comments is that, "OOP isn't bad, how people tend to approach OOP is bad," but how people approach OOP is also due to how OOP actually works. As was explained in the previous video, using OOP will result in more complexity, restrictions, and rule-breaking than is necessary. You can use classes to create ADTs, for example, but you should then remain procedural and avoid using a superclass. There is no reason to use OOP because your method calls will use object references that result in shared state despite creating a restrictive hierarchy specifically for the purpose of separating state.
As an honest question, Brian (me being a computer science student), don't you think high-level reasoning (statistical modelling) is much easier using OO programming? Many mathematical concepts like graphs can be best expressed through sometimes complicated OO models.
Simply said, do you agree that OO programming is the best solution for problems that are already expressed in the OO domain?
"Hammers are better than axes!" *shows examples of nails to be clubbed into a board*
The problem with your analogy is that a good language should never be a single tool -- it should be a toolbox containing multiple tools. The problem is that most OO languages make OO mandatory, and you find yourself with a single tool instead of a whole box.
Niall Tracey your explanation lacks logic on so many levels. Use multi paradigm language like C++ then... Should a oop language follow non oop rules? Nonsense
@@wierzba1992 My point is that there shouldn't be such a thing as an OO language, as every production-level app will have features that don't make sense in OO.
@@nialltracey2599 If you don't need OO in your code, you can do it in an OO language (eg: programming everything in a single class, which I'd kill you for on a code review, but it's possible, and for very very simple tasks)
use the backsite of the axe as a hammer
7:10 1) It is trivial to pass objects around and call those methods elsewhere, instead of some nondescriptive function pointers; this could be part of an interface. Otherwise, yes, just use functions. Nobody would argue that.
8:05 2) Hashmaps are (compareatively) slow, not typesafe ("stringly typed"), genereally don't have code completion (IDE support), they are hard to debug, and cannot be checked by code checkers. I am not sure how ruby represents objects, but in any compiled language, yaml or json should get deserialized into native objects.
8:55 3) Yes, that indeed is a fair point. Sometimes, it is easiest to just use a function. Then again: If you use that function in several places, it can get tiresome, or if you have more than one config for different events, then this approach could eliminate errors; or if you need the config object and download method as parameters, then again, an object might be easier to handle.
17:10 4) In that case, you have a point, but in many other cases, this is very undesirable. First, you lose type information (can't say what kind of item you have got), and second, string comparison is very slow. Especially for exceptions, one should never use strings.
1. It is equally trivial to pass around functions. In fact, most OOP languages allow to pass functions as first class objects.
2. Hashmaps are not comparatively slow nor is it not typesafe. It depends on the implementation and language of choice. Code completion/IDE debuggers are generally not a good argument for or against paradigms because they can create these features, and oftentimes I find IDE auto-code changes more annoying than not (Jonathan blow has a video to demonstrate the issues)
3. Config object doesn't need to be an object even as part of parameters. Data is just data, which is what this video is demonstrating.
4. He used string comparison because that was the original code example. Also, re-think what types mean, losing type definition is a valid case in every kind of programming paradigm (for example, OOP allows for recasting and implicit casting, C lang treats pointers and blocks of data simply as block of data, and you can type it to do anything, etc, etc).
I think what people misunderstand about this video is that none of this should be surprising or new. You really can't argue against non-OOP implementation because C is such a strong non-OOP language that it alone debunks any argument you can make against people who do not like OOP. The argument is just a reminder of how a more C-like thinking to program construction has advantages over a more Java-like thinking of a program, and that there's almost (and I believe) no advantage for a Java-like implementation using OOP over C-like implementation
String compares in most modern languages are practically free. Do a search for "string interning". You have some very confused and outdated ideas in that rant.
"Who cares. It's effing garbage" ... LOL Thanks for making me laugh so hard 😂
You completely miss the point of OOP and take the worst examples to show how "bad" it is. Of course, small examples can be easily implemented with procedural programming. I wonder if you ever tried writing a bigger program. At some point you definitely start thinking in an OO way eventhough you don't explicitly use OOP language features. I am glad that I am working with OOP projects, when I see single classes that are 2000 lines of code and there are dozens of those in the project.
+theSomething As I explained in the previous video, I don't eschew encapsulation entirely. I just think proper modules of encapsulation are much larger than the typical class. Anywhere from a couple thousand lines to up and beyond 100k.
Large non-OOP code bases do exist, e.g. look at git or the Linux kernel.
+theSomething Yes the given examples are extremely bad.
I don't program in strict OOP but I use classes/interfaces and so on for most things.
Now here - if this is their solution to a OOP program - they failed to execute it. There is SO MUCH redundant code I'm not even starting on the rest.
The "days_remaining -=1" part at 16:15 alone drives me nuts.
And the solution given in the video has the same kind of redundancy aswell.
As far as I'm concerned - both solutions are bad. There are way cleaner and better maintainable solutions to these kind of problems.
+Brian Will the fact that you point to linux kernel as an example of non oop (hint, it's actually oop, just in a non oop language) without mentioning the reasons.. you just confirmed that you are just rambling emptily and have no idea about proper use of oop.
+theSomething Java is garbage anyway, regardless of anyone's opinion of OOP.
+Dan Kelly Agreed
This sounds like less like he's dissing OOP itself and more like he's dissing people who use OOP.
So what I got from this is use Objects when you actually need them like at the end where he ultimately wrote things into a constructor and called an Object so I understand what people say when they think the title is misleading or clickbaity.
I agree with a lot of what you’re saying, although I will say that objects are to be used when you need persistence for property values and I’ve re-written a lot of procedural code due to this
What is easier to persist than a hash map?
According to my professors, that last argument you touched on (about OO making it so you don’t need to know everything to use code) is the only real point of OO. That said, it’s an extremely valuable benefit and I couldn’t disagree more with your take that you should need to know how literally every part your software works. That’s totally unrealistic with any large-scale codebase, and nowhere did I realize this more than at my AWS internship.
My first instinct was to try and understand HOW everything worked before I did anything, but you can’t move at a pace acceptable to customers if you try to do that. You absolutely must be able to have as many segments of your code as possible that you can just think of as a black boxes with inputs and outputs and just assume that they do as described. Being able to get by with only knowing WHAT a piece of code does without needing to know HOW is crucial to working at the pace that customer focused firms require.
In other words: yes, OO can make it so your code is way harder for others to understand, but that’s because the point is to make it so others don’t have to understand it at all. Function based programming is a much better redress to some of the issues you raised with OO because you can still get this crucial “black-boxing” ability, but don’t have to contort everything around OO dogma. Great discussion to have though, even if I don’t agree with all your points.
> You absolutely must be able to have as many segments of your code as possible that you can just think of as a black boxes with inputs and outputs and just assume that they do as described
Functions. They are called Functions. What you are referring to is called abstraction. OO is not the only or even remotely the first way to abstraction. What we do is Class Oriented Programming anyway. Its not OO as Alan Kay (the inventor of OO) imagined
Yes. But there's nothing about the OO paradigm that makes it better at abstraction than good procedural code. Nothing good can come from blurring the distinction between data and algorithms.
With OOP you just pass bundles of closures on bundles of closures on bundles of data everywhere. It's hard to read, hard to debug, and it's always worse for performance with all those layers of indirection. OOP is combining the worst of functional programming with the worst of simple imperative procedural (classless/objectless) programming. OOP is only good for writing and selling books about software "engineering".
Honestly, the only thing I regret about learning Haskell is that it makes using any other language painful in comparison. Rust and Scala are nice but Haskell will always hold a special place in my heart.
@@karlwithak. Binary code is better than any language. Is there any better than binary code? Only local splashes of energy on the space-time comtinuum we called particles.