OMG so true! This drives me nuts in my C++ job! Every time I want to figure out what is happening I have to go up and down the inheritance/interface tree. Nothing does anything. After 3-4 jumps I don't even know what I am looking for. Alright, then you realized let's say there is no actual implementation in this dependency tree. Great. You search for all classes that implement the interface in question. Excellent, they all do something different. Now you have to find that the piece of code you were originally looking at which implementation was used in the background. But then you can easily find yourself in the same cycle, trying to find what implementation actually got there. Madness. Even worst when you have interfaces prematurely. There is only a single implementation yet, I need to jump to extra hoops, because we designed the system.
Yes, I get frustrated with this at my job too. I use my debugger to automate searching through interface layers more than I use it to actually debug something.
I subscribe to what you said, true, totally true. And i'll add : when you have to reverse engineer a binary of which you don't have the source code, you can see pretty soon if it was written using OO because nothing does anything, and the cpu just sits there doing function calls and shoveling data arround for nothing, and after a few hundred cycles it actually does something ( like a sum, or a xor or , you know ...something usefull, the actual computation ) Or when the control flow just disappears into nothing, because the function to be called is computed at runtime... Then we complain that damn word.exe barely opens on a 24 core machine, and when you write, the letters lag behind your typing speed and stuff like that.
The problem is people focus too much on one paradigm. Objects are great, but everything doesn't have to start by inheriting a purely abstract class etc.
"Objects are great..." [Citation needed] The problem with generalities like that are they don't always apply. Even worse I've yet to see a time where an OO object is great vs simply using a `struct`. Unless you just mean `struct`s with pure data are great?
@@totheknee Citation needed? I said it, you're quoting me. You're argument is like me saying, "hammers are great" and you being like "not always!" For what objects can do they're great. Being great doesn't mean it's great for everything. If you don't understand basic logic like that then you need not be programming anything my friend. Especially when i preface that with "people focus too much on one paradigm" lol trying to figure if you're a fail troll or what
5:40 - Being honest here: please don't mix up the term "premature optimization" with "premature overengineering." Reason being that almost no one these days seem to know what optimization even means, and they just repeat what they hear without understanding. It's so bad that some (most?) programmers these days think that simply avoiding writing slow code in the first place is "premature optimization." For example, if I avoid a triple nested loop and just use a single constant instead, someone will jump down my throat and say I'm "prematurely optimizing" when in reality I just didn't need a triple nested loop. It's almost as if they think we _need_ triple nested loops everywhere, and then we remove them at the end of production in the mythical "optimization phase."
I think that if you don't need a triple nested loop, it's perfectly valid to refuse this code in code review not because of optimization but because lack of maintainability + readability. Code review then indicates a better implementation, and maybe redirect to a code guideline that leads everyone in the project to better readable code.
@@fellowkrieger457 I find code reviews are a waste of time for everyone, except when training someone. Additionally the best programmers have the least time to do reviews, and often the mediocre programmers add the most lines of code, so overall it's likely to produce worse code. If the project has implicit rules that are hard to get the large teams to follow, we've found they should be made explicit by automating them, e.g. with compile-time validation rules.
The issue I have with casual use of words like optimization and performance is that they aren't specific. Optimizing for what? What trade-offs are acceptable? How are you defining performance? Many people who throw around the word optimization a lot don't even know what it means.
@@brandyballoon In terms of defining performance, the biggest thing missing today is knowing that the hardware limit requires simple arithmetic to figure out, and measuring against the theoretical maximum is extremely simple and powerful, yet virtually nobody does it anymore. If you're only ever measuring relative gains to other software/versions, then you'll never know whether what you're doing is actually performant.
I hate when engineers starts to implement design patterns without an actual need. The codebase isn’t even got any bigger yet. And instead of building a momentum to ship product faster, they stuck arguing what design pattern should be used to make it future proof.
@@DEBO5 Sure, but that is exactly the problem. You don't know what the requirements are going to change to, or even *if* they are going to change at all. There is this deeply rooted fear of throwing away code and just building from scratch. The people who love their abstractions deal with it by building these overly general abstractions, where a simple if statement or switch might have sufficed and been clearer. The people who dislike abstractions deal with it by writing giant modules of spaghetti code, that you need to be inanimately familiar with in order to maintain, instead of just using a bit of dynamic dispatch or a well known pattern. The former wastes incredible amounts of time building their tower of abstractions for things that could have been simple and the latter wastes incredible amounts of time maintaining their brittle code because it got more complex than they thought. Both lead to code that is incredibly hard to read and reason about. The non-abstracted code, because you've strands of spaghetti going off in all directions and the abstracted code, because now you need to familiarize yourself with the tower of babble that was dumped on you. The point isn't to avoid design patterns and abstractions, it's to avoid their premature usage. Ideally, the the code should always be the simplest code that deals with the actual problem. Implement that code and if at any point you notice that your simple code stops being simple, tear it down and write code that uses the abstractions and patterns that are actually applicable to the new requirements. But don't start off moulding your code to some distant fantasy requirements that may never materialize. You're going to waste a lot of time writing abstractions that are utterly unnecessary.
Although, I agree that generally pre-mature abstraction is bad (that it negatively affects developer productivity) and that quite a lot of organizations like to "abstract" things out to make the code more maintainable and extensible without the need for it, I would, however, like to visit your point about - "code that perfectly solves the problem with some SOLID principle violations". I think we, as engineers, should understand that the problem you are trying to solve is a constantly changing goal-post. If you solve perfectly solve problem A right now even with bad code, you will then probably need to solve problem B, followed by problems C and D. This is a very likely scenario in all (big and small) organizations. That is when writing code with abstraction shines and is very much needed. Understanding the balance of how much abstraction your code needs is what you, as an engineer, should decide. If you over-abstract too soon, or if you do not abstract at all - both these scenarios will bite the engineer later. OOP/Abstraction is not the problem, but a tool, and we should not overutilize it or shy away from it.
@@drygordspellweaver8761OOP is a paradigm. What you’re talking about is people that think something is true without reason (which I think equating OOP to a cult falls under). There are people who do this for every paradigm. These are all just approaches that organically arose to solve problems. Sometimes approaches are supplanted, sometimes they remain valuable for certain problems. I haven’t seen any compelling evidence that OOP no longer has value for all problem spaces.
The point is that you can abstract it later, if you really really need it in order to ship your project. In reality, most of the time you don't need that abstraction, even in company working with team. You just need to ship project, earn some profit and than decide, do you really need to abstract something, will it solve the bug tracking problem, or testing problem or team productivity problem. You should analyze it later, it will safe your time, your mental health, your motivation to stick with project and team.
Not everything needs an interface or base class. Not everything needs to be injected through DI. Not everything needs its own library. Not everything needs clean architecture or DDD. Follow these and you’ll be fine.
Not everything. But simple DI helps create simple, consistent test harnesses and mocks. A lot of the frameworks are "magic" in the sense most don't care how they work and there is heavy reliance on opaque annotations. But ultimately they just hide repetitive mechanics and can let programmers focus *more* on the business logic and tests.
I think this was the biggest mental hurdle I had to overcome when I started programming. I was basically learning how to conform to this weird standard. I also think that's why I appreciate functional programming so much because you get to solving problems a lot faster That being said, I do think OOP has a place. I don't see why it's bad that we have industry standards in an industry. It gets out of hand at times, sure, but I'd rather have guidelines for everyone to follow rather than everyone doing their own thing
Doing an own thing is good if it's a good thing. But the programming society is not uniform: some are better educated, some have stronger common sense and measure than the others, etc. I've seen a recent interview with Dave Cutler - can't imagine a person like him following standards. He is the one who defines them.
"I don't see why it's bad that we have industry standards in an industry" Plainly, I'd say standards are good. But OOP isn't a standard, it's more of a philosophy or a paradigm on how to structure code. Most people don't do OOP, even the ones that do doesn't mean they do it "right", there's plenty of ways OOP codebases can differ, there's usually unwritten conventions for a particular codebase. We have some standards that work and are followed, like for example TCP, but as a whole this industry is a mess.
it is a problem the same way agile and scrum and all this shit is a problem: you are paying for illusion of efficiency with actual efficiency. I could not be a problem, but it is. Truth is, interfaces in Spring help you inject or override code from module to module, but there's nothing about OOP in that, its just Java. If you are writing an interface of an abstract class of the class you need but wouldn't need if java didnt enforce objectifying because you think it is the correct thing to do (and a lot of people do) then we have a problem
I’ve worked with too many people who can’t even explain code they wrote four weeks ago because everything is abstracted away behind services, factories and interfaces that do nothing but juggle data around in the most convoluted way possible. Everything is “maximally reusable” but never gets reused. And then the desire to wrap SQL which is very well readable in massive “builders” where you have no chance to quickly check what SQL is actually being executed.
The point is to not have to read the raw SQL. Why you would ever want to do that beyond performance analysis is beyond me. In fact, its advisable to do this for security reasons so you dont make injection attacks easy. And I honestly cant think of how you would even construct an OO architecture without reuse. Its practically impossible unless you absolutely suck at understanding it. Factories make sense because they allow you to do things in a more flexible way. For example, Ive used factories for building database connection strings. Doing this makes it stupid easy to add connections to new DBMS or even different file types. Most people think supporting multiple DBMS is a waste of time, but it's not uncommon to need to switch between multiple ones, such as Access and MSSQL for example.
I spent almost year developing a shitty interface that basically read back and from between two systems. One used a REST API and the other an oracle DB. Then the team responsible for the oracle DB said, we're switching to MS SQL. Because I used an abstraction layer I only changed a single dependency and a few builders for the connection strings, queries, etc. The switch took me about an hour? If I was rawdogging SQL in every function that needed to read or write that DB, man, have mercy on me.
@@jshowao It may surprise you but some people can read raw SQL better than stacks of ...->and(...)->or(...) - not just for performance analysis but also if you wonder why the result isn't what you expected. Also I wasn't dissing OO architecture in general but the anti-patterns that many people build thinking they're doing it right. And I've seen enough AdapterFactoryController and AbstractInterfaceProvider classes to know when something's off the rails.
@@jshowao _"Forth is said to be an amplifier. A good programmer programs better in Forth; a bad programmer programs worse in Forth. The sad fact is that too many programmers must be considered "bad"."_ And they write all those frameworks, libs, modules - which halt without reason in the middle of a run, consume *HUGE* amounts of memory - or just barf out a stack dump while inexplicably waiting for something. "I don't care how much data and code is pushed over the line at any time - that's the responsibility of the framework". That's why.
@@jshowao "The point is to not have to read the raw SQL. Why you would ever want to do that beyond performance analysis is beyond me" Because SQL is pretty easy to read and is... a standard. SQL is already an high level abstraction! (Some raw SQL may be hard to read, but this is usually because it does complex things that no abstraction will be able to significantly simplify.) "In fact, its advisable to do this for security reasons so you dont make injection attacks easy." You should never inject a non sanitized string into a SQL query of course, but this has nothing to do with wrapping SQL behind an abstraction: parametrized queries are fine.
You're using it right. Abstraction inherently isn't bad (it's obviously what a lot of coding is about), but when you abstract, you start putting up walls and sometimes it's hard to couple those abstractions together in order to work together the right way. So it can be bad to unnecessarily create abstractions before you need them because you end up spending your time connecting them together in the right why and it ultimately makes your code less dynamic. EDIT: I don't know why everyone has to have a moral judgement on everything. It's a tool in your toolbox, use it at your will. If you don't think you need, don't use it.
The characteristics/parts of OOP are tools. Yes in a purity sense, treating a paradigm like a religion is what I mean. And yeah I wouldn't say he's making a "moral" argument, I mean it in a more figurative way. I'm not sure what the word I want to use is. All I'm saying is it doesn't have to be all or nothing.@@marcs9451
As always, it really depends on the context. It’s easy to cherry-pick parts of Object-Oriented Programming (OOP) and rant about them, but the bigger picture matters. If you’re coding solo on your personal project, no one cares what paradigm you use. But in a company, working with a team, it’s essential to follow the same standards and patterns. OOP principles are just the basics-things like the Repository pattern, MVI, and others help make code more maintainable and readable. These patterns aren’t just ‘rules,’ they’re tried-and-true methods for keeping large projects organized. In bigger projects with thousands of files and millions of lines of code, skipping these leads to spaghetti code. While every developer might think they can do it better their own way, most hit a wall eventually and realize that these principles exist for a reason. Consistent standards make it easier for teams to collaborate, maintain, and update the code
@@shrin210 Inheritance is essential for OOP for large scale projects, just so that you can implement the strategy pattern, which is the pattern necessary for anything that has any type of behavior that changes depending upon the input during runtime. If your code doesn't change its functionality based on inputs during runtime then write procedural or functional code and don't use OO. My biggest issue with the rants about OO is that the examples people give to say OO is bad is not OO done right, but OO done wrong, and then labelling OO as always wrong. To be fair most OO done in business that entry level devs see is OO done wrong, because most devs use OO wrong and try to add in patterns where they shouldn't be if they are even that advanced.
@@toms7114 Totally disagree that Inheritance is necessary for large projects. People are building large projects in JavaScript, Rust, Golang and C without any inheritance.
@@shrin210 And all of those languages are hard to maintain as large code bases, because those languages have built in excessive use of composition. The best argument I've ever heard for composition is if I have to add in some new feature to a class once I use composition and I mark it as the first composition, if I have to add some new feature to the same class twice I add it in and mark it as the second composition, if I have to add in a new feature to that class a third time I refactor. Also c should never be large scale, it should be small procedural code snippets for drivers that gets used by larger programs to control those devices. I am saying to use the right language for the right job. I'm not saying use OO for everything is right, I'm saying that the control methodology for large scale programs with a large team working on it should follow OO design patterns and principles and have those patterns and principles be the coding practices that are enforced when modifying that code base. I get why composition is favored in modern coding practices. It is easier to get new devs up to speed, but it ends up costing more money because you have to have more devs every step of the project. I guess I am just too much of an engineer to think that a well designed system is better than spending more money over time by throwing bodies at a problem to solve it.
@@toms7114 Who told you composition needs more devs and cost more? Pure nonsense Composition is explicit and Inheritance is implicit. With inheritance they tried making abstraction easy but Tracing inheritance became the toughest part. Watch the talk on Data oriented programming. ruclips.net/video/rX0ItVEVjHc/видео.htmlsi=km5qM3ZQFqgAa7Ew Summary of video. Programming like OOP concepts ( reality objects inheriting something from other objects.) These are just nonsense concepts. Programming is just tranforming one form of data to another form of data and that is the only reality - Data oriented programming
Regarding Alan Kay's definition of OOP: As I understand it his idea was very similar to what we call today "actor model" or "actor-based concurrency", which is the core concept behind the language Erlang. The idea is to have "objects"/"actors" that only communicate via messages instead of direct method calls, and just react to messages they receive. Software built like this is very easy to distribute across multiple CPU cores or even devices as the program itself doesn't need to concern itself with how the messages are actually transmitted. It also reduces coupling to a point individual actors can be restarted after a crash without affecting any other part of the program, the worst that can happen are some lost messages. Erlang was designed by a telecommunication company (Ericsson) for minimal downtime of their systems, and this actor-based model allows live updates as well as crash recovery without any downtime. It's so good at what it does that many modern messaging services (e.g. Discord) still use Erlang in the backend.
The difference is that in Kay model messages are asynchronous, in the later and simpler models they're synchronous. It's not that much of a difference on the system design level.
I think the main take away is that only HUMANS care about objects. It's more in line with how we model the environments around us. But an "object" from our heads can only ever be _grafted onto_ problems in computer space. I think OO offers itself really well to situations where there is a real-world system already in place that your program is modeling and "objects" in your code line up with actual real objects in that system. It's also pretty good for setting up guide rails for other developers, but if those guide rails are bad then new devs will inherit bad practices. For solving a single well-defined problem, I think sticking with procedural programming is the way to go. Starting with OO will cause you to set up arbitrary walls to stay confined in when you should just be focusing on raw problem solving. Procedural lets your solution change shape at will so you can really explore the problem space.
Agreed. I frequently will solve a problem procedurally first, because I found that trying to make it OO from the start resulted in lots of time wasted as I learned more about how to solve the problem I was working on.
OOP maybe good for game development, because its actually modeling some sort of world with state. CRUDs not model anything. I did program games without OOP, and its just as fine, as every other application.
Having grappled with abstraction, SOLID and design patterns for over 20 years all I can say is Hallelujah. I can't tell you how often I've had to think "wtaf does open for extension and closed for modification really mean and do I really need to follow this rule in the age of modern refactoring tools?". The worm is turning. Over abstracted code is an absolute mindfuck. I started to push back on pointless abstractions on PR's a while back. OOP and it's rules were a best guess of how it should work at a certain point of time. We've seen the results. Pretty horrible. And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method.
"And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method." Thank you! I repeat this to no end, but the message does not seem to stick. There is a religious fervor to which "clean code" is applied in some circles that bothers me sometimes.
Looking back, my favorite concept is the "Object Calisthenics" challenge. For those who don't know, it's a way to go extreme with OOP, allegedly to practice how to think that way. But if you've ever given it a serious go, you'll quickly find that the work required gets exponential really quickly. And looking back it's embarrassing that I didn't realize the absurdity then. I just thought I needed even more practice. It wasn't until I heard Muratori speak sense to Uncle Bob that it all clicked for me why I had become so disengaged. Every time I get to work with problems rooted in fundamentals, I love programming again. I had lost that.
Object-Oriented Programming was invented by Ole Johan Dahl and Kristen Nygaard for the Simula language in the 1960s. It was especially designed for modeling real-world systems and simulations, introducing key concepts such as classes, objects, and inheritance.
There is a HUGE misunderstanding about the Dependency Inversion Principle. It indeed says to rely on abstractions rather than implementations. But that's only the second part of the principle. If you apply only this part, it will lead to code that is too abstract and unmaintainable. The key is the first part that says : High Level Code (business/domain) should not depend on Low Level Code (details), both should depend on abstractions. That is, separating only the low-level concerns (Persistence, UI...) from the high-level policies (Use cases, Domain Model). That's the core of Hexagonal Architecture / Clean Architecture, and what I teach to my students. With the notable benefit of being able to test your Domain Model independently from the low-level technical concerns. And being able to swap out your ORM/Database Engine if necessary. And being able to run your code locally or inside an airplane with no internet access, since the gist of your code is implementation independant. The only caveat is how your code is a little bit more difficult to navigate because from your domain model point of view, you can't know which implementation will be called. In practice you rarely have more than two implementations (in memory & concrete) so it's seldom a problem. That's a good trade given all the benefits you gain (testability, reusability...).
The idea of domain layer is very weird to me. I would rather architect the program just simply with UI/Presentation layer and Business/Backend layer. You don't need more layers. Its much easier to add integration changes, add few queries to database or rest service or to low level api.
Things very rarely get switched like ORMs. Even after a few years a codebase is considered legacy and the only way to get ahead doing it in a new way that is popular at the time. I think thats what happened with OOP. The ancients thought what if we do it this way and it worked well enough to be handed down to every programmer that came after. Not every programmer but you get what I mean.
On the other hand, there's the old saw: "There is no problem in computer science that can't be solved using another level of indirection." I remember once trying to program a calculator using only instance variables. How much easier it is to solve a problem like this with the appropriate data structure. Once you have data structures, I think you're starting to move towards OOP. There's another book I read a bit of called "The Philosphy of Software Design". One refreshing aspect of that book was the author's focus on complexity -- the central problem in software design is supposed to be to minimize complexity. Sometimes all the cruft of OOP increases complexity. Indirection itself is a form of complexity. A hierarchical page table is harder to understand than a simple page table, and a simple page table is harder to understand than a giant array that makes no distinction between physical and virtual memory addresses. But you get so much power out of separating the physical location in which a piece of memory resides from the system you use to identify that physical location! The difficult thing is developing the foresight to know when making something more complicated in the short run could help to make things simpler in the long run. Sometimes you can get the worst of both worlds, obviously.
True! There's also a mantra to not over engineer and to prematurely abstract. So you should decide when to abstract and in that case you knew it needed to.
I know a place where OOP is taken to the point where they cannot figure out the final composition of the objects after all the polymorphism, overloads, templates and inheritance. When you have a literally 500 classes entangled under your object, good luck.
Stop it all right here - OOP in C++ was modeled (or influenced by) the Simula programming language. Simula introduced objects in 1967. Smalltalk programming language appeared in 1972, so Simula preceded Smalltalk in respect to object-oriented programming. And Bjarne Stroustrup has very explicitly cited Simula as his influence per the object-oriented programming features of C++. This is all straightforward history that anyone with CS background should know.
18 дней назад+1
Overuse is always a problem. The experienced developer is the one who knows when to not use a certain paradigm/pattern/idiom. Problem is it takes many years to reach that level, if ever. OOP is great when done carefully. It is part of how we are able to make the large systems of today.
These tidbits of information have persisted from among the elder members of the programming community, they are exceptionally valid here. Abstractions should be useful, classes are abstractions. Prefer the free function unless you have something you actually need to encapsulate. There is nothing wrong with accessing a class/struct data member without getters/setters if you don't need them.
The problem with Blow is that his statements are weak and don't solve anything. Yeah, sure, you can just focus on solving the problem, but it doesn't automatically mean that the problem solution will be easy to maintain and to reuse. That's why paradigms and software-architectures were invented in the first place.
seminar called "why isn't functional programming the norm?" is basically all about the history of OO programming. And yeah, the original conception isn't obviously bad or anything. Regardless of whether or not you think its good, you have to acknowledge that it did not become ubiquitous BECAUSE of an analysis of the usefulness of the doctrine. It became ubiquitous because of fashion. C++ became the fashion, java was marketted to C++ users and new programmers, and javascript was marketted to java users, and so-on.
It sounds like the real problem is the way dependency injection is used than object oriented programming. I enjoy object oriented programming. I HATE the way some developers not only over use DI but throw in the mediator pattern breaking all my tools for discovering code. I’m a software architect and I read A LOT of code. It’s such a pain.
@@skyhappy I use “tools” in the sense of techniques. Often times in Visual Studio you can use features like “Find all References” to see how a function or class is used within a project. Dependency injection can break this to a degree.
@@brianm6965do you mean dependency inversion? That's when classes only implement interfaces. I used the same find all references tool in Visual Studio and also had to find implementations a bit painfully this way.
@@brianm6965I use DI in VS and have no problem with the IDE resolving compile time references. Don’t really understand what you don’t like about it; I follow the principles in “Dependency Injection in .NET” and find it lends itself to writing more loosely coupled code that’s more testable and the object graph is very easy to understand. Wondering if you’ve worked with it where people abuse it (resolving things front the container all over the place instead of using constructor injection)?
@@brianm6965 Well, dependency injection intentionally does that so that you can just inject a mock service or another service when you want. It's meant to help testing code with 10 different mock services for 10 different situations.
So I just started learning OOP and so far I really like it. I think issues with it arise when you turn every little thing into a class, similar to how "clean code" says that if a function/method does more than one thing it should be refactored into another function, which is absolute madness. OOP is essentially just building a program out of bricks, but some people go too far and break the bricks down into gravel, and some even break it down into sand. Even the book where it's only lightly touching on OOP paradigms (it's for a specific language, not OOP) goes too far imo... there are parts where it suggests making an object for what should just be code executing in the main program entry point for example. I've also only just barely learned about inheritance and I can already see that being a nightmare if you don't really use restraint and only use it where it saves you from writing pages of boilerplate. Basically OOP seems like a very, very good model for breaking down programs, avoiding global state, and protecting code from other code while still allowing the pieces to interact, but it also seems very easy to go overboard with.
Inheritance should be largely avoided. Use Interfaces instead of inheritance. OOP is very good when you have very large programs that you're working on over years. Take an enterprise company with 1 million lines of code and you'll be glad its all ordered out the way it is. The first time you open a class and find it does...everything with functions that do...everything, you'll understand.
@@chudchadanstudagreed but it is commonly abused and can easily make code more confusing. Sometimes it’s clear it’s the right choice but I think “preferring composition over inheritance” is not a bad general rule
@chudchadanstud learned the hard way that yeah Inheritance should be avoided. It's not dogma but just experience from its pain. prefer composition instead.
Good abstractions take lots of time, attention, vision, case study, prototyping and testing to make. When done well, they can survive generational change in technology. A great example of this is a core protocol such as HTTP, which I don't think would be a stretch to liken to a plain text OO interface. I think lots of people, myself included, had dreams of their code living forever and only being built on top of because we saw the success of some legendary early abstractions. But in reality, my procedural code from the 90's outlived OOP code I wrote much later, simply because I was not able to come up with high quality models several times a day every day, and bad assumptions would just pile up. These days I lost all shame to do everything in procedural spaghetti first, and factor things out on first reuse. This way most of it naturally coalesces into a hierarchy of objects, and the stuff that doesn't is obviously not doing anything worth abstracting. So I can either completely forget that it exists, or if it has a bug, I enjoy the benefit of fixing a flat page of code that contains most of the context of the problem, that's usually very generously commented because I was relaxed and grooving hands on with a fun problem when I wrote it.
The problem is further exacerbated when you are working in a large codebase and you’re forced to solve a problem that exists because the original design of the class didn’t know all messed up ways programmers are going to use the class down the road. Solving the problem becomes exponentially harder because you can’t just go into the core code and start modifying abstract classes fields and instead you have to hack your way around the structure in place and potentially making it even more confusing because now you’re extending the class and casting objects as your new class. It can get messy for sure. The joys of programming.
What you're describing is a situation where someone DIDN'T follow OOP principles. The programmer violated the very first principle, which exists specifically to address this situation.
The useless part of Jonathan's discourse is "in the eighties it was better, people were better and more intelligent, oh how we have sunk". This is basically the same old story told by every conservative. Maybe OO is bad, maybe it has gone too far, maybe it's a mistake, but it too was invented to try and solve a real problem: projects got so big they started to be unmaintanable and unreadable. It was a mess that cost companies a lot of money. Today we have way better tools and other techniques, so maybe we can ditch OO, but no need to fantasize about an idealized past.
Some people take SOLID literally. They write 10,000 methods, each doing one and only 1 thing. So the program ends up being 50 times more lines of code and running 10 times as slow as just a straight forward procedural implementation. And God help anyone who has to fix a bug in that mess.
I'm not older, but I have used Smalltalk and I love Smalltalk. Things like Smalltalk and Erlang are really what object oriented really meant. Something radically different from C++ or Java.
Having spent nearly 15 years writing code, I've found that most people are using classes more like modules organising functions (particularly in Java). From my experience, files & folders are the best module system for organising code and classes are most useful when reserved for validation whether that be validating a collection of values (as an object - like contact form details) or a single value (like a 255 character string, an email address, a positive number, etc). When it comes to inverting control, I don't until it's necessary, and when it becomes necessary, I opt for more of an adapter pattern with functions, where an adapter function sits between my implementation functions switching between implementations based on an environment variable or an additional function parameter. This makes it really easy to navigate through the actual implementation code and reduces abstractions. The obvious issue with this approach is that I could easily forget to provide an adapter and implementation for a particular function (e.g. a database call to create a record) whilst having adapters and implementations for all of my other database calls. I suppose it's an issue I'm willing to live with for the benefits the approach provides, if it were a serious recurring issue, then I could make use of some facade-type pattern.
Why not just solve the actual problem as simply as possible? Adding needless interaction and complexity to your code does nothing but create slow code. Our thoughts should not be about arbitrary things like objects. We should be thinking about the way our hardware performs its operations. We should be thinking about vectorization of mathematical operations, we should be thinking about cache friendly data structures. We should be thinking about organizing our code to assist the microcontroller or microprocessor in prefetch. Only after all of these considerations should we think about the best way to organize the constructs in such a way that they are maintainable. The code that we write lasts for years or even decades and when we write over abstracted bloated code then we lose so much potential in terms of speed of execution, memory consumption, and power consumption. Spending a little more time thinking about and writing our code will more than make up for itself.
@@brotherpeter00 I kind of agree, particularly that "Only after all of these considerations should we think about the best way to organize the constructs in such a way that they are maintainable". For example, I'd say for an "application" less than 100-200 lines, you may as well write all the code in a single file. I think it's a balancing act between writing code for maintainability and performance where the balance depends on how quickly/often you're going to iterate on that particular part of code, the size of the code, and how much impact that code has on end users. For example, if you're only going to get an opportunity to optimise the code once every 18 months and the code is only executed once every 3 months, you may want to prioritise maintainability over performance. I guess ultimately, it's all circumstantial.
OOP is just one of the many paradigms you can use, if it doesn't feel right for the problem you're trying to solve, then simply don't use it. 🤨 But keep in mind that you can always experiment and COMBINE elements of different paradigms.
I find that the biggest problem with object-oriented programming is the people are so concerned with object-oriented design that they fail to do the most basic thing which is have a firm understanding of the problem they are trying to solve.
Skill issue. Literally every paradigm (functional, imperative, etc) doesn't "solve the problem" and just provides a framework for solving problems. That's why they're paradigms, not solutions. Use the one that works best for the problem. Also, building for interfaces allows you to easily use a stub or fake when testing, even if you only have one real implementation.
OOP is totally fine and in fact very similar to imperative if you don't use inheritance. After all, there's little difference between data.doThing() and doThing(data). I think one of the biggest problems with OO is trying to reuse code through inheritance, which usually gets really messy and unmaintainable. If you have clear separation of data, logic, and presentation (not OO-specific recommendations) and avoid pointless abstraction, OO can be great.
I would absolutely avoid virtual mapping. Because, why introduce some indirection when you can allow the computer to get it directly? Inheritance turns out to be very useful if you want to enforce unit type correctness in Physic. Like a function that take Radian and you pass in a Degree and it gets converted at compile time to radian. And give error if you try passing in float for instance. You do something similar for glm::vec3. Like Point and Direction both use vec3, but, are not the same. It is meant to be used as correct enforcement tool. The idea is not to stray too far from basic. Don't adopt just one paradigm.
No, because data.doThing() takes a whole lot of extra boiletplate underneathe the hood. OOP is atrociously slow on top of adding complexity for the sake of hiding data.
@@drygordspellweaver8761 data.doThing() and doThing(data) is exactly the same as far as the compiler is concerned. This idea that OOP is slow is actually incorrect. What truly matters is how the data is laid out and how it's being used. OOP class stores data in interleaved form. So if you just wanted an array of position you need to separate them from the other so it doesn't "pollute" the cache line with information that isn't position if all you wanted was position. Yet. Interleaved data is also beneficial in it's own way when you do in fact use all of the stuff in one place that was in it to reduce jumping around memory. It is a tool. None else. If all you have is a Hammer everything is a nail. So, use everything that works well for the task at hand.
Exactly! Stay away from inheritance except for inheriting types for increasing readability(You know, declare an abstract class Vehicle that does nothing and then make classes like Cars, Motorcycle, Airplane, etc inherit from Vehicle. This does not break your code and helps later on if you just want to do an operation on any kind of vehicle without writing 10 if statements. Later on you can add the common abstract method to the Vehicle class and implement it in your sub classes). Other than that don't overuse inheritance. Go with composition.
He is right yes. Even if you manage to define a good abstraction it still took you energy to do so. It's like those pagination algorithms that computers use: the threshold at which they are worth it is when they work 90% of the times, and they work 92, but for object oriented programming most of the times you are adding cognitive overhead as well as actual overhead. OOP can be good but you always need to ask yourself if you are being organized or just fancy. Ask it constantly, and never get used to just being fancy.
This feels like a strawman but I'm not smart enough to say why. Functional and OOP are different tools to solve different problems. Being dogmatic about one or the other being better for everything doesn't really make sense. For example the main programming I do is ETL. It's more important for me to turn solutions around quickly than to get closer to the hardware. Different problems require different solutions.
FP and OOP aren’t necessarily mutually exclusive. Java has embraced FP style for quite a while. I think FP is great for lower level code. Code that’s closer to the actual problem solving. For example, transforming lists. OOP is great for higher level code. Architectural problems concerning the bigger picture. You’re shooting yourself in the foot if you treat simple list transformations as architectural problems.
the video assumes you are the only developer working on the piece of software or feauture. Then ofcourse OOP or TDD does not make any sense. If you working in a team of 5,10,20 developers things start to get interesting and then you start to understand what all of those abstractions, interfaces, test isolations, doubles,injectors,factories are for.
OOP is just a way of organizing your programming work. It helps you think about the problem and constrains you into a certain set of work patterns to help minimize errors. It also can help to manage complexity in a project better. Yes, OOP can be done badly (bad code and bad design are things), and a lot of the abstraction and modeling tools it provides may be overkill or just a worse fit for some projects. Personally, I don't have a huge issue locating implementations in OOP code, so I don't get this argument, but maybe I'm privileged somehow.
Most of the armchair critics of OOP are those that seem to never have got to work on a codebase that properly implemented OOP. It's like those women who say "all men are pigs" after their 5th breakup
@@AAZinvicto This is exactly what I was thinking. I mean, obviously, different tools for different problems. Use what is appropriate, but don't complain about what you don't understand. I have a anger/disgust reaction to 800-liine methods.
@@AAZinvicto I worked for many different companies. The thing is, something like properly implemented OOP doesn't really exist. What does properly implemented OOP even mean?
I like it, keep it simple, know what is needed. Dont write everything oop, know when you need to write oop. Just write to make it work and is testable. If you start with the test, it help you just to satisfy the tests, and dont write more. If you start with the code, you try to think about everything. When i start with TDD, i also switched to move from oop to more simple code that is functional.
01:10 I love Jonathan Blow, and have been a huge fan since Braid. I own a copy of The Witness, and keenly follow his thoughts and updates on Twitter and RUclips and wherever else he gives talks. But, really, as someone who studied PL Theory and the history and origin and (most importantly) the CONTEXT in which programming languages were developed, I stopped watching at this moment. "... solve problems in the *_best_* way", really? No. Alan Kay never made this claim, regardless of SmallTalk. No one ever made this claim. You have Functional and OO languages, and Imperative and Logic-based languages like Prolog. They all solve something different, and evolved in extremely different contexts. Having used OO in many industry projects today (while also diving into other programming paradigms), I can assure you, the subset of problems and the scenarios in which OO is supposed to be used, it definitely does its job very well there.
Can you share an example where OO is beneficial? I only have a decade of industry experience and have only found counterevidence, so bear with me. The only farfetched scenarios I can think of, is when you include ecosystems into consideration. Because OOP languages are the most popular and have ecosystems that allow getting many short-term/one-off projects done really fast.
I can fulfill today's requirements directly, but they get massive, interdependent, and ever-changing. I use abstractions and OOP to encapsulate that mess. When I started my current job, I was adding features, but my pull requests had huge net LOC reduction. We joked that at this rate we'll finish the project with zero code.
Those who criticize DI and OOP principles are lucky enough to have never experienced what it's like to maintain a large, "explicit" codebase with low abstraction. Fixing bugs and adding features require extreme effort. Much more than what is required to find an implementation because "go to definition" points to an interface.
@@vitalyl1327 Hmmm, let me guess, you think functional is the best way right? Well, that's if all your app is some toy app and all it is doing is mathematical computations and simple data processing. Functional fails when you are dealing with real world applications that involves state management. OOP remains the best and most efficient for real world applications.
OOP is just meant to organise your code properly and hence your code becomes more maintainable. There can be unnecessary abstraction but its defintely a great principle to follow for larger projects
Don't fall into the trap of thinking that OOP is just classes with methods in them. OOP is a much bigger paradigm than organising code into structures that make sense. No-one in the world has issue with the organisation part of OOP. It's the inheritance models and patterns that most people have issues with because they force you into a structure that you'll need to reorganize, sometimes extensively, just to add something new that you hadn't planned for. By its very nature, strict OOP actually makes your code LESS maintainable because making changes to the structure becomes much harder when you've got 50 tiny classes all inheriting from each other and another 20 factories generating instances of those classes. This is why injection, interfaces and composition are often considered a better way to do things.
You can write (probably even better maintainable code) using strict procedural programming. I have seen a hell of lot more maintainable C, assembly and Pascal code than anything OOP. With procedural languages you need to be aware to separate code from data (they aren't one and the same thing and bundling them is just very inconsistent. It makes more sense to have a structure and a file and/or lib that holds all functions that can process the data in that struct. The problem also with OO becomes that in more abstract or technical cases it's not really clear what an object hierarchy should be and it gets very hard to take a guess where something is. There's a reason that heavy OO is on it's retreat with new(er) languages like Rust which is a arguably a very lean OO without subclassing, Jai, Go, Odin and Zig.
As a rule of thumb, I would add a Layer of abstraction if the code is larger then a terminal page (between 40 and 60 lines). Or there is a chunk of code, which is repeating itself (but not a one lkner). For me a layer of abstraction is like a hirarchical layer in a company. The more (layers) you have, the more overhead! If there is more then 1 layer in a file, I indent the function.
nothing is bad, OOP is not bad, FP is not bad, AOP is not bad everything is a tool and people just learn to use the right tool for the right problem. If you understand basic thing about code readability and maintainability everything else trickles down from it : key to readable/maintainable (good) code is make it so completely unfamiliar developer (or maybe you in 3 weeks) looks at it and spends least amount of time to exhaustively understand what it does and how to modify it. Having 7 layers of abstraction and being forced to debug to understand which implementation actually executes code is bad, having 7 levels of higher order functions in FP which creates a function that creates a function that creates a function that does stuff is bad... its not about less lines of code either, one can write crypting hard to understand one liner using all sorts of language features but the same thing will be significantly easier and faster to understand (and debug) when its a couple of if statements with good naming of everything. Its not hard : good code = least amount of time you need to spend on average to understand any portion.
May be I'm less qualified to have an opinion but I've always thought the main reason languages like Java existed mainly to write your code once and to run it everywhere. If we had only one type of CPU architecture we wouldn't have Java. All that can be done with Java can be done in lower level languages more efficiently.
The point of using OOP or any set of "beliefs" is that you get to structure everything in a way that makes sense even if it's tedious, which will make large projects manageable. Have fun writing code with low abstraction and feeling smart, but don't forget you'll need to rewrite when there's more code to deal with.
I agree here. I don't know what the target audience of this channel is but apparently not people who write business applications. I have the issues with abstractions as well but if you reach a certain level of complexity they are necessary, otherwise you will just have only messy spaghetti code at the end of the day which can't be changed any more.
@@mudi2000a Exactly. People here are probably at that level where they kill both the code's flexibility and readability to get rid of 20 lines of code and think they are smart for doing so.
I just started learning programming starting with C# a couple years ago, so my thoughts may not mean anything, but this the same thing I thought. I've looked at the non Object oriented languages, and I definitely like the structure that OOP provides 🤷♂️. I also understand the issues people mention throughout the comments, but that's where good documentation comes into play. And there's usually a tool for something. At least that's what I figure from everything I've read and listened to and watched. Haven't built any big applications yet
@@GloriousMightykarpYup, I see so many videos like this (I think at this point the algorithm has picked up I mean being triggered by them lol). In my experience some people saying these kinds of things are really good, so you can’t completely discount them, but they are overly dogmatic. Then you have a bunch of inexperienced people lapping it up. The more you work with abstraction and techniques that manage complexity in large code bases the easier they become to understand, and the more you appreciate the problems they solve. Are you really going to say someone like Martin Fowler, doesn’t know what they’re talking about?
I find oop harder to reason about. Modules are great, and I think it's helpful to tuck away the squiggly bits, so that the flow and logic is easier to follow.
OOP is like the most elaborate California Closet's design you could possible install in your closet. When all you needed were a couple of wire shelves.
OOP isn’t the problem imo. The problem is bad design, sometimes in the form of over-engineering. I’ve also noticed a lot of times it’s a failure to correctly model the right things in your apps domain. This makes reading the code - and therefore changing it - tedious. Maybe the problem is OOP is too hard to get right, and I may agree with that.
And the poor object hierarchy is ALWAYS something that happens when you work with far more abstract or technical problems. OOP only works for business projects because business processes are basically all object and everybody sees that an Invoice is an object and that an invoice is send to a Customer and a customer is a Person. It gets so much harder already with embedded systems are interrupts objects? Are ports with 8 pins each objects? One would say yeah a port is an object with the x amount of pins. Others would say no a pin is an object and a Port is collection of pins and that can be an object but can also just be a vector because you can bundle other pins than too. The thing is, they are both right and it gets obfuscated by presumptuous object hierarchies. So in 30 years of OOP I have literally never saw an object model in anything bigger than a single function program that made sense and was easy to understand -- even when staring at the UML. I have seen assembly code written 40 years ago, that I can deduce instantly what it does just by clear functions and a nice block of reserved memory for variables.
I agree 100% it would be so much better to have less abstraction , for example you have a car that is a boat that also is a refrigerator a vacuume cleaner also is a washer and dryer ...... sarcasm this is just a word salad of "all I know is scripting"
If the solution is complicated, you’re doing it wrong. The purpose of abstractions is to simplify the work. Writing macro assembly code is easier than machine code. Writing C is easier than assembly. OOP is easier than procedural code because it abstracts (hides/encapsulates) the details that aren’t a primary concern of the problem you’re solving. Iterating thru loops. State variables and if statements. Switches and cases. Code duplication. OOP just makes it easier to build apps and make changes later on. Object orientation’s classes and encapsulation are architectural mechanisms. That is, they provide ways for a programmer to organize the code and data as they choose. OOP languages do not dictate how code and data are structured, they just enforce the access to them. When you use the object orientation facilities correctly it makes it easier to read and understand code. If you write procedural code in an object oriented language, it’s going to get complicated and ugly in a hurry. If you treat variables like data containers that are processed in a client function, your code will be unwieldy and hard to understand. If you put functions and classes into a hierarchy of abstractions because of a theoretical model instead of the problem you’re trying to solve, your code will be hard to find. A binary search tree can be used to hold a string. But traversing and manipulating the string would be unnecessarily complicated, don’t you think?
Agreed. Every tool has a use case. OOP enables programmers to architect multi layered products. This allows a single library to support over thousands of use cases, while keeping the code clear, uniform and easy to maintain. What’s the alternative? Thousands of header files with specifics? Appalling to hear this generalized criticism, especially with the example of dispatching a single object in a simple editor. Let’s not build space rockets because I can walk to the grocery store?!
Simula was invented in 1967, and Smalltalk in 1972 -- well before the 80's. In theory, once you have the right abstractions, it's only a few lines to solve the problem. But by all means, every programmer should find his/her own way of working.
🎯 Key Takeaways for quick navigation: 00:00 🧐 *The problem with software development began in the 80s when more abstraction was introduced with higher-level programming languages like Java, leading to less understanding of the underlying system.* 01:07 🤔 *Object-oriented programming is often criticized, as the term itself has evolved from its original meaning, and it can lead to complex belief structures without necessarily solving problems.* 02:56 📦 *Object-oriented programming adds a layer of complexity, making it necessary to understand the principles and hierarchy, which may divert focus from solving actual problems.* 03:39 💡 *Object-oriented programming can simplify complex problems, but as software development evolves, more time is spent on abstraction and less on solving real-world issues.* 06:13 🏗️ *While adhering to programming principles is important, sometimes practicality and simplicity in code can be more effective in solving problems than following complex belief structures.* Made with HARPA AI
I don't just want to solve a problem. I want to solve it in a way where I don't want to kill myself when I have to come back to it in a year or 5 to expand or change it. Yeah people often over engineer that aspect and make it needlessly complicated but that's just bad code and you can write bad code in any paradigm.
Most of the principles of OOP were developed under the environment of hundreds of developers were working on monolithic desktop GUI apps. Most people don't work on these sorts of things anymore but still adhere to these principles. It's my opinion that if you're working on a codebase that only a single small team touches, SOLID code is damn near an anti-pattern. You have luxuries that people that developed SOLID never had.
this. objects make a lot of sense in UI because they mostly represent widgets which are little islands of state and behaviour with hierarchies which can also call each other. not so much in other domains. these days modules, closures and immutable records are all the rage
Yep. I've been saying this for years now: abstraction has to be justified by its payoffs. And not everything needs to be abstracted according to the "ideal" OO paradigm. Doing that only brings you closer to being an Architecture Astronaut - not a good thing.
I'm not sure why, but I'm not fully convinced. Maybe it's because I don't have that much experience. But imagine working on two codebases: one written in C, C++, or Java that handles its tasks using loops, if-else statements, and similar constructs. The other codebase, however, has a clear interface that shows the operations each class performs. For example, the service class calls a processor class, and that processor class only handles student data. I think I would still prefer the second approach because it not only makes the code easier to read but also easier to test, debug and maintain. I know exactly what responsibility each component of my code has. 👾
YESS. I create abstraction so that the code has pattern. And the abstraction is not really that deep, has no parent class or something. Just implement the interface. And its one of the 3, repository pattern (for data access layer), factory pattern (for reusable lib like file storage, notification, etc), and strategy pattern (for payment). That's it! And yet, this mediocre programmer still mess things up. They don't even use the reusable function and started to couple database query with payment into one function. Like wtf? They even leak the secret key god damn it
From the projects I have seen it's 50/50 if the spaghetti was caused by abstraction or the lack of it. But what I can say is that the ones cause by abstraction were much harder to untangle.
Often people use interfaces so they can use dependency injection. The real benefit of this is it's easy to mock out a dependency when writing unit tests. This is the real benefit I've seen from going full OO with abstractions. It makes testing easier because you can mock out methods you are dependent on
@@gullijons9135 hmmm your right, I guess I'm c# you can just make all your methods virtual to achieve the same thing. I thought it was only possible with an interface. TIL!
The problem with OOP (the classes, objects, inheritance kind) is that it relies on building these taxonomies of entities regardless of whether it makes sense in your particular problem. And not only creating them, but also getting them right from the get-go. Oh I hate speculative abstraction!
@@chudchadanstud Sure tests are important, but they catch bugs only in the behavior you thought of. In contrast, if your data types reflect what you're modelling precisely, the compiler will point out every spot where you forgot to handle a case or where things no longer match up. And that reminds me of another point: including hidden state in your objects obliterates property-based testing. Such a shame, since that is _the easiest_ way of comprehensively testing your functions.
@@mskiptr I don't get it. What makes you think OOP isn't strongly typed? Introducing bools and ints for error handling literally creates the same problem you just described. It's called Primitive Obsession. Like I said, there is nothing that will save you from refactoring bugs besides tests. Bugs during refactoring are a given. Why are people trying to run away from their responsibilities as programmers?
there's a counter-argument to the all anti-OOP arguments too. if i'm dealing with geometric shapes for example, and i make a few shape classes with data and methods, did i do a bad thing inherently? do i need to care about how badly these OOPy shapes lend themselves to solving problems that i don't have, and probably will never have? or can i just keep my OOPy shapes and use them in my library? they're not hurting anything at all, and trying to make them not OOPy actually introduces *more* levels of abstraction in this case.
The thing to remember is that OOP isn't made for small functionalites and straightforward algorithms, it's intended to keep huge systems flexible and easy to extend. You don't need OOP abstractions where few if's and for's will greatly do the job, but you won't build a big app flexible from if's and for's alone. Do not overcomplicate things, but some ideas are already so complex, that OOP is the best choice. And OOP is great for game development. That's how I see it.
Huh? I hated it since.mid-80s, and none of the issues with OOP that were raised back then had been addressed and fixed since then. It totally deserve all the hate it gets.
The battle of piss and poo: “structural” (i.e. procedural, any OO lang is also structural nowadays) vs OOP. Nope, not taking parts. I want to see both sides burn. Functional programming is the future.
15 years later "why Functional programming is bad". People talking about how you have to step through 20 curried functions to actually understand what anything does or w/e i.e. bad programmers will write badly designed code. The more popular your paradigm the more bad programmers you'll have in it And idk, from my perspective functional seems like a super convoluted way to do stuff, with tons of memory duplication and w/e for certain things. Like say, coding a UI.
I really feel like this is another one of those instances where the incompetence of some programmers is used to discredit the entire paradigm of programming. There is not "the problem with oop". Especially because all modern programming languages are hybrid languages which do not force you into using oop all the way and to the extend where the imaginary idealist is statisfied. I'm sorry but this video is worthless to me with this messaging. It oversimplifies many of the problems programmers face at work into the whole paradigm being broken.
I started programming learning C and writing simple libraries from scratch and the feeling of learning what happens under the hood, why my code segfaulted and understanding how a language is used to write itself😮. Then I switched to Java 😂 and now I think I am not learning programming but simply throwing libraries over libraries and libraries.... Layers of Abstractions : Assembly, Bytecode, Java Code, Oops, Interfaces, JDBC, JPA, Hibernate... I don't understand what is happening under the hood. You learn a library then next year it changes its internal structure. Now you have to relearn the same library. Most Developers spend their most time trying to understand libraries. Remove the library... Most developers will simply crumble.
Yeah, do that if you think that it a good idea. For example, write an application which is using a mariadb database. Then someone comes and says, we need to also support Postgresql and Oracle because our customers want it. Now, either you use some pre-existing database abstraction layer, or you will have to write it yourself. And the 2nd option is often not the correct one as you will suddenly have a big effort. Just to show one example where this thinking falls apart. Usage of too many libraries can be also bad but not using them at all is not possible unless you are a hobby coder.
@@Muskar2 True, but the thing is that when you need to deliver things, you are better off finding something that just works out of the box. C is good for different things. I use it as my primary hobby language but writing your own unsafe https code in C is just... stupid. Especially considering that web dev is basically a loser job where you cannot ever understand (or code) the entirety of what you're doing.
Yeah, you don't need OOP & to create complexity in your Hello World app. If you don't need it, don't implement it for the sake of implementing it. That's what Jrs do. But forgive them, they're trying to learn & show others that they can. Reel them in gently. But, and listen closely, .... abstraction is how we deal with complexity. That's how our minds work. Imagine trying to program a robot to walk out a door. Every little instruction and movement - Insane. But our minds have abstracted away the details. We think: get up, go to the door, open it, walk out. Or maybe just "leave". OOP is simply a way to abstract complexity into the correct objects so that we don't paint ourselves into a corner. But certainly, pick the appropriate tools for the job.
abstraction isn't the only version of complexity though? i genuinely don't understand this argument, as if say functional code is always as simple as it needs to be?
Got to the Smalltalk thing and gave to in the video. Why are you commenting over the guy if you don't know something basic like what OOP originally referred to? Why don't you stop recording, do some research, find out and then record? You have Google don't you? This is incredibly lazy content. You're basically just taking someone else's video, who didn't go to huge efforts himself as voicing over it. Ffs, this is yt rock bottom.
The main problem is that students of pure informatics departments frequently never ever will be confronted by anything else than just OOP those days. But remember: at the and of the day, when the sun comes down, every program is strictly procedural.
OOP is just one example of messy code. I've seen people doing functions only and they still hide the implementations deep down the code base. Like you have to go trace lots of function call in order to reach the actual thing and read it.
That isn't really an issue even if you have to go 100 levels deep if you can for sure trace it. Issue comes with Dependency Injection. You don't know where to find the actual implementation with Dependency Injection!
@@arpitkumar4525 even dependency injection is not a problem if it is written in an easy to follow way. And DI has also advantages. When one utilizes Test Driven Development approach, DI becomes an indispensable tool.
This reminds me of a colleague working on frontend in Angular. She said, we created so many interfaces at some point we forgot what we were supposed to do. Imagine THIS happening to a UI project, and now bring this mindset to a problem which doesn't even have UI. You'll have invisible daemons haunting your code. :)
Object Oriented Programming is a way to segmentate code. That's all... It's not even a hard difference from functional programming. Functional programming also has 'abstractions' such as a user. However, it's not put concretely into one identifiable block of code. The 'user' is all over the place in functional programming. If you build small websites or things with few abstractions, then perhaps indeed an object oriented approach isn't necessary nor beneficial. However, once you understand object oriented programming, it just cost a little extra for even such small programs to be object oriented. Then they became way more scalable and are more uniform. So anyone can basically come in and understand what's going on fairly quickly. I feel like many people don't know actual coding at all. They don't even understand object oriented programming properly. The guy in the video says stuff like "just write the editor", "just write the plugin". If you do so with shitty code and you actually charge a customer for it, it's just bad ethics at this point. If the customer wants changes or adjustments, who is going to help them? How much time and effort will it cost?
I do not see any problems with OOP after 20 years of programming using it. It simplifies huge projects and hides unnecessary code details inside the classes. You do not need to know details, use properties and methods of objects. And it is also more easy to support and extend your software.
People whining about how 'x' programming paradigm is bad are just identifying themselves as amateurs. If you are working with any Turing Complete language (paradigm), then you are able to commit any number of atrocities, which makes them all "bad", or "problematic".
@@AndrewARitz Programming paradigms matter in objective ways. The hardware has specific paradigms on its own and favors programs that align with them. And even though humans are adaptable and differ, we can only comprehend a limited amount of complexity, so adding unnecessary complexity is objectively bad.
You guys dont know oop. The code is in the structure. In the relation between objects. And just look to the interface. Its abstracted. Its not for games, maybe that is your problem.
Try hardware verification. Every 2 years you start a new project from scratch, and the first thing you do is solve "real problems" and it's in fact most of what you do for most of the project, and that's because there are no real libraries (just empty skeletons). This is because the ASIC design is usually proprietary and unique. We still rely a lot on OOP to build the verification environment because it's good for EVERYTHING. The code is easier to read, easier to modify, expand upon and to debug.
@@somebodyoncetoldme1704 "Also. objects do solve a real problem. If you consider code duplication a problem." You're the first person i've seen mention this. Does he really think that programmers just woke up one day and said "you know what, i'm going to complicate programming for not good reason" OOP was _created_ to solve problems. This just tells me he has never worked on any codebase of any real size or complexity.
Yes actually, the guardrails are put in place to enforce standards within the codebase. You can call it an "assembly line", which is actually a good thing. Assembly lines generally ensure fast and efficient production, and result in products with fewer defects. This saves both time and money. And this is why OOP and FP are used.
I have been tip-toeing around the "devs are too dumb to make code that works" argument for so long, so thank you for saying it. I haven't worked in industry as a developer, so I have hesitated to pass judgement on all these various ideas like OOP vs fuctional, micro-services vs monolithic, etc., and I have heard all the arguments for these "belief structures" that people have. And I have always wondered what problem are people trying to solve? How are they trying to solve that problem? And it seems like to me that the decision to choose OOP vs FP, micro-service vs monolithic, etc. is never as an answer to either of those questions, it's always an answer to a completely different question that has nothing to do with the problem at hand. Again, no industry dev experience, but it seems to me that the decisions being made on thing like OOP vs FP are about continuity of operations and other business decisions, and have very little to do with actually solving the problem at hand. Exactly like you said, it's about ensuring that the development process at a business can be easily migrated from developer-to-developer, from team-to-team. Now, yes, the current state of industry-style development does seem to necessitate things like OOP and micro-services, despite the fact that so many incredibly talented develops seem to not like them as go-to methods. That doesn't mean that any of these things are concepts you should never use, but it's like what Blow is saying--it should be done as an intentional choice when it becomes apparent it is useful, but not taken as some programming dogma. Because then your choice is about solving a problem programmatically.
There's no need to pass judgement. They are tools. Ever hear a carpenter say you should avoid using a hammer (OOP) at all cost. A hammer (OOP) is objectively bad. Any professional carpenter will laugh at that statement. Yet for some reason this flies in programming world.
I'm really not trying to be argumentative, but yes, I have actually heard carpenters (and all sorts of other tradesmen) make arguments about what is Objectively The Best™ way to do something, once you take a step into their expertiese. For instance, I have heard carpenters say you should never, under any circumstance, cut a 45º angle unless you used the angle measurement built into a tool to do it. Even if you use a square and geometry to ensure its absolutely a 45º cut, there are guys who will swear that if you're not using the compass built into your miter/table/circular saw to measure the angle then you're going to be off. Ask a random assortment of plumbers about sharkbite connections, and you will definitely find some insisting they are objectively, undeniably unuseable. Many electricians will swear that you should never use an arc fault breaker except to pass an inspection. Don't even get me started on the arguments about which tools brands are objectively better than others. So, no, this thing does not solely exist in the world of programming. It exists whereever there are people.
What I think you're missing is - you gotta pick something. Procedural, FP, OOP, whatever. In general, for a given project, there might be an obvious choice (C# for Unity) or obvious bad choices (C for webapps). Outside of that, picking the "right" thing is most likely about picking what you're most familiar with. I can guarantee you almost no one is going out there and taking a survey of all potential programming models and technologies before they pick something for their project. That includes Blow.
@@bobbycrosby9765 I don't think anyone is arguing against the reality that choices need to be made and that those choices can be daunting. What Blow is literally saying is that sometimes choices being made have less (or nothing) to do with that choice being a good way to solve a problem, and more to do with the fact that people have arbitrarily taken the choice as some kind of standard to always use. There's a big difference between looking at the choices you have most readily available versus trying to look at the entire world of programming for potential choices, and there's an even bigger difference between actually evaluating what's immediately at-hand versus just arbitrarily deciding. The thing that is being criticized is that the reason something is being chosen is often because the thinking is precisely "we just gotta pick something", and it doesn't get investigated further than that, sometimes even if there's tons of problems.
Everything needs to be abstracted so we can mock our code and test it my friend. You keep asking questions yourself that have super obvious answers. Having said this, I prefer to create interfaces for functions than classes. I think its a lot cleaner when we do this. My main concern with OO are the mamushka dolls of multiple layer inheritances that end up creating confusion. Typeclasses is the way to go
OoP is the skeuomorphism of programming. Great for helping people learn, but ultimately unnecessary. Eventually, you realize that you don’t need a doer-of-things to do things and that you’d really rather just get the job at hand done than make a world of abstractions.
its actually the opposite, oop makes it harder to learn, because it abstracts and moves codeflows away. you need to learn more. oop does only matter as a structual framework in statically typed languages with a strong emphasis on compile-time checking. basically "if i upgrade this plugin, will my project still work. ah fuck no.. so many errors" vs "if i upgrade this plugin, will my project still work? lets find out and test each and every part. oh it was used in this module, who would have thought" so all of those programming languages have pros and cons. sometimes its compile time. sometimes its validation. oop is only a small part of the whole thing and all sides have tradeoffs.
@@EudaderurScheiss Incorrect, it's much easier for humans to wrap their heads around abstractions. Hence our very liberal use of metaphors in almost anything. The issue is with OOP that it's not very efficient on the compiler side of things.
You just argued for OOP in the last 15 seconds of your video. That is exactly one of the reasons why OOP is great. When you code your hello world pet project that you abandon in two weeks, you're going to be fine without OOP. But when you work on an enterprise app with hundreds or thousands of developers that come and go over several decades, the structures and abstractions OOP provides are essential to preserve maintainability.
I've seen and coded pure C and assembly that still runs today so that's an invalid argument. Actually I have seen far more maintainable code in procedural languages that OOP. You can both fuck it up and do it well, but it's easier to do low-level code well than highly abstracted code -- because there's less rules and less to think about.
Most enterprise apps these days are not apps, but rather, they are systems loosely connected via a network. We're writing smaller programs than ever yet people still swear by OOP because it's what they're used to.
@@bobbycrosby9765 exactly! It’s what they were taught at school and most never developed in a strict procedureral so they don’t know what the benefits and drawbacks are of both.
I started coding in C/C++ for Arduino and created only procedural/functional code. Picking up things along the way, I now use OOP for most tasks. It's very useful for scope.
6:18 most professors have not worked in the real world The way OOP is taught is fraught will bad ideas and half implementation and poorly cobbled concepts that work under certain circumstances and not at all in others It’s interesting to study the origins of these things, it was all based on hype cycles from previous ages
I see the point you’re making, but you can say that about almost anything. Here are some examples: Machine code is an abstraction of the electrical engineering circuitry that is actually doing the all of the physical computing. Electrical engineering circuitry is just an abstraction of the physics of the electrons moving through matter. Calculus is an abstraction of real analysis. Biology is an abstraction of chemistry. The point is that you can actually solve real problems as you abstract away from the physics and math. The downside is that it won’t be as universal. Knowing libraries in C++ won’t help you if you arrive somewhere where they don’t use those libraries, but knowing physics and math will work all over the observable universe. The downside is that you can’t actually build anything by only knowing physics and math 😂.
You missed the point i guess. Pushing OOP for every problem is a bad abstraction. You won't use hammer for cutting wood. Right tool for right job is needed.
@@shrin210 no, I agree with you. Electrical engineering is a fantastic tool, but it isn’t the best tool for designing an internal combustion engine. I was responding to the part where he said OOP didn’t solve any real problems. I’m not defending the use of OOP for everything and I’m all for using other programming paradigms when they are superior in their application :)
OMG so true! This drives me nuts in my C++ job! Every time I want to figure out what is happening I have to go up and down the inheritance/interface tree. Nothing does anything. After 3-4 jumps I don't even know what I am looking for.
Alright, then you realized let's say there is no actual implementation in this dependency tree. Great. You search for all classes that implement the interface in question. Excellent, they all do something different. Now you have to find that the piece of code you were originally looking at which implementation was used in the background. But then you can easily find yourself in the same cycle, trying to find what implementation actually got there. Madness.
Even worst when you have interfaces prematurely. There is only a single implementation yet, I need to jump to extra hoops, because we designed the system.
Yes, I get frustrated with this at my job too. I use my debugger to automate searching through interface layers more than I use it to actually debug something.
The funny thing is the same people who write this dynamic dispatch spaghetti garbage when asked if goto is bad they’ll say yes.
This has been my experience with a lot of OOP codebases! Even some I wrote myself and revisited after a few years.
I subscribe to what you said, true, totally true.
And i'll add :
when you have to reverse engineer a binary of which you don't have the source code, you can see pretty soon if it was written using OO because nothing does anything, and the cpu just sits there doing function calls and shoveling data arround for nothing, and after a few hundred cycles it actually does something ( like a sum, or a xor or , you know ...something usefull, the actual computation )
Or when the control flow just disappears into nothing, because the function to be called is computed at runtime...
Then we complain that damn word.exe barely opens on a 24 core machine, and when you write, the letters lag behind your typing speed and stuff like that.
break points , epic bruh moment
The problem is people focus too much on one paradigm. Objects are great, but everything doesn't have to start by inheriting a purely abstract class etc.
I second this! That's the point!
"Objects are great..." [Citation needed]
The problem with generalities like that are they don't always apply. Even worse I've yet to see a time where an OO object is great vs simply using a `struct`. Unless you just mean `struct`s with pure data are great?
@@totheknee Citation needed? I said it, you're quoting me.
You're argument is like me saying, "hammers are great" and you being like "not always!"
For what objects can do they're great. Being great doesn't mean it's great for everything. If you don't understand basic logic like that then you need not be programming anything my friend.
Especially when i preface that with "people focus too much on one paradigm" lol trying to figure if you're a fail troll or what
Well, yes, for the most part.
You can stick to your abstract way of life and introduce a little bit of composition. Do like PHP does.
Lmao useless shit
5:40 - Being honest here: please don't mix up the term "premature optimization" with "premature overengineering." Reason being that almost no one these days seem to know what optimization even means, and they just repeat what they hear without understanding. It's so bad that some (most?) programmers these days think that simply avoiding writing slow code in the first place is "premature optimization." For example, if I avoid a triple nested loop and just use a single constant instead, someone will jump down my throat and say I'm "prematurely optimizing" when in reality I just didn't need a triple nested loop. It's almost as if they think we _need_ triple nested loops everywhere, and then we remove them at the end of production in the mythical "optimization phase."
Premature optimization is the overengineering of solutions related specifically to performance.
I think that if you don't need a triple nested loop, it's perfectly valid to refuse this code in code review not because of optimization but because lack of maintainability + readability.
Code review then indicates a better implementation, and maybe redirect to a code guideline that leads everyone in the project to better readable code.
@@fellowkrieger457 I find code reviews are a waste of time for everyone, except when training someone. Additionally the best programmers have the least time to do reviews, and often the mediocre programmers add the most lines of code, so overall it's likely to produce worse code. If the project has implicit rules that are hard to get the large teams to follow, we've found they should be made explicit by automating them, e.g. with compile-time validation rules.
The issue I have with casual use of words like optimization and performance is that they aren't specific. Optimizing for what? What trade-offs are acceptable? How are you defining performance? Many people who throw around the word optimization a lot don't even know what it means.
@@brandyballoon In terms of defining performance, the biggest thing missing today is knowing that the hardware limit requires simple arithmetic to figure out, and measuring against the theoretical maximum is extremely simple and powerful, yet virtually nobody does it anymore. If you're only ever measuring relative gains to other software/versions, then you'll never know whether what you're doing is actually performant.
I hate when engineers starts to implement design patterns without an actual need. The codebase isn’t even got any bigger yet. And instead of building a momentum to ship product faster, they stuck arguing what design pattern should be used to make it future proof.
Yes and then the project requirements completely change lol. And people hate on high level language and quick shipping approaches…
@@DEBO5
Sure, but that is exactly the problem. You don't know what the requirements are going to change to, or even *if* they are going to change at all.
There is this deeply rooted fear of throwing away code and just building from scratch. The people who love their abstractions deal with it by building these overly general abstractions, where a simple if statement or switch might have sufficed and been clearer.
The people who dislike abstractions deal with it by writing giant modules of spaghetti code, that you need to be inanimately familiar with in order to maintain, instead of just using a bit of dynamic dispatch or a well known pattern.
The former wastes incredible amounts of time building their tower of abstractions for things that could have been simple and the latter wastes incredible amounts of time maintaining their brittle code because it got more complex than they thought.
Both lead to code that is incredibly hard to read and reason about. The non-abstracted code, because you've strands of spaghetti going off in all directions and the abstracted code, because now you need to familiarize yourself with the tower of babble that was dumped on you.
The point isn't to avoid design patterns and abstractions, it's to avoid their premature usage. Ideally, the the code should always be the simplest code that deals with the actual problem.
Implement that code and if at any point you notice that your simple code stops being simple, tear it down and write code that uses the abstractions and patterns that are actually applicable to the new requirements. But don't start off moulding your code to some distant fantasy requirements that may never materialize. You're going to waste a lot of time writing abstractions that are utterly unnecessary.
Design patterns are one the biggest distractions in dev. Just write the code that's needed already.
I hate it too but in my experience you better implement the pattern early unless you want to spend a lot of time refactoring.
design patterns are applied to solve certain problems. if you apply a pattern without solving a priblem then it is an antipattern
Everyone complains about OOP but is okay saying "I'll just need 4 months to rewrite all this code" with a straight face.
Although, I agree that generally pre-mature abstraction is bad (that it negatively affects developer productivity) and that quite a lot of organizations like to "abstract" things out to make the code more maintainable and extensible without the need for it, I would, however, like to visit your point about - "code that perfectly solves the problem with some SOLID principle violations". I think we, as engineers, should understand that the problem you are trying to solve is a constantly changing goal-post. If you solve perfectly solve problem A right now even with bad code, you will then probably need to solve problem B, followed by problems C and D. This is a very likely scenario in all (big and small) organizations. That is when writing code with abstraction shines and is very much needed. Understanding the balance of how much abstraction your code needs is what you, as an engineer, should decide. If you over-abstract too soon, or if you do not abstract at all - both these scenarios will bite the engineer later. OOP/Abstraction is not the problem, but a tool, and we should not overutilize it or shy away from it.
abstraction doesn't require OOP though. OOP is a cult mentality, a belief in some mythical 'clean code' standard.
@@drygordspellweaver8761OOP is a paradigm. What you’re talking about is people that think something is true without reason (which I think equating OOP to a cult falls under). There are people who do this for every paradigm. These are all just approaches that organically arose to solve problems. Sometimes approaches are supplanted, sometimes they remain valuable for certain problems. I haven’t seen any compelling evidence that OOP no longer has value for all problem spaces.
> to make the code more maintainable...without the need for it
That statement is self-contradictory.
The point is that you can abstract it later, if you really really need it in order to ship your project. In reality, most of the time you don't need that abstraction, even in company working with team. You just need to ship project, earn some profit and than decide, do you really need to abstract something, will it solve the bug tracking problem, or testing problem or team productivity problem. You should analyze it later, it will safe your time, your mental health, your motivation to stick with project and team.
Not everything needs an interface or base class.
Not everything needs to be injected through DI.
Not everything needs its own library.
Not everything needs clean architecture or DDD.
Follow these and you’ll be fine.
Not everything. But simple DI helps create simple, consistent test harnesses and mocks. A lot of the frameworks are "magic" in the sense most don't care how they work and there is heavy reliance on opaque annotations. But ultimately they just hide repetitive mechanics and can let programmers focus *more* on the business logic and tests.
I think this was the biggest mental hurdle I had to overcome when I started programming. I was basically learning how to conform to this weird standard. I also think that's why I appreciate functional programming so much because you get to solving problems a lot faster
That being said, I do think OOP has a place. I don't see why it's bad that we have industry standards in an industry. It gets out of hand at times, sure, but I'd rather have guidelines for everyone to follow rather than everyone doing their own thing
Doing an own thing is good if it's a good thing. But the programming society is not uniform: some are better educated, some have stronger common sense and measure than the others, etc. I've seen a recent interview with Dave Cutler - can't imagine a person like him following standards. He is the one who defines them.
"I don't see why it's bad that we have industry standards in an industry"
Plainly, I'd say standards are good. But OOP isn't a standard, it's more of a philosophy or a paradigm on how to structure code. Most people don't do OOP, even the ones that do doesn't mean they do it "right", there's plenty of ways OOP codebases can differ, there's usually unwritten conventions for a particular codebase. We have some standards that work and are followed, like for example TCP, but as a whole this industry is a mess.
@@thrashwerk
I’m confused. Is OOP just the practice of putting everything in a class? Or is OOP using classes in any capacity?
I'm done with people oposing fucntional programming to oop, as if you couldn't go stream.filter.foreach.toarray in java
it is a problem the same way agile and scrum and all this shit is a problem: you are paying for illusion of efficiency with actual efficiency.
I could not be a problem, but it is. Truth is, interfaces in Spring help you inject or override code from module to module, but there's nothing about OOP in that, its just Java. If you are writing an interface of an abstract class of the class you need but wouldn't need if java didnt enforce objectifying because you think it is the correct thing to do (and a lot of people do) then we have a problem
I’ve worked with too many people who can’t even explain code they wrote four weeks ago because everything is abstracted away behind services, factories and interfaces that do nothing but juggle data around in the most convoluted way possible. Everything is “maximally reusable” but never gets reused.
And then the desire to wrap SQL which is very well readable in massive “builders” where you have no chance to quickly check what SQL is actually being executed.
The point is to not have to read the raw SQL. Why you would ever want to do that beyond performance analysis is beyond me. In fact, its advisable to do this for security reasons so you dont make injection attacks easy.
And I honestly cant think of how you would even construct an OO architecture without reuse. Its practically impossible unless you absolutely suck at understanding it.
Factories make sense because they allow you to do things in a more flexible way. For example, Ive used factories for building database connection strings. Doing this makes it stupid easy to add connections to new DBMS or even different file types. Most people think supporting multiple DBMS is a waste of time, but it's not uncommon to need to switch between multiple ones, such as Access and MSSQL for example.
I spent almost year developing a shitty interface that basically read back and from between two systems. One used a REST API and the other an oracle DB. Then the team responsible for the oracle DB said, we're switching to MS SQL. Because I used an abstraction layer I only changed a single dependency and a few builders for the connection strings, queries, etc. The switch took me about an hour? If I was rawdogging SQL in every function that needed to read or write that DB, man, have mercy on me.
@@jshowao It may surprise you but some people can read raw SQL better than stacks of ...->and(...)->or(...) - not just for performance analysis but also if you wonder why the result isn't what you expected.
Also I wasn't dissing OO architecture in general but the anti-patterns that many people build thinking they're doing it right. And I've seen enough AdapterFactoryController and AbstractInterfaceProvider classes to know when something's off the rails.
@@jshowao _"Forth is said to be an amplifier. A good programmer programs better in Forth; a bad programmer programs worse in Forth. The sad fact is that too many programmers must be considered "bad"."_
And they write all those frameworks, libs, modules - which halt without reason in the middle of a run, consume *HUGE* amounts of memory - or just barf out a stack dump while inexplicably waiting for something. "I don't care how much data and code is pushed over the line at any time - that's the responsibility of the framework". That's why.
@@jshowao "The point is to not have to read the raw SQL. Why you would ever want to do that beyond performance analysis is beyond me"
Because SQL is pretty easy to read and is... a standard. SQL is already an high level abstraction! (Some raw SQL may be hard to read, but this is usually because it does complex things that no abstraction will be able to significantly simplify.)
"In fact, its advisable to do this for security reasons so you dont make injection attacks easy." You should never inject a non sanitized string into a SQL query of course, but this has nothing to do with wrapping SQL behind an abstraction: parametrized queries are fine.
You're using it right. Abstraction inherently isn't bad (it's obviously what a lot of coding is about), but when you abstract, you start putting up walls and sometimes it's hard to couple those abstractions together in order to work together the right way. So it can be bad to unnecessarily create abstractions before you need them because you end up spending your time connecting them together in the right why and it ultimately makes your code less dynamic.
EDIT: I don't know why everyone has to have a moral judgement on everything. It's a tool in your toolbox, use it at your will. If you don't think you need, don't use it.
If only I live in a world where I don't have to deal with someone else codebase.
Paradigms are not tools, that is a complete nonsense take. And there's not moral argument on Jon's part
The characteristics/parts of OOP are tools. Yes in a purity sense, treating a paradigm like a religion is what I mean. And yeah I wouldn't say he's making a "moral" argument, I mean it in a more figurative way. I'm not sure what the word I want to use is. All I'm saying is it doesn't have to be all or nothing.@@marcs9451
I don't know, it's also nice to have contracts with abstraction. So you're not coupled to the "how" it is done.
I mean it's a treadoff.
As always, it really depends on the context. It’s easy to cherry-pick parts of Object-Oriented Programming (OOP) and rant about them, but the bigger picture matters. If you’re coding solo on your personal project, no one cares what paradigm you use. But in a company, working with a team, it’s essential to follow the same standards and patterns. OOP principles are just the basics-things like the Repository pattern, MVI, and others help make code more maintainable and readable. These patterns aren’t just ‘rules,’ they’re tried-and-true methods for keeping large projects organized. In bigger projects with thousands of files and millions of lines of code, skipping these leads to spaghetti code. While every developer might think they can do it better their own way, most hit a wall eventually and realize that these principles exist for a reason. Consistent standards make it easier for teams to collaborate, maintain, and update the code
The rant in OOP is always about Inheritance and nothing else.
Everything else is good like Repository pattern, MVI or whatever.
@@shrin210 Inheritance is essential for OOP for large scale projects, just so that you can implement the strategy pattern, which is the pattern necessary for anything that has any type of behavior that changes depending upon the input during runtime. If your code doesn't change its functionality based on inputs during runtime then write procedural or functional code and don't use OO.
My biggest issue with the rants about OO is that the examples people give to say OO is bad is not OO done right, but OO done wrong, and then labelling OO as always wrong. To be fair most OO done in business that entry level devs see is OO done wrong, because most devs use OO wrong and try to add in patterns where they shouldn't be if they are even that advanced.
@@toms7114 Totally disagree that Inheritance is necessary for large projects.
People are building large projects in JavaScript, Rust, Golang and C without any inheritance.
@@shrin210 And all of those languages are hard to maintain as large code bases, because those languages have built in excessive use of composition. The best argument I've ever heard for composition is if I have to add in some new feature to a class once I use composition and I mark it as the first composition, if I have to add some new feature to the same class twice I add it in and mark it as the second composition, if I have to add in a new feature to that class a third time I refactor.
Also c should never be large scale, it should be small procedural code snippets for drivers that gets used by larger programs to control those devices.
I am saying to use the right language for the right job. I'm not saying use OO for everything is right, I'm saying that the control methodology for large scale programs with a large team working on it should follow OO design patterns and principles and have those patterns and principles be the coding practices that are enforced when modifying that code base.
I get why composition is favored in modern coding practices. It is easier to get new devs up to speed, but it ends up costing more money because you have to have more devs every step of the project.
I guess I am just too much of an engineer to think that a well designed system is better than spending more money over time by throwing bodies at a problem to solve it.
@@toms7114 Who told you composition needs more devs and cost more? Pure nonsense
Composition is explicit and Inheritance is implicit.
With inheritance they tried making abstraction easy but Tracing inheritance became the toughest part.
Watch the talk on Data oriented programming.
ruclips.net/video/rX0ItVEVjHc/видео.htmlsi=km5qM3ZQFqgAa7Ew
Summary of video.
Programming like OOP concepts ( reality objects inheriting something from other objects.) These are just nonsense concepts.
Programming is just tranforming one form of data to another form of data and that is the only reality - Data oriented programming
Regarding Alan Kay's definition of OOP:
As I understand it his idea was very similar to what we call today "actor model" or "actor-based concurrency", which is the core concept behind the language Erlang. The idea is to have "objects"/"actors" that only communicate via messages instead of direct method calls, and just react to messages they receive. Software built like this is very easy to distribute across multiple CPU cores or even devices as the program itself doesn't need to concern itself with how the messages are actually transmitted. It also reduces coupling to a point individual actors can be restarted after a crash without affecting any other part of the program, the worst that can happen are some lost messages. Erlang was designed by a telecommunication company (Ericsson) for minimal downtime of their systems, and this actor-based model allows live updates as well as crash recovery without any downtime. It's so good at what it does that many modern messaging services (e.g. Discord) still use Erlang in the backend.
The difference is that in Kay model messages are asynchronous, in the later and simpler models they're synchronous. It's not that much of a difference on the system design level.
discord uses elixir, not erlang
@@marusdod3685 Elixir is a syntax sugar on top of Erlang. Sort of.
@@marusdod3685 Ok. Though Elixir uses Erlang's VM, so it's the same idea.
Messages that passes misterious ways to make it microservices-level-hard from the beginning sounds even worse than Java.
I think the main take away is that only HUMANS care about objects. It's more in line with how we model the environments around us. But an "object" from our heads can only ever be _grafted onto_ problems in computer space. I think OO offers itself really well to situations where there is a real-world system already in place that your program is modeling and "objects" in your code line up with actual real objects in that system. It's also pretty good for setting up guide rails for other developers, but if those guide rails are bad then new devs will inherit bad practices.
For solving a single well-defined problem, I think sticking with procedural programming is the way to go. Starting with OO will cause you to set up arbitrary walls to stay confined in when you should just be focusing on raw problem solving. Procedural lets your solution change shape at will so you can really explore the problem space.
Agreed. I frequently will solve a problem procedurally first, because I found that trying to make it OO from the start resulted in lots of time wasted as I learned more about how to solve the problem I was working on.
Also, in the real world, not everything is an object. Some things are concepts.
OOP maybe good for game development, because its actually modeling some sort of world with state.
CRUDs not model anything.
I did program games without OOP, and its just as fine, as every other application.
Having grappled with abstraction, SOLID and design patterns for over 20 years all I can say is Hallelujah.
I can't tell you how often I've had to think "wtaf does open for extension and closed for modification really mean and do I really need to follow this rule in the age of modern refactoring tools?". The worm is turning. Over abstracted code is an absolute mindfuck.
I started to push back on pointless abstractions on PR's a while back. OOP and it's rules were a best guess of how it should work at a certain point of time. We've seen the results. Pretty horrible. And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method.
"And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method."
Thank you! I repeat this to no end, but the message does not seem to stick. There is a religious fervor to which "clean code" is applied in some circles that bothers me sometimes.
Don't tell the POOPs (professional OOP'ers) that I write 1000 line functions
;)
If you don't know what that means, then I can understand why you'd be frustrated.
What's "that"? Which specific point are you referring to?
Looking back, my favorite concept is the "Object Calisthenics" challenge. For those who don't know, it's a way to go extreme with OOP, allegedly to practice how to think that way. But if you've ever given it a serious go, you'll quickly find that the work required gets exponential really quickly. And looking back it's embarrassing that I didn't realize the absurdity then. I just thought I needed even more practice. It wasn't until I heard Muratori speak sense to Uncle Bob that it all clicked for me why I had become so disengaged. Every time I get to work with problems rooted in fundamentals, I love programming again. I had lost that.
Object-Oriented Programming was invented by Ole Johan Dahl and Kristen Nygaard for the Simula language in the 1960s. It was especially designed for modeling real-world systems and simulations, introducing key concepts such as classes, objects, and inheritance.
There is a HUGE misunderstanding about the Dependency Inversion Principle.
It indeed says to rely on abstractions rather than implementations.
But that's only the second part of the principle.
If you apply only this part, it will lead to code that is too abstract and unmaintainable.
The key is the first part that says : High Level Code (business/domain) should not depend on Low Level Code (details), both should depend on abstractions.
That is, separating only the low-level concerns (Persistence, UI...) from the high-level policies (Use cases, Domain Model).
That's the core of Hexagonal Architecture / Clean Architecture, and what I teach to my students.
With the notable benefit of being able to test your Domain Model independently from the low-level technical concerns.
And being able to swap out your ORM/Database Engine if necessary.
And being able to run your code locally or inside an airplane with no internet access, since the gist of your code is implementation independant.
The only caveat is how your code is a little bit more difficult to navigate because from your domain model point of view, you can't know which implementation will be called.
In practice you rarely have more than two implementations (in memory & concrete) so it's seldom a problem.
That's a good trade given all the benefits you gain (testability, reusability...).
I agree. You’re supposed to identify seams in your application. This lets you focus on what’s important-your domain model.
The idea of domain layer is very weird to me. I would rather architect the program just simply with UI/Presentation layer and Business/Backend layer. You don't need more layers. Its much easier to add integration changes, add few queries to database or rest service or to low level api.
agree. the advantages become more clear when we start writing thousands or millions of lines of code
Do you have any recommended reading on the subject?
Things very rarely get switched like ORMs. Even after a few years a codebase is considered legacy and the only way to get ahead doing it in a new way that is popular at the time. I think thats what happened with OOP. The ancients thought what if we do it this way and it worked well enough to be handed down to every programmer that came after. Not every programmer but you get what I mean.
On the other hand, there's the old saw: "There is no problem in computer science that can't be solved using another level of indirection." I remember once trying to program a calculator using only instance variables. How much easier it is to solve a problem like this with the appropriate data structure. Once you have data structures, I think you're starting to move towards OOP.
There's another book I read a bit of called "The Philosphy of Software Design". One refreshing aspect of that book was the author's focus on complexity -- the central problem in software design is supposed to be to minimize complexity. Sometimes all the cruft of OOP increases complexity. Indirection itself is a form of complexity. A hierarchical page table is harder to understand than a simple page table, and a simple page table is harder to understand than a giant array that makes no distinction between physical and virtual memory addresses. But you get so much power out of separating the physical location in which a piece of memory resides from the system you use to identify that physical location!
The difficult thing is developing the foresight to know when making something more complicated in the short run could help to make things simpler in the long run. Sometimes you can get the worst of both worlds, obviously.
True! There's also a mantra to not over engineer and to prematurely abstract.
So you should decide when to abstract and in that case you knew it needed to.
John Ousterhout!! Great book
OOP is trash, instead I always use 12 levels of "if else" statements.
Or how about you break your definitions into header files and just write code how it was always written before cpp?
I know a place where OOP is taken to the point where they cannot figure out the final composition of the objects after all the polymorphism, overloads, templates and inheritance. When you have a literally 500 classes entangled under your object, good luck.
Don’t forget single entry single exit so no early returns 😂
@@BobrLovr The moment you realize that header files make for ... objects. Aaany day now.
Selfawarewolfism is strong in programmers.
@@cyrusol lawl, tell me you have no idea what you're talking about without telling me
Stop it all right here - OOP in C++ was modeled (or influenced by) the Simula programming language. Simula introduced objects in 1967. Smalltalk programming language appeared in 1972, so Simula preceded Smalltalk in respect to object-oriented programming. And Bjarne Stroustrup has very explicitly cited Simula as his influence per the object-oriented programming features of C++.
This is all straightforward history that anyone with CS background should know.
Overuse is always a problem. The experienced developer is the one who knows when to not use a certain paradigm/pattern/idiom. Problem is it takes many years to reach that level, if ever. OOP is great when done carefully. It is part of how we are able to make the large systems of today.
Software development is indeed hard, specially when you don’t know what you’re doing. But sure, it’s OOP’s fault, lol
These tidbits of information have persisted from among the elder members of the programming community, they are exceptionally valid here. Abstractions should be useful, classes are abstractions. Prefer the free function unless you have something you actually need to encapsulate. There is nothing wrong with accessing a class/struct data member without getters/setters if you don't need them.
The thing about depending on interfaces isn’t so much about having many implementations but about testing and stubbing.
Lots of programmers out there still think testing is only for qa.
@@zS39SBT4fe5Zp8Q those are the ones who make videos on RUclips
The problem with Blow is that his statements are weak and don't solve anything. Yeah, sure, you can just focus on solving the problem, but it doesn't automatically mean that the problem solution will be easy to maintain and to reuse. That's why paradigms and software-architectures were invented in the first place.
seminar called "why isn't functional programming the norm?" is basically all about the history of OO programming. And yeah, the original conception isn't obviously bad or anything.
Regardless of whether or not you think its good, you have to acknowledge that it did not become ubiquitous BECAUSE of an analysis of the usefulness of the doctrine. It became ubiquitous because of fashion. C++ became the fashion, java was marketted to C++ users and new programmers, and javascript was marketted to java users, and so-on.
Yes, it was all about mindlessly following fashion.
It sounds like the real problem is the way dependency injection is used than object oriented programming. I enjoy object oriented programming. I HATE the way some developers not only over use DI but throw in the mediator pattern breaking all my tools for discovering code. I’m a software architect and I read A LOT of code. It’s such a pain.
How does one overuse DI? I am assuming you mean dependency inversion. Also why do you have tools for discovering code?
@@skyhappy I use “tools” in the sense of techniques. Often times in Visual Studio you can use features like “Find all References” to see how a function or class is used within a project. Dependency injection can break this to a degree.
@@brianm6965do you mean dependency inversion? That's when classes only implement interfaces. I used the same find all references tool in Visual Studio and also had to find implementations a bit painfully this way.
@@brianm6965I use DI in VS and have no problem with the IDE resolving compile time references. Don’t really understand what you don’t like about it; I follow the principles in “Dependency Injection in .NET” and find it lends itself to writing more loosely coupled code that’s more testable and the object graph is very easy to understand. Wondering if you’ve worked with it where people abuse it (resolving things front the container all over the place instead of using constructor injection)?
@@brianm6965 Well, dependency injection intentionally does that so that you can just inject a mock service or another service when you want. It's meant to help testing code with 10 different mock services for 10 different situations.
So I just started learning OOP and so far I really like it. I think issues with it arise when you turn every little thing into a class, similar to how "clean code" says that if a function/method does more than one thing it should be refactored into another function, which is absolute madness. OOP is essentially just building a program out of bricks, but some people go too far and break the bricks down into gravel, and some even break it down into sand. Even the book where it's only lightly touching on OOP paradigms (it's for a specific language, not OOP) goes too far imo... there are parts where it suggests making an object for what should just be code executing in the main program entry point for example.
I've also only just barely learned about inheritance and I can already see that being a nightmare if you don't really use restraint and only use it where it saves you from writing pages of boilerplate. Basically OOP seems like a very, very good model for breaking down programs, avoiding global state, and protecting code from other code while still allowing the pieces to interact, but it also seems very easy to go overboard with.
Inheritance should be largely avoided. Use Interfaces instead of inheritance. OOP is very good when you have very large programs that you're working on over years. Take an enterprise company with 1 million lines of code and you'll be glad its all ordered out the way it is. The first time you open a class and find it does...everything with functions that do...everything, you'll understand.
@@jasonwismer2670 Inheritance should not be avoided, it should be used appropriately. It's really tiring hearing this dogma.
Instead of using C to manipulate the sand directly with glue
@@chudchadanstudagreed but it is commonly abused and can easily make code more confusing. Sometimes it’s clear it’s the right choice but I think “preferring composition over inheritance” is not a bad general rule
@chudchadanstud learned the hard way that yeah Inheritance should be avoided.
It's not dogma but just experience from its pain.
prefer composition instead.
Good abstractions take lots of time, attention, vision, case study, prototyping and testing to make. When done well, they can survive generational change in technology. A great example of this is a core protocol such as HTTP, which I don't think would be a stretch to liken to a plain text OO interface.
I think lots of people, myself included, had dreams of their code living forever and only being built on top of because we saw the success of some legendary early abstractions. But in reality, my procedural code from the 90's outlived OOP code I wrote much later, simply because I was not able to come up with high quality models several times a day every day, and bad assumptions would just pile up.
These days I lost all shame to do everything in procedural spaghetti first, and factor things out on first reuse. This way most of it naturally coalesces into a hierarchy of objects, and the stuff that doesn't is obviously not doing anything worth abstracting. So I can either completely forget that it exists, or if it has a bug, I enjoy the benefit of fixing a flat page of code that contains most of the context of the problem, that's usually very generously commented because I was relaxed and grooving hands on with a fun problem when I wrote it.
Neither of them know what they are talking about. OO started in Simula-67.
Why is wrong using abstraction? Like using assembly will solve the problem.
The problem is further exacerbated when you are working in a large codebase and you’re forced to solve a problem that exists because the original design of the class didn’t know all messed up ways programmers are going to use the class down the road. Solving the problem becomes exponentially harder because you can’t just go into the core code and start modifying abstract classes fields and instead you have to hack your way around the structure in place and potentially making it even more confusing because now you’re extending the class and casting objects as your new class. It can get messy for sure. The joys of programming.
What you describe is not unique to OOP.
@@NathanTenney OOP makes it harder to change things
@@NathanTenney True but solving it the OOP way makes it 10x harder than say doing it functionally for example. That was OPs main point.
What you're describing is a situation where someone DIDN'T follow OOP principles. The programmer violated the very first principle, which exists specifically to address this situation.
The useless part of Jonathan's discourse is "in the eighties it was better, people were better and more intelligent, oh how we have sunk". This is basically the same old story told by every conservative. Maybe OO is bad, maybe it has gone too far, maybe it's a mistake, but it too was invented to try and solve a real problem: projects got so big they started to be unmaintanable and unreadable. It was a mess that cost companies a lot of money. Today we have way better tools and other techniques, so maybe we can ditch OO, but no need to fantasize about an idealized past.
Some people take SOLID literally. They write 10,000 methods, each doing one and only 1 thing. So the program ends up being 50 times more lines of code and running 10 times as slow as just a straight forward procedural implementation. And God help anyone who has to fix a bug in that mess.
If you're paid per line of code....😅
I'm not older, but I have used Smalltalk and I love Smalltalk. Things like Smalltalk and Erlang are really what object oriented really meant. Something radically different from C++ or Java.
Having spent nearly 15 years writing code, I've found that most people are using classes more like modules organising functions (particularly in Java). From my experience, files & folders are the best module system for organising code and classes are most useful when reserved for validation whether that be validating a collection of values (as an object - like contact form details) or a single value (like a 255 character string, an email address, a positive number, etc).
When it comes to inverting control, I don't until it's necessary, and when it becomes necessary, I opt for more of an adapter pattern with functions, where an adapter function sits between my implementation functions switching between implementations based on an environment variable or an additional function parameter. This makes it really easy to navigate through the actual implementation code and reduces abstractions. The obvious issue with this approach is that I could easily forget to provide an adapter and implementation for a particular function (e.g. a database call to create a record) whilst having adapters and implementations for all of my other database calls. I suppose it's an issue I'm willing to live with for the benefits the approach provides, if it were a serious recurring issue, then I could make use of some facade-type pattern.
Why not just solve the actual problem as simply as possible? Adding needless interaction and complexity to your code does nothing but create slow code. Our thoughts should not be about arbitrary things like objects. We should be thinking about the way our hardware performs its operations. We should be thinking about vectorization of mathematical operations, we should be thinking about cache friendly data structures. We should be thinking about organizing our code to assist the microcontroller or microprocessor in prefetch. Only after all of these considerations should we think about the best way to organize the constructs in such a way that they are maintainable. The code that we write lasts for years or even decades and when we write over abstracted bloated code then we lose so much potential in terms of speed of execution, memory consumption, and power consumption. Spending a little more time thinking about and writing our code will more than make up for itself.
@@brotherpeter00 I kind of agree, particularly that "Only after all of these considerations should we think about the best way to organize the constructs in such a way that they are maintainable". For example, I'd say for an "application" less than 100-200 lines, you may as well write all the code in a single file.
I think it's a balancing act between writing code for maintainability and performance where the balance depends on how quickly/often you're going to iterate on that particular part of code, the size of the code, and how much impact that code has on end users. For example, if you're only going to get an opportunity to optimise the code once every 18 months and the code is only executed once every 3 months, you may want to prioritise maintainability over performance. I guess ultimately, it's all circumstantial.
OOP is just one of the many paradigms you can use, if it doesn't feel right for the problem you're trying to solve, then simply don't use it. 🤨 But keep in mind that you can always experiment and COMBINE elements of different paradigms.
I find that the biggest problem with object-oriented programming is the people are so concerned with object-oriented design that they fail to do the most basic thing which is have a firm understanding of the problem they are trying to solve.
Skill issue. Literally every paradigm (functional, imperative, etc) doesn't "solve the problem" and just provides a framework for solving problems. That's why they're paradigms, not solutions. Use the one that works best for the problem.
Also, building for interfaces allows you to easily use a stub or fake when testing, even if you only have one real implementation.
OOP is totally fine and in fact very similar to imperative if you don't use inheritance. After all, there's little difference between data.doThing() and doThing(data). I think one of the biggest problems with OO is trying to reuse code through inheritance, which usually gets really messy and unmaintainable. If you have clear separation of data, logic, and presentation (not OO-specific recommendations) and avoid pointless abstraction, OO can be great.
I would absolutely avoid virtual mapping. Because, why introduce some indirection when you can allow the computer to get it directly?
Inheritance turns out to be very useful if you want to enforce unit type correctness in Physic. Like a function that take Radian and you pass in a Degree and it gets converted at compile time to radian. And give error if you try passing in float for instance. You do something similar for glm::vec3. Like Point and Direction both use vec3, but, are not the same.
It is meant to be used as correct enforcement tool.
The idea is not to stray too far from basic. Don't adopt just one paradigm.
No, because data.doThing() takes a whole lot of extra boiletplate underneathe the hood. OOP is atrociously slow on top of adding complexity for the sake of hiding data.
@@drygordspellweaver8761doThing(data) data.doThing() is exactly the same as far as the compiler is concerned.
@@drygordspellweaver8761 data.doThing() and doThing(data) is exactly the same as far as the compiler is concerned.
This idea that OOP is slow is actually incorrect.
What truly matters is how the data is laid out and how it's being used.
OOP class stores data in interleaved form. So if you just wanted an array of position you need to separate them from the other so it doesn't "pollute" the cache line with information that isn't position if all you wanted was position.
Yet. Interleaved data is also beneficial in it's own way when you do in fact use all of the stuff in one place that was in it to reduce jumping around memory.
It is a tool. None else.
If all you have is a Hammer everything is a nail. So, use everything that works well for the task at hand.
Exactly! Stay away from inheritance except for inheriting types for increasing readability(You know, declare an abstract class Vehicle that does nothing and then make classes like Cars, Motorcycle, Airplane, etc inherit from Vehicle. This does not break your code and helps later on if you just want to do an operation on any kind of vehicle without writing 10 if statements. Later on you can add the common abstract method to the Vehicle class and implement it in your sub classes). Other than that don't overuse inheritance. Go with composition.
He is right yes. Even if you manage to define a good abstraction it still took you energy to do so. It's like those pagination algorithms that computers use: the threshold at which they are worth it is when they work 90% of the times, and they work 92, but for object oriented programming most of the times you are adding cognitive overhead as well as actual overhead.
OOP can be good but you always need to ask yourself if you are being organized or just fancy. Ask it constantly, and never get used to just being fancy.
This feels like a strawman but I'm not smart enough to say why. Functional and OOP are different tools to solve different problems. Being dogmatic about one or the other being better for everything doesn't really make sense. For example the main programming I do is ETL. It's more important for me to turn solutions around quickly than to get closer to the hardware. Different problems require different solutions.
FP and OOP aren’t necessarily mutually exclusive. Java has embraced FP style for quite a while.
I think FP is great for lower level code. Code that’s closer to the actual problem solving. For example, transforming lists.
OOP is great for higher level code. Architectural problems concerning the bigger picture.
You’re shooting yourself in the foot if you treat simple list transformations as architectural problems.
the video assumes you are the only developer working on the piece of software or feauture. Then ofcourse OOP or TDD does not make any sense. If you working in a team of 5,10,20 developers things start to get interesting and then you start to understand what all of those abstractions, interfaces, test isolations, doubles,injectors,factories are for.
Or when you have to look at your own code of a year or more ago, which is virtually equal to being written by somebody else.
OOP is just a way of organizing your programming work. It helps you think about the problem and constrains you into a certain set of work patterns to help minimize errors. It also can help to manage complexity in a project better.
Yes, OOP can be done badly (bad code and bad design are things), and a lot of the abstraction and modeling tools it provides may be overkill or just a worse fit for some projects.
Personally, I don't have a huge issue locating implementations in OOP code, so I don't get this argument, but maybe I'm privileged somehow.
Most of the armchair critics of OOP are those that seem to never have got to work on a codebase that properly implemented OOP.
It's like those women who say "all men are pigs" after their 5th breakup
@@AAZinvicto This is exactly what I was thinking. I mean, obviously, different tools for different problems. Use what is appropriate, but don't complain about what you don't understand. I have a anger/disgust reaction to 800-liine methods.
@@AAZinvicto I worked for many different companies. The thing is, something like properly implemented OOP doesn't really exist. What does properly implemented OOP even mean?
I like it, keep it simple, know what is needed.
Dont write everything oop, know when you need to write oop.
Just write to make it work and is testable.
If you start with the test, it help you just to satisfy the tests, and dont write more.
If you start with the code, you try to think about everything.
When i start with TDD, i also switched to move from oop to more simple code that is functional.
01:10 I love Jonathan Blow, and have been a huge fan since Braid. I own a copy of The Witness, and keenly follow his thoughts and updates on Twitter and RUclips and wherever else he gives talks.
But, really, as someone who studied PL Theory and the history and origin and (most importantly) the CONTEXT in which programming languages were developed, I stopped watching at this moment.
"... solve problems in the *_best_* way", really? No. Alan Kay never made this claim, regardless of SmallTalk. No one ever made this claim. You have Functional and OO languages, and Imperative and Logic-based languages like Prolog. They all solve something different, and evolved in extremely different contexts.
Having used OO in many industry projects today (while also diving into other programming paradigms), I can assure you, the subset of problems and the scenarios in which OO is supposed to be used, it definitely does its job very well there.
Can you share an example where OO is beneficial? I only have a decade of industry experience and have only found counterevidence, so bear with me. The only farfetched scenarios I can think of, is when you include ecosystems into consideration. Because OOP languages are the most popular and have ecosystems that allow getting many short-term/one-off projects done really fast.
Man, it's refreshing to hear this, just solve the damn problem :)
enjoying the react content :)
I can fulfill today's requirements directly, but they get massive, interdependent, and ever-changing.
I use abstractions and OOP to encapsulate that mess.
When I started my current job, I was adding features, but my pull requests had huge net LOC reduction.
We joked that at this rate we'll finish the project with zero code.
Those who criticize DI and OOP principles are lucky enough to have never experienced what it's like to maintain a large, "explicit" codebase with low abstraction. Fixing bugs and adding features require extreme effort. Much more than what is required to find an implementation because "go to definition" points to an interface.
That's the issue. Boot camp graduates giving advice.
You left off one thing.
*and don't test their code.
As if OOP is the only way to build abstraction. I'd say, it's one of the worst ways to represent abstraction, really.
@@vitalyl1327 Hmmm, let me guess, you think functional is the best way right? Well, that's if all your app is some toy app and all it is doing is mathematical computations and simple data processing. Functional fails when you are dealing with real world applications that involves state management. OOP remains the best and most efficient for real world applications.
6:16 that's when you turn to Practical Object Oriented Programming!
Aww, POOP, you never let us down!
OOP is just meant to organise your code properly and hence your code becomes more maintainable. There can be unnecessary abstraction but its defintely a great principle to follow for larger projects
Don't fall into the trap of thinking that OOP is just classes with methods in them. OOP is a much bigger paradigm than organising code into structures that make sense. No-one in the world has issue with the organisation part of OOP. It's the inheritance models and patterns that most people have issues with because they force you into a structure that you'll need to reorganize, sometimes extensively, just to add something new that you hadn't planned for. By its very nature, strict OOP actually makes your code LESS maintainable because making changes to the structure becomes much harder when you've got 50 tiny classes all inheriting from each other and another 20 factories generating instances of those classes.
This is why injection, interfaces and composition are often considered a better way to do things.
You can write (probably even better maintainable code) using strict procedural programming. I have seen a hell of lot more maintainable C, assembly and Pascal code than anything OOP. With procedural languages you need to be aware to separate code from data (they aren't one and the same thing and bundling them is just very inconsistent.
It makes more sense to have a structure and a file and/or lib that holds all functions that can process the data in that struct.
The problem also with OO becomes that in more abstract or technical cases it's not really clear what an object hierarchy should be and it gets very hard to take a guess where something is.
There's a reason that heavy OO is on it's retreat with new(er) languages like Rust which is a arguably a very lean OO without subclassing, Jai, Go, Odin and Zig.
Like Linus said, Linux is in C not C++ because is better and keeps away C++ programmers. Feels better to work with types.
@@ilmanti Most people think of OOP in terms of Inheritance exclusively, but Uncle Bob said to favor Composition over Inheritance. He's right too.
As a rule of thumb, I would add a Layer of abstraction if the code is larger then a terminal page (between 40 and 60 lines). Or there is a chunk of code, which is repeating itself (but not a one lkner). For me a layer of abstraction is like a hirarchical layer in a company. The more (layers) you have, the more overhead! If there is more then 1 layer in a file, I indent the function.
nothing is bad, OOP is not bad, FP is not bad, AOP is not bad
everything is a tool and people just learn to use the right tool for the right problem.
If you understand basic thing about code readability and maintainability everything else trickles down from it : key to readable/maintainable (good) code is make it so completely unfamiliar developer (or maybe you in 3 weeks) looks at it and spends least amount of time to exhaustively understand what it does and how to modify it. Having 7 layers of abstraction and being forced to debug to understand which implementation actually executes code is bad, having 7 levels of higher order functions in FP which creates a function that creates a function that creates a function that does stuff is bad... its not about less lines of code either, one can write crypting hard to understand one liner using all sorts of language features but the same thing will be significantly easier and faster to understand (and debug) when its a couple of if statements with good naming of everything.
Its not hard : good code = least amount of time you need to spend on average to understand any portion.
May be I'm less qualified to have an opinion but I've always thought the main reason languages like Java existed mainly to write your code once and to run it everywhere. If we had only one type of CPU architecture we wouldn't have Java. All that can be done with Java can be done in lower level languages more efficiently.
The point of using OOP or any set of "beliefs" is that you get to structure everything in a way that makes sense even if it's tedious, which will make large projects manageable. Have fun writing code with low abstraction and feeling smart, but don't forget you'll need to rewrite when there's more code to deal with.
Cope lol
I agree here. I don't know what the target audience of this channel is but apparently not people who write business applications. I have the issues with abstractions as well but if you reach a certain level of complexity they are necessary, otherwise you will just have only messy spaghetti code at the end of the day which can't be changed any more.
@@mudi2000a Exactly. People here are probably at that level where they kill both the code's flexibility and readability to get rid of 20 lines of code and think they are smart for doing so.
I just started learning programming starting with C# a couple years ago, so my thoughts may not mean anything, but this the same thing I thought. I've looked at the non Object oriented languages, and I definitely like the structure that OOP provides 🤷♂️. I also understand the issues people mention throughout the comments, but that's where good documentation comes into play. And there's usually a tool for something. At least that's what I figure from everything I've read and listened to and watched. Haven't built any big applications yet
@@GloriousMightykarpYup, I see so many videos like this (I think at this point the algorithm has picked up I mean being triggered by them lol). In my experience some people saying these kinds of things are really good, so you can’t completely discount them, but they are overly dogmatic. Then you have a bunch of inexperienced people lapping it up. The more you work with abstraction and techniques that manage complexity in large code bases the easier they become to understand, and the more you appreciate the problems they solve. Are you really going to say someone like Martin Fowler, doesn’t know what they’re talking about?
I find oop harder to reason about. Modules are great, and I think it's helpful to tuck away the squiggly bits, so that the flow and logic is easier to follow.
OOP is okay. Over abstraction is not.
OOP is like the most elaborate California Closet's design you could possible install in your closet. When all you needed were a couple of wire shelves.
OOP isn’t the problem imo. The problem is bad design, sometimes in the form of over-engineering. I’ve also noticed a lot of times it’s a failure to correctly model the right things in your apps domain. This makes reading the code - and therefore changing it - tedious. Maybe the problem is OOP is too hard to get right, and I may agree with that.
And the poor object hierarchy is ALWAYS something that happens when you work with far more abstract or technical problems. OOP only works for business projects because business processes are basically all object and everybody sees that an Invoice is an object and that an invoice is send to a Customer and a customer is a Person. It gets so much harder already with embedded systems are interrupts objects? Are ports with 8 pins each objects? One would say yeah a port is an object with the x amount of pins. Others would say no a pin is an object and a Port is collection of pins and that can be an object but can also just be a vector because you can bundle other pins than too. The thing is, they are both right and it gets obfuscated by presumptuous object hierarchies.
So in 30 years of OOP I have literally never saw an object model in anything bigger than a single function program that made sense and was easy to understand -- even when staring at the UML.
I have seen assembly code written 40 years ago, that I can deduce instantly what it does just by clear functions and a nice block of reserved memory for variables.
I agree 100% it would be so much better to have less abstraction , for example you have a car that is a boat that also is a refrigerator a vacuume cleaner also is a washer and dryer ...... sarcasm this is just a word salad of "all I know is scripting"
If the solution is complicated, you’re doing it wrong. The purpose of abstractions is to simplify the work. Writing macro assembly code is easier than machine code. Writing C is easier than assembly.
OOP is easier than procedural code because it abstracts (hides/encapsulates) the details that aren’t a primary concern of the problem you’re solving. Iterating thru loops. State variables and if statements. Switches and cases. Code duplication. OOP just makes it easier to build apps and make changes later on.
Object orientation’s classes and encapsulation are architectural mechanisms. That is, they provide ways for a programmer to organize the code and data as they choose. OOP languages do not dictate how code and data are structured, they just enforce the access to them.
When you use the object orientation facilities correctly it makes it easier to read and understand code. If you write procedural code in an object oriented language, it’s going to get complicated and ugly in a hurry. If you treat variables like data containers that are processed in a client function, your code will be unwieldy and hard to understand. If you put functions and classes into a hierarchy of abstractions because of a theoretical model instead of the problem you’re trying to solve, your code will be hard to find.
A binary search tree can be used to hold a string. But traversing and manipulating the string would be unnecessarily complicated, don’t you think?
Agreed. Every tool has a use case. OOP enables programmers to architect multi layered products. This allows a single library to support over thousands of use cases, while keeping the code clear, uniform and easy to maintain. What’s the alternative? Thousands of header files with specifics? Appalling to hear this generalized criticism, especially with the example of dispatching a single object in a simple editor. Let’s not build space rockets because I can walk to the grocery store?!
Simula was invented in 1967, and Smalltalk in 1972 -- well before the 80's.
In theory, once you have the right abstractions, it's only a few lines to solve the problem.
But by all means, every programmer should find his/her own way of working.
🎯 Key Takeaways for quick navigation:
00:00 🧐 *The problem with software development began in the 80s when more abstraction was introduced with higher-level programming languages like Java, leading to less understanding of the underlying system.*
01:07 🤔 *Object-oriented programming is often criticized, as the term itself has evolved from its original meaning, and it can lead to complex belief structures without necessarily solving problems.*
02:56 📦 *Object-oriented programming adds a layer of complexity, making it necessary to understand the principles and hierarchy, which may divert focus from solving actual problems.*
03:39 💡 *Object-oriented programming can simplify complex problems, but as software development evolves, more time is spent on abstraction and less on solving real-world issues.*
06:13 🏗️ *While adhering to programming principles is important, sometimes practicality and simplicity in code can be more effective in solving problems than following complex belief structures.*
Made with HARPA AI
I don't just want to solve a problem. I want to solve it in a way where I don't want to kill myself when I have to come back to it in a year or 5 to expand or change it. Yeah people often over engineer that aspect and make it needlessly complicated but that's just bad code and you can write bad code in any paradigm.
Most of the principles of OOP were developed under the environment of hundreds of developers were working on monolithic desktop GUI apps.
Most people don't work on these sorts of things anymore but still adhere to these principles. It's my opinion that if you're working on a codebase that only a single small team touches, SOLID code is damn near an anti-pattern. You have luxuries that people that developed SOLID never had.
this. objects make a lot of sense in UI because they mostly represent widgets which are little islands of state and behaviour with hierarchies which can also call each other.
not so much in other domains. these days modules, closures and immutable records are all the rage
Except IMGUI is often better but not commonly practiced in OOP languages in my experience
Yep. I've been saying this for years now: abstraction has to be justified by its payoffs. And not everything needs to be abstracted according to the "ideal" OO paradigm. Doing that only brings you closer to being an Architecture Astronaut - not a good thing.
Let's get into POOP - Procedural Object Oriented Programming.
I'm not sure why, but I'm not fully convinced. Maybe it's because I don't have that much experience. But imagine working on two codebases: one written in C, C++, or Java that handles its tasks using loops, if-else statements, and similar constructs. The other codebase, however, has a clear interface that shows the operations each class performs. For example, the service class calls a processor class, and that processor class only handles student data. I think I would still prefer the second approach because it not only makes the code easier to read but also easier to test, debug and maintain. I know exactly what responsibility each component of my code has. 👾
This guy has never worked in spaghetti code then. Typically when you do not abstract, mediocre programmers tend to write spaghetti.
YESS. I create abstraction so that the code has pattern. And the abstraction is not really that deep, has no parent class or something. Just implement the interface. And its one of the 3, repository pattern (for data access layer), factory pattern (for reusable lib like file storage, notification, etc), and strategy pattern (for payment). That's it!
And yet, this mediocre programmer still mess things up. They don't even use the reusable function and started to couple database query with payment into one function. Like wtf? They even leak the secret key god damn it
@@thoriqadillah7780 , always
The only thing that stops OOP from appearing to be spaghetti is the find definition button.
From the projects I have seen it's 50/50 if the spaghetti was caused by abstraction or the lack of it. But what I can say is that the ones cause by abstraction were much harder to untangle.
Often people use interfaces so they can use dependency injection. The real benefit of this is it's easy to mock out a dependency when writing unit tests. This is the real benefit I've seen from going full OO with abstractions. It makes testing easier because you can mock out methods you are dependent on
Any useful testing tool can create mocks of implementations, there's NEVER a need to create an interface just for testing.
@@gullijons9135 hmmm your right, I guess I'm c# you can just make all your methods virtual to achieve the same thing. I thought it was only possible with an interface. TIL!
@@gullijons9135 that said, I've still enjoyed using dependency injection
The problem with OOP (the classes, objects, inheritance kind) is that it relies on building these taxonomies of entities regardless of whether it makes sense in your particular problem. And not only creating them, but also getting them right from the get-go.
Oh I hate speculative abstraction!
You do realise you can simply remove them right and no one is forcing you do add them?
@@chudchadanstud Good luck not introducing refactoring bugs without a strong and precise type system
@@mskiptr That's what unit testing is for. No lang will save you from bugs due to refactoring.
@@chudchadanstud Sure tests are important, but they catch bugs only in the behavior you thought of. In contrast, if your data types reflect what you're modelling precisely, the compiler will point out every spot where you forgot to handle a case or where things no longer match up.
And that reminds me of another point: including hidden state in your objects obliterates property-based testing. Such a shame, since that is _the easiest_ way of comprehensively testing your functions.
@@mskiptr I don't get it. What makes you think OOP isn't strongly typed?
Introducing bools and ints for error handling literally creates the same problem you just described. It's called Primitive Obsession.
Like I said, there is nothing that will save you from refactoring bugs besides tests. Bugs during refactoring are a given.
Why are people trying to run away from their responsibilities as programmers?
there's a counter-argument to the all anti-OOP arguments too. if i'm dealing with geometric shapes for example, and i make a few shape classes with data and methods, did i do a bad thing inherently? do i need to care about how badly these OOPy shapes lend themselves to solving problems that i don't have, and probably will never have? or can i just keep my OOPy shapes and use them in my library? they're not hurting anything at all, and trying to make them not OOPy actually introduces *more* levels of abstraction in this case.
This is what I find…. Too much stuff not enough code.
The thing to remember is that OOP isn't made for small functionalites and straightforward algorithms, it's intended to keep huge systems flexible and easy to extend. You don't need OOP abstractions where few if's and for's will greatly do the job, but you won't build a big app flexible from if's and for's alone. Do not overcomplicate things, but some ideas are already so complex, that OOP is the best choice. And OOP is great for game development. That's how I see it.
I am so sick of people hating on oop. Its the best thing invented for prgramming, and everyone hating is is just jumping on a trend.
Huh? I hated it since.mid-80s, and none of the issues with OOP that were raised back then had been addressed and fixed since then. It totally deserve all the hate it gets.
Depends on the language bro.
Not all OOP aren't the same in every languages. Some of them are amazing and other are just terrible...
Loving OOP and shoving it everywhere was literally a trend so much so that every modern language copied Smalltalk
That is a true statement.
It's not the OOP it's the over engineering using OOPS.
The battle of piss and poo: “structural” (i.e. procedural, any OO lang is also structural nowadays) vs OOP.
Nope, not taking parts. I want to see both sides burn. Functional programming is the future.
15 years later
"why Functional programming is bad". People talking about how you have to step through 20 curried functions to actually understand what anything does or w/e
i.e. bad programmers will write badly designed code. The more popular your paradigm the more bad programmers you'll have in it
And idk, from my perspective functional seems like a super convoluted way to do stuff, with tons of memory duplication and w/e for certain things. Like say, coding a UI.
I really feel like this is another one of those instances where the incompetence of some programmers is used to discredit the entire paradigm of programming.
There is not "the problem with oop". Especially because all modern programming languages are hybrid languages which do not force you into using oop all the way and to the extend where the imaginary idealist is statisfied.
I'm sorry but this video is worthless to me with this messaging. It oversimplifies many of the problems programmers face at work into the whole paradigm being broken.
Coding to a superclass (parent class or an interface) helps in implementing the Open close principle.
I started programming learning C and writing simple libraries from scratch and the feeling of learning what happens under the hood, why my code segfaulted and understanding how a language is used to write itself😮. Then I switched to Java 😂 and now I think I am not learning programming but simply throwing libraries over libraries and libraries....
Layers of Abstractions :
Assembly, Bytecode, Java Code, Oops, Interfaces, JDBC, JPA, Hibernate... I don't understand what is happening under the hood. You learn a library then next year it changes its internal structure. Now you have to relearn the same library. Most Developers spend their most time trying to understand libraries.
Remove the library... Most developers will simply crumble.
Are you in school or working full-time
Yeah, do that if you think that it a good idea. For example, write an application which is using a mariadb database. Then someone comes and says, we need to also support Postgresql and Oracle because our customers want it.
Now, either you use some pre-existing database abstraction layer, or you will have to write it yourself. And the 2nd option is often not the correct one as you will suddenly have a big effort. Just to show one example where this thinking falls apart.
Usage of too many libraries can be also bad but not using them at all is not possible unless you are a hobby coder.
Fine. But are you really going to write your own HTTP server in C? Good luck with that.
@@friedrichmyers HTTP is not that bad, HTTPS is the boss fight
@@Muskar2 True, but the thing is that when you need to deliver things, you are better off finding something that just works out of the box. C is good for different things. I use it as my primary hobby language but writing your own unsafe https code in C is just... stupid. Especially considering that web dev is basically a loser job where you cannot ever understand (or code) the entirety of what you're doing.
Yeah, you don't need OOP & to create complexity in your Hello World app. If you don't need it, don't implement it for the sake of implementing it. That's what Jrs do. But forgive them, they're trying to learn & show others that they can. Reel them in gently. But, and listen closely, .... abstraction is how we deal with complexity. That's how our minds work. Imagine trying to program a robot to walk out a door. Every little instruction and movement - Insane. But our minds have abstracted away the details. We think: get up, go to the door, open it, walk out. Or maybe just "leave". OOP is simply a way to abstract complexity into the correct objects so that we don't paint ourselves into a corner. But certainly, pick the appropriate tools for the job.
abstraction isn't the only version of complexity though? i genuinely don't understand this argument, as if say functional code is always as simple as it needs to be?
Got to the Smalltalk thing and gave to in the video. Why are you commenting over the guy if you don't know something basic like what OOP originally referred to?
Why don't you stop recording, do some research, find out and then record? You have Google don't you?
This is incredibly lazy content. You're basically just taking someone else's video, who didn't go to huge efforts himself as voicing over it.
Ffs, this is yt rock bottom.
The main problem is that students of pure informatics departments frequently never ever will be confronted by anything else than just OOP those days. But remember: at the and of the day, when the sun comes down, every program is strictly procedural.
OOP is just one example of messy code. I've seen people doing functions only and they still hide the implementations deep down the code base. Like you have to go trace lots of function call in order to reach the actual thing and read it.
That isn't really an issue even if you have to go 100 levels deep if you can for sure trace it. Issue comes with Dependency Injection. You don't know where to find the actual implementation with Dependency Injection!
@@arpitkumar4525 Dependency Injection feels like magic fr
@@arpitkumar4525 even dependency injection is not a problem if it is written in an easy to follow way. And DI has also advantages. When one utilizes Test Driven Development approach, DI becomes an indispensable tool.
@@arpitkumar4525 Problem is when people think you can only do DI through interfaces, there's nothing wrong with depending on an implementation (class)
I think when you are dealing with a lot of data, OOP seems ok?
Functions are preferred, OOP on lot of data. What do you think?
This reminds me of a colleague working on frontend in Angular. She said, we created so many interfaces at some point we forgot what we were supposed to do. Imagine THIS happening to a UI project, and now bring this mindset to a problem which doesn't even have UI. You'll have invisible daemons haunting your code. :)
So to summarize, OOP is more boilerplate, so don't use it prematurely.
OOP is more boilerplate, so don't use it at all. Programmers claim to want simplicity but then add 15 layers of complexity.
@@CyrilCommando sure lets make a back end API purely procedural 🤣
I guess you people prefer your application code in a single python file
@@Fantaztig lol you can make your code modular while not abusing oop, they're not mutually exclusive.
Perfect
Object Oriented Programming is a way to segmentate code. That's all...
It's not even a hard difference from functional programming. Functional programming also has 'abstractions' such as a user.
However, it's not put concretely into one identifiable block of code. The 'user' is all over the place in functional programming.
If you build small websites or things with few abstractions, then perhaps indeed an object oriented approach isn't necessary nor beneficial.
However, once you understand object oriented programming, it just cost a little extra for even such small programs to be object oriented.
Then they became way more scalable and are more uniform. So anyone can basically come in and understand what's going on fairly quickly.
I feel like many people don't know actual coding at all. They don't even understand object oriented programming properly.
The guy in the video says stuff like "just write the editor", "just write the plugin". If you do so with shitty code and you actually charge a customer for it, it's just bad ethics at this point. If the customer wants changes or adjustments, who is going to help them? How much time and effort will it cost?
You have clearly never worked with OOP. ;-)
I do not see any problems with OOP after 20 years of programming using it. It simplifies huge projects and hides unnecessary code details inside the classes. You do not need to know details, use properties and methods of objects. And it is also more easy to support and extend your software.
People whining about how 'x' programming paradigm is bad are just identifying themselves as amateurs. If you are working with any Turing Complete language (paradigm), then you are able to commit any number of atrocities, which makes them all "bad", or "problematic".
@@AndrewARitz Turing completeness does not turn software architecture into a 100% subjective practice either
@@Muskar2 so what?
@@AndrewARitz Programming paradigms matter in objective ways. The hardware has specific paradigms on its own and favors programs that align with them. And even though humans are adaptable and differ, we can only comprehend a limited amount of complexity, so adding unnecessary complexity is objectively bad.
I've been programming since 1973 and OOP encapsulation is a godsend. Can't wait to mark something "private" in C++.
You guys dont know oop. The code is in the structure. In the relation between objects. And just look to the interface. Its abstracted. Its not for games, maybe that is your problem.
Try hardware verification.
Every 2 years you start a new project from scratch, and the first thing you do is solve "real problems" and it's in fact most of what you do for most of the project, and that's because there are no real libraries (just empty skeletons). This is because the ASIC design is usually proprietary and unique.
We still rely a lot on OOP to build the verification environment because it's good for EVERYTHING.
The code is easier to read, easier to modify, expand upon and to debug.
And we don't use interfaces, only classes and inheritance.
In 7 years I've yet to even see an abstract class.
Also. objects do solve a real problem.
If you consider code duplication a problem.
@@somebodyoncetoldme1704
"Also. objects do solve a real problem.
If you consider code duplication a problem."
You're the first person i've seen mention this.
Does he really think that programmers just woke up one day and said "you know what, i'm going to complicate programming for not good reason"
OOP was _created_ to solve problems.
This just tells me he has never worked on any codebase of any real size or complexity.
@@khatdubell Jonathan Blow bring out of touch with commercial software development? No way!!
Yes actually, the guardrails are put in place to enforce standards within the codebase. You can call it an "assembly line", which is actually a good thing. Assembly lines generally ensure fast and efficient production, and result in products with fewer defects. This saves both time and money. And this is why OOP and FP are used.
Overengineering its a thing definitely...
I have been tip-toeing around the "devs are too dumb to make code that works" argument for so long, so thank you for saying it. I haven't worked in industry as a developer, so I have hesitated to pass judgement on all these various ideas like OOP vs fuctional, micro-services vs monolithic, etc., and I have heard all the arguments for these "belief structures" that people have. And I have always wondered what problem are people trying to solve? How are they trying to solve that problem? And it seems like to me that the decision to choose OOP vs FP, micro-service vs monolithic, etc. is never as an answer to either of those questions, it's always an answer to a completely different question that has nothing to do with the problem at hand. Again, no industry dev experience, but it seems to me that the decisions being made on thing like OOP vs FP are about continuity of operations and other business decisions, and have very little to do with actually solving the problem at hand. Exactly like you said, it's about ensuring that the development process at a business can be easily migrated from developer-to-developer, from team-to-team. Now, yes, the current state of industry-style development does seem to necessitate things like OOP and micro-services, despite the fact that so many incredibly talented develops seem to not like them as go-to methods. That doesn't mean that any of these things are concepts you should never use, but it's like what Blow is saying--it should be done as an intentional choice when it becomes apparent it is useful, but not taken as some programming dogma. Because then your choice is about solving a problem programmatically.
There's no need to pass judgement. They are tools. Ever hear a carpenter say you should avoid using a hammer (OOP) at all cost. A hammer (OOP) is objectively bad.
Any professional carpenter will laugh at that statement. Yet for some reason this flies in programming world.
I'm really not trying to be argumentative, but yes, I have actually heard carpenters (and all sorts of other tradesmen) make arguments about what is Objectively The Best™ way to do something, once you take a step into their expertiese. For instance, I have heard carpenters say you should never, under any circumstance, cut a 45º angle unless you used the angle measurement built into a tool to do it. Even if you use a square and geometry to ensure its absolutely a 45º cut, there are guys who will swear that if you're not using the compass built into your miter/table/circular saw to measure the angle then you're going to be off. Ask a random assortment of plumbers about sharkbite connections, and you will definitely find some insisting they are objectively, undeniably unuseable. Many electricians will swear that you should never use an arc fault breaker except to pass an inspection. Don't even get me started on the arguments about which tools brands are objectively better than others. So, no, this thing does not solely exist in the world of programming. It exists whereever there are people.
What I think you're missing is - you gotta pick something. Procedural, FP, OOP, whatever.
In general, for a given project, there might be an obvious choice (C# for Unity) or obvious bad choices (C for webapps). Outside of that, picking the "right" thing is most likely about picking what you're most familiar with. I can guarantee you almost no one is going out there and taking a survey of all potential programming models and technologies before they pick something for their project. That includes Blow.
@@bobbycrosby9765 I don't think anyone is arguing against the reality that choices need to be made and that those choices can be daunting. What Blow is literally saying is that sometimes choices being made have less (or nothing) to do with that choice being a good way to solve a problem, and more to do with the fact that people have arbitrarily taken the choice as some kind of standard to always use. There's a big difference between looking at the choices you have most readily available versus trying to look at the entire world of programming for potential choices, and there's an even bigger difference between actually evaluating what's immediately at-hand versus just arbitrarily deciding.
The thing that is being criticized is that the reason something is being chosen is often because the thinking is precisely "we just gotta pick something", and it doesn't get investigated further than that, sometimes even if there's tons of problems.
I so agree with your point. Entered the Java world recently and I'm really overwhelmed by the overuse of object oriented patterns everywhere.
Everything needs to be abstracted so we can mock our code and test it my friend. You keep asking questions yourself that have super obvious answers. Having said this, I prefer to create interfaces for functions than classes. I think its a lot cleaner when we do this. My main concern with OO are the mamushka dolls of multiple layer inheritances that end up creating confusion. Typeclasses is the way to go
OoP is the skeuomorphism of programming. Great for helping people learn, but ultimately unnecessary.
Eventually, you realize that you don’t need a doer-of-things to do things and that you’d really rather just get the job at hand done than make a world of abstractions.
its actually the opposite, oop makes it harder to learn, because it abstracts and moves codeflows away. you need to learn more.
oop does only matter as a structual framework in statically typed languages with a strong emphasis on compile-time checking.
basically "if i upgrade this plugin, will my project still work. ah fuck no.. so many errors" vs
"if i upgrade this plugin, will my project still work? lets find out and test each and every part. oh it was used in this module, who would have thought"
so all of those programming languages have pros and cons. sometimes its compile time. sometimes its validation.
oop is only a small part of the whole thing and all sides have tradeoffs.
@@EudaderurScheiss Incorrect, it's much easier for humans to wrap their heads around abstractions. Hence our very liberal use of metaphors in almost anything. The issue is with OOP that it's not very efficient on the compiler side of things.
these insights are pretty informative, keep it coming!
loving this typa content
You just argued for OOP in the last 15 seconds of your video. That is exactly one of the reasons why OOP is great. When you code your hello world pet project that you abandon in two weeks, you're going to be fine without OOP. But when you work on an enterprise app with hundreds or thousands of developers that come and go over several decades, the structures and abstractions OOP provides are essential to preserve maintainability.
I've seen and coded pure C and assembly that still runs today so that's an invalid argument.
Actually I have seen far more maintainable code in procedural languages that OOP. You can both fuck it up and do it well, but it's easier to do low-level code well than highly abstracted code -- because there's less rules and less to think about.
Most enterprise apps these days are not apps, but rather, they are systems loosely connected via a network. We're writing smaller programs than ever yet people still swear by OOP because it's what they're used to.
@@bobbycrosby9765 exactly! It’s what they were taught at school and most never developed in a strict procedureral so they don’t know what the benefits and drawbacks are of both.
I started coding in C/C++ for Arduino and created only procedural/functional code. Picking up things along the way, I now use OOP for most tasks. It's very useful for scope.
6:18 most professors have not worked in the real world
The way OOP is taught is fraught will bad ideas and half implementation and poorly cobbled concepts that work under certain circumstances and not at all in others
It’s interesting to study the origins of these things, it was all based on hype cycles from previous ages
I see the point you’re making, but you can say that about almost anything. Here are some examples:
Machine code is an abstraction of the electrical engineering circuitry that is actually doing the all of the physical computing.
Electrical engineering circuitry is just an abstraction of the physics of the electrons moving through matter.
Calculus is an abstraction of real analysis.
Biology is an abstraction of chemistry.
The point is that you can actually solve real problems as you abstract away from the physics and math. The downside is that it won’t be as universal. Knowing libraries in C++ won’t help you if you arrive somewhere where they don’t use those libraries, but knowing physics and math will work all over the observable universe. The downside is that you can’t actually build anything by only knowing physics and math 😂.
You missed the point i guess.
Pushing OOP for every problem is a bad abstraction.
You won't use hammer for cutting wood.
Right tool for right job is needed.
@@shrin210 no, I agree with you. Electrical engineering is a fantastic tool, but it isn’t the best tool for designing an internal combustion engine. I was responding to the part where he said OOP didn’t solve any real problems. I’m not defending the use of OOP for everything and I’m all for using other programming paradigms when they are superior in their application :)
5:40 ist not even "premature Optimization", it's an optimization along the wrong axis, based on the wrong criteria, it's improving the wrong numbers.