Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
The fact that you've been using a screwdriver as a hammer your entire life doesn't bother you?
OOP, procedural, functional...these are paradigms of application architecture and not even the only three.
Your story tells me one thing, you sound like a decent developer but you're a shit architect.
I say this every time I see posts like this.
Use the right tool for the right job. Stop trying to force languages and architecture into solutions that repel against the other.
OOP is not necessarily about modeling reality. Most teachers will teach it as if it was though, and it’s part of the issue.
That ball example is just bullshit.
Next issue is that everyone seems to think that you either do OOP or FP (or something else).
IMO, you can and you should use both! Use it where it fits best. Mix and match.
Yeah I'm the opposite.
I started my career not giving a damn about OOP
Until my first job where fixing one bug caused multiple bugs somewhere else.
Then I bought into the idea of single responsibility, separation of concerns and learned how to accomplish that with some patterns (definitely not all GoF though)
Modern tooling takes away a lot of that boilerplate and it for sure is a lot easier to do OOP. (rename, extrapolate function/class etc)
Sure beats the text search that I do now at my current python job
I thought the most important advantage of OOP was SOLID. As in, it allows really large teams of developers work on really large pieces of software efficiently, in addition to making the codebase organized and easily extendable / modifiable.
What was that book... The mythical man month. That kind of explains the reasoning behind the explosion of OOP, in parallel with big tech. As in why a paradigm that allows large number of programmers work in tandem efficiently would be considered the holy grail as the size of codebases grew exponentially.
Didn't gcc struggle with abstractions and found themselves writing OOP in C? Which is what finally prompted them to rewrite it in C++?
I find objects to be a very natural way of subdividing global space and restricting access. Basically you only get access on a need to know basis. I also find immutability to be a great way to keep oneself from doing stupid things.
@sariel you're the exact kind of fool I expected to get when writing this post. I've talked to hundreds of people like you. Starting the conversation off with a given that is not true.
Let me ask you this, did the entire industry of programmers that had no use of OOP and made working solutions to problem really give a fuck about what you thought is a hammer or a screwdriver? OOP is less a screwdriver and more like a kazoo. Many solutions also exist to this day that run things you wouldn't even understand on languages like C, that are core to the world even functioning. Not a piece of OOP in sight.
@Lensflare I'm not against using and learning multiple methodologies I hope the story I shared shows I have taken the time to do that.
However, I have never been in an environment where OOP has made me either enjoy my work more or be more productive. There's good and bad code for all paradigms, and good procedural is imo by far the easiest to work with.
I find John Carmack said it best. "Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework." He is probably referring to functional programming but it works for procedural too. Imo the thing the industry needs is a call to brevity and simplicity rather than over abstraction. Over abstraction makes maintenance harder as does over complication.
OOP is actually good if the problem domain already has objects in the sense of OOP - like GUI programming or simulations.
But when you drown in these nebulous permutations of manager controller factory handler foo, with no relation to the actual problem domain, you know that OOP is a bad fit.
Also, Alan Kay didn't have glorified structs in mind when he coined the term OOP. Instead, it was about actors passing messages around as their only way of interfacing.
@progresshuh I was wrong.
You're a shitty developer too.
You completely missed my point. You spent years building an object oriented solution that didn't work. You knew it wasn't the solution and yet you still continued to use OOP.
Call it whatever you want, you're not going to trigger me. The only thing that triggers me are pretentious developers who hate using tools because they don't understand how to use them.
@sariel projecting much, I smell a lot of pretension but it's not from my own posts but yours.
The object oriented project was due to the platform the client chose, I just agreed to do it for him at his asking. The modifications I did using the platform, custom plugins I did, and suiting it to his business needs were the project. 98% of the codebase was not my doing, it was done likely by people who think much like you do.
As far as being a shitty developer, my clients will disagree. You don't stay in business by yourself for 12+ years with clients that you have had for 9+ sticking with you by delivering bad work. I've had clients personally tell me my work for them has saved their own businesses and changed the way they do business for the better.
Come back when you can handle a difference of opinion maturely, when I called you a fool it wasn't an insult, it was an observation.
I wanted to bring some balance to this thread. I mean it's an interesting discussion to have because the Internet generally doesn't like OOP haha
The top comment is by Eric Lippert. He was a main C# guy at Microsoft.
But I still like OOP because it's an art. You can write code like proses. Making it easy to understand and read. And I'm dumb so I actually like that inflexibility which prevents me from making mistakes. Or at least limits me from making more mistakes.
Given that most OOP programmers don't understand the most basic rule of OOP.
Classes don't model objects (real or otherwise), concepts of anything like that.
They enforce invariants.
And the fact that they miss this cornerstone bleeds into terrible usage of inheritance (of which 95% give or take is fundamentally wrong), as they don't realize their inheritance chains break the invariants of the base classes.
This is what leads to the clusterfuck of factories, and whatnot, trying to shoehorn inheritance chains just so you can do ArrayList<Base>.
That being said, OOP has its place when it fits the problem, and knowing it is, like everything else, another tool in your belt, which in turn can make you more versatile and productive.
@Demolishun I haven't heard that story, but I've heard of John Carmack pushing back against Oculus team members, Linus Torvalds having to push back heavily against OOP for linux kernals, a domain it has NO business being in. It sounds like to me they got some developers on board that simply weren't comfortable without OOP.
One argument people like to try to make is OOP helps with big projects. The linux kernel is over 8 million lines of code though and more solid than most software ever will be today. Entirely in C. And I'm fairly certain they aren't trying to make OOP happen in C.
@Fast-Nop @progresshuh Oh, we don't try to make that argument. We do make that argument.
Linux Kernel is Linus' pet project. You won't see any "juniors" contributing to it. They get chewed up and spit out real quick. In addition, and much more importantly, it is not a project trying to make money within a constrained timeframe.
Commercial projects with deadlines have to contend with juniors and deliver value, quickly. OOP makes that happen, so here we are.
Read The Mythical Man Month.
@iceb Polymorphism is kind of hated even by OOP enthusiasts at this point isn't it? Strange he'd list that as a unique benefit.
I'd also say it's been wildly popular rather than wildly successful. That it's been successful would mean defining what it was trying to achieve. In my view that should be less complex programs with better run time that uses fewer resources and better developer productivity. I frequently see it fail on if not one then all three of those metrics.
@hardCoding I'll check out the book but there's already been studies finding programming paradigm have little to nothing to do with productivity. Being someone that has experienced it making me far less productive, I'm not about to be moved by one guys book. A large scale scientific study maybe that controls for various parameters like what is commonly taught in schools. That'd be convincing.
The closest I've seen was a study that measured different times to complete an app using different languages. C came out high on lines of code per hour iirc as well as project completion time. Wish I could link it but I can't find the reddit post that linked it.
I think you're making assumptions on a lot of variables. Assumptions which I'm both skeptical of and are contrary to personal experiences.
@progresshuh I think polymorphism is amazing. But only if you keep the layers minimum (I think 3 should be max)
making programs small is a different problem altogether. I too, think small apps/programs that are reliable should be the way to go. But who gets paid for that these days.
In a way microservices is also a way to do OOP. Instead of taking the object modeling at code level. It brings it up at a service level. Who knows if we'll see microservices factory one day haha.
@progresshuh I found this blurb (I am sure there are others):
It does not mention oop, just some abstractions would be cleaner in C++. What shocked me is that I went and looked at the codebase and main is wrapped in a class. It has a comment for the reason, but I expected main to be more C like.
@hardCoding There is no evidence to support that claim. In particular because OOP doesn't scale.
Each object should only deal with its parent and its children. If you find out you need an interface to another part of the tree (e.g. because of requirement changes), you need to pass shit up until a common parent, then pass it down again.
Nobody has time for that in practice because the larger your system is, the more work the clean way means until you spend all day refactoring shit. So they short-cut across the tree.
The result: the usual OOP spaghetti, and everything about reuse and stuff goes out of the window. The banana, the gorilla and the whole jungle, that's where this comes from.
The problem is few people started with realistic examples, so everyone got a distorted idea about OOP. It was never about "modeling" per se, it's actually just a code packaging/organizational scheme.
If you have a bank account, it likely needs certain things: a balance, ways to add and subtract from the balance. A checking account has those things too, but then it also has maybe a number of available checks, or daily withdrawal limit.
From that, OOP tells us we'd make an Account base class and a CheckingAccount class that extends it. That makes sense, and you can quickly see the benefit of it: the properties and methods common to all types of accounts go in the base class, those for a specific type of account go in the subclass. It makes sense at the source code level too: likely two source files, one referencing the other.
If schools started with examples like that instead of some abstract geometry garbage, I bet people today would have a better take on OOP.
@progresshuh don't misconstrue arrogance for experience.
OOP is not the silver bullet. Neither is functional or procedural.
I don't know why people hate one paradigm over another. By refusing OOP you're limiting the solutions you can provide to your customers.
It would be like taking your car to get new tires and the shop refusing to give you an oil change. It's far more profitable to provide the oil change while the car is "in the shop" than letting your competition up the street eat into your margins.
Am I pretentious? Absofuckinglutely! Am I wrong in calling out your primitive opinion of OOP? I don't think so.
Since you have likely went out of your way to avoid OOP in your career, I don't think you are a good unbiased source of information, so I think I'll take your musings with a truckload of salt.
neriald12992dI started work with C. I loved it, worked with it for 5 years. I could close my eyes and see each branch each call happening, whole program was mapped to my mind.
Then I moved to another company, working with C++ now. It was really hard at the beginning but I’m lucky that codebase is properly architected. It is a big project similar to my previous work. Eventually I understood why cpp/OOP is so backwards. Because it allows you to extend APIs without breaking backwards compatibility thanks to interfaces, it allows you to mock them and unit test them much better than you could with a procedural language.
As others keep saying, OOP isn’t a magical bullet, it has its place and it’s above procedural languages because it can do everything procedural can do and more.
Oh and I can still close my eyes and whole program still appears in my mind, it looks fragmented but just the same nonetheless.
Also you mentioned strict typing and thats bad? Wtf?
@Fast-Nop Question regarding architecture. Wouldn't architectural rot happen in other paradigms too (Is there another one outside of FP)
Also, I think it might be a good thing to have an architecture that skews the app to do things a certain way.
Otherwise everyone wants their app to do everything. And all of us are just building the same thing in a hundred different ways (Which is a pet peeve of mine)
@iceb Ofc the same can happen in other paradigms as well - the point was that there is no evidence that OOP does considerably better.
Btw., there's still procedural in widespread use, mainly because it's the closest match to how computers actually work. That's why it runs on the smallest chips so that the product BOM can be reduced.
@sariel A child avoids touching fire when it burns them. I don't think that's any reason to say you shouldn't believe them touching fire is bad.
I have had my fair share of burnings from OOP architecture. Far too many. My dislike is not from some armchair but from experience. Just because I choose to code on my own without OOP when I can doesn't mean I haven't had it be part of almost every project I have had to do for clients, if it's not somehow part of the CMS or ecommerce store it's in one of its libraries. If I didn't know how to code with it I'd not be able to deliver things to clients.
That does not mean I like it or have seen one iota of benefit from it in any paradigm. What I have seen is over engineering to the detriment of many a library/cms.
The amount of assumptions you make in such little time is what makes me take your posts with a grain of salt. You think something that makes you feel superior and then put it in post without any interest in validity.
I am actually eating popcorn right now. It is not just an expression.
@progresshuh Oooh I think I see what it is now. You have been working by yourself for a very long time.
----- on a second read through. I guess I just got that impression don't know if it's actually true----
You know what you have done, you know what each thing do and how they relate. And most importantly. You think like yourself.
I mean in that case it's really whatever floats your boat.
But when we work with other people, OOP provides a way for everyone to work together.
okay. I define these interface. I'll work on the code that deals with them and you make the implementation. And if it sucks I can just replace it with something else. (for example)
@iceb Why do people encapsulate factories with classes hidden in a cpp file? (if you know C++) This makes it so the code can never be reused for another purpose. I have run into code like that in our system. I see one benefit, and that is you can't screw with it easily. But it still ends up being a walled garden.
Edit: Also, the example I am thinking of, has no methods for even seeing the data. It just is completely self contained.
Edit: I guess factory is the wrong word for this.
Interfaces are not an exclusively OOP construct. They are a contract.
Which can be expressed in many ways, inheritance being just one of them.
Then again, kinda pr9ves my point that no one mentions invariants.
Classes, and objects, enforce invariants.
That's their benefit, that's what they provide.
You can define interfaces in C, but have no language support to *enforce* them.
@iceb I've worked alone a lot, but it's not like I never worked on teams. First college group project I was the lead, it was all procedural and it was used and liked by the medical department at our college.
The first job I had out of college was a 3 developer team, procedural based but also had to integrate with a ton of other systems. I thrived in that environment to be honest.
I think organization is very made up. There is no way to organize that is actually better from group t group. What works for one group might not for another.
A lot of hiring these days is very based on "culture fit". Bootcamps exist to train the uneducated to think like a companies existing infrastructure and fit as a cog in a wheel, ready to go, without dissent.
I guess this is one way to get people to work together better. I would not be one to say it's a very good one though. If everyone is on the same page and beliefs you work together better. It doesn't make those beliefs sound though.
The number one problem with OOP for me is the overuse of inheritance.
When I realized that, I started to utilize composition over inheritance.
But I can’t avoid inheritance entirely because it’s everywhere. Even in the standard libs.
I don’t mean that it should be banned but it should be avoided in the vast majority of cases.
@neriald there was a point in time dynamic typing was seen as a benefit of interpreted languages. In my view it still is.
Introducing strict typing to an interpreted already dynamic language is a misuse of the language, you should pick something else. Something where typing is already strict.
People think it matters for code stability and so on but they are just uncomfortable. It only matters if you want exact control over memory.
As for the seeing branches of code thing I can only think you're talking about Linus statement on OOP while at the same time misunderstanding it. OOP will have unexpected behaviors on the hardware level, something that is terrible for something like a kernel.
OOP being able to do anything procedural can do and more though is just wrong. C++ converts OOP class method for example to a function with prepended names, it converts to procedural just ugly versions of it. You aren't doing anything in OOP unique, unless you count wasting cpu cycles.
neriald12992d@progresshuh you are not wrong about strict types in interpreted language(I missed interpreted part earlier) since it doesn’t have compilation/static analysis steps.
Strict types do bring stability, lotsa runtime errors are avoided thanks to strict types. Memory is usually cheap these days but yeah that’s still a plus if you want your integers shorter.
I don’t jerk of to Linus like you guys do so I have no idea of his statements other than famous “fuck you nvidia”. However, OOP runs just like procedural code and it always does the same things, nothing unexpected can happen there if you know what happens under the hood.
Just an example, with OOP, in tests I can mock classes and make them return what I want so that I can test all branches in code. Your turn to find an example of what procedural can do that OOP can’t.
Yes, in some way methods are functions with defined accessors, your point? Plus my cpu cycles are wasted during compilation step, no harm there.
The answer: use OOP only as needed. Just because we are all apes and mammals and vertebrate, there is no need for your Human class to extend all the way to the a class of common animal kingdom. Yeah, using real world as example is stupid. Should we extend all the way to our microbe ancestors?
If your app only deals with car, the top most parent class should simply be 'Car'. There is no need for 'Vehicle' class.
@Lensflare in this I agree, inheritance is very powerful when used right but can very easily spiral out of hand unless you really know why you use it
In my experience, a big bonus with OOP is the encapsulation. Yes it locks things in and locks things down BUT that mean that I often do not need to know what is behind the interface and I also often should not know since its the responsibility of another team.
Yes, if I do know all the code I can build more efficient code and use short cuts but such code requires much more knowledge to work with meaning new people will take more time to get productive.
And that is one reason OOP became so big, junior devs could much easier reuse objects created by others to create new functionality without having to know exactly what was going on under the hood, and the owners of the object could change the internals at any time as long as the contract stayed the same.
Yes you can achieve the same with FP and Procedural but its usually not a built in property of the language but something the team have to enforce, and that requires much more experienced developers.
And for the linux kernel, juniors are probably not encouraged to work with that anyway ;)
So OOP is more of a way to handle big, diverse developer teams, and I am not talking 12-20, but rather hundreds of devs poking around in the same code base.
In that case you really do want to prevent devs from bypassing the defined way, since many times they will not know the whole picture.
Yes, often the resulting code can be less efficient but the alternative is that many programs would never be built without OOP since there still is not enough good devs for what the world needs.
Oop is a way to get more devs to be able to work on big programs.
At least that is in my opinion one of the big drivers behind the popularity of OOP.
Once developers get better you will see more and more functional behind those interfaces :)
@neriald In dynamically typed interpreted languages you're left to do as little or as much type checking as you want. Making people do strict typing for everything to avoid a programmer not doing their job properly is throwing the baby out with the bathwater.
If you have unexpected input you can typecast, if you are checking for errant data there's utility functions. For data you fully expect, there is often not much need for this. Does that leave room for a bug to pop up? Sure. But painting your entire program with strict typing to avoid a bug like that is overkill and misuse of the language.
The number of errors I have had where types are an issue are few and far between, and usually very easy to fix.
Static typing is great for memory management. It's a bad crutch for trying to write less buggy code.
I only mentioned Linus cuz of prior posts and your topic seemed to come up out of the blue.
Testing can be done to mock function calls too.
Hazarth73761dSometimes I think different programming paradigms are made for people, so we can pick and choose the one that is the easiest for us to work with and imagine and there is no way to objectively compare them, because in the end the only thing that really matters is if you can make the project happen or not.
I love procedural, functional and OOP. Really whatever I come across, as long as I can code in it, it's fun. And I use all of them in separate contexts depending on the thing that I'm building. You know you did good, when you just inherently can look at the code and immediately understand what's going on. It's a rare thing, but I've seen projects on GitHub do it, and it always makes me happy when reading the code and knowing some of the domain stuff leads to me understanding the code.
The only code that still confuses me is TypeScript... I hate the nesting xD
Voxera113615h@progresshuh I am of the complete opposite opinion.
Strict typing save do much hazel and maybe more importantly allows the compiler to make performance optimizations that can in done cases give you 2-3 times better performance for the same code done with dynamic types since every time you move data the compiler/interpreter of a dynamically typed language will need to do a lot if tests and check if casting is done.
So even if you do not need it for security, the performance sacrifice is in my opinion not worth it.
You are correct. Qt has been adding type hints to their QML JS flavor. This is going to potentially give them a 4x speedup due to being able to have type info in JS (among other things):
There is a link in that article that shows the things they have tried to get speedups.