why people say OOP is bad because it makes the code complex when it's how enterprises are able to create complex software in the first place?

>>105670700 (OP)
Reactionary retards said to never use OOP in response to hype train retards saying OOP is the only way to do things

Depends what you are developing. For enterprise it makes sense because they are doing complex software. For average programmer doing his own projects it might be complex and could be better without.

>>105670700 (OP)
by writing very shitty inefficient OOP code

>>105670796
>by writing very shitty inefficient OOP code
what does it look like?
>>105670735
>For average programmer doing his own projects it might be complex and could be better without.
I dont know why people say this
even the most trivial shit looks much cleaner oop style and it's infinitely easier to write anything

>>105670886
i want to see this trivial clean example

>>105670700 (OP)
Those are sellers. OOP actually makes sense creating a block of classes and their methods makes it easier to understand what's going on. For example, I have a class Car, and the car does things that's it

>>105671127
>I have a class Car, and the car does things that's it

It never ends there. Eventually you will have you car drive on a Road, inspected by a Mechanic and at some point all internals of your Car will be exposed to outside world. And at this point why the fuck di you hide it in the first place?

>>105671350
Um sweetie, you don't understand, it's like being behind a streering wheel and pressing on the pedal, and not under your car with a wrench.

>>105670700 (OP)
>>105670700 (OP)
>enterprise
> complex software
Windows/Mac/Linux are all written in a procedural way not OOP. Most AAA games only superficially use OOP, mostly for namespacing purposes, and that's only because C++ has shitty namespacing features. Most compilers like GCC/Clang also falls under this.

> muh it uses "class"
No it's just a extended struct, there are no contracts being respected. Getters/Setters are anti-OOP. Casts are everywhere, member variables are accessed directly in a adhoc way.

Believe me, if C++ had superior namespaces nobody would be using classes.

>>105671390
>Windows/Mac/Linux are all written in a procedural way not OOP.
This is why they are inflexible bloated slop. Look at Mezzano to see what an OS that uses OOP is like.

>>105671449
>Look at Mezzano to see what an OS that uses OOP is like.
An useless toy?
My inflexible operating system supports any filesystem I could think of, mezzano as I see, only supports ext, the shittiest choice that nobody would choose unless forced.

>>105671449
> resorting to meme OSs like Mezzano/TempleOS
grim

>>105671489
It doesn't end there.
My inflexible operating system gives me the ability to create products that people can actually buy, runs on "actual" real home computers, solves actual problems.

>>105671489
>My inflexible operating system supports any filesystem I could think of, mezzano as I see, only supports ext, the shittiest choice that nobody would choose unless forced.
Mezzano supports anything you can write. You can write the driver in the REPL and you don't have to compile, reboot, or even close the window. Mezzano eliminates the distinction between "OS" and "user" code.

>>105671509
>My inflexible operating system gives me the ability to create products that people can actually buy, runs on "actual" real home computers, solves actual problems.
That's because of business reasons, not technical reasons. Windows/Mac/Linux are made by big tech who spend hundreds of billions of dollars vs Mezzano made by a couple guys doing the work for free.

>>105671518
Sorry I don't live in my mommy's basement and can't spend several years reinventing ZFS from scratch for your literally who operating system.
I literally cannot write it myself. Luckily someone else did.

>>105671518
> Mezzano eliminates the distinction between "OS" and "user" code.
Too bad you can only run it on a VM that is written in C. Or am I supposed to find the specific hardware, from a specific year, and install them in a specific combination, to actually get the install screen? Also tell me the specific GPU vendor, with the specific model, with the specific driver version.

>>105670700 (OP)
The problem is not OOP itself. The problem is, the people who always defaults to OOP, are not very bright.
You know that thing about hammers and nails.

>>105671547
> defaults to OOP
Nah, if that was the case OOP would be useful. What most people do is use superficial OOP. They use classes, methods, etc but there is no contract to actually respect the boundaries. Almost every OOP codebase uses Getters/Setters which just bring the entire thing back to programming procedurally.
And then as the project grows, and a private member is need, almost every single person simply create a new getter or make it public. Which again brings us back to procedural programming.
People say OOP is bad, because its a waste of time.

>>105671538
>Too bad you can only run it on a VM that is written in C.
It works on my machine. You only need the VM to create the initial disk image and compile it.

>to actually get the install screen?
The install uses a Common Lisp compiler to create the disk image, then you run it in the VM and the code copies the rest of the files over the VM's internal network. Of course, that's because they don't have the work or funding of big tech companies who can hire tens of thousands of programmers and buy thousands of different PCs to test the code. You're basically comparing a guy who built a car in his garage to a big car company.

>>105670710
>>105670735
CRUD webgui's over databases are not complicated or hard in any way.

also, you have DTO's which are just pure data and services which are just pure logic. In what fucking universe is that OOP?

>>105671669
A guy who built a car in his garage wouldn't tell me that I need to jump through hoops, he'd just turn the key and have that beast rev up.

>>105671693
don't talk to me

anti-oop dunning-kruger crowd has never faced a hard problem in their lives that benefits from oop.
for example, undo system with custom commands. you can't use switch, because not all commands are known during compilation

>>105672428
Ok dunning kruger.

>>105671350
>at some point all internals of your Car will be exposed to outside world.
no they wont. car has clearly defined interfaces and no internal variable is exposed but just the methods themselves. there's always an encapsulation going on. it's much better than the alternative which is just nothing.
>>105671390
>Windows/Mac/Linux are all written in a procedural way
C is deprecated on Windows. msvc is just a c++ compiler.
you know the serenityos guy, the only reason he could do those such things from scratch is because he writes everything in c++ and etc. oop just makes it so easier to create large scale software

>>105672460
Now I know why serenity OS is trash.

>>105671489
>My inflexible operating system supports any filesystem
it supports it via ad hoc implementation of OOP

>>105672512
Tell me again why my ad hoc implementation of OOP just works while your pure OOP implementation doesn't.

>>105670700 (OP)
>enterprises as a good example
Reminds me of how lichess written by one guy outperforms chess.com massive team beautifully

>>105671350
Because academics are retarded and solution-oriented instead of problem-oriented, they want to change the problem to fit to the solution instead of the opposite
Same thing with functional bullshit, the end goal is proving their solution can be useful for something

>OOP in JavaScript

>>105672527
gtk and gnome are full of ad hoc OOP, where they for example use strings to access object properties. this is pure insanity and it makes it 100x slower than any real OOP.
linux is also full of these inneficient pseudo OOP quirks

>>105672594
>Because academics are retarded and solution-oriented instead of problem-oriented, they want to change the problem to fit to the solution instead of the opposite
This is because big tech has the time, money, people, and computers to not have to care about the overall design. Academics care a lot about the overall design because that saves code, which saves work and makes the system smaller. It's comparatively less effort for a big tech company to hire 10,000 Indians to write another 10 million lines of code than it is for an academic or hobby project to write another 10,000 lines of code.

>>105672668
Now you are creating a false duality

There's:
>decent people writing good projects
>masturbators in eternal analysis paralysis
>big tech hiring a thousand indians

First case is everything that works, second case is functional/OOP toys, and third case is slop

nocoder retards will be nocoder retards

>>105671390
>Windows/Mac/Linux are all written in a procedural way not OOP.
system programming is inherently low level, OOP by itself requires more levels of abstraction
enterprise software programming is inherently high level and full of abstractions upon abstractions because business processes are themselves highly abstract and complex

>>105672687
>>decent people writing good projects
Mezzano, all that academic software
>>masturbators in eternal analysis paralysis
You, Cniles thinking FizzBuzz is "systems programming"
>>big tech hiring a thousand indians
Windows, Linux, Unix, Mac, Android

>>105671390
>>105672710
all major operating systems, including the Linux kernel, are written with OOP. have you tried opening a book instead of shitting up the board with your nocoder ramblings?

>>105672732
>Mezzano, all that academic software
You really think that your masturbation is high-level sex?

>>105672732
>Cniles
>FizzBuzz
You really need to detox from this board, how much anons have you been sucking to get your mouth full of shitty internal memes?

>>105672734
Linux went from ad hoc OOP to full OOP in few posts and you still haven't explained why mezzano is trash.

>>105672967
im not the person you were replying to

>>105673063
Don't worry, I don't see OOPtards as people at all.

>>105671449
>This is why they are inflexible bloated slop.
says the man who writes functional programming code, that compiles to javascript that runs in electron

>>105673089
mezzano is written in an OOP language, drooling retard

>>105673119
>says the man who writes functional programming code, that compiles to javascript that runs in electron
That sounds like projection. Electron and JavaScript are an outcome of the inflexibility of C-based operating systems.

>>105673136
Yes, that's why it's useless and nobody uses it.

>>105673162
Electron and JavaScript are an outcome of C++ retards not being shot in the back of their head soon enough.

>it's how enterprises are able to create complex software in the first place
There havent been any refute against this so far
big procedural blob of code that's not fizzbuzz is pita to write and maintain and may god help you if you decide to go back to reading those codes again after a year or so

>>105673239
Calling a single function called solve_my_problem() is sure a major pita, I wish I had a factory somewhere in there for 50 different objects to make it more complicated.

>>105670700 (OP)
There is not one way to do things, there's tradeoff and choices to make. As a dev (or tech lead/architect) that's your job to find the balance needed.

>>105673252
you will need to pass parameters and structs to that solve_my_problem() and do other things with the return as well. with object methods they are all in their own place and you dont have to memorize them anymore.
Im probably giving (you)s to a nocoder so it's my fault

>>105673297
No I won't, in fact I cannot, _start takes no parameters, try again, nocoder.

>>105673239
>big procedural blob of code that's not fizzbuzz is pita to write and maintain
Enterprise-level software is a PITA to write and maintain no matter how you slice it. A 10 million LOC project being maintainable is like a 500 pound person being healthy, that is not how it works.
Though this does also make whining about OOP a bit superfluous, most OOP hate is just hatred of Java idioms.

>>105673252
>Calling a single function called solve_my_problem() is sure a major pita, I wish I had a factory somewhere in there for 50 different objects to make it more complicated.
Then you'll have 10 million lines of code in "solve_my_problem" and you can't change anything without recompiling and restarting the program. With OOP, you can extend anything on the fly, without having to close or restart anything. It's also divided better so you can reuse the same structures and interfaces whenever you need them instead of having a monolithic blob.

>>105673314
Im sure you do a lot of void solve_my_problem(void) in your real life programming work lol
>>105673317
I said pita as in required cognitive complexity to change something in code. a 10 mloc monster codebase is trivial to work with if it's properly modularized.

>>105673427
Every single program that runs on your system is abstracted by an OS calling into a _start with nothing but a prepared stack. And guess what, cretin. It's abstracted so well that you doubleclick while mouthbreathing, and it just runs.

>>105673426
>Then you'll have 10 million lines of code in "solve_my_problem"
don't forget that you will need solve_solve_my_problem() because it got so huge after some point and you can't do anything to it without breaking some other thing

>>105673460
why are you just keep telling us you're a nocoder and further humiliate yourself?

>>105673483
>why are you just
good morning sir

>>105673460
>Every single program that runs on your system is abstracted by an OS calling into a _start with nothing but a prepared stack. And guess what, cretin. It's abstracted so well that you doubleclick while mouthbreathing, and it just runs.
That's how it works on a non-OOP OS. On an OOP OS, you can use anything in the system. Any object (which includes functions and methods) is available at all times. Your programs can return values or be passed other objects. Your programs can be parameterless or take string parameters too, but that's a special case. They aren't forced to be.

>>105670700 (OP)
>why people say OOP is bad
Because they are retarded.

>>105673501
And why would I want this?

>>105673427
>a 10 mloc monster codebase is trivial to work with if it's properly modularized.
Which never happens, ever.

>>105673559
10mloc codebase is easier to work with when written in C and not Java, because if C programmers didn't know what they were doing, the project would've died before 10mloc happened.

>>105670700 (OP)
The original argument against OOP was against dogmatic OOP
Ie instead of trying to plan a rigid inheritance tree structure ahead of time you just start making the program the "procedural" way and implement OOP abstractions on the fly wherever it simplifies things
If this seems obvious its because it is, and people were just arguing against the worst excesses of OOP *philosophy* taken to its extreme
Retards now take this too far in the other direction and are dogmatically anti OOP without actually knowing why

>>105673597
TL;DR procedural is OOP done right.

>>105673559
>Which never happens, ever.
there are books on these kinds of enterprise code and integration patterns that I have on my readlist. maybe CS education and consequently most CS majors suck at their jobs because software is an architecture work at some point and it's like an architecture trying to build something without knowing anything about architecture

as long as whatever language you are working in has testing capabilities and is compatible on the hardware its deploying to it doesn't matter

>>105673597
>Ie instead of trying to plan a rigid inheritance tree structure ahead of time you just start making the program the "procedural" way and implement OOP abstractions on the fly
this is how terrible and hard to reason OOP codebases form.
Also, no. you don't have to plan all structure ahead of time. design patterns exists for this reason so that you can just add new functionality to your structure instead of hardcoding everything to the code
>>105673621
architect*

>>105673644
>just plan for requirements that we weren't told yet bro

>>105673541
It increases the power and extensibility of the system. Imagine that instead of "sequence of bytes" """files""" you have actual objects. All your pictures, for example, are objects, which have a class and methods. You don't need to change all your programs to handle a new image format because you can just define a new class and everything on the system automatically can use it. You can use CHANGE-CLASS to change a PNG to JPEG, for example. Imagine that everything on the system works like this. All your objects have an actual type and class associated with them. Arrays, numbers, characters, and bits are objects too. So you can eliminate the whole idea of "files" and the extra complexity associated with them. Instead of a "file" you have to parse, for example, for configuration settings, you have a package and the package contains variables and you can set their contents directly. The variables have types and it can check to make sure you're giving them valid values. Programs are packages too (probably several subpackages per program), with all the variables, types and functions already available as objects in the package.

>>105673647
you can't write the whole thing procedurally either without the knowing requirements.
oop has advantange that you can start to design and implement likely existing objects independently. Doing this in "procedural" way just dont exist because it's an inherently object oriented approach to programming.

>>105673644
>design patterns exists for this reason
design patterns aren't architecture-level, they won't fix your program's structure
also, unless you have a shitload of experience with real enterprise code (academic shit doesn't count), it's actually detrimental to preemptively apply a design pattern - you will almost certainly make a decision that will screw you over in the long run. it's safer to write it "the hard way" first and then refactor into a design pattern

>>105673647
>>just plan for requirements that we weren't told yet bro
unironically yes

>>105670700 (OP)
One of the big issues with object oriented programming on modern hardware is that due to caching, working memory isn't random access but sequential access in practice. It is really a lot cheaper to access memory near to something accessed recently because then it can be fetched from the cache.

OO means you'll basically get arrays of structs instead of structs of arrays, you really want structs of arrays instead for good performance and I mean it really matters when you actually get down to it and test it. I'm serious that looping over a struct of arrays to do something is really like 70 times faster than looping over an array of structs in practice.

Makes the code less maintainable though but if you're say writing an rts game where every unit has a bunch of common properties like position and health and stuff it's far better to have a struct of arrays than an array of struct performance wise when your engine needs to loop over all these units every tick to compute the next tick.

Some people are just luddites. OOP is useful for many higher level tasks. Reproducible classes are essential to certain structures like neural networks. Of course lower level languages are important to firmware development. If you want to see where luddism gets you as a programmer look at the people who argued for the superiority of Visual Basic or that guy who applied to over 800 jobs yet refused to move on from being a PHP developer.

>>105673839
I don't want to be a luddite, I would rather be employed. Did you see that the Pope warned against AI? That is honestly pretty ridiculous. It is really just multiplying groups of numbers together. It reminds me of when the Pope opposed heliocentrism. Not only do I embrace the technology I work with models published in the last 10 years as research papers. If you understand the math it is not anything spooky, just multiplication. Same people oppose OOP. Same people opposed Java. On and on and on. All technology can be used for good or evil. A hammer can build a home or injure an innocent person.

The lack of OOP in Rust has been the biggest hurdle to me moving to it. Ownership, borrowing, memory safety in general has been relatively easy to grasp as a former pythonbabby, but the lack of stuff like partially abstract classes is extremely annoying. It's what made me actually consider learning C++ instead, but I really want memory safety and I heard C++ is full with footguns. If Safe C++ ever becomes a thing I am switching.

I don't know how other languages do it, but in Rust people just end up writing horrifying macros to make Franken-OOP constructs anyway and a lot seems to be unfinished and pending features in nightly. Stuff like generic consts is a beta feature which is a bit baffling.

I realize they want to avoid AbstractSingletonProxyFactoryBean. I do too, but I'm a big boy and I can use my tools responsibly. I don't like having my tools taken away because the language designer sees me as a child. We're all consenting adults here.

>>105673821
dont newly created objects located next to each other in memory so cache locality shouldnt be much of a problem?
though it indeed might be the best to use structs in those cases. but you will still be using objects (manager object for that struct) and anytime you can replace that struct with a class inside that manager object without breaking something in any other place of the code

>>105670700 (OP)
because most developers are retarded and can't wrap their heads around simple concepts like composition and dependency inversion

>>105673954
How are abstract classes functionally different from traits in Rust?

>>105673958
They do, but similar data is still spead out far wider. Say you have some Unit object in some RTS game which has fields like
>position
>health
>orientation
>owner
>cooldown state of weapon
>current speed

And like many other things, these all take up space so the “owner” field of different units isn't as compactly laid out in memory as it could be. It turns out that in practice you mostly in code want to access similar data right after each other, so the more similar data can fit into the least memory right next to each other, the more cache hits you're going to get.

idk man I write C code

>>105673954
I hated the complete lack of real OO until I started thinking about problems in terms of types. Traits (easy mode typeclasses) are tits.

>>105674009
>idk man I write Hello World and FizzBuzz
We know.

At the moment I am too concussed after a car full of gen alphies pit maneuvered me off the fucking highway yesterday to argue properly, but OOPjeets and FPtroons need to run, not walk, off a fucking cliff

>>105670700 (OP)
oop is like agile
no one knows what it means anymore
ever job ad has it
gurus sell it to your boss
somewhere there's a research paper which describes it in 3 sentences

>>105674051
I do embedded on aircraft, which yeah ngl unironically it kinda is FizzBuzz tier

>>105673821
this is a foolish assumption that every problem can be solved by looping over an array. even in games this leads to problems like you can't just fire an event, or change the state just in time. you must dealy the execution by recording it as some sort of command.

>>105674007
from abc import ABC, abstractmethod

class Foo(ABC):
@abstractmethod
def f(self): pass
def g(self): print('hello from Foo')

class Bar(Foo, ABC):
def f(self): print('hello from Bar')
@abstractmethod
def h(self): pass

class Baz(Bar):
# no need to impl f, the Bar ABC defines a default impl
def h(self): print('hello from baz')

baz = Baz().f() # "hello from Bar"

might just be a case of python giving me a lot of freedom, but it's this freedom of chaining types that I want. It quickly spirals out of control in Rust, and from what I've seen it requires you to generate a morbillion helper types with or without macros or 3rd party crates. If there is a better solution then be my guest and BTFO me.
>erm but why would you possibly want THAT?!
I have an Animal, and a Dog and a Cat. Leave my OOP alone.

>>105674141
>this is a foolish assumption that every problem can be solved by looping over an array
Name a single one other than when you're writing a compiler or some shit

>>105674088
>anymore
this implies you knew what it is to begin with
OOP opponents use this as an excuse for not being able to even define OOP at all

>>105670700 (OP)
Why do you think enterprise code is complex?

>we renamed functions and shoved them inside of namespaces
>this is revolutionary!

what people filtered by OOP think OOP is
>>105674936

>>105670700 (OP)
OOP is good in moderation
doing everything OOP style doesn't make sense
enterprise OOP is too much
design patterns should be justified
it seems too many people use a pattern just because they can and don't think it make sense to justify the overhead of the boilerplate
encapsulation is not actually a good thing IMO
imo it's only justified if you make a library and need to expose an stable interface while not exposing implementation which can be refactored freely
in your application you shouldn't be afraid of being able to change anything
encapsulation driven code like in java is mostly boilerplate
interface driven code is cargo cult, if you have only a one implementation of a interface it's not needed
if the need for an interface surfaces naturally you just refactor the code so that the previous thing implements the interface and now there are 2 or more
spring style dependency injection is cargo cult and code smell
unit tests that mock 10 things to test a single small thing is a code smell and shows that the codebase is overcomplicated
fakes are a better way to test stuff in isolation, mocks tests are unnecessarily complex
tdd is overrated unless you have a spec - you implement a standard, protocol or have a sensible functional design spec (not agile style)
make the code so simple that you have no code that you are afraid of touching/removing/refactoring
instead of protecting other teammates of doing wrong things by making the code overly protective by doing so called clean code/best practice just have proper code reviews so people write things with intent, not implement mechanically dumb things that is full of boilerplate, easy, but inefficient solutions
properly named functions make the code easy to follow even if the code underneath is not trivial, just name the functions sensibly and create them when needed

imagine listening to a guy called uncle bob. unfortunately i fell for the meme and it was really like getting raped

>>105676044
I use Clojure and I can barely even discuss it anymore because that geriatric retard made a terrible blog post about it. Day of the pillow NOW.

>>105675840
about half of your points are plain wrong - based on wrong understandings and/or non-realistic made up scenarios
of the remaining, half are heavily debatable/just opinions
the remaining quarter have some worth (maybe not full but at least some)

>>105676090
hush, i want that sweet peter norvig vs ron jeffries tangent

>>105673297
Ok so you argued for namespaces or modules, not OOP.

>>105676044
what if i told you that there are no difficult to understand programs, only badly written ones, and it's possible to write programs in such a way that they are understandable to anyone.
the problem is that reading the program and understanding what it does is not the same, because meaning is not always given in the source code context. we have a term for source code stripped of the meaning: obfuscation. the code is either obfuscated (unintentionally), or not. it's that simple. clean code is just a programming discipline that aims to write meaningful code. there are no hard rules, just advices.

>>105674088
>oop is like agile
>no one knows what it means anymore
I think it's just CIA-virtue-signaling

>>105670700 (OP)
By throwing endless jeets at it until it sticks.

>>105673757
Ok, call me back when you extend it to support my basic usecases.

>>105670700 (OP)
OOP code keeps pajeets employed fixing bugs that OOP causes. Everyone in this thread defending OOP is brown.

>frogposter
opinion discarded

>>105678326
>ytboy mad because he got replaced

>do_something();
>get_something();
vs.
>$foo->india->resources->streets->poo();
>$bar->india->resources->women->smell->like->poo_not_in_loo();

>>105678594
Racism is not cool.

>>105676090
these are my opinions, you do you
there are no wrongs in something that are purely opinions
there is no objective one true way to do programming and your are presumptuous to think you are right
they are unpopular, because most employed developers are shit developers and are afraid of working with "raw code"
but "clean code" and such practices lead to gigantic, bloated codebases, tons of indirections, poor performance
the "not clean code" is not bad code, it's just code unfamiliar to "clean code babies"
naming your variables, functions well and structuring the modules and project sensibly is enough to make the project clean
The "uncle Bob" is a grifter and he have done a lot of damage influencing and grooming shitty developers
my take on things is people shouldn't be afraid of changing code, if you hide something because it's "hard" you are not helping anyone
someone will need to do "hard" things and no layers of shit will help with that, on the opposite all indirections made by fancy design patterns just make the experience awful and annoying
when I started coding I was a "fan" of design patterns and I liked complex code
after growing up I realised that simple code and least amount of it makes the codebase better in every way
the more code someone produces, the more bugs they are possibly generating especially if there is a lot of state and interactions around
I don't say we need to use assembly, just write normal code
in commercial settings I can't do that, because of retards that expects me to write "enterprise grade code"
but when I write something for myself I write simple, boring, non-bloated code
in pathological scenarios of "fear" you get a situation like in nodejs where there are tens of thousands of microdependencies
who is even auditing the code? why does the project that worked 2-3 months ago randomly can't build?
dependencies are a liability and people should be cautious before adding one, I don't trust makers and users of microdependencies

>>105678862
>there are no wrongs in something that are purely opinions
while opinions can't really be "wrong", they reveal a point of view and present conclusions that, with enough experience, you can deduce in how they were formed

for example
>it seems too many people use a pattern just because they can and don't think it make sense to justify the overhead of the boilerplate
it's usually ambitious but inexperienced developers that apply design patterns too eagerly, in large part because universities are bad at teaching

>encapsulation is not actually a good thing IMO
>imo it's only justified if you make a library and need to expose an stable interface while not exposing implementation which can be refactored freely
>encapsulation driven code like in java is mostly boilerplate
>instead of protecting other teammates of doing wrong things by making the code overly protective [...]
typical conclusions from usual bad teaching
encapsulation is a core principle to a good OOP codebase if you understand its purpose (so you also understand when it's ok to not apply it), but again, universities are bad at teaching programming

>>105679144
What teaching? Nobody teaches anyone in this industry. You don't know anything about me.
I might be self-taught, but it doesn't invalidate my opinion. I would argue being self-taught might be better, because you aren't indoctrinated and learn from your mistakes.
>encapsulation is a core principle to a good OOP codebase if you understand its purpose
This is a meaningless sentence.
Why does everything needs to be abstracted away?
I don't like the practice of private access by default in java.
If the interface doesn't expose access to something that is needed you need to do dumb shit like writing a delegates, reflection etc that leads to less clear code.
I prefer the python's lack of access modifiers and naming of members that indicate whether something is protected, private.
You still have the hiding of irrelevant - implementation details in your IDE and people respect the boundaries themselves, but if you really need to access something private you can without working around the problem.
In case of java you need to add even more (actually unclean) code to access such things.
This is from my experience. If you only work on crud you might never have such problems.
I find you talking as if you are regirgurating something you read:
good OOP is ... bla bla bla
I never even stated that I'm subscribing to "pure OOP ideology". There are many tools and one should pick the best tool for the job.
The codebases in the wild is a mix of different paradigms and styles and it's actually good when something is not done the OOP way.
Because too much OOP leads to that stinky enterprisy code
Thankfully Java has more functional elements and people started doing less of it
I made a mistake of generalization. I didn't mean encapsulation, but hiding complexity. It's a separate matter.
Encapsulation is good and is a basis of any modern programming. It's not even an OOP thing, encapsulation just means abstraction.
Making a struct instead of having loose variables is an abstraction

>>105679345
>I didn't mean encapsulation, but hiding complexity
I made mistake upon my mistake. Shame on me. I meant restricting access...

>>105679345
>>105679361
if you are self-taught then you learned from same or similar materials as universities use to teach, at least some misconceptions are the same as in academia

>encapsulation just means abstraction
>restricting access
wrong
encapsulation means the principle of not exposing internals, and exposing only what's meant to be public
this doesn't just mean to use the 'private' keyword for everything - if you make a private field that acts as internal state of a process and then add a public setter and getter for it, you effectively break encapsulation

>If the interface doesn't expose access to something that is needed you need to do dumb shit like writing a delegates, reflection etc that leads to less clear code.
encapsulation is not a measure to "protect" code from other developers
also your scenario implies either something has been hidden when it shouldn't have been, or you're trying to access something you were not intended to access - either way it's not a problem with encapsulation by itself but either an implementation defect or interface design flaw

>This is from my experience. If you only work on crud you might never have such problems.
I work with quite heavy business processes and not respecting encapsulation by modifying internal state of other objects is probably the largest code stink I have to deal with

>Because too much OOP leads to that stinky enterprisy code
in most cases, it's having the attitude of avoiding OOP when writing in an OOP language that creates the worst quality code
too often people do lazy, procedural implementations because they're short-term simpler to implement
then they blame OOP not working when they have been avoiding or half-assing it

>>105679345
>Why does everything needs to be abstracted away?
nobody ever claimed this. abstractions are done because they make things easier and safer. they are good for scale / flexibility but better keep it low / zero cost as possible. there are inherently no abstraction that is "too much" because it's relative to the engineer's perspective.
abstractSingletonProxyFactoryBean gets ridiculed but it's like billion times harder to write whatever that achieves procedurally in a non-sphagetti way.
>I don't like the practice of private access by default in java.
private by default anything is good for formal safety. it's the middle between procedural sphagetti and pure functional math autism
>If the interface doesn't expose access to something that is needed
this is logical contradiction. classes expose everything that's needed and not less. if you think there should be a new method to a class you go talk to the developer of that class and ask for it. if you're the developer yourself, you write it.
>You still have the hiding of irrelevant - implementation details in your IDE
how do you expect your IDE to know implementation details? have you actually written any code before? how is it gonna know which part of code should be accessed by which? pre-/postconditions and invariants?
>people respect the boundaries themselves
it's not about respect but decreasing complexity by constraining the code to it's supposed behavior. have you ever tried to write a formally correct code before?

>>105679649
> if you make a private field that acts as internal state of a process and then add a public setter and getter for it, you effectively break encapsulation
If Im not wrong on the terminology, then no. You're still abiding to the contracts the developer of that class choosed. one day he might change the internals of getter/setter and you wouldn't notice anything because the access to that element is encapsulated.

>>105679840
>You're still abiding to the contracts the developer of that class choosed. one day he might change the internals of getter/setter and you wouldn't notice anything because the access to that element is encapsulated.
with this train of thought, you are inferring implementation details of the interface
ideally, you would think only about the interface - if there is a getter then it's just another method that returns the value of some property or calculation. you shouldn't care or even think if it's ever been mapped to a field or not. similarly with setters: you just set the value of some abstract property of the interface

>>105679649
I'm tired of that elitism mannerisms.

>>encapsulation just means abstraction
>>restricting access
>wrong
>encapsulation means the principle of not exposing internals, and exposing only what's meant to be public
You are constantly talking like I don't know what is encapsulation. I think if you read what I've written before we are saying the same things. You catch me by words that are just an expression of a mental shortcut. Maybe I just suck at english, it's not my native language so I don't know how to express myself better.

Here you are:
Encapsulation for me is packing of an idea into a thing that encapsulates that idea into a named entity (so abstraction) that is easier to work with or just for reusability. It can be a data type, enum, a function, a class, a module, a library, a whole program in shell pipeline (from shell perspective a program looks like a command). It doesn't necessarily hide everything from the user. What is exposed/public is an interface the user can work with.

What I meant about restricting access is that OOP way at least in java conflates encapsulation with restricting access so it does in fact protect code from other developers so they can't poke anything that is not public.

>I work with quite heavy business processes and not respecting encapsulation by modifying internal state of other objects is probably the largest code stink I have to deal with
Have you worked on a legacy projects that used a framework that is already deprecated, but client doesn't want to spend money on migration? You need to implement a feature that is impossible to do without having certain things available to you. Maybe it's just a special case, but I worked in legacy projects like that for years. Business wants to teach a 30 years old dog to do new tricks. You need to do it. You can fork it if you have the source, but now if you recompile it with a different compiler stuff might break and you need other dependencies that might be lost to time.

>>105679840
>nobody ever claimed this. abstractions are done because they make things easier and safer
People in enterprise at least in legacy codebases liked design patterns very much. Switch statement for 3 invariants? No, lets do strategies. Abstract Query builder factories with atom level granularity etc.
>also your scenario implies either something has been hidden when it shouldn't have been
That was the case. Can't make something work if it's not exposed. Developers don't exist. It's deprecated, but it's in use. Business does not care. They are cheap bastards and our people can't convince them to eat the cost and we don't work for free and they want new features. They don't want to spend years on reimplementing something they have. A developer have no say. Only security incidents are respected, but only the thing in question is patched.
>in most cases, it's having the attitude of avoiding OOP when writing in an OOP language that creates the worst quality code
Functional additions to Java 8 was what made Java much better to work with. It revitalized the language and made it so much more palatable. Sorry that people love non-OOPy parts of the language.
>too often people do lazy, procedural implementations because they're short-term simpler to implement
OOP is just structural programming with objects that have behavior coupled to the objects. Unless you write pure functions your implementation is procedural and if you wrote purely functional it wouldn't be OOP either.
>how do you expect your IDE to know implementation details?
>it's not about respect but decreasing complexity by constraining the code to it's
IDEs uses various techniques analyzing the code. In case of python class members starting with _ and __ are hidden. They are still accessible. This is better, because you don't need to fuck around at a time you need it and it still hides the details that were hidden.
>it's not about respect but decreasing complexity by constraining the code ...
as above

>>105680173
>with this train of thought, you are inferring implementation details of the interface
Read the docs

As I stated in first post hiding everything makes developers afraid of learning how things works. And developer should know how his framework work. By piling abstractions on top of abstractions indefinitely you are diluting the knowledge so far you have a wrong picture of what actually runs when the code executes. This is the cause of the industrywide enshittification. Developers hidden themselves from actual code to the point they have no fucking clue, everything is so inefficient and when there is a problem they just pile another abstraction on top. This is literally why companies started doing microservices when they are not "on that scale as Amazon". They thought that it's just easier to make smaller separate services from clean slate that talk to the big ugly legacy blobs that they can't comprehend.

>>105670700 (OP)
Because they don't jobs and need to make themselves feel better by making up arbitrary, contrarian rules that make them feel elite.

>>105671350
>never ends there. Eventually you will have you car drive on a Road, inspected by a Mechanic a
that would be the case without oop as well. real life is complex.
> at some point all internals of your Car will be exposed to outside world.
no
>And at this point why the fuck di you hide it in the first place?
okay, you're retarded.

>>105672594
>Reminds me of how lichess written by one guy outperforms chess.com massive team beautifully
proof that it's due to the lack of oop? or do you just make shit up that confirms your bias?
I took a 10 second look at the source code and there's plenty of oop.

>>105682480
How is it contrarian? Rust doesn't support OOP, neither do Go or Zig. Nobody needs OOP.

>>105670700 (OP)
>when it's how enterprises are able to create complex software in the first place?
Have you ever used said software? It's shit.

>>105670700 (OP)
It ends up as an unreadable bloated mess because it is more profitable to use shitty coding practices to hire less and newer (cheaper) programers to do the work and leave the user with the end result

>>105682828
And OOP was developed for this purpose, to be a shitty but easy to use

>>105670700 (OP)
>use OOP when it makes sense to have objects that manage a set of data that belongs to them
>use functional programming when it doesn't
>don't be autistic about always using a pattern from your college textbooks when it makes no sense to do so
OOP is fine and a very useful way of organizing software when applied correctly. There are just a lot of retards and autists out there who fuck it up and make unmaintainable messes.

>>105682570
That's strange since the Rust documentation has an entire chapter dedicated to OOP: https://doc.rust-lang.org/book/ch18-00-oop.html
I guess this is part where we just make OOP mean whatever the fuck we want it to mean.

>>105682828
>>105682836
the opposite. OOP aligns well with business domains because it's very similar to how humans perceive the world.

>>105682206
it's not elitism (not my intent, anyway), rather giving a more coherent perspective than learning materials usually give, to better understand and then utilize the principle for your benefit. it's your choice to reflect on it and either consider or dismiss it

>Encapsulation for me is packing of an idea into a thing that encapsulates that idea into a named entity (so abstraction) that is easier to work with or just for reusability. It can be a data type, enum, a function, a class, a module, a library, a whole program in shell pipeline (from shell perspective a program looks like a command). It doesn't necessarily hide everything from the user. What is exposed/public is an interface the user can work with.
just structuring or abstracting data is not by itself encapsulation
again, encapsulation it's the specific principle/intent of hiding implementation details and exposing only a public interface

>What I meant about restricting access is that OOP way at least in java conflates encapsulation with restricting access so it does in fact protect code from other developers so they can't poke anything that is not public.
and again, that is one of the typical poor teachings - it's not about some arbitrary restricting access or "protecting code from other developers"

>Have you worked on a legacy projects that used a framework that is already deprecated, but client doesn't want to spend money on migration? You need to implement a feature that is impossible to do without having certain things available to you.
don't see the relevance of encapsulation to the scenario you're describing
yes, 30+ year old codebases might have some restricted APIs that would be convenient for you to have public access to - that's not an encapsulation problem

>>105682321
>A developer have no say.
sounds like the root of your problems, which is a policy issue and not a programming issue

>Functional additions to Java 8 was what made Java much better to work with
the point was more about writing everything as static functions, suffering from primitive obsession and juggling a multum of parameters instead of using instance fields

>OOP is just structural programming with objects that have behavior coupled to the objects
that's another generalization based on an implementation detail and ignoring the principles behind it

>>105670700 (OP)
the fuck does oop mean anyways, anything is oop these days

>>105682397
that's just rambling with no relevance to encapsulation, or any point of its own

>>105683789
>the fuck does oop mean anyways
you write small units of code that call other small units of code, each with their own local scopes instead of relying on and controlling global state
it's intentionally "loosely defined" because objects can be whatever you need them to be

to that you can then add a bunch of other principles like polymorphism or encapsulation

>>105683687
Are you a priest of the church of OOP or something?
Encapsulated is not limited to OOP and I'm pretty sure about that.
I've did a quick search right now and the first result says that notion of encapsulation predates OOP and another result is a wikipedia page that literally says what I said about encapsulation.
>don't see the relevance of encapsulation to the scenario you're describing
Because that tangent wasn't about encapsulation but about the access restriction practice in java - making everything closed by principle probably due to O in SOLID.
I'm not against abstraction and hiding details, but I'm against doing things by default for no apparent reason. Following some arbitrary rules without your own judgement. OOP is a tool, but it's one tool and sometimes there might be different way that might be self evident. Your argument about needing accessors because someone might add something there in the future is moot imo. I've never seen accessors used for such things outside school. They are just accessors, as the name states they just do this. It's so rare and out of place that I would even consider it a code smell, because it does something more than the name tells without looking up the source. The function should do what it says. If you are working with beans they are always lightweight and have no business logic. Get should get and set should set. If not for reflective frameworks that need them they wouldn't be needed at all, because they are redundant. As for validation if there is a need for validation it would be better to be explicit. It should be done were it's created so in the constructor or at the place that is responsible for creating these object. Factory here actually makes sense and I would agree that it's not a bad use of it even though it may seem "against my stance" in this discussion. But my stance is not that OOP is bad, but using following a dogma as some grifters like Uncle Bob preach. Have you seen the code in his book? It bad.

>>105670700 (OP)
>people
why are you listening to underaged neets and hobbyists online?

>>105670700 (OP)
Is mostly is a skill issue. Too many morons believe they can code but they can only push their heads deep inside their assholes.

>>105671693
you are a larping retard

>>105671390
larping retarded faggot kys you're self in minecraft and then in IRL

>>105685440
>Are you a priest of the church of OOP or something?
just a strong proponent of it

>Encapsulated is not limited to OOP and I'm pretty sure about that.
never claimed anything is exclusive or limited to OOP, just that encapsulation is a significant principle to a good OOP codebase

>I'm against doing things by default for no apparent reason
and I am giving my own reasoning while pointing out other reasonings I find wrong

>Your argument about needing accessors because someone might add something there in the future
this has never been my argument, and in fact it's another typical wrong teaching

>But my stance is not that OOP is bad, but using following a dogma as some grifters like Uncle Bob preach. Have you seen the code in his book? It bad.
I am against "x dogma is bad, ignore it entirely" dogma; i prefer to find whatever value I can in anything I read, rather than dismiss works entirely due to a bad popular opinion, especially by people who don't seem to work on the kind of codebases a book is intended for in the first place
while Clean Code is extremely overselling each of its points, you can still take some of its general principles and apply them to your own codebases (surely you won't disagree that proper naming is a good general principle?), and I find that most of his points improve the codebases I worked on
yes, his refactored code is quite awful if you read it 'as-is' but I don't believe the point is to write code exactly like that - rather, look at the "before" and "after" and just apply the same general principle to your code
in general I think people make the mistake of reading Clean Code like a gospel or bible (and then disregarding it as whole), rather than a guide book where you need to think for yourself before applying the principles

>>105683120
>use OOP when it makes sense to have objects that manage a set of data that belongs to them
In other words don't use OOP, use namespaces. OOP never makes sense and is always retarded. Don't ever use inheritance. Don't ever use OOP.

i wrote this using rust. oop is bad!

>>105687754
>OOP never makes sense and is always retarded
#filtered_by_oop

>>105687778
I got filtered after learning clojure end seeing the light. I hope one day you are also saved.

OOP is the most suitable paradigm for cognitive ergonomics of human minds.
the only reason why would anybody use an other paradigm is to make formal proofs, by fp.
oop has entire ontological framework behind it to model reality. which is objectivist epistemology I think.

>>105687729
You are ignoring most of my points and not addressing others. Discussing this is a waste of time if the other party disregards everything that the other party says. You are larping as some know-it-all better-than-thou OOP engineer. The worst kind. You assessed me as a young postgrad without real experience and don't care what I have to say. And ironically the way you speak look like something someone that only used OOP and is completely enamored with it would say. You are not reading what I've written, because you think you are superior to me. You just come across some statement and quickly pick it up for your counter argument without reading a little further to see it that the point was not complete. If you actually read what I've written you wouldn't make this point now for example [1]:

[1]
>I am against "x dogma is bad, ignore it entirely" dogma;
I never said this. If you read what I've written:
>Following some arbitrary rules without your own judgement
It's not a stance of ignorance. And also at the end of the pots I said I don't mind usage of factory for object creation which literally acknowledges the pattern the GoF described in their other book.

[2]
And you wouldn't bicker and lecture me about encapsulation in every post. You were literally saying the same things I said in other words - excluding the perspectives outside OOP which I included in my definitions. OOP is just one way to view things. When I see your posts I see religious tier attachment to OOP and not seeing forest for trees if the trees are not OOPy. That is my last post, because I see you just constantly trying to come up as a winner in a debate and completely disregarding anything that doesn't suit your point of view. I don't know if it was intentional or not, but your posts are full of sophistry.

That is my last post and I don't care, because talking to you is like talking to the wall.

>>105688255
stopped following your posts at some point
I just don't get what you're even trying to say.
you said a couple of wrong facts about oop and then got corrected
now what exactly?

>>105688272
If you bothered to read you would see that my stance was not against OOP, but about dubious OOP practices that makes code more complex for no reason and doing things like "they always were done without challenging them". I literally write OOP even when I write perl, not java. But I'm not going all the way with retarded practices. Just taking the good parts. I think there are many stupid things people do in OOP that just make the code tedious to read and making working with it annoying. Java is already a verbose language and this just generates a lot of worthless code.
>you said a couple of wrong facts about oop and then got corrected
no, you were wrong and you don't want to admit that my definition of encapsulation was indeed correct as I stated in some post that what I've written would was basically what you can read on wikipedia

>>105670700 (OP)
the programming model inherently conflicts with the way cpus functions, OOP is easier for your brain to understand , but it result in inefficient code because cpus are fundamentally sequential, procedural programming is much closer to how the processor actually executes and is easier for the compiler to apply inlining optimizations. you can even go a step further and produce inlined c sphagetti to make it even faster, but will be indecipherable to most people who look at it

>>105688335
>dubious OOP practices that makes code more complex for no reason
like what? I see you gave getter/setters as examples of unneeded encapsulations but those are very much needed because any'thing' an object exposes should be an abstract entity because otherwise you depend on the implementation details of that class. what if it actually happens and you need to alter the behavior of accessing to X integer? If you dont have a getter you're fucked because that means you have to change your interfaces of your class and any class that depends on it. These kinds of things what makes OOP code unreadable because there's no uniformity across codebases or different parts of the same project.
>I think there are many stupid things people do in OOP that just make the code tedious to read and making working with it annoying
imagine and architect or an non-cs engineer complaining about methods and practices that developed throughout years to make their job more managable and better overall. this is how ridiculous that sounds. rejecting oop practices because they initially look complex makes no sense. well, maybe not if you're writing fizzbuzz.
>no, you were wrong
not the same person
>>105688346
>but it result in inefficient code because cpus are fundamentally sequential
I think you're mistaking oop with fp

>>105688255
>You are ignoring most of my points and not addressing others
I pick the points that I think can drive a discussion; I ignore points that I find are just ramblings or otherwise have no point to discuss, or themselves ignore a point because then it would just be an endless loop
I also don't address points I generally agree with or have no strong opinion about since there's nothing to discuss there - addressing each point or sentence would make the posts too long and only dilute the stronger points
if you feel very strong about a specific point, maybe make a separate post focused just on that

>I never said this.
please clarify what you meant by >>105685440
>But my stance is not that OOP is bad, but using following a dogma as some grifters like Uncle Bob preach. Have you seen the code in his book? It bad.
maybe I did miss something in your post, but I see only complete criticism of SOLID and Clean Code, as if there is no value to be found in either, and dismissing it as "dogma". I find that stance (not just to those two, but in general) to be wrong, hence the comment:
>I am against "x dogma is bad, ignore it entirely" dogma

>>105688272
>my stance was not against OOP, but about dubious OOP practices that makes code more complex for no reason and doing things like "they always were done without challenging them"
on the surface the point itself has nothing to challenge or disagree with
the pivot point is that many OOP practices are considered to have "no reason" or similar, and are thus dismissed, but in fact many of them have good reasoning that's just not commonly explained or expressed, or are explained in a wrong way that doesn't encourage people to apply them

>you were wrong and you don't want to admit that my definition of encapsulation was indeed correct as I stated in some post that what I've written would was basically what you can read on wikipedia
your definition was only correct on the mechanics/implementation details, but not the purpose of it

oops, accidentally quoted wrong post

discussions about OOP are pointless without code examples. people are talking imaginary bad/good that doesn't exists

>>105688487
a cpu has no concept of objects, with OOP the compiler has to deal with it and it does not usually produce the most optimal code, at least when we're talking about C .

>>105688346
>>105688757
Code that is "easier for the brain to understand" is exactly what you want in many cases.
Optimizing CPU usage in an application that isn't CPU-bound is nonsense.

>>105688757
desu havent looked at assemblies of many oop code before but it's not as abstracted from the machine as fp I presume. object methods are just indirect calls and they can be optimized. many big C projects also heavily use methods for abstraction so it's not very much different from what you would do on C
maybe keep attention on cache locality.