Object-Oriented Programming is Embarrassing: 4 Short Examples 

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 RU-vid 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.

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

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

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

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.

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?

Obbb-vio-us. I insist: Classes are made to HIDE what is behind.

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.

@@Alex-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.

+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.

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 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

@@NoeLPZC He does not even try to demonstrate the principals of OOP. There are 2 important use cases for OOP - Providing a public interface with swappable implementations. - Modeling objects which contain unique state and behavior.

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.

Captain R. WITTEREL can u plz tell me the story for ur profile pic i seen it every where ?!!

@@majedhk5460 Oh yeah yeah. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-C0sjsSq84QU.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)

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.

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!

This so much. Personally, I don't care all that much, as long as your code is testable and readable. Generally that includes some classes and dependency injection, but not everything needs to be a class as often enough data is just data. Purists hurt my head. Now we can move on to more important arguments, such as east or west const!

Some are obsessed with how code affects them and some are more obsessed with how it affects everyone. That's how it is with me: I rather just make something how the computer can do it quickly than worry about some paradigm that pretends to make it more maintainable. Like "maintainability" is often subjective, but there are some objective things we should all be able to agree on. Some people think some paradigm, like OOP, will achieve maintainability, but most often the constraints without keeping the reason into account will only make things worse. Instead of focussing on making maintainable code they focus on OOP instead and compromise maintainability to achieve OOP. Other programmers dislike maintaining OOP code for that reason and urge others to simply not use it. On the other hand those against OOP can be divided between the hardcore DOP guys and the people that simply never formally learned to work with OOP will churn out unexplainable code to the OOP guys, who learned OOP as their main thing and have for their entire career and don't get other mindsets and/or don't share the priorities of others. Like If I ask what's more important: performance or maintainability? Features or stability? Etc. Either side will lean more to one answer than the other. You don't choose OOP if performance is actually important to you for instance. I find it sad that performance is so often a second class citizen in a lot of software. This affects everyone. Slightly less maintainable code (on the surface only, non OOP-code can be even more maintainable, if done right) only affects the developers. I therefore find that kind of selfish that under the guise of some mantra they insist on some paradigm that may well hurt all sides. Therefore I say: avoid OOP unless it makes sense for the logic of the program. OOP modelling doesn't model a program, it models an alternate reality that you then have to emulate in software. Just look at the data, see what is needed where and how it is connected. Does one field need to be in memory with the one besides it? Are you performing a function on the object or on a property of the object? (ie: are you moving the car or are you moving its location? Do you need to know the car's colour while you're moving it?) Now this is a game engine view on programming, but I think this is relevant in all software. Performance matters.

@@nextlifeonearth I think what you've said is fair and I won't argue it. As I said, I'm a C++ programmer and some people might say I don't use pure OOP, because I don't exactly follow typical OOP practices. The reason I use classes is merely an attempt to organize properties with functions. I don't stuff everything into classes and I don't have some God Object. I only put things in classes if it's something that needs to be instantiated multiple times and/or has functions that act specifically on that data. You don't need to stuff everything in classes and objects. If you're going to read a file, do math, you don't need to make a class out of it; however, I personally find it best to make classes out of things like entities that need to have multiple instantiations with-as said before-functions that act specifically to manipulate the class' data based on certain 'actions'. Of course you can do all that without classes, but things like inheritance, polymorphism, member visibility, etc. can make things much less of a headache in that regard. (Or so I've found personally.) I'm just the type of guy that will use everything at my disposal. And so I don't feel I've really given up much performance using certain OOP practices. And after all, modern machines don't take as big a hit in that regard as they used to, so even pure OOP, whilst still objectively worse on performance, isn't that huge of a problem. Although I wasn't alive then, I'm sure Assembly programmers were once complaining about the slowness of languages like C compared to their own, which is true, but isn't nearly as maintainable as C. In conclusion, I think of programming more like a buffet, where I take the best of all worlds and do my best to throw away the worst.

@@nobodyspecial1553 "modern machines don't take as big a hit in that regard as they used to" I fundamentally hate this mindset. It's the reason I need to wait 40 seconds before a program starts up, like it's 1997. It's using so much more resources than necessary. Imagine the many gigajoules wasted because of this mindset. Imagine the unnecessary hardware upgrades that wasted more of our planet's resources because of this mindset. I hate it. Nobody ever complained about C being too high level as far as I know. Some parts will always have to be in asm, like intrinsics libraries or operating systems. At some point you're fighting abstractions instead of just doing what you need to. You need access to some field in an object that's owned by this object that's owned by this object that you have access to. Time to make a bunch of methods I guess? I have no problem with objects, it's the "oriented" part that I have issues with.

@@nextlifeonearth What program are you running that takes 40 seconds to startup? Have you analyzed why it takes that long? Or are you just assuming? Or is this hyperbole?

Exactly, I see many people here saying oop is good and then proceed to describe classes only instead of oop

basically, just dont use inheritance

and horribly inefficient code, let's not forget that.

@@occamraiser I didn't even think there was a distinction, but you're right. Bad code that performs badly.

​@jasenq6986 polymorphism is still useful when you have moving parts at runtime

*[...] 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.

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

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.

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.

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.

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.

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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-V6VP-2aIcSc.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

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.

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

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?"

@@YanYan-zu8dc 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.)

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?

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

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

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.)

@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

_"How would you tackle that?"_ By doing a common-law rescission on the application (and any other papers signed) to whatever "school" is perpetuating such nonsense, and then suing them for fraud and failure to disclose all material facts if they choose not to honor the rescission. If you are paying someone to teach you how to write programs, then they should be teaching that in the most efficient manner possible. If you were being trained as a mechanic, and your assignment was, "You can replace the oil however you want but you must use the sledge hammer as part of the process." The real test is "are you dumb enough to do what you're being told to do here?"

@@alphaforce6998 Putting you under certain constraints for an exercise is not bad.

@@meyes1098 Yes it is, if the exercise is an exercise in futility.

Hashmap.

Using tons of "if" statements instead of "else-if"s is dead and is so bad there is no reason to use it :')

@@6-dpegasus425 good point.

_In computer science, if somebody says that "something is dead" or "something is so bad that there is no reason to use it..._ But you don't mind watching videos that explain the opposite, right? "Why tool X is the best"

@@andreypanin2136 I actually do. Both extremes are bad. Many videos that say "tool X is best" often fail to clarify either that it is best only in certain conditions or there are equally viable alternatives available.

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 *"

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.

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.

So I'm far from an anti-OOP dogamatist, if anything I love OOP but he's right on the Parser class. There was absolutely no reason to make that a class. They should have used statics. Not just for the Parser, but also for the config. Statics are great for global state and stateless functions. Objects should only be used when you have local state and/or polymorphic behavior. But if your function is stateless or uses global state, there's absolutely no reason to make it a class, and some IDEs and even some compilers will warn you if you make an object or method a member function/variable even though it doesnt use any member state.

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

Yes but the problem is, that's exactly what students are taught at uni. We were using java and even then, in first grade, I was really confused at why everything needs a class. It's abstract, and it never models reality. I think the only acceptable option should be something like python or c++ where classes are optional. And even then, i think the only logical class type are dataclasses. As soon as you start mixing in functions, the whole thing begins to lose meaning.

See the problem in your comment about a chair is, you never model a chair in your code. We shouldn't be teaching programming principles with real world examples that have nothing at all to do with real programming. It gives people a completely wrong picture of what's going on.

This dude in 2016 was nowhere near qualified for giving insightful and enlightened industry criticism of programming paradigms and language design, lol. I've looked at his Github and other videos just to get a feel for what type of dev he was at the time and where he's gone since then. Seems he came to terms with his inability to understand OOP that early in his career and embraced OOP, because not long after this video he ended up getting really into C# and Unity development, for example, and seemed like he got better at writing code. But I can tell from his work in 2016 he didn't have a clue, but was really cocky and over-confident (as mid-level engineers tend to be when they realize they're better than the juniors and starting to grasp the tip of the iceberg of more complex topics). He went head over heels for GoLang and the "minimalist" style, which you see through the entire video. But I saw where he was even trying to make his own language and took a really naive approach to lexing and parsing it by raw, hand-written string manipulation lol. No wonder he moved on from that project, lol. He clearly learned and got better though, and ended up doing quite a bit of OOP. The video fails to land a single blow against OOP, only attack cherry-picked pieces of code from the internet, often taken out of context. But I think he dazzled viewers with the cool, confident demeanor and good speaking voice, well-crafted words (for the most part) and the pseudo-authoritative way he voiced dubious criticisms of a paradigm he hadn't even come to terms with yet. Like he attacks the practice of UML, yet has _no idea_ what it's for or how many different ways (and at how many different levels of resolution) it can be used, or that it's one system/technique for _modeling_ which is a much bigger field of vital importance to many areas of the techscape. He bashed what he called "visual tools", because all he had seen before was probably things like the visual scripting tools for "GameMaker" and "low-code" tools. He'd clearly never had any experience with the enterprise modeling tools for Visual Studio, probably never even seen how the class designer can refactor a huge project in minutes rather than days and days of hand-editing files. He attacked the UML tutorial guy for generating really bloated code which probably was a pretty bad choice for an example, but the UML tutorial was probably trying really hard not to conflate a complex modeling lesson with complex code, and opted for a trivial sort of program ... yeah, I think it wasn't a great choice, but it was a forgivable offense. Then he attacks random bits of Ruby and stuff he got from only the gods know where ... just more strawman code, low-hanging fruits, none of it even in a well-designed language or from a well-written code base (the place you _actually_ have to go if you're gonna try to cut the throat of an entire paradigm or language design). He was also clearly confused about "short code" vs "good code" ... his idea of making stuff "good" was just making it really, really small and short. That's all he attempts to do, and leads up his reveals with "All you need is this!" ... short code is not necessarily good, unfortunately, and his wasn't really that good lol. His changes to the coin flip program were still kinda awkward and goofy-looking if tiny program size and brevity were the metric of success (like the crap with swapping the two strings around lol). Then, he wanted to throw a jab at "Uncle Bob", who he viewed as an icon of OOP, and clearly felt that if he could make Uncle Bob's code look dumb, he'd somehow win the argument. I haven't been able to find the original code Uncle Bob wrote (I'll find it eventually) but it was clear he had taken it out of context. He says yeah this is stupid, he has abstract classes, I dunno what this dumb marshaling stuff is ... yeah, clearly you don't, lol. It _looked_ like Uncle Bob was making some abstract marshaling code that could be swapped around for different concrete implementations, and marshaling can be a complex thing. It's hard to say much more without knowing the purpose/intent behind it and how well it suited the needs/problem it addressed. But all he does then is turn around and "minimize" the code again, lol. Making it into something more "GoLang-like" and "minimalist", again confusing quality and brevity (which are sometimes not correlated much at all). So he _might_ have taken a well-designed and robust marshaling system and just locked it into one fixed, unchangeable implementation, lol. I'd love to find the Uncle Bob code to really find out. Overall, no good punches were thrown that landed _anywhere_ in the vicinity of OOP as a paradigm or any well-designed OOP languages. He likes going after stuff like badly written Javascript with pseudo-OOP style. Javascript isn't an actual OOP language, in my book, it's a scripting language with way too many things (a bit of everything) stuffed into it and overcooked. The minimalist, "procedural" sort of code has its uses, and you can still write code that way in an OOP language when its appropriate ... overall, it was a really silly video but it got him a lot of attention and views (succeeded there, at least) and provided a really poor take for people struggling with the challenges of learning OOP: a paradigm which is _amazing_ to work with once you have finally ascended the learning curve of scale, architecture, design and quality. And it looks like he _outgrew_ these silly dogmatic ideas and moved on with his career, because he did some better things in the following years with languages like C# ...

Apologies for the late reply. The design of your OOP code CAN be overly complex by you the coder. Unlike other paradigms, it's very easy to spiral into design hell with OOP if you haven't used it much before. A 'fun' way to experiment this is to make a 300 line procedural and OOP project. After you've made it, leave it for a week (just forget about it temporarily) and come back to it and see how easy it's to pick up and add new features. Readability has huge effects as a project ages. Hope this was helpful in some way, best of luck

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.

Great!

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.

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.

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?

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.

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?"

Nothing more depressing than seeing what code I wrote 2 years ago. And that works for every year.

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.

> 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".

You haven't stated any benefits to OOP because there are none. Organization is not a benefit of OOP. OOP is designed to OBFUSCATE so corporations can feel a bit more comfortable allowing untrusted persons to work on the project. OOP also creates make-work opportunities for schools and colleges to teach nonsense by mixing in esoteric ideas into what should be a simple, concise problem-solving exercise. Fools claiming that OOP gets better with increased project size are completely delusion because if it turns a "hello world" program into 50-100 lines it's essentially bloating the source by a factor of 5,000-10,000%. "Well defined interfaces" - what does that even mean? "Not constantly creating and destroying objects" - lolwhat? Both of these are NON ISSUES when you write procedural code, but if you think that your way of doing things is the better way (when it is not) then you will not be able to write code in the truly better way. It is much the same way the many catholics believe they are "saved" and that they'll find their way to heaven, but in reality, catholicism - as with all religions - is a satanic deception that promotes the idea of self-achieved salvation, in addition to the worship of idols and false gods. So while many catholics sincerely believe they are righteous, on the Day of the Lord they will hear Christ Jesus tell them: "Depart from me you workers of iniquity - I do not know you."

@@alphaforce6998 wow, that really sounded like a religious tirade to me. I mean refuting the claim that Java gets better when working on larger projects by saying a hello world, which is the opposite of a large application, is really verbose? And then trying to claim that Java is some kind of corporate attempt to hide code when Java is massively open source and easy to dig through and even decompile into source code? It all sounds like conspiracy theory and rabbid hatred rather than logic.

What is easier to persist than a hash map?

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

In this special case " "if piece == knight, if piece == pawn" have some advantages over "piece.getPossibleMoves()" Everybody reading the code of first example sees immeditialy which type of figures are existing and in the following code how they can move. In the second example you have to find out which classes are implementing "getPossibleMoves()" - check the corresponding classes which might even use some inheritance to implement getPossibleMoves() etc. But it is special case because it is unlikely that a new type of chess figure will appear in the future and so where is no risk that you have to go through all of your code to extend the ""if piece == knight, if piece == pawn" stuff. Pure procedural code is sometimes easier to read but when you understand your OO-code and it was designed well it is easier to maintain and update.

Same. This is what happens when your theoretical understanding isn’t as good as you think. Happens a lot to people who code in Java as a first language. Can’t hold it against them.

I don't know what this comment means. It's either an insult to the author of the video or an insult to the authors of the OOP code. Either way no information is given, other than that Andy D has been programming for 30+ years.

That's because you're a boomer who learned to program in the peak of OOP and never evolved past that

@Vishwesh Rajurkar i'm not smart enough to definitively say OOP is always bad. But I can tell you i've never seen a problem solved with OOP that couldn't be done just as well, if not better, with a procedural or functional approach.

Coding is like driving. Everyone has their own way of approaching it and some people delude themselves into thinking that their way is the _only_ way when It all boils down to wether or not you can get from point A to point B without causing a mess. If your code runs and It's comprehensive then you're good.

@@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.

I believe you should use OO when building large systems. The reasoning behind is that if it's a proper OO where messages are implemented there is no need for understanding the makeup of the objects/classes (not all oo have classes) you are utilising in that system. Also you can optimise any object at anytime needed as long as it produces the same results, therefore a change would not break other peoples coding and contributions. But the way oo has been implemented in most cases this is not what we se happening. In java we see different version of virtual machines. Why, it's oo we shouldn't have any issues with versions. I think the only ones that have tried to implement this was those who created smalltalk and NeXT Step later Open Step and MacOSX. But I don't see these ides have gone any further than this. I find C++ lacking as it doesn't do messaging and therefore I don't really consider it oo. Now my knowledge may be lacking a lot here I'm more of a philosopher than a coder although I do some coding now and then.

@@dbtest117 C++ doesn't do messaging? ofc it does, it's called callbacks aka function pointers. Signals/Slots messaging is just syntatic sugar using function pointers.

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.

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

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.

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

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.

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

You may be right about some of your points, but you are definitely incorrect about functional programming :-) The basics of FP are way simpler than OOP and can be (and are) taught successfully to students worldwide. It's just seen as difficult because it's unfamiliar to many.

@@yawaramin4771 oh, the concepts are simple, as are the concepts of recursive function theory (or the axioms of Group Theory). But writing a non-trivial application or doing a computability proof, is beyond most. You need to look into the complexity of simple systems. 🤓

@@1dkappe 'writing a non-trivial application or doing a computability proof' is difficult no matter what programming paradigm you are in. That is irrelevant to the conversation. Like I said, it's all about familiarity. Everyone can be taught FP, and many people are taught and become productive in FP after joining teams that are producing industrial or line-or-business software. E.g. Elm, Clojure, F#, Scala, OCaml, Haskell.

@@yawaramin4771 I think we’re in agreement. “Many” people can be taught FP. But only 1% of those people can then write non-trivial, well organized applications. Too much of the programming population just doesn’t have the cognitive capacity. That’s based on my experience teaching and hiring developers over decades. So, to recap: if we take a population of 100 developers who can write ok procedural code, only 10 of those can manage the same with OO. Of those, only 1 (so 1% overall) can manage the same with FP. Let’s not even talk about Ada. 😉

@@1dkappe and I believe that far more people can manage to write FP (and in fact they do on a daily basis, if you look at the sheer numbers of frontend developers writing functional-style JavaScript React components or similar). Your 100/10/1 numbers observation is exactly that-numbers of people who are taught those paradigms. If you teach 100 people FP to begin with, you will find 90 of them can manage to do FP just fine. It's OOP that confuses and makes things more complex than they need to be. For proof, just watch the video ;-)