to the guys saying "oop is dumb" / "i don't need oop" / "i've never worked with oop"...

i have some questions:
- which language are you working with
- which problems are you solving
- how big is your code base
- how do you maintain readability of your code?

don't get me wrong, i don't believe that oop is always the answer. i'm just curious which fields these statements are coming from. if they all come from a low level (assembler, C, ..) or functional languages or "scripty" languages (python, JS), or if there are also people working with languages like C++ where oop is pretty much established. and if the latter, i'm curious how people design their code and what problems they solve... tell me your story :D

XY: We need OOP in DTOs.

Me: That,'s not the purpose of a DTO, neither is it a good idea... A DTO shall provide data in it's simplest form, as public variables and be done with it.

XY: No. We need to use OOP.

One year later, we migrated back as the clusterfuck of having DTOs which try to use polymorphism / composition / ... lead to an unbearable mess.

I wasn't the only one who was vehemently against this... But "OOP great, OOP must be used" team.

Such experiences lead to a bad rep of OOP.

Just because some people read some books / watched some vids / read ShitOverflow and try to violently shove OOP in a zealous manner into everything, OOP has a bad rep.

I think OOP is dumb. Especially in the hand of dumb devs. Even more in the hand of dumb devs who don't like thinking, instead they'll just act without caring for consequences.

OOP done right / intelligent is careful evaluation if it's needed, it makes sense and brings a long term value.

;)

DTO example was just as one explanation, I could bring up more (e.g. the diamond problem, when devs try to overabstract / overgeneralize without purpose)...

@IntrusionCM so people use "OOP" as a synonym for "software patterns, poorly applied"? i mean, the DTO itself is an oop software pattern already, even as a simple data structure with public members with primitive data types. right?

@soull00t Exactly.

When it comes from a code monkey: DRY-ignorant "scripting" where existing code is copypasta'd and slightly modified to implement new functionality. Pretty common in Web dev and honestly the best most companies can expect while treating their employees like they do.

When you hear it in a talk, it normally comes from a functional programming evangelist.

I use OOP and functional approaches depending on language support and problem to solve. Normally, the result is a hybrid. If i where a more mathematical person, i would probably use the functional approach more (but still not exclusively).

@IntrusionCM @zlice okay interesting, it's just that in my perception, OOP is a pretty established thing that everybody knows and uses and knows how to apply in a (more or less) meaningful way... at the university, this was also standard (except in courses like functional programming). it just sounds so weird to me that people might still say today "oh, have you heard of this fancy OOP, it's the new shit, let's try it out! and while where at it, use ALL the "oop", using all the software patterns there exist, because i read this fancy new book about it"... i mean, this paradigm has been around for so long, and software patterns as well, this mindset just confuses me.. sounds like coming from a parallel universe... 😅 (and i'm absolutely familiar with "non-oop" programming)

@Oktokolo "DRY-ignorant "scripting" where existing code is copypasta'd and slightly modified to implement new functionality"
yeah, that's what i also encounter in our code a lot...

i also try to find a sweet spot between "is well human readable / maintainable" and "is lean / cheap (which might sometimes be relevant) / not overengineered"..

@soull00t

Well... I think that's part of the problem.

The history of OOP, it's paradigms and evolution over time etc.

I think some of the stuff is older than 50 years?

Many forget this.... OOP or in a broader sense design patterns are theoretical - some of the patterns should be seen in a historical context, as they were "invented" at a specific time trying to solve a specific problem.

As an example, some see DTOs as a violation of DRY.

While I partially understand this, a DTO should be simple - storing one DTO more or less doesn't hurt nowadays.

Back in the 90s, it would be unimaginable. As the resources were extremely limited and every bit counts.

Nowadays... Pfffff.

Patterns like bitmasks instead of string enums fall into the same category...

The "curse" of DRY is usually that people try to deduplicate by utilizing composition or other OOP patterns. Which can lead pretty fast to a "touch this and everything falls apart" situation (change one class and all dependent classes need to be checked and their dependent classes etc.)

I only really see value in OOP when I have common database functions that I can avoid re-writing for all the different 'things' (such as clients, teams, clubs, members, purchases) that have their own table in the DB. For most people, those are always the Objects in OOP. Having a base class of dbObject means I can clone, returnRowsWhere, insertFromArray and so on for all such things. What I don't like about OOP is having to push things in and out of different scopes - for web stuff, particularly with dynamically generated many input forms, I just find it's way easier to have variables exposed in the same scope as the html. How do I organise my code? Every page is someName.php, it submits forms to someName-exec.php. Any re-used page components are includes, I'll break any complex page into smaller components, usually corresponding to visually separate parts of the page. It always seems that full OOP/MVC adds complexity and reduces clarity - what's straightforward becomes tough to do.

@lambda123 i understand.
i think, some of uncle bob's ideas are absolutely valid points and make sense (e.g. when it is about increasing human readability), but for many other of his concepts i think "fuck no, just noooope"... (e.g. aspect oriented programming is such a thing)

some software patterns i use intuitively for coding (e.g. factory) or they are already frequently used in our code base (singleton, interface for dependency injection), but for many software patterns i also think i'm probably never gonna use them... there might be valid use cases, but haven't had them so far.

@IntrusionCM yeah, DRY is something to be used with reason and caution (as actually everything, i guess xD), i guess there are unexperienced people who treat it as the non plus ultra because they are not aware of the downsides...

OOP is most popular imo. OOP codebases are "easier" to mantain because even no experience juniors have some knowledge of oop. It's what is thought in college.

If you don't want OOP, you can still make your own custom variable types with structs. (or well... classes with only public properties if the struct keyword isn't available in your language).

I remember PHP's mysqli extension was implemented in both approaches. OOP and functional. It's not a good extension and shouldn't be used, but it is still interesting to see.

We're using C in mostly procedural style, typical code base size around 10k LOC (not counting empty lines and comments). The products are about taking input like messages and sensor data, and output like other messages and actuators. Code base organisation is done by a layered architecture and component split at layer level.

The bug reports we get are vague and have at best logs at interface level, often not even that. We have no access to the customer installations. Therefore, debugging mostly is via the Chuck Norris method - staring at the code until it confesses. Sometimes, there's not even a source level debugger available.

Not saying that OOP is dumb - it's a good match when the objects actually correspond to objects in the problem domain, such as GUI programming, particle simulation, game character modelling.

@Fast-Nop hmm, there are so many more applications for oop. our codebase has tens of millions lines of code and is written in C# and C++. it's pretty complex (or let's say feature rich, that sounds better) and goes from UI and business logic down to hardware abstraction. no chance having a maintainable code base here without oop ^^ and there are plenty of use cases (within the code), which each for themselves are a legitimate application of oop... (okay, now i'm really starting to sound like an oop missionary..^^)

@soull00t The hard question is at this point of discussion: what is OOP?

It's kinda funny, I just rolled my eyes because we're taking in the whole thread about it but we never agreed on one definition of it...

Object oriented programming, yes.

But what does this mean?

I just realized it is a bit like saying "I use this tool" while standing in a hardware store.... XD

It really bothers me in many technical discussions pointing this out, but there is - at least not that I'm aware of it - a "consistent" definition of OOP.

https://en.m.wikipedia.org/wiki/...

As an example - wikipedia goes back to 1970 to smalltalk.

XD

C# is far far away. XD

@Fast-Nop concerning the bug reports /debugging, this really sounds horrible xD

@soull00t Do you have any of these nebulous classes with names consisting of permutations of manager, handler, factory, and so on, with no corresponding thing in the actual problem domain? That's a tell-tale sign of an OOP mismatch that is widely accepted as feature.

One typical problem that I've seen that is rather wrong and hence not an OOP issue per se, but foreseeable application: objects are only supposed to interact with their direct children and parents. Interaction with a parallel tree goes up until a common ancestor, then down. Both ways.

Only that most people don't write it like that because it takes too much time, so just add a direct interaction path. The combinatory complexity explodes.

At the other end, I've done GUI programming in procedural C - and it sucked so much that it's clear why people didn't want to go on like that.

@soull00t Another thing that is often, our code is passing messages around. The code is procedural, but the logic revolves around parts of the code sending messages to a central "router" and from there to individual "actors".

This is actually what Alan Kay had in mind when he coined the term OOP, not structs with function pointers.

@soull00t Oh, I've done debugging with only a free pin to which I could solder an LED, so that's not too nice, but doable.

The most difficult bug that took me two weeks to even find the reason (not even a fix) was a race condition that happened half in hardware, an external transceiver, and half in software, which failed to consider the limitations in the transceiver. No way a source level debugger would have helped here. :)

@IntrusionCM hmm okay legitimate point, definition of OOP is somewhat broad and we went some way since the 60ies...

my definition of it was the one to be found in modern languages such as C++, C#, Java, with classes instantiated by objects, inheritance, fields, methods and access modifiers.. but yeah, cannot really give you an official definition right now. ^^ for me it was only important to distinguish between the object-oriented paradigm (which differs from e.g. functional, logical or procedural paradigms) and software patterns (which might or might not build upon oop structures), since people seem to mix these two things up...

By contrast to the scarring experience of GUIs in procedural C, when I wanted a GUI driven feature in one of the OSS applications I like, and the author wasn't keen on it but open to a PR, I had no trouble getting into that, figuring out how things went together, and adding the feature. That was well written C++/Qt, and of course OOP. Pretty enjoyable.

@Fast-Nop
"Do you have any of these nebulous classes with names consisting of permutations of manager, handler, factory, and so on, with no corresponding thing in the actual problem domain? That's a tell-tale sign of an OOP mismatch that is widely accepted as feature."

sure we have, and they exist for absolutely legitimate reasons. let's say you have a feature which results in moving some data around, analyzing and transforming it or creating something new out of it... while respecting the current environmental parameters which might influence the end result. (sorry for the abstract example, don't want to get any more concrete than that) this might be such a complex task already, consisting of thousands of lines of code. it is much more readable if you divide this code to multiple classes. some are for analyzing, some are for transforming, some are for settings these classes up using the environmental parameters. this is no nebulous classes, they solve very concrete problems...

@Fast-Nop but calling classes SomethingHandler and SomethingManager is indeed nebulous and should be avoided, it's a sign that they have more than one responsibility and better be splitted (or removed)

@soull00t yes...

For me there are usually 3 categories:

Programming paradigm (functional, procedural, ...)

Programming architecture / design (design patterns, algorithms, anti patterns, ...)

Programming workflow (build tools, VCS, semantic versioning, ...)

The last one might be seen as "odd" or doesn't belong here...

... But without it, nothing would be possible (at least long term...).

OOP is a multi paradigm, though it of course "a lot in it" is intertwined with architecture / design patterns.

But many of these design patterns can be applied to other paradigms, too - which is your point and is correct.

Same for workflows - versioning can work with any paradigm, but you cannot create a "release" of a software without a version… as an example.

@soull00t It might be that I'm totally wrong because I can't know about your use case, but it's possible that the main point of these classes could be to transform the problem domain so that it can be dealt with using OOP.

Means, they might be an OOP artifact that you wouldn't need without OOP. However, they might still be the lesser evil compared to other approaches, I can't say.

@IntrusionCM i agree on everything 😁

@soull00t One really good thing about code monkeys is, that their code is as readable as the code they copied - if their changes are minimal. So when you have to work with code monkeys, provide them with easy to read "templates" to copy.

The result surely is more laborious to maintain than when applying DRY. But if you provided your monkeys with easy to read linear code mosty consisting of boiler plates, the code assembled by the monkeys likely will be patchable by the monkeys. So you could use the monkeys to patch the code after you researched a fix...

@lambda123 The post i replied to is the one where i was mentioned. I am talking about code monkeys - not coders who actually write (instead of just assembling) well-maintainable (whether it be straightforward and/or simple or not) code.

@Oktokolo oh boy, do such programmers really exist? 🙈 i mean, i heard of them... sounds like literally half-brained programmers...

@soull00t Yes they are legion. And they aren't neccessarily less intelligent. But they normally miss some pretty soft skills absolutely neccessary to become a good coder:

If you want to be able to write code solving a problem from scratch, you not only need to understand the problem, but you have to come up with a working solution. And while coding in general isn't recognized as a creative job by the public, you absolutely need at least some creativity to be able to advance past the copy-and-modify level.

Also, most just don't like coding but try it anyways. Of them, most have insufficient will power to become good at it while fighting themselves...