The Problem with Object-Oriented Programming

[@Qwantopides]

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.

[@euclid9492]

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.

[@sporefergieboy10]

The funny thing is the same people who write this dynamic dispatch spaghetti garbage when asked if goto is bad they’ll say yes.

[@CallousCoder]

This has been my experience with a lot of OOP codebases! Even some I wrote myself and revisited after a few years.

[@RolandNSI]

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.

[@BobrLovr]

break points , epic bruh moment

[@psyience3213]

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.

[@self-aware986]

I second this! That's the point!

[@totheknee]

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

[@psyience3213]

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

[@fallegapyro]

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.

[@ibnlopqrt]

Lmao useless shit

[@totheknee]

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

[@jason_v12345]

Premature optimization is the overengineering of solutions related specifically to performance.

[@fellowkrieger457]

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.

[@Muskar2]

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

[@brandyballoon]

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.

[@Muskar2]

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

[@Rockyzach88]

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.

[@ThienNguyen-bg1kx]

If only I live in a world where I don't have to deal with someone else codebase.

[@marcs9451]

Paradigms are not tools, that is a complete nonsense take. And there's not moral argument on Jon's part

[@Rockyzach88]

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

[@fellowkrieger457]

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.

[@yp5387]

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]

Yes and then the project requirements completely change lol. And people hate on high level language and quick shipping approaches…

[@JaconSamsta]

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

[@steve16384]

Design patterns are one the biggest distractions in dev. Just write the code that's needed already.

[@ifstatementifstatement2704]

I hate it too but in my experience you better implement the pattern early unless you want to spend a lot of time refactoring.

[@redhotbits]

design patterns are applied to solve certain problems. if you apply a pattern without solving a priblem then it is an antipattern

[@magicmulder]

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.

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

[@JanVerny]

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.

[@magicmulder]

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

[@HansBezemer]

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

[@sacha9593]

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

[@obnx7]

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.

[@drygordspellweaver8761]

abstraction doesn't require OOP though. OOP is a cult mentality, a belief in some mythical 'clean code' standard.

[@tehflyingknee1]

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

[@jason_v12345]

> to make the code more maintainable...without the need for it That statement is self-contradictory.

[@cheerwizard21]

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.

[@LuisAlonzoRivero]

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.

[@coder_foo]

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.

[@asdasddas100]

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

[@InconspicuousChap]

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.

[@thrashwerk]

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

[@JUIIICED.]

@@thrashwerk I’m confused. Is OOP just the practice of putting everything in a class? Or is OOP using classes in any capacity?

[@lucaxtshotting2378]

I'm done with people oposing fucntional programming to oop, as if you couldn't go stream.filter.foreach.toarray in java

[@lucaxtshotting2378]

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

[@zS39SBT4fe5Zp8Q]

Everyone complains about OOP but is okay saying "I'll just need 4 months to rewrite all this code" with a straight face.

[@SaHaRaSquad]

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.

[@vitalyl1327]

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.

[@marusdod3685]

discord uses elixir, not erlang

[@vitalyl1327]

@@marusdod3685 Elixir is a syntax sugar on top of Erlang. Sort of.

[@SaHaRaSquad]

@@marusdod3685 Ok. Though Elixir uses Erlang's VM, so it's the same idea.

[@Georgggg]

Messages that passes misterious ways to make it microservices-level-hard from the beginning sounds even worse than Java.

[@kuso666]

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]

The rant in OOP is always about Inheritance and nothing else. Everything else is good like Repository pattern, MVI or whatever.

[@toms7114]

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

[@shrin210]

@@toms7114 Totally disagree that Inheritance is necessary for large projects. People are building large projects in JavaScript, Rust, Golang and C without any inheritance.

[@toms7114]

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

[@shrin210]

@@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. kzbin.info/www/bejne/qImTeqeMerudfsUsi=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

[@mariusirgens5555]

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.

[@ancyracademyfr]

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

[@tehflyingknee1]

I agree. You’re supposed to identify seams in your application. This lets you focus on what’s important-your domain model.

[@cheerwizard21]

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.

[@RajaBabuChauhan-f4x]

agree. the advantages become more clear when we start writing thousands or millions of lines of code

[@justsomeguy8385]

Do you have any recommended reading on the subject?

[@BullyInDaHouse]

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.

[@benbowers3613]

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.

[@Daekar3]

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.

[@pmberry]

Also, in the real world, not everything is an object. Some things are concepts.

[@Georgggg]

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.

[@firezdog]

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.

[@CallousCoder]

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.

[@tristan61922]

John Ousterhout!! Great book

[@MrGone0608]

Why is wrong using abstraction? Like using assembly will solve the problem.

[@qwe14205]

OOP is trash, instead I always use 12 levels of "if else" statements.

[@BobrLovr]

Or how about you break your definitions into header files and just write code how it was always written before cpp?

[@SergLapin]

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.

[@RetroAndChill]

Don’t forget single entry single exit so no early returns 😂

[@cyrusol]

@@BobrLovr The moment you realize that header files make for ... objects. Aaany day now. Selfawarewolfism is strong in programmers.

[@BobrLovr]

@@cyrusol lawl, tell me you have no idea what you're talking about without telling me

[@BeatPoet67]

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.

[@jonathanlamarre3579]

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

[@drygordspellweaver8761]

Don't tell the POOPs (professional OOP'ers) that I write 1000 line functions ;)

[@jason_v12345]

If you don't know what that means, then I can understand why you'd be frustrated.

[@BeatPoet67]

What's "that"? Which specific point are you referring to?

[@Muskar2]

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.

[@imaginaryangle]

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.

[@Vedarta]

Software development is indeed hard, specially when you don’t know what you’re doing. But sure, it’s OOP’s fault, lol

[@rcdmrl]

The thing about depending on interfaces isn’t so much about having many implementations but about testing and stubbing.

[@zS39SBT4fe5Zp8Q]

Lots of programmers out there still think testing is only for qa.

[@DinHamburg]

@@zS39SBT4fe5Zp8Q those are the ones who make videos on KZbin

[@AaronNGray]

Neither of them know what they are talking about. OO started in Simula-67.

[@datguy4104]

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.

[@jasonwismer2670]

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.

[@chudchadanstud]

@@jasonwismer2670 Inheritance should not be avoided, it should be used appropriately. It's really tiring hearing this dogma.

[@Flackon]

Instead of using C to manipulate the sand directly with glue

[@tehflyingknee1]

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

[@halcyonramirez6469]

​@chudchadanstud learned the hard way that yeah Inheritance should be avoided. It's not dogma but just experience from its pain. prefer composition instead.

[@multiHappyHacker]

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.

[@SnakeEngine]

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.

[@DctrBread]

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.

[@Fitzrovialitter]

Yes, it was all about mindlessly following fashion.

[@imadetheuniverse4fun]

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.

[@TheSulross]

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.

[@ryasmi]

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.

[@brotherpeter00]

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.

[@ryasmi]

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

[@brianm6965]

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]

How does one overuse DI? I am assuming you mean dependency inversion. Also why do you have tools for discovering code?

[@brianm6965]

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

[@skyhappy]

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

[@tehflyingknee1]

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

[@howardlam6181]

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

[@SatyaPrakash-lm7rh]

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

[@alimuratakkan]

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.

[@SunSailor]

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.

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.

[@future62]

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.

[@oscarfriberg7661]

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.

[@lucaxtshotting2378]

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.

[@Modinthalis]

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.

[@TheJGAdams]

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.

[@drygordspellweaver8761]

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.

[@TheJGAdams]

@@drygordspellweaver8761doThing(data) data.doThing() is exactly the same as far as the compiler is concerned.

[@TheJGAdams]

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

[@arpitkumar4525]

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.

[@Vortex-qb2se]

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.

[@ArchaeanDragon]

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.

[@AAZinvicto]

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

[@johnmaloney1681]

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

[@blubblurb]

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

[@DigitalDesignET]

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.

[@dwolrdcojp]

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.

[@NathanTenney]

What you describe is not unique to OOP.

[@marusdod3685]

@@NathanTenney OOP makes it harder to change things

[@mushrifsaidin]

@@NathanTenney True but solving it the OOP way makes it 10x harder than say doing it functionally for example. That was OPs main point.

[@anthonyobryan3485]

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.

[@overclucker]

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.

[@se4geniuses]

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?

[@Ytuserqf]

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

[@Tekay37]

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.

[@johnapple3471]

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

[@ilmanti]

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.

[@CallousCoder]

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.

[@jesusallerdiez]

Like Linus said, Linux is in C not C++ because is better and keeps away C++ programmers. Feels better to work with types.

[@johnmaloney1681]

@@ilmanti Most people think of OOP in terms of Inheritance exclusively, but Uncle Bob said to favor Composition over Inheritance. He's right too.

[@dazzykin]

Coding to a superclass (parent class or an interface) helps in implementing the Open close principle.

[@GloriousMightykarp]

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.

[@HobokerDev]

Cope lol

[@mudi2000a]

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.

[@GloriousMightykarp]

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

[@edattacks]

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

[@tehflyingknee1]

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

[@adrianojordao4634]

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.

[@brianwhittington9952]

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.

[@CallousCoder]

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.

[@dsmann12]

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.

[@shikharraje]

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

[@Muskar2]

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.

[@gmodrules123456789]

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.

[@brotherpeter00]

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.

[@GoodVolition]

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.

[@Arcwise]

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.

[@awmy3109]

That's the issue. Boot camp graduates giving advice.

[@khatdubell]

You left off one thing. *and don't test their code.

[@vitalyl1327]

As if OOP is the only way to build abstraction. I'd say, it's one of the worst ways to represent abstraction, really.

[@awmy3109]

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

[@curtismantle]

You’re talking about different things in this video. OO programming is a paradigm but concepts such as interfaces and dependency injection are used with OO but are not part of it.

[@genechristiansomoza4931]

OOP is okay. Over abstraction is not.

[@SaudBako]

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.

[@The_Conspiracy_Analyst]

6:16 that's when you turn to Practical Object Oriented Programming!

[@williamdrum9899]

Aww, POOP, you never let us down!

[@headsofhiphop]

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]

Any useful testing tool can create mocks of implementations, there's NEVER a need to create an interface just for testing.

[@headsofhiphop]

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

[@headsofhiphop]

@@gullijons9135 that said, I've still enjoyed using dependency injection

[@drygordspellweaver8761]

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.

[@CanwegetSubscriberswithn-cu2it]

If you're paid per line of code....😅

[@PieterWigboldus]

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.

[@mskiptr]

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]

You do realise you can simply remove them right and no one is forcing you do add them?

[@mskiptr]

@@chudchadanstud Good luck not introducing refactoring bugs without a strong and precise type system

[@chudchadanstud]

@@mskiptr That's what unit testing is for. No lang will save you from bugs due to refactoring.

[@mskiptr]

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

[@chudchadanstud]

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

[@jackbotman]

Man, it's refreshing to hear this, just solve the damn problem :)

[@ohwow2074]

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.

[@arpitkumar4525]

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!

[@friedrichmyers]

@@arpitkumar4525 Dependency Injection feels like magic fr

[@vyli1]

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

[@gullijons9135]

@@arpitkumar4525 Problem is when people think you can only do DI through interfaces, there's nothing wrong with depending on an implementation (class)

[@harm991]

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?

[@alfredoneto452]

I think it just doesn't make sense when you got a problem to solve and the first thing you think of is "how can i first of all conform to this OOP design standard before solving the actual problem. I think the right idea is to first think of a solution to the problem at hand, then implement the most simple/understandable solution and, if the probability of having to make that piece of code open to future changes (like when its a domain knowledge that changes/grows often) is low, you can just leave it at that. You can even tolerate duplication instead of DRYing out the code right away if that's the case, for instance. The thing is when you know the code will have to grow to conform to the increasing domain requirements, and you see you're just adding more ifs and elses, you naturally think "there's gotta be a better way of doing this". And usually this way involves going up on levels of abstractions and unavoidably creating some level of indirection. It's all about tradeoffs. So instead of thinking of a preexisting design pattern to conform to, whe should flip the situation on it's head and start thinking from more concrete to more abstract -AS PER NEEDED. So we should first try to understand why/how these design patterns first came to be, like what's the problems they were trying to solve when these things came into existence? Why do they exist? And go from there. It's far more productive to follow design guidelines, like making some good design questions as you code, then just implementing some OOP philosophy if it matches your situation, and iterate from there than just thinking first of an OOP design pattern and try to make your domain fit into that structure. Of course i don't believe OOP is perfect, nor that it solves everything. It's just one more tool, and nobody should be faithful to only one tool :)

[@krellin]

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.

[@diamondtulip6186]

I prefer C++ over C, but not because of objects, but because of memory management. C++ automatically calls destructor once your automatically allocated object goes out of the scope. For me object is just thingy holding memory an thus helping me with automatic memory deallocation once the object is destroyed.

[@Muskar2]

Eventually you might realize that it's not beneficial to (have C++) dynamically rediscover large object graphs that the programmer would not only already know, but could trivially deal with if batched together in lifetimes. Usually an application only has a handful of different lifetime behaviors, and grouping them that way also provides a lot of mental clarity about intent. E.g. the entire life of the application; during specific events/scenes/screens; for the duration of one frame/main loop iteration; only during the current scope/function etc. I think C++ is designed at handling the rarest case: long-term memory with poorly-defined lifetimes/ownership.

[@bobbycrosby9765]

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.

[@marusdod3685]

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

[@Muskar2]

Except IMGUI is often better but not commonly practiced in OOP languages in my experience

[@creamyhorror]

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.

[@aazzrwadrf]

enjoying the react content :)

[@ajward137]

Surely the point about writing any program, is that you need to model the problem to understand it. Then you need to choose a language and model a solution navigating the strenghs and weaknesses of the chosen language. The idea behind object oriented programming is to build useful objects that model aspects of the solution. Frequently (though not always), this leads to a more maintainable solution, because the objects modelled in the problem mimic aspects of the solution. Like any tool, object oriented programming can be abused. SmallTalk is nothing like C++, but you can write object oriented solutions to something like the Game of Life in both languages that have a lot of structural similarities. Smalltalk is more "fun" and is faster to write, but C++ is less likely to suffer scalability and portability issues in a production environment. Programming is a hard skill to master. ...and remember: a good Fortran programmer can write Fortran in any language 🙂

[@Yakushii]

So to summarize, OOP is more boilerplate, so don't use it prematurely.

[@CyrilCommando]

OOP is more boilerplate, so don't use it at all. Programmers claim to want simplicity but then add 15 layers of complexity.

[@BobrLovr]

@@CyrilCommando sure lets make a back end API purely procedural 🤣

[@Fantaztig]

I guess you people prefer your application code in a single python file

[@deistormmods]

@@Fantaztig lol you can make your code modular while not abusing oop, they're not mutually exclusive.

[@ibnlopqrt]

Perfect

[@dismian7]

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?

[@schmetterling4477]

You have clearly never worked with OOP. ;-)

[@_Mikekkk]

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.

[@AndrewARitz]

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

[@Muskar2]

@@AndrewARitz Turing completeness does not turn software architecture into a 100% subjective practice either

[@AndrewARitz]

@@Muskar2 so what?

[@Muskar2]

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

[@zf4hp24]

I've been programming since 1973 and OOP encapsulation is a godsend. Can't wait to mark something "private" in C++.

[@mythomaniac9903]

Honestly at this point I mostly write at most, if any inheritance at all, one layer. Most of my code now doesn't use any inheritance. If anything I might make a Component interface for a game engine, and have that be the only actual inheritance. My code has gotten so much better by somewhat (but not fully) abandoning OOP fundamentals. I use objects, and I use encapsulation, but not much more than that. Also not fully related, but overuse of DRY and SOLID can make your codebase a pain. Don't be afraid to repeat a few lines of code, and for SOLID, specifically the SRP, don't be too dogmatic about what "one thing" is.

[@voidpointer398]

Also many people think of srp in a wrong way according to the author single responsibility usually refer to an actual real world actor it may be a person or even a business department

[@NJActuary]

It's not either OR. OOP provides good structure. Functional provides practical. You need both. Notice python, javascript providing more OOP and Java providing more functional. The big convergence is here.

[@kevinb1594]

Javascript only provides OOP to appease C# developers and MS hammerfisting the web development community with TS. It doesn't actually use OOP since everything is converted to functions in the end.

[@oscarljimenez5717]

​@@kevinb1594OOP is not about classes or functions, is about attaching functionality to state, making a Object, that's what the name come from. You perfectly can do OOP with JS, also you perfectly can do FP with JS.

[@theo-dr2dz]

I think he is right and he is not right. To me, in practice, a class is simply a mini-namespace that combines variables and functions, those can be public, private or protected and they can inherit. Now, what I think is the most valuable aspect of classes is the modularity. It gives a kind of fine-grained modularity. A language like C has no modularity at all, I mean no namespace mechanism of any kind, every symbol that is not constrained to a local block is global everywhere it is (in)directly included. That makes name-clashes a real problem, hence very convoluted, prefixed naming. The second most valuable aspect is the possibility of making variables and functions private, so that stuff that is only relevant internally, is only visible internally. That makes lots of things a lot simpler. And inheritance and abstract interfaces _can_ be convenient, but should be used very sparingly. It is nice to be able to draw graphics through direct x and opgengl with a unified interface. That is a real use case of an abstract interface. But this is very easily overused and especially in the typical kind of enterprise software it very easily becomes a debugging nightmare, making it hard and time-consuming to hunt down the code where stuff actually happens. The C++ core guidelines actually recommend not to have inheritance hierarchies of more than 2 or max 3 levels deep. That makes sense to me. So one base class and one derived. Only derive from derived in extreme exceptions. The problem with inheritance is that it imposes a very rigid, hardcoded hierarchy. Most real-life things are not perfectly hierarchical. There are hybrids and there are exceptions to the rule. OO inheritance can't handle those very well. Also, relations between things can't be externallyn defined in data. It has to be hard-coded. A system like ECS works much better with entities that can be data-defined and can combine many aspects.

[@KvapuJanjalia]

Let's get into POOP - Procedural Object Oriented Programming.

[@ulfdellbrugge827]

i dislike OOP, but it might solve problems other than what a program has to do. For example it might enable organizations with silo'ed non-crossfunctionional teams to to do their job. The teams encapsulate their part of the code and make only very small parts public and other teams only can use it the way that the original team designed the class. Not sure it's the best way to solve organization culture issues, but sometimes it is what it is.

[@Carlos-yj3on]

Overengineering its a thing definitely...

[@Scotthutchinsonking]

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"

[@aakashPotter]

I so agree with your point. Entered the Java world recently and I'm really overwhelmed by the overuse of object oriented patterns everywhere.

[@davidespinosa1910]

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.

[@surajmandal_567]

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.

[@skyhappy]

Are you in school or working full-time

[@mudi2000a]

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.

[@friedrichmyers]

Fine. But are you really going to write your own HTTP server in C? Good luck with that.

[@Muskar2]

@@friedrichmyers HTTP is not that bad, HTTPS is the boss fight

[@friedrichmyers]

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

[@icegiant1000]

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.

[@Life4YourGames]

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.

[@AreQ212]

6:30 interfaces doesn't provide you only "extensibility" but also, what in my opinion is even more important, testability. Of course pure function would be definitely better, but sometimes you have to mock that db ;)

[@oscarcharliezulu]

This is what I find…. Too much stuff not enough code.

[@kc.88]

Kinda feel the same way. Too many times, we have projects that have so many layers of abstractions (factories, interfaces, abstract classes) for the sake of abstraction. The code becomes immensely difficult to follow and drains all your energy trying to understand what's it's actually doing. Also, remember the good old days of TheServerSide design patterns overload? Ppl came up with patterns just for the sake of coming up with patterns. LOLs...

[@gonzalezm244]

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

[@shrin210]

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.

[@gonzalezm244]

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

[@martinruegg9367]

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.

[@somebodyoncetoldme1704]

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]

And we don't use interfaces, only classes and inheritance. In 7 years I've yet to even see an abstract class.

[@somebodyoncetoldme1704]

Also. objects do solve a real problem. If you consider code duplication a problem.

[@khatdubell]

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

[@kevgoeswoof]

⁠@@khatdubell Jonathan Blow bring out of touch with commercial software development? No way!!

[@DotaBlitzPicker-wn7oq]

I think Object oriented is fine. The big thing I think it does well is that it formalizes the fragmenting of logic. And while that sucks for small systems. (why would you fragment that)... it is the "BIG" problem in software development. No human can completely keep a sufficiently large full system in their working memory to reason about. Object oriented is just the 'martial art' of fragmenting a large system in such a way that it breaks into workable chunks that can be loaded into the human working memory and reasoned about. Without it two different people could load two different subsets into their working memory and come to two completely different conclusions about what software is doing in vastly different times.

[@oijgg3p]

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.

[@vitalyl1327]

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.

[@sukapow]

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

[@Romogi]

That is a true statement.

[@surajmandal_567]

It's not the OOP it's the over engineering using OOPS.

[@oijgg3p]

@@vitalyl1327 That's exactly the problem, you are not accepting the "new ideas" and sticking to c / assembly logic. And don't get me wrong, that's completely fine (my grandfather drives 1960's car, and hates "new junk"). The problem starts when "new kids on the block" start hating it for no apparent reason than "everyone else does it".

[@yan-amar]

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.

[@InconspicuousChap]

OOP has only two areas I know of where it is perfectly applicable: graphic design (including UI, including browser UI) and simulations. By now it has been almost completely washed away from everywhere else: you would see beans, utilities, interfaces, mutable and immutable data structures, but no one in sane mind would follow "everything is an object" principle. Implementation is concealed using interfaces, not a fig-leaf "private/protected"-based "encapsulation", not really protecting applications from tight coupling. Hindley-Milner type systems provide real polymorphism with far better static control instead of ad-hoc "inheritance". Moreover, corporation managers had liked and promoted OOP since 1980-s for an entirely different reason than converting the world to objects: they had thought that it had been a good way to split large developer teams to smaller units and develop large applications in parts. That's how the corporations work, so C++, Java, etc., just reflect that way of thinking. Now OOP is being abandoned, for another corporate management toy: microservices. They love it for exactly same reason, and as long as this approach is tailored to their view, it results in exactly same poor quality, copy-paste powered, designless software as OOP did.

[@CallousCoder]

UI, Business software are ideal for OO (very clear object definitions very clear functionality of those objects). But not even simulations as the abstractions of OO cost too much hence Odin was created. But yeah I agree some areas fit OO others simply don't but most don't seem to see that. Nor that I as a 22 year old after learning C++ and OOP, I was advocating everything should be done in OOP.

[@InconspicuousChap]

@@CallousCodervery small percentage of business software is suitable for OO. Basically, real world domains don't fit it at all, they are too complicated for such type system. Only artificial data type hierarchies do fit, and not all of them. Consider e.g. collection frameworks - domain artificial enough. 25-30 years ago, in times of OO euphoria, all of them have been designed in an OO model, but look at them now: C++ has departed from OO in STL, keeping Hindley-Milner (templates) and traits-like approach. Java still pretends to retain OO, but at what cost: e.g. for each type an associative array the key type should possess entirely different sets of properties. Array - the index should be an integral type. SortedMap - the index should be comparable. HashMap - the index should be able to compute a hash code... and since Java 8 or so, also be comparable, because they have suddently started to convert buckets to balanced trees. AMT... they don't even know what it is. Java collections are so ugly and inefficient that authors of each popular JVM language (Scala, Kotlin, Clojure, Frege) have created their own framework, as well as some corporations have for Java itself. And they all are traits-based, not hierarchial. So long inheritance, and without inheritance there is no OO: implementation concealing and polymorphism have been present in non-OO paradigms long before the OO itself.

[@CallousCoder]

I agree and that’s what I mean with business apps is simple “procure, sales and invoicing” you can object model without any obscurity. But that’s truly about it. For the rest I fully agree and I’m on the same page - OO didn’t deliver on the management promises they peddled.

[@InconspicuousChap]

@@CallousCoderI guess no paradigm would ever deliver on the corporate management's expectation because those expectations are internally controversial, to begin with. Software requires integrity, management's thought is fragmented. They want their organization units to reflect fragmentation of their minds, but still deliver something of good quality. The best way to ensure quality here is to move the management away from the process. That's why most of the best software begins in startups with no pointy-haired bosses in them and gets bought by those bosses when it reaches maturity. Or sometimes even corporations produce something decent because the managers don't try to break the team's integrity at the early stage.

[@CallousCoder]

@@InconspicuousChap you and I should get together and drink some shots because I think we’d get along great! Yeah management is politics and politics are rarely logical. And what it seems to be for me coding business apps is like trying to build a skyscraper on floating ice. This is also why I’m more into system- and embedded development “take out that human aspect” 😁 We have a saying here in The Netherlands: “there never enough time to do it right, but there’s always more than enough time to do it over.” And I literally just can of a freelance project (that was great for my profits though) where we had to move to the cloud before Nov 22nd 2022 (also a weird arbitrary date). When we started the migration (that was my task - and banking is a drama with processes, procedures, paper work!). So 2 weeks in I heard there was also a new subscription that we’d eventually needed to land on. When I looked at the services that were banking approved some crucial services we needed weren’t listed yet. So I explained the manager that if we’d wait for that it would be May, June or July and we’d never make it then. So what I propose is we go now, and me and my collesgue will burn rubber and have the perm team look over our shoulder and let them do medial tasks but then we’ll make the deadline. And then as of Nov 22nd we’ll basically do it again but then to the new subscription so then it’s just amending the CI/CD pipeline and infra as code and we’ll let the permanent team do that and I’ll be there to assist. He was like: “let me talk to upper management to see if we can get an extension of our cloud leap because this basically is doing it twice.” -“yeah you got it.” No more than 25 minutes later he called and said: “your suggestion it is, can I already book you in for another year contract? I can’t give it yet but we’ve a verbal agreement that I’ll extend on October.” So we waisted basically 500k because the wouldn’t want to extend 6 months. And probably because they knew that version 3 of the cloud platform was far from stable. Because I had arguments with my former department (CISO) that there are weird situations where I’m basically never compliant and yet the cloud team delivers it and it’s crucial to most finance apps. 🤣 Was fun to walk back after 3 years into CISO and tell them they were jack asses (in a more politically correct way) 😝 So in the end the move to version 3 took almost as long and far less needed to be done. But policies that broke stuff, policies that didn’t allow doing things we already did and were allowed on v2. Pfffff And literally the month before I left I suddenly had to implement HSM keystore because they changed requirements and policies.

[@zwanzikahatzel9296]

object orientation is not an abstraction, at all. an abstraction is a way of conceptualizing a problem so that you don't have to think about the details, for example a generic function that can add any two numbers regardless of type, or a way capturing a pattern so you can use the essence of that pattern instead repeating slightly different versions of that pattern, for example with the high order "map" function where you can generalize the idea of applying a function to each element to a collection. Object orientation doesn't do that at all, it's a frame of mind, a discipline, an imposed structure to which you have to conform to solve the problem, it's a form of regulation. it postulates that objects are a good way of organizing programs but that doesn't automatically mean objects will capture useful patterns or hide the right kind of details. The original intent is similar to strong static typing: it imposes a structure and discipline for you to follow, that forces you to solve the problem within that structure, that hopefully results in programs of higher quality. Sometimes some forms of discipline actually work to that effect: for example you can use strong stating typing to enforce certain types of correctness. But unfortunately in the case of OOP you get no benefits, it just force you into that frame of mind unnecessarily, no benefit, just a lot of extra typing and complexity and you get nothing for it. One major red flag is that OOP has no theoretical or mathematical underpinning, its just a tech fad.

[@ycombine1053]

In my 13 years of professional programming, I have never once had a problem that OOP made easier. But I've had plenty that it made harder. It doesn't remove complexity, it just scattered it to the winds and makes it impossible to reason about.

[@AllanSavolainen]

I think it can help with GUIs, though I am happy to just register event listeners and work with them. But for GUI elements OOP atleast won't make things more difficult.

[@anticipayo]

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