Yeah, I wish C++ had function/scope epilogs and labeled loops/breaks, too. Those are the cases where the “never use goto” rule can be broken to make better code than adding all of the code that would be required to handle it the “right” way (setting up early exit flags and if statements after each level of nested loop to check the flag).
Yep. I’m old, cranky, and prone to broad statements to get reactions.
That said, for any of you all that love inheritance, I’m judging you so hard. So hard. Very judged. I probably hate your code, and your friends’ code, and your last teacher’s code. Especially your last teacher’s code.
Excuse me if I don’t appreciate when the compiler adamantly refuses to do its job when there’s one single unused variable in the code, when it could simply ignore that variable and warn me instead.
I also don’t enjoy having to format datetime using what’s probably the most reinventing-the-wheel-y and most weirdly US-centric formatting schemes I have ever seen any programming language build into itself.
I used to think I was just a fanboy. But as time went on and I gained more and more experiences, I’ve only become all the more sure that ANSI C is the only language I ever want to write anything in.
Those are nice. Services that manage data are an example. Having the class also declare how to interact with the data is nice.
My most OOP pattern I like using is implementing an interface with an abstract class for “standard” implementation. Then implement abstract methods for a concrete thing.
Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.
I like polymorphism. Having to have a hundred differently named functions or structs or something that do the same thing but slightly differently in Rust is annoying as hell. Especially with all the underscores you have to type… If Rust were more functional though it’d make that problem go away pretty quickly.
Inheritance makes complicated objects that would otherwise be impossible possible, but it only works if you know those objects really well. The problem is people write ridiculously complicated mystery objects in libraries and no one knows what’s going on anymore.
Springboot is very confusing. The inheritance tree is insane, they created a class for everything, which I get… But it is so hard to understand the whole scope their design.
Inheritance starts to suck > 1 level deep.
Multiple inheritance starts to suck at the point people discuss adding it to a language, or a few femtoseconds after the big bang, whichever comes first.
I completely agree. I taught JS/TS for 5yrs and I always emphasised that the ‘class’ keyword was just syntactic sugar for what was already available in prototype inheritance of JS.
Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.
JS Objects aren’t typically used that way, they tend to be used as pure data containers. At least, that’s how we mostly use them.
Occasionally, we’ll use objects to simplify passing multiple arguments including arrow functions, but I’d say that doesn’t really count unless the arrow function mutates the object it’s a part of.
Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.
You’re referring to one subtype of OOP. That may be what most people mean when they say OOP, but that doesn’t make it correct. Object-oriented programming is programming with objects, which does not require inheritance or classes.
And maybe you have some functions that interact with them but don’t keep them super public so they’re only used by specific modules/store/redux thingy?
Anyone who praises FP is either a student, works primarily in academia, or otherwise never had to look at a deep stack trace in their life.
Every time a production system spits out a backtrace that’s just 15 event loop calls into a random callback, I lose 6 months life expectancy. Then I go look at the source, and the “go to definition” of my LSP never works because WHY WOULD IT, IT’S ALL FUNCTIONAL hapi.register CALLS
I hate it I hate it I hate it I hate it. I support UBI because the people pushing functional programming in real production systems should be reassigned to gardening duties.
I have the same problem with oop. 10 levels of encapsulated calls just to see you were in an overridden methods without enough data to find out which implementation it was. Ugh
I mean, bad programming sucks regardless of the “paradigm” (and vice-versa, mostly). But as someone whose job it often is to sift through production logs hunting for an issue in someone else’s component, at least I have a chance with OOP, because its behavior is normally predictable at compile time. So with the source and the backtrace I can pretty reasonably map the code path, even if the spaghetti is 300 calls deep.
Now where shit really hits the fan is OOP with dependency injection. Now I’m back to square 1 grepping through 15 libraries because my LSP has no idea where the member comes from. Ugh.
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing - is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil - objects are merely a poor man’s closures.”
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.
Can someone please enlighten me on what makes inheritance, polymorphism, an operator overloading so bad? I use the all regularly, and have yet to experience the foot cannons I have heard so much about.
Operator overloading is adding complexity, making code subtly harder to read.
The most important lesson for code is: It should primarily be written to be easy to read by humans because if code is not trash, it will be read way more often than written.
I would argue that there are very definitely cases where operator overloading can make code more clear: Specifically when you are working with some custom data type for which different mathematical operations are well defined.
I am very fond of the idea of “stateless” code, which may seem strange coming from a person that likes OOP. When I say “stateless”, I am really referring to the fact that no class method should ever have any side-effect. Either it is an explicit set method, or it shouldn’t affect the output from other methods of the object. Objects should be used as convenient ways of storing/manipulating data in predictable/readable ways.
I’ve seen way too much code where a class has methods which will only work"as expected" if certain other methods have been called first.
If the only tool you have is a hammer, everything looks like a nail.
That’s the only thing I can think to answer your question. There are some problems that are best solved with other tools, like text parsing for example you might want to call out to some code written in a functional language.
Oh, thanks then! I’ve heard people shred on OOP regularly, saying that it’s full of foot-canons, and while I’ve never understood where they’re coming from, I definitely agree that there are tasks that are best solved with a functional approach.
I don’t think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let’s add encapsulation and implementation hiding to this list.
The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore
It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.
Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it’s the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.
A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.
In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object’s private members, or data processing for that object and its immediate children or peers.
Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.
Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…
Indeed, I’d say an algorithm split among different objects is usually an indication of tightly coupled code. Every code pattern has its pitfalls for inexperienced devs, and I think tight coupling is OOP’s biggest.
I don’t really think it’s any of those things in particular. I think the problem is there are quite a few programmers who use OOP, especially in Java circles, who think they’re writing good code because they can name all the design patterns they’re using. It turns out patterns like Factory, Model View Controller, Dependency Injection etc., are actually really niche, rarely useful, and generally overcomplicate an application, but there is a subset of programmers who shoehorn them everywhere. I’d expect the same would be said about functional programming if it were the dominant paradigm, but barely anyone writes large applications in functional languages and thus sane programmers don’t usually come in contact with design pattern fetishists in that space.
Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.
I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like generatorFactoryServiceCreatorFactory because the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.
This makes sense to me, thanks! I primarily use Python, C++ and some Fortran, so my typical programs / libraries aren’t really “pure” OOP in that sense.
What I write is mostly various mathematical models, so as a rule of thumb, I’ll write a class to represent some model, which holds the model parameters and methods to operate on them. If I write generic functions (root solver, integration algorithm, etc.) those won’t be classes, because why would they be?
It sounds to me like the issue here arises more from an “everything is a nail” type of problem than anything else.
You will still have private/public sections, interfaces (unless you class them as inheritance), classes and instances, the SOLID principles, composition over inheritance. OOP is a lot more than just large family trees of inheritance, a way of thinking that’s been moved away from for a long time.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
C++ classes are fairly optional but if you’re already using cpp then it likely wasn’t your choice and neither will the choice of OOP.
Yeah, I like the sweet spot that C++ is in. It can do anything C can but then you have classes and STL and all that on top of it.
once i learned about defer it became a hard requirement. cpp kinda gives me that but other c like languages do it better.
Yeah, I wish C++ had function/scope epilogs and labeled loops/breaks, too. Those are the cases where the “never use goto” rule can be broken to make better code than adding all of the code that would be required to handle it the “right” way (setting up early exit flags and if statements after each level of nested loop to check the flag).
Interfaces are great.
Inheritance is often a sign that the previous developer didn’t understand interfaces.
Broad generic claims like that tell me more
Yep. I’m old, cranky, and prone to broad statements to get reactions.
That said, for any of you all that love inheritance, I’m judging you so hard. So hard. Very judged. I probably hate your code, and your friends’ code, and your last teacher’s code. Especially your last teacher’s code.
Prefer composition over inheritance. Though that doesn’t mean inheritance has no place in programming.
Just use C
It’s called Go
You spelled Elixir wrong.
Excuse me if I don’t appreciate when the compiler adamantly refuses to do its job when there’s one single unused variable in the code, when it could simply ignore that variable and warn me instead.
I also don’t enjoy having to format datetime using what’s probably the most reinventing-the-wheel-y and most weirdly US-centric formatting schemes I have ever seen any programming language build into itself.
I used to think I was just a fanboy. But as time went on and I gained more and more experiences, I’ve only become all the more sure that ANSI C is the only language I ever want to write anything in.
I was the same, but I recently gave zig a try, it’s lovely to write.
Managed to segfault the compiler though, so maybe not quite ready yet.
Using classes is nice tbh. Using inheritance usually isn’t. Inheriting from inherited class should be forbidden.
so an interface with state?
Those are nice. Services that manage data are an example. Having the class also declare how to interact with the data is nice.
My most OOP pattern I like using is implementing an interface with an abstract class for “standard” implementation. Then implement abstract methods for a concrete thing.
Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.
Polymorphism just goes over my head.
It’s not that hard however I think it’s absolutely useless and doesn’t add any value to the code.
I like polymorphism. Having to have a hundred differently named functions or structs or something that do the same thing but slightly differently in Rust is annoying as hell. Especially with all the underscores you have to type… If Rust were more functional though it’d make that problem go away pretty quickly.
Inheritance makes complicated objects that would otherwise be impossible possible, but it only works if you know those objects really well. The problem is people write ridiculously complicated mystery objects in libraries and no one knows what’s going on anymore.
Springboot is very confusing. The inheritance tree is insane, they created a class for everything, which I get… But it is so hard to understand the whole scope their design.
Tho, C# is statically typed so you can look at the available methods any one library has at any time in the IDE
that, and that its often not the best use of time to map out the entire project structure in uml before u even write a method…
Objects are fine.
OOP sucks.
Inheritance starts to suck > 1 level deep. Multiple inheritance starts to suck at the point people discuss adding it to a language, or a few femtoseconds after the big bang, whichever comes first.
This has bell curve meme vibes. I’m just not sure what the middle guy would be saying.
It would say PrototypeFilterStubFacadeBridgeDecoratorTaskRequestMapEventExporterInfoModelRequestIterator
He died of XML factory injection pattern exposure.
If only he had a briefcase of XSLTs to make sure the XML was safe first.
“I hate inheritance! I hate inheritance! I hate inheritance! I hate inheritance!”
But well, inheritance goes brrrrrr.
We all get disappointed when we don’t inherit anything useful…just a garage full of confusion
deleted by creator
Uh… from Caml? Because OCaml’s object support is the least surprising part of the language.
modules >>> classes, anyway.
I haven’t used TypeScript in a classically OOP way and it never felt like I was being urged to do so either.
It becomes quite OOP if you use it with React
Huh? I’ve worked with TypeScript + React for the last 5yrs and the only time I see OOP is when someone’s done something wrong.
Maybe you’re thinking of old react with class based components?
Proving that adding the
classkeyword to the ECMAScript spec was a mistake that leads folks down a path they should not travel 🙃I completely agree. I taught JS/TS for 5yrs and I always emphasised that the ‘class’ keyword was just syntactic sugar for what was already available in prototype inheritance of JS.
I’ve worked on projects with 10 000+ lines of typescript and maybe 3 classes total.
But you have used objects I think.
Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.
JS Objects aren’t typically used that way, they tend to be used as pure data containers. At least, that’s how we mostly use them.
Occasionally, we’ll use objects to simplify passing multiple arguments including arrow functions, but I’d say that doesn’t really count unless the arrow function mutates the object it’s a part of.
You’re referring to one subtype of OOP. That may be what most people mean when they say OOP, but that doesn’t make it correct. Object-oriented programming is programming with objects, which does not require inheritance or classes.
With such a broad definition you could call even Haskell an oop language
So you’re arguing that “Object oriented” shouldn’t apply to languages that are oriented around objects?
And maybe you have some functions that interact with them but don’t keep them super public so they’re only used by specific modules/store/redux thingy?
Why Isn’t Functional Programming the Norm? – Richard Feldman
Anyone who praises FP is either a student, works primarily in academia, or otherwise never had to look at a deep stack trace in their life.
Every time a production system spits out a backtrace that’s just 15 event loop calls into a random callback, I lose 6 months life expectancy. Then I go look at the source, and the “go to definition” of my LSP never works because WHY WOULD IT, IT’S ALL FUNCTIONAL
hapi.registerCALLSI hate it I hate it I hate it I hate it. I support UBI because the people pushing functional programming in real production systems should be reassigned to gardening duties.
I’m not advocating one way or the other, but I would gladly take on the gardening duties :D
I have the same problem with oop. 10 levels of encapsulated calls just to see you were in an overridden methods without enough data to find out which implementation it was. Ugh
I mean, bad programming sucks regardless of the “paradigm” (and vice-versa, mostly). But as someone whose job it often is to sift through production logs hunting for an issue in someone else’s component, at least I have a chance with OOP, because its behavior is normally predictable at compile time. So with the source and the backtrace I can pretty reasonably map the code path, even if the spaghetti is 300 calls deep.
Now where shit really hits the fan is OOP with dependency injection. Now I’m back to square 1 grepping through 15 libraries because my LSP has no idea where the member comes from. Ugh.
deleted by creator
deleted by creator
Can someone please enlighten me on what makes inheritance, polymorphism, an operator overloading so bad? I use the all regularly, and have yet to experience the foot cannons I have heard so much about.
Nothing, just use a good tool for the job, whatever that job requires.
Operator overloading is adding complexity, making code subtly harder to read. The most important lesson for code is: It should primarily be written to be easy to read by humans because if code is not trash, it will be read way more often than written.
I would argue that there are very definitely cases where operator overloading can make code more clear: Specifically when you are working with some custom data type for which different mathematical operations are well defined.
Yeah, that’s a very useful exception.
Having to run a debugger to know what gets called at a given time is awful, and this oop practices exacerbate this
I am very fond of the idea of “stateless” code, which may seem strange coming from a person that likes OOP. When I say “stateless”, I am really referring to the fact that no class method should ever have any side-effect. Either it is an explicit
setmethod, or it shouldn’t affect the output from other methods of the object. Objects should be used as convenient ways of storing/manipulating data in predictable/readable ways.I’ve seen way too much code where a class has methods which will only work"as expected" if certain other methods have been called first.
If the only tool you have is a hammer, everything looks like a nail.
That’s the only thing I can think to answer your question. There are some problems that are best solved with other tools, like text parsing for example you might want to call out to some code written in a functional language.
Oh, thanks then! I’ve heard people shred on OOP regularly, saying that it’s full of foot-canons, and while I’ve never understood where they’re coming from, I definitely agree that there are tasks that are best solved with a functional approach.
I don’t think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let’s add encapsulation and implementation hiding to this list.
The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore
Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it’s the function that walks the object structure. The navigation is done using tools like
applyormaprather than a loop in a method on the parent instance.A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.
In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object’s private members, or data processing for that object and its immediate children or peers.
Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.
Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…
Indeed, I’d say an algorithm split among different objects is usually an indication of tightly coupled code. Every code pattern has its pitfalls for inexperienced devs, and I think tight coupling is OOP’s biggest.
I don’t really think it’s any of those things in particular. I think the problem is there are quite a few programmers who use OOP, especially in Java circles, who think they’re writing good code because they can name all the design patterns they’re using. It turns out patterns like Factory, Model View Controller, Dependency Injection etc., are actually really niche, rarely useful, and generally overcomplicate an application, but there is a subset of programmers who shoehorn them everywhere. I’d expect the same would be said about functional programming if it were the dominant paradigm, but barely anyone writes large applications in functional languages and thus sane programmers don’t usually come in contact with design pattern fetishists in that space.
Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.
I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like
generatorFactoryServiceCreatorFactorybecause the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.This makes sense to me, thanks! I primarily use Python, C++ and some Fortran, so my typical programs / libraries aren’t really “pure” OOP in that sense.
What I write is mostly various mathematical models, so as a rule of thumb, I’ll write a class to represent some model, which holds the model parameters and methods to operate on them. If I write generic functions (root solver, integration algorithm, etc.) those won’t be classes, because why would they be?
It sounds to me like the issue here arises more from an “everything is a nail” type of problem than anything else.
deleted by creator
you can write oop without inhetitance
There’s the camp of those who say that inheritance is synonymous with OOP. I’m not in that camp, but I’d like to see you duke it out with them.
That’s just structs and unions right?
You will still have private/public sections, interfaces (unless you class them as inheritance), classes and instances, the SOLID principles, composition over inheritance. OOP is a lot more than just large family trees of inheritance, a way of thinking that’s been moved away from for a long time.
I learnt Caml in the 90s at university, I was completely lost, in Prolog too.