drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2025-03-15 23:42:07 +01:00
parent 11eb6b01b2
commit 6d2a78f17c
37 changed files with 2131 additions and 1952 deletions
Download patch file Download diff file Expand all files Collapse all files

4
oop.md
View file

@ -30,8 +30,8 @@ Just a brief summary of why the mainstream OOP is a fail:
- For simple programs (which most programs should be) such as many [Unix](unix.md) utilities OOP is simply completely unnecessary.
- **It is in conflict with [Unix philosophy](unix_philosophy.md)** -- Unix philosophy advocates for making small programs that do one task well and for these, as mentioned above, OOP is more of a burden. "Doing one thing well" is a similar definition of object in OOP and here the two paradigms clash -- if we adopt Unix philosophy, any program should basically be just a single object, negating the whole purpose of OOP. To truly make use of OOP we have to accept that a program will consist of multiple objects, i.e. that it will do several things at once -- in other words **OOP advocates for creating monolithic programs** ([bloat](bloat.md)).
- **OOP languages make you battle artificial restrictions** rather than focus on solving the problem at hand.
- **OOP is designed for bad programmers on the detriment of good programmers**. Good languages always try to give you freedom, their value is in providing features you didn't have before and which can help you achieve something better, without forcing you to use those features -- they are purely there as a completely voluntary choice for the expert who knows what he's doing, when to use a certain feature and when to NOT use it. OOP however does the opposite, **it artificially LIMITS what you can do**, for example by enforcing encapsulation or forcing everything to be object, even if it doesn't have to be so -- it's quite literally like [DRM](drm.md), an artificial obstacle -- it assumes the programmer is stupid and has to be prevented from doing something, ENFORCED to program certain way because he doesn't know how to program well, which is sadly true in [capitalism](capitalism.md) where hordes of stupid people are made into programming slaves, but it hurts the actually skilled programmers. It's like forcing a life jacket on anyone who goes swimming -- it will probably be safer for the majority of average and bad swimmers, but if you're an Olympic level competitive swimmer, it will be a disaster, it will just put you on the same level as the average swimmer.
- Great number of the supposed "features" and [design patterns](design_pattern.md) (setters/getters, singletons, inheritance, ...) turned out to actually be [antipatterns](antipatter.md) and burdens -- this isn't a controversial statement, even OOP proponents usually agree with this, they just try to somehow document and dodge all the traps.
- **OOP is designed for bad programmers on the detriment of good programmers**. OOP is essentially about technically enforcing "best practices" and as someone once wisely said, **best practices just formalize mediocrity**. Good languages always try to give you [freedom](freedom.md), their value is in providing features you didn't have before and which can help you achieve something better, without forcing you to use those features -- they are purely there as a completely voluntary choice for the expert who knows what he's doing, when to use a certain feature and when to NOT use it. OOP however does the opposite, **it artificially LIMITS what you can do**, for example by enforcing encapsulation or forcing everything to be object, even if it doesn't have to be so -- it's quite literally like [DRM](drm.md), an artificial obstacle -- it assumes the programmer is stupid and has to be prevented from doing something, ENFORCED to program certain way because he doesn't know how to program well, which is sadly true in [capitalism](capitalism.md) where hordes of stupid people are made into programming slaves, but it hurts the actually skilled programmers. It's like forcing a life jacket on anyone who goes swimming -- it will probably be safer for the majority of average and bad swimmers, but if you're an Olympic level competitive swimmer, it will be a disaster, it will just put you on the same level as the average swimmer.
- Great number of the supposed "features" and [design patterns](design_pattern.md) (setters/getters, singletons, inheritance, ...) backfired horribly and turned out to actually be [antipatterns](antipatter.md) and burden -- this isn't a controversial statement, even OOP proponents usually agree with this, they just try to somehow document and dodge all the traps.
- OOP as any higher abstraction very often comes with **overhead, memory footprints and performance loss** ([bloat](bloat.md)) as well as **more complex [compilers](compiler.md), language specifications, more [dependencies](dependency.md), [magic](magic.md) etc.**
- The relatively elegant idea of pure OOP didn't catch on and the **practically used OOP languages are abomination hybrids of imperative and OOP paradigms** that just take more [head space](head_space.md), create [friction](friction.md) and unnecessary issues to solve. Sane languages now allow the choice to use OOP fully, partially or avoid it completely, which leads to a two-in-one overcomplication.
- The naive idea of OOP that the [real world](irl.md) is composed of nicely defined objects such as `Human`s and `Tree`s also showed to be completely off, we instead see shit like `AbstractIntVisitorShitFactory` etc. Everyone who ever tried to make some kind of categorization knows it's usually asking for trouble, categories greatly overlap, have unclear borders, multiple parents etcetc.