Object-Oriented Programming is Embarrassing: 4 Short Examples

A follow up to • Object-Oriented Progra...

[@Vixikats]

Actual title: "Overengineered solutions to simple problems are bad."

[@ZeruelB]

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

[@deanolium]

The problem is that the strengths of OOP require non-trivial examples -- however that's almost always out of scope of KZbin 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.

[@ifstatementifstatement2704]

@@ZeruelB Yeah lol, crazy.

[@Austin1990]

deanolium In the flipping game video, I believe it was specified that the code was overkill but merely an example of the principles.

[@MrAST4R0TH]

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.

[@xiphaliadanlianthol6715]

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.

[@nice_sprite5285]

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.

[@alexho5769]

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

[@nice_sprite5285]

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

[@alexho5769]

@@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 :)

[@CreepSoldier]

i think the point is that the Bad OOP is the one beeing taught in classes and the one mostly found in programs

[@bdormer1]

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.

[@JohnCorley13]

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?

[@MaxRunia]

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

[@JohnCorley13]

@@MaxRunia excellent point

[@theRealRindberg]

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.

[@JohnCorley13]

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

[@deckard5pegasus673]

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.

[@Jedimaster36091]

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.

[@siddharth8184]

Crazy part is that instead of rewarding you, he went off at you

[@ShazeAn]

That's exactly what jealous boss does, a good leader doesn't. I guess thats how boss vs leader is differentiated.

[@niclash]

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

[@isk8atparks]

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

[@mattjones1154]

“Polymorphic dispatch in this example is overkill, therefore all polymorphic dispatch is bad.” This video should just be called “Bad code is bad.”

[@JellyMyst]

Object-oriented programming produces bad code.

[@rosek6585]

@@JellyMyst Most of the time... yeah... BUT you can write even more shitty oo code if you try.

[@JellyMyst]

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

[@ptechlead]

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

[@Frozander]

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

[@alexclark6777]

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

[@niccster1061]

LOL

[@PetersFXfilms]

@@niccster1061 Wow, this is the perfect metaphor.

[@youKnowWho3311]

Always be on team Depends...... I start every conversation with this caveat.

[@niccster1061]

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

[@PetersFXfilms]

@BringerOfTheTruth Are you really suggesting that we should never use object oriented programming?

[@gnir6518]

As a student, I learn a lot from these videos and especially the discussions in the comments. Thank you all for your insights

[@MrDocProfPj]

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.

[@aaronbono4688]

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.

[@walrustrent2001]

@@aaronbono4688 strong typing exists outside of OOP

[@aaronbono4688]

@@walrustrent2001 right, that's why I mentioned typescript.

[@bassam_salim]

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

[@philippebaillargeon5204]

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.

[@arturk9181]

I do like object but i treat them as a feature of a language rather than "EVERYTHING MUST BE AN OBJECT!"

[@SteveM000100]

+suckmynobs static!

[@KilgoreTroutAsf]

+Artur K Here's a sane person.

[@Tudrum2]

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

[@Tudrum2]

+suckmynobs Ou, and second thing, if everything is based on Object that will make life easier when you use Reflection

[@HairyPixels]

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

[@BlueBetaPro]

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.

[@majedhk5460]

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

[@BlueBetaPro]

@@majedhk5460 Oh yeah yeah. kzbin.info/www/bejne/eWHWm6aJpp1nh7c

[@weneedtogoback8553]

Tell that to Ruby

[@asdfdfggfd]

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.

[@ilyasuzdalnitski7479]

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)

[@DevideNull]

Some people may fear they will lose their jobs if the code is too easy to understand.

[@alejandrodelabarra2838]

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

[@MattRamsay-wh6cd]

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

[@Zachucks]

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.

[@swapode]

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.

[@Alejandro388]

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

[@codekomali1760]

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

[@Alejandro388]

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

[@pip0109]

You cant say OOP is BAD but you can say procedural is BAD .. the code he suggests is close to unmaintainable!

[@InfallibleCode]

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand. " - Martin Fowler

[@1Maklak]

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.

[@13b78rug5h]

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

[@1Maklak]

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

[@Alex-gj2uz]

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

[@1Maklak]

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

[@skyflight99]

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.

[@UrSoMeanBoss]

I like the modern C++ approach to classes. In short many industries have largely abandoned OO philosophy and they just use classes as ways to tie data to the behavior that operates on it, and for RAII principles (mostly just resource management). Classes aren't bad; how people use them are often bad. OO makes it easier to write bad code.

[@klimmesil9585]

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

[@jasenq6986]

basically, just dont use inheritance

[@occamraiser]

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

[@UrSoMeanBoss]

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

[@briannoel7398]

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

[@jsnadrian]

if this had the title "Roasting Bad OOP", you'd have 100% likes and an empty comments section

[@NoeLPZC]

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.

[@benhardwiesner6963]

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

[@trollnerd]

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

[@XfStef]

All OOP is bad. It's bad conceptually. It's bad when you implement it. It's bad on performance and code readibility.

[@gwho]

@@NoeLPZC exactly. so much waht you said.

[@nobodyspecial1553]

C++ programmer here-I've dabbled in many languages, but C++ being my favorite, I used to be a Java programmer. I just find it amazing how toxic the programming community is and how dogmatic everyone is.

[@defeqel6537]

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!

[@nextlifeonearth]

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.

[@nobodyspecial1553]

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

[@nextlifeonearth]

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

[@nobodyspecial1553]

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

[@AlFredo-sx2yy]

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.

[@lupf5689]

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

[@AlFredo-sx2yy]

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

[@lupf5689]

@@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 :-/

[@AlFredo-sx2yy]

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

[@leighdf]

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.

[@rhymereason3449]

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.

[@allseeingeye93]

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.

[@GBGOLC]

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?

[@EvileDik]

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

[@tabularasa0606]

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.

[@rhymereason3449]

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

[@iAmTheSquidThing]

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.

[@WARnationLD]

Samuel Clemens They have been teaching you wrong then the most classic example being the square and rectangle example.

[@PerryGrewal]

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.

[@LedoCool1]

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

[@andreimasterdev]

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

[@jeffwells641]

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.

[@rickchristenham5416]

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]

Not to mention that certain development is much easier when handling objects. Like game development.

[@AndersenCastaneda]

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

[@stijn3085]

@@AndersenCastaneda "real programmers"

[@saltysalt7339]

@@AndersenCastaneda We don't talk about the Error 404 Quality not found examples

[@KevinUchihaOG]

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

[@miyazakizachary5108]

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.

[@alexanderterry187]

This seems like more of a "don't put crap into objects when you don't need to" than a case against OOP.

[@GoldenGamer-es5tl]

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

[@JellyMyst]

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

[@pee-buddy]

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.

[@LanPodder]

@@pee-buddy i dont think thats the case

[@pee-buddy]

@@LanPodder If you know OOP well enough, it would be clear as day that the guy really is hopelessly lost

[@DavidWoodMusic]

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.

[@joshodom9046]

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.

[@viktordoe1636]

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

[@YanYan-zu8dc]

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

[@DavidWoodMusic]

@@YanYan-zu8dc Haha getting there.

[@user-jn4sw3iw4h]

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

[@ChristopherSalisburySalz]

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.

[@nyscersul42]

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.

[@nyscersul42]

If someone tells you how to use a tool, it becomes far more difficult to think of other ways to use it.

[@Shneebly]

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.

[@Luis-gb1ph]

Hey man I totally agree with you, I feel like many problems are overengineed to the top and then it's so hard to understand a very simple problem.

[@BroddeB]

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

[@patricklangan950]

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: kzbin.info/www/bejne/jGe5gWBolq6WicU

[@BroddeB]

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

Following your logic, taking a simple scenario made for teaching and saying "OOD is the best" is equally as ignorant

[@BroddeB]

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

[@Soremwar]

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

[@bored4428]

I think the main point is: "Know your tools and how to use them. Less is more."

[@ChristopherSalisburySalz]

I would like to hear Uncle Bob's reply to your observations about his code. I agree 100% with you about OOP creating a lot of mental overhead that often isn't needed. I have also seen some examples where OOP really can be very slick.

[@eddiebreeg3885]

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.

[@hastingsx2865]

this is underrated comment

[@qx-jd9mh]

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.

[@charlydagos]

"UML is just fucking garbage" -- You're my hero, Mr Brian Will.

[@SE45CX]

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.

[@omgomgomgd]

I am a CS tutor. I am always wondering why teachers are teaching this garbage to the next generation of programmers.

[@AlqGo]

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.

[@ChrisSeltzer]

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

[@feschber]

Chris Seltzer isn’t the whole point of functional programming to eliminate sideeffects?

[@steven1671]

Wouldn't rewriting a codebase have that effect regardless of the paradigms used?

[@StraightCrossing]

@@steven1671 In my opinion yes. A rewrite is almost always going to be better no matter what.

[@98danielray]

@@steven1671 given that "charitability" to a disagreeing comment but not to the video showing bad code regardless of paradigm?

[@BriceFernandes]

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

[@blackerhawk1508]

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.

[@alphaforce6998]

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.

[@trentonjennings9105]

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.

[@nickwilson3499]

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.

[@rahem027]

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

[@DerrickJolicoeur]

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.

[@quintongordon6024]

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

[@justinhutchison9866]

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.

[@owencoopersfx]

I guess it comes up to personal preference for making sense of things. I personally much more like OOP because it allows me to categorize and therefore organize things effectively. If you don’t enforce any boundaries, then it just keeps possibilities virtually infinite. That might be fine for some people, but for someone like me that just becomes overwhelming. Being able to parse things into categories makes everything more understandable. Sure, it’s all data, but by enforcing restrictions on types of data, you can help communicate specifically what each thing is for, and with limitations then you can know what any given thing can or cannot do, based on what it is.

[@jmcoelho7]

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.

[@alphaforce6998]

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? :)

[@choosetolivefree]

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

[@markharrison9021]

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.

[@brodyyucan]

@Marcus - The universe is written in Objective - C

[@bossssssist]

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

[@steamdecklife]

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

[@Jim-mn7yq]

@@steamdecklife agreed. Although my old company called them dats access layers.

[@Gogglesofkrome]

@@brodyyucan the universe is written in binary, and how it gets there is a matter of logic

[@TebiByyte]

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.

[@paulie-g]

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.

[@kaseyboles30]

Modularity is independent of language paradigm.

[@yuplucas4023]

@@kaseyboles30 agreed. What I want to see is someone demonstrate that OOP gives you some kind of modularity that a procedural approach can't.

[@karaloop9544]

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?

[@TheWookieDavid]

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

[@agame1239]

I like using oop not for competitive programming kinda problems .but for other projects : one time we were asked to make a programm that does alot of things with a train ride including tickets ,distinations , travelling time , and other aspects that u take in consideration if travelling by train . So making a class for that was really neat to deal with .

[@Sonsequence]

My favourite thing is writing procedural code and using a class as a short-live container to make it more declarative. First imagine a 70 line method. Then split it into separate methods. In a mess with variable passing spaghetti because it turns out both method 1 and method 4 need a particular variable? So replace the variables with memoized calculated properties. Ruby uses the @myvar ||= idiom. Python has @cached_property decorator. The caching isn't mainly for performance. It makes your vars more like constants, thus easier to reason about. That is not OOP but quite a lot of other common and good uses for classes are similar.

[@skilz8098]

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.

[@gerardgauthier4876]

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.

[@raksipulikka]

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

[@MidnightBloomDev]

Seeing by the replies self taught programming wasn't enough

[@Tristoo]

@@gerardgauthier4876 C++ is not an object oriented language.

[@Tristoo]

@@MidnightBloomDev Well you clearly have your head up your ass.

[@MrTrollinglol]

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

[@JellyMyst]

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.

[@Frozander]

@@JellyMyst That sums up my experience with Java.

[@Roboprogs]

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.

[@Roboprogs]

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.

[@okie9025]

@@JellyMyst at least "HTTPRequestSingletonFactory" is more readable than "r_x *"

[@AmedeeVanGasse]

For the Gilded Rose kata, which you solved with a switching branch, the original assignment is to extend the system with additional products: "Comjured" items. The assignment also says: "Feel free to make any changes to the UpdateQuality method and add any new code as long as everything still works correctly. However, do not alter the Item class or Items property as those belong to the goblin in the corner who will insta-rage and one-shot you as he doesn't believe in shared code ownership (you can make the UpdateQuality method and Items property static if you like, we'll cover for you)." How would you tackle that?

[@alphaforce6998]

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

[@meyes1098]

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

[@alphaforce6998]

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

[@GdeVseSvobodnyeNiki]

Hashmap.

[@scienceontheright]

OOD and OOP are just one approach to coding solutions, not a one-size-fits-all approach. I've been coding professionally for about 30 years (C, C++, C#, Java, Python, Golang, etc), and I have to say, your premise at the beginning (3:45) is something I have never heard before, or at least, not since the mid-1990s. Requirements come first. For example, if you are trying to model a chair, then it should be a highly-specific chair as defined by the requirements and the interface(s) needed for the consumers of that class. You never build a chair class for every and all chairs now and forevermore. Instead, you might be asked to build a class that models a gaming chair that has between 4 and 8 chair legs, can swivel, and can support up to 400lbs of a single human comfortably for a maximum of 8 hours at a stretch. In other words, the requirements define the models. And if you do it right, you get clearly defined interfaces that provide concrete boundaries. It sounds like you were taught something that is impractical at best. The examples you provided are an attempt to introduce OOP, not suggest that's how it should be done in the real world. Hence, your premise for this video, in my opinion, is incorrect.

[@bgdgdgdf4488]

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.

[@bgdgdgdf4488]

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.

[@GameDevNerd]

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

[@Mayur7Garg]

In computer science, if somebody says that "something is dead" or "something is so bad that there is no reason to use it", it is very likely that they are using carefully selected examples to make their point rather than talking about it in a more generalized version. Such people are using flawed logic to force their coding practices on you whilst never trying to know what you actually do. Ignore such toxic people. Computer science is so vast that in it, there is room for every technology and tool due to sheer number of varied use cases. Nothing will ever fit all use cases. That is not a reason to stop using whatever clearly works for you.

[@6-dpegasus425]

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

[@kdot78]

@@6-dpegasus425 good point.

[@andreypanin2136]

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

[@Mayur7Garg]

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

[@bosshua]

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.

[@Twosies20]

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.

[@Andy-wv2xj]

@@Twosies20 Sure. from that moment I knew this video has a big garbage

[@JerryO1995]

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]

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

[@kspfan001]

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

[@IntoTheVerticalBlank]

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.

[@daboos8]

Both have pros and cons, but I clearly see your point about the over doing / over thinking things. Regardless of the tool, I think it’s critical to spend more time properly naming things.

[@KyleWoodlock]

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.

[@ConernicusRex]

I was looking for this to see if someone explained it to his simple ass.

[@skeletalearth]

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.

[@KyleWoodlock]

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

[@trollnerd]

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.

[@HowT0Code]

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

[@THENewTubez]

How bout multi paradigm programming, everything has it's place... A pure anything would probably not be the best way

[@brecoldyls]

THENewTubez this sounds very rational

[@garychap8384]

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

[@chihchang1139]

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

[@tiagodagostini]

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

[@garychap8384]

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

[@mac1991seth]

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.

[@federicozambelli9091]

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

[@AdNecrias]

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.

[@bpin5267]

I watched this a few years ago, and since then have acquired much more development experience. I have returned to say: I DISAGREE! that is all.

[@iamstruck]

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.

[@recompile]

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.

[@kant12]

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

[@PierreCHARLES1838]

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

[@Austin1990]

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.

[@Ext3rmin4tor]

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

[@AndyD070568]

As a software engineer with 30+ year's experience, I can say that this video is embarrassing.

[@ConernicusRex]

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.

[@beefbroccoli5489]

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.

[@andrepduarte]

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

[@beefbroccoli5489]

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

[@Teutathis]

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.

[@r2-p2]

Whenever I try to keep struct and functions separate, I start to miss features classes offer me. C'tors and d'tors for example. It would surely be possible to go without them but then I have to manually call them in the proper places which - for d'tors - is not a trivial pursuit in some cases. I use classes to bundle various states and behaviors which communicate with an external system to build a somewhat simple interface for the rest of the system. Is this a bad thing?

[@allseeingeye93]

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.

[@Stringboiler]

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

[@PeterBosak]

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.

[@nobytes2]

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.

[@flater420]

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

[@samuellourenco9526]

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.

[@sdfsdf421df]

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

[@Danielle_1234]

@@flater420 In the video he was talking about classes, not mock objects, not interfaces. Interfaces do not have to be classes.

[@MidnightSt]

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.

[@dillerboy]

As many others have pointed out. This seems like more of an argument about being practical. But comes at it from an extreme angle. You use the tool you feel best fits the problem, in some cases it is clearly different paradigms. In others there are no clear benefits for either approach and people just pick what they like. While I haven't really spent much time programming professionally recently. That was pretty much how it worked when I was.

[@SteveAcomb]

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.

[@rahem027]

> 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

[@kevinkassil6038]

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.

[@youtubeenjoyer1743]

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

[@mycouchsmellslikesoda1625]

"Im just gonna use a small example to demonstrate this OOP concept" "oMg YoU uSe AlL tHeSe ClAsSeS fOr SoMeThInG sO sImPlE??"

[@StarContract]

We: 1) are developing in Java large enterprise applications, using oop features all the time 2) are using python as a scripting tool without ever using classes 3) are writing code in C where we often use structs but not all the time You: obJECt oRIeTed proGrAmMiNg iS bAD, HEre iS a 1k LiNEs prOgrAm aS a pRoof

[@DiegoSayron]

Great!

[@transcendtient]

"These OOP Examples are Embarrassing, but Using These Examples to Generalize All of OOP is More Embarrassing"

[@csprofile]

This video was recommended in my feed, I agree with part of it, but it would be nice to have an updated video to see if you're still having the same perception 7 years latter.

[@tenzenin6301]

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.

[@mateussarmento7692]

OOP goal is not to facilitate reading but to improve the process of change. It gives us the opportunity to substitute with code injection without changing or damaging the overall structure

[@overclucker]

Sometimes the libraries necessitate OOP, and it makes sense continue the OOP style when it fits well with existing code. You can't escape it if you use python, and I've found that I need a solid understanding of CLOS to integrate with many exceptional Common Lisp libraries.

[@cherubin7th]

I like pure functions, but sometimes also feel better to use a class. Programming languages that allow you both are best IMO.

[@cristianbilu]

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 )

[@carlosavila4290]

Still orthopedic.

[@danieldavies765]

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.

[@vr77323]

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

[@Danielle_1234]

Generally you can use a file as a namespace instead of a class in this situation. (ymmv)

[@pyhead9916]

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

[@christophfischer2773]

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.

[@trollnerd]

There's really only 2 reasons in my mind to use objects: 1) You need to record or use local state 2) You have some kind of polymorphic behavior Beyond that, just use statics.

[@ffghjj9996]

wasn't this already addressed in this video

[@nialltracey2599]

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

[@trollnerd]

@@nialltracey2599 I think its incorrect that every demonstration of OOP leads to what you call "inelegant complicated unmaintainable code". Look at Unreal Engine. It is a behemoth codebase and it is all written using OOP practices. It's definitely not unmaintainable, it is receiving massive updates on a regular basis. It is complicated, but not because of OOP, game engines are just complicated. I don't think the engine is inelegant, I think they've done a fantastic job personally. So just because YOU can't create good OOP code, doesn't mean no one can.

[@makers_lab]

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.

[@Skiggles]

Hey Brian. I totally agree with your assessments both here and in your original video. The one thing that keeps pulling me away from C and back to C++ is the container classes. Things like the map or vector classes are so useful and needed. Can you recommend any resources for learning how to do this in C in a simple way aside from the typical linked list examples out there? I really want to get away from C++ if I can only figure out this one aspect. I would also add that I like the idea of using a hybrid approach such as using classes minimally and only when it makes sense. Nothing to stop us from using a plain old library of functions in C++ for everything else.

[@hhattonaom9729]

Hi I’m a beginner. So am I understanding right that OOP overcomplicates coding for most applications that procedural or functional programming can do? Is that the general message?

[@stephenstephanov8961]

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

[@ishdx9374]

coin flipper: console.log(Math.random() > 0.5 ? "tails" : "heads")

[@rasmadrak]

www.ripleys.com/weird-news/coin-toss-or-not/ ;)

[@derDrache1988]

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

[@overloader7900]

@@derDrache1988 fprint(rand()%1?"twins":"tails"); Instead of % could be &

[@esbensloth]

Random.nextBoolean()?"tails":"heads"

[@ishdx9374]

@@overloader7900 %1 would always give tails

[@szredinger]

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]

It seems to me that the best use case for UML is reverse engineering code lol

[@Austin1990]

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.

[@stevendeans4211]

UML is good for analysis. A way of stating the actual problem and the required solution.

[@stevendeans4211]

@Jumpy Cat I have a pre release copy of the standard that I got back when I was designing with OMT.

[@0xfeedcafe]

UML are so useful, it sucks that not many people use it

[@1dkappe]

Having been in the computer science racket and then later owned a software development shop for over 20 years, this video really points out problems with both the author and the industry. Of all developers, only 10% can manage OO. The rest should stick to procedural and, to boot, not write large and complex systems. Of the remaining developers, less than 1/10th can manage functional programming. Those aren’t good odds for building a business or industry. What this author is ranting about, I suppose, is all these rules and acronyms that are meant to help the developer who lack the cognitive ability to write OO code produce something useful. I’m not sure that he understands that’s what he’s doing, though.

[@yawaramin4771]

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.

[@1dkappe]

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

[@yawaramin4771]

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

[@1dkappe]

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

[@yawaramin4771]

@@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 ;-)

[@John.Farrar]

Brian, other approaches I have considered are these. Your point about UML is something I partially support. At the beginning we are often answering more questions than we can answer.Iterative changes will come if the application is used and lasts any amount of time. Instead of which is superior, how about considering the strengths of OOP and functional code and creating a mix? There is another flaw in teaching it is bad when it creates a win. There are better wins possible, but the debate on better wins is far different than good and bad. My perception there is if you don’t win like I win you are not winning. Or, if your win is not as profound as my win it is bad. I do realize you are not the originator of this debate, so this is something too many of us have accidentally joined comparing apples and oranges. The end result is oranges suck because. We can show how apples are better fits. P.S. When this whole debate was ramping up there used to be a teaching of Pure OOP.. I used to as similar questions in that season. I called OOP ravioli that hid complexity vs procedural done as spaghetti. Spring files became the new location to store confusion during that season. Granted, spring has definitely improved but OOP went woke on procedural in those days. My quest, agile code that is sustainable. Reduce technical debt and fulfill the why to business needs above the how.

[@thomaslogan3003]

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

[@testingbls]

What is easier to persist than a hash map?

[@AntsanParcher]

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.

[@alectoperez1383]

Why not just have operator overloading? Then you don't need run-time polymorphism :)

[@jaesangkim1930]

I like your comment and agree with it to some degree at least.

[@laeioun]

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.

[@dmwalker24]

I've worked with more than a few devs who absolutely did not have a complete understanding of the program as a whole. Maybe that's why they couldn't see why I wanted that kind of end-to-end understanding in my operational roles. If there's a problem, I want to be able to conceptualize where that problem is likely to have come from.

[@benvella1728]

I thought this video would be in jest... Turns out I found the flat earthers of programmers.

[@rlbond]

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.

[@Danielle_1234]

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

[@LabGecko]

rlbond Did you watch the video? He starts off covering exactly what you said about toy examples.

[@maksymiliank5135]

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.

[@Boxing_Gamer]

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.

[@jasenq6986]

it definitely does not scale well from my experience. Its probably the antithesis of scaling

[@cliffmathew]

I have found the sequence diagrams useful when discussing, reviewing and revising expected functionality among the team.

[@aaronbono4688]

There is a massive difference between how you code a small app vs a large app. For example, weak typed languages are great for small, little things because you can whip them out quick and without a lot of planning and design. However, large applications are best with strongly typed languages as the large code base makes it very hard to keep all the data structures and names of variables, classes, functions, etc. in your head. Likewise, OO vs. procedural vs. functional languages have their strengths and weaknesses. For example, with a large Java Spring Boot application, I want to create well defined interfaces that my code talks to. Then on startup, the application will construct implementations that may vary from one implementation to another. With Spring, it creates singletons of the controller, service and DAO classes so we are not constantly creating and destroying objects. These Spring beans might actually contain other objects like a DataSource which is used to connect and talk to the DB. The beans could also do some caching or hold configuration or so many other things we would need to make the application configurable, scaleable and fast. When you start to have an application with 10's of thousands of lines of code in it, just having functions and data structures becomes very limiting. Basically what I hear the complaint about here is more around not using the proper tool for the job at hand. Sometimes OO is a horrible choice (like small and simple sets of code). Other times it makes the code clean, well organized and versatile.

[@alphaforce6998]

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

[@aaronbono4688]

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

[@voxorox]

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.

[@michaelmahn4373]

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.

[@rwxrobfun]

You actually could not make such a video about procedural programming.

[@storerestore]

@@rwxrobfun "It's embarrassing how our CPUs ultimately execute the code we write!"

[@rwxrobfun]

@@storerestore The level of inexperience and ignorance in that statement is dumb-founding. This is why I engage the equivalent of flat-Earther technologists.

[@SpecOpsFerret]

Brian sounds like me while revising my own code after a few months.

[@martinn.6082]

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

[@asthmaticpathic]

It’s interesting to me how objects are meant to help better understand how data interacts in your application, but it ends up making it more complicated when it’s not needed.

[@dbtest117]

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.

[@tecTitus]

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

[@AnalogIdeas]

If you are using the class as a namespace you don’t need a “useless instance”, you can make the methods static. The “instance” is only useful if you are following an interface where you can swap implementations.

[@botondhetyey159]

I mean, why do you need a class if you're just gonna use it as a namespace anyway?

[@AnalogIdeas]

@@botondhetyey159 obviously it isn’t necessary, but the class still provides the unit of loadable code. It can also be unloaded if the code is no longer needed. In that way the class is just like a shared library/DLL. It’s really not a big deal. If that’s all you have to complain about, they must be doing a good job.

[@Asto508]

⁠@@AnalogIdeasIt's even funnier if you consider that making that class static is also making it zero cost in comparison to having s bunch of loose functions. OOP is sometimes also about access modifiers and grouping functions properly for other developers instead of having them accessible from anywhere and hell to happen. That guy simply doesn't understand the purpose of OOP on a larger scale.

[@skipfred]

I like that you acknowledge right in the beginning of the video that the strongest argument for OOP is in large, complex programs, then proceed to not look at any large or complex programs and conclude that OOP is bad based on that.

[@yoursubconscious1774]

He did state in the video that if anybody can find GitHub repositories with 1000+ lines of code email him and he said he’s just going to look into small examples that he found on his first search. This video is just a starter explaining it

[@BritishBeachcomber]

The examples do not prove that OOP is bad, but simply that the examples themselves are badly coded.

[@NoeLPZC]

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.

[@HonsHon]

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

[@Grunchy005]

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?

[@NoeLPZC]

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

[@howardlam6181]

@@Grunchy005 No. There are multiple cores in the CPU and the GPU accept jobs in batches.

[@maunique2852]

Just found this video (you will probably not even check comments on a 6 year old video). I am so pleased to find a like minded person regarding Obeject Oriented programming. I have been a software engineer (yep different to a coder) for 30 years now mainly working in real time embeded and safety critical so my view may be different to data analyst environments. So refreshing to hear a view other than OO is great and the future no matter what. One point I dont agree with you on the use of suitable design (not UML). Sitting down to write code before planning structure, units etc in not a good approach in my view/experience. Other than than, great video!

[@Muskar2]

Reading some of the comments to this and seeing the like/dislike ratio, it's incredibly apparent that the industry is ripe for some deeper discussions about this. Some day there needs to be a tally of all the common defenses for OOP, so it can be properly debunked for good. I'm sick of software that is 1000x slower than it could be, and is impossible to maintain when it scales - and somehow pretending that it's the optimal way or that the gospel isn't truly followed.

[@alphalobster8021]

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.

[@sadunozer2241]

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

[@jadetermig2085]

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

[@Fudmottin]

One of my first programming jobs, I worked on a project written in C++. It was reasonably sized, about 500KLOCs. I came up with the term "object oriented spaghetti." OOP doesn't protect you from spaghetti code at all. I was thrown into the deep end doing debugging. So I had to do a lot of call stack tracing. This was financial trading software. You could think of it as a retail version of a Bloomberg terminal.