Rendered at 06:52:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mickeyp 18 minutes ago [-]
OOP is fine. Not using OOP is fine too if your architecture / design demands it.
What people forget -- much like the design patterns in the gang of four book -- is that languages and frameworks evolve.
A decorator pattern was a niche but useful abstraction in the 1990s. In Python today you can @decorate stuff just like that. It's evolution.
The same holds for OOP. Encapsulation and co-located methods with the encapsulating slots was an incredibly powerful upgrade over basic structs. Now most languages have first-class functions and lexical scoping so you can build your own encapsulation that way.
It's all good. Just use whatever fits best.
slopinthebag 3 minutes ago [-]
OOP hate is definitely a popular way to signal that you aren't just a "common grunt programmer". And there are personalities who have made it a big part of their appeal.
But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
jongjong 4 minutes ago [-]
Some problems don't require OOP, but most large complex problems do, IMO.
Every complex codebase I've seen which was pure Functional Programming was spaghetti code and unmaintainable.
What I saw every single time was that the project was syncing a huge amount of state in a central place and then passing it through a large number of components and sub-components. The top level component basically had to have full awareness of everything going on inside the system in order to do its job and there were no separation of responsibilities because none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.
React with Redux is probably the best FP framework I've seen thus far but even it is kind of a mess. I have nightmares about Redux Saga. I mean, even the project logo looks like a spaghetti.
A good book for appreciating the OO mindset is Object Thinking by David West.
yxhuvud 34 minutes ago [-]
> If you think you already know OOP, this article will change the way you think about programming
No, it won't. I'm especially sad that this, like so many OOP guides before it, did not go into how it interacts with data structures and bigger picture stuff. It had the perfect chance to do that as it could have made a Catalog class and then had a discussion about what belongs to that and what to the books. Instead it started to abstract on author, in the stupidest way possible (no, no one will ever look up a book using the author birth date).
fjcururuvy7 29 minutes ago [-]
The older I get the more I realize the stuff I learned in university was just plain wrong.
It's incredibly difficult now dealing with zoomers in the workplace that think I'm some old boomer that never learned "proper computer science".
No, sorry Timmy, it's not because I don't understand microservices, it's because I actually do.
Zak 17 minutes ago [-]
This seems like a beginner-level OOP-in-Python tutorial, and I'm disappointed the author didn't demonstrate a functional abstraction for `find_by`.
wolvesechoes 23 minutes ago [-]
OOP, like most stuff discussed in dev-related web, exists so that permaonline people can have another reason to create their own tribes and fight each other.
phplovesong 29 minutes ago [-]
There is good OOP, there is bad OOP, and then there is PHP(OOP).
victorbjorklund 1 hours ago [-]
Site died.
echelon 40 minutes ago [-]
OOP is perfectly fine.
Rigid class-based inheritance (especially multi-inheritance) is what sucks. This over-engineered complexity really only benefits things like window toolkits where you want super rigid modeling of widget types. But even that's a stretch.
Traits do OOP the right way. Complete flexibility.
Dog goes "woof"
Cat goes "meow"
Bird goes "tweet"
And mouse goes "squeak"
Does not need classes.
garretraziel 38 minutes ago [-]
Not sure if intentional, but I read it in Ylvis’ “What does the fox say?” and now I can’t get it out of my head, thank you very much.
dnautics 10 minutes ago [-]
Nah even traits are kinda bad because it increases the indirection necessary for code reading
OtomotO 59 minutes ago [-]
OOP exists to add a quadrillion of layers to otherwise perfectly understandable business code in an attempt to obfuscate meaning and intent and guard against malicious extraction of valuable trade secrets.
Oh, it also helps me to pay my bills, because someone has to untangle the mess.
And it helps my therapist, because he has to keep the madness that grows inside of me in check.
Jokes aside: I was taught OOP at university.
I was also taught functional programming, answer set programming and other forms such as logical programming.
Focus was definitely on OOP though.
I mainly see OOP as a way to (dis) organizer code and a way for hardware manufacturers to sell more hardware.
What people forget -- much like the design patterns in the gang of four book -- is that languages and frameworks evolve.
A decorator pattern was a niche but useful abstraction in the 1990s. In Python today you can @decorate stuff just like that. It's evolution.
The same holds for OOP. Encapsulation and co-located methods with the encapsulating slots was an incredibly powerful upgrade over basic structs. Now most languages have first-class functions and lexical scoping so you can build your own encapsulation that way.
It's all good. Just use whatever fits best.
But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
Every complex codebase I've seen which was pure Functional Programming was spaghetti code and unmaintainable.
What I saw every single time was that the project was syncing a huge amount of state in a central place and then passing it through a large number of components and sub-components. The top level component basically had to have full awareness of everything going on inside the system in order to do its job and there were no separation of responsibilities because none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.
React with Redux is probably the best FP framework I've seen thus far but even it is kind of a mess. I have nightmares about Redux Saga. I mean, even the project logo looks like a spaghetti.
The "behaviours" being modelled here were data access. Writing .name() instead of .name.
You can save yourself the time of manually packing these structs by writing out a constructor in full. Which the article called "automatic".
(You don't even need to write out the constructor for a struct in C99. Probably any other modern language too)
No, it won't. I'm especially sad that this, like so many OOP guides before it, did not go into how it interacts with data structures and bigger picture stuff. It had the perfect chance to do that as it could have made a Catalog class and then had a discussion about what belongs to that and what to the books. Instead it started to abstract on author, in the stupidest way possible (no, no one will ever look up a book using the author birth date).
It's incredibly difficult now dealing with zoomers in the workplace that think I'm some old boomer that never learned "proper computer science".
No, sorry Timmy, it's not because I don't understand microservices, it's because I actually do.
Rigid class-based inheritance (especially multi-inheritance) is what sucks. This over-engineered complexity really only benefits things like window toolkits where you want super rigid modeling of widget types. But even that's a stretch.
Traits do OOP the right way. Complete flexibility.
Does not need classes.Oh, it also helps me to pay my bills, because someone has to untangle the mess.
And it helps my therapist, because he has to keep the madness that grows inside of me in check.
Jokes aside: I was taught OOP at university.
I was also taught functional programming, answer set programming and other forms such as logical programming.
Focus was definitely on OOP though.
I mainly see OOP as a way to (dis) organizer code and a way for hardware manufacturers to sell more hardware.