Świetna dyskusja dlaczego OOP ssie.

No i dalej każdy samodzielny lub będący modułem kod pisany funkcyjnie jest wedłóg twej zachłannej teorii kodem zorientowanym obiektowo.

Kompletnie nie zrozumiałeś i nadintepretujesz moją wypowiedź. Siedem razy użyłem słowa "postrzegać". Przypominam, że wg słownika:
zobaczyć i ocenić kogoś w określony sposób
https://sjp.pwn.pl/szukaj/postrzega%C4%87.html
co oznacza, że zawsze mamy do czynienia z osobą, która dokonuje oceny. Tą osobą jest programista.

I znów będzie to kod zorientowany obiektowo.

Nic takiego nie napisałem.

Raczej jest tak, że masz:

1. rzeczywistość
2. pewne słowo / pojęcie (np. "OOP", "funkcje" itp.)
3. człowieka, który używa tego pojęcia

ja twierdzę, że patrząc na rzeczywistość (1) człowiek (3) może używać różnych słów (2). Nie znaczy to, że automatycznie rzeczywistość (1) się zamieni.

Programiści wymyślają sobie różne teorie (np. OOP) ale nie znaczy to, że OOP istnieje w sposób realny. Więc nie mógłbym argumentować I znów będzie to kod zorientowany obiektowo. bo byłby to jakiś absurd (żaden kod nie jest zorientowany obiektowo ani w jakikolwiek inny sposób, bo to bezduszne literki. To ludzie orientują kod).

Znajdź mi w ogóle artykuł naukowy stosujący twoją definicję,

Odsyłam do podstaw logiki najpierw, do semiotyki, lingwistyki, filozofii... Generalnie do wszystkiego, co pozwoli ci lepiej rozumieć relacje między rzeczywistością("odpalam program, działa"), językiem (np. OOP, programowanie funkcyjne itp) a użytkownikiem języka(programistą). Ew. jak chcesz czegoś łatwiej strawnego, to nawet NLP czy obejrzenie Matrixa albo obradów Sejmu by pomogło, żeby uświadomić sobie, że słowa(pojęcia/teorie/myśli itp.) a rzeczywistość to nie jest to samo.

Bo na razie to tkwisz w przekonaniach rodem z podstawówki.

Co nie jest dobre, programista akurat powinien umieć rozróżniać abstrakcję od rzeczywistości/empirii, w końcu na tym polega między innymi programowanie. Więc jeśli nie jesteś w stanie dojrzeć tego, że OOP, programowanie funkcyjne, proceduralne czy cokolwiek innego to zaledwie abstrakcja, system pojęciowy a nie rzeczywistość, to nic dziwnego, że masz problem ze zrozumieniem posta i tego, że nigdzie nie napisałem, że "coś jest kodem zorientowanym obiektowo", tylko, że można to tak postrzegać. Czyli zaakceptowałem możliwość, że ktoś to tak postrzega.

EDIT: w sumie doprecyzowałbym jeszcze swoją wypowiedź. Przyjmując za rzeczywistość fakt, że "program działa", a kod to "literki", dalej będziemy się poruszać w obrębie programowania. A często ważniejsza jest dziedzina, dla której się pisze ten kod. Jak się robi np. program dla szpitala, to rzeczywistością będzie raczej fakt, że lekarze leczą a pacjenci są chorzy. Programowanie ma tylko pomóc w organizacji szpitala (np. przez umawianie wizyt). OOP / DDD itp. mogą być pomocne w tym względzie, że pozwalają na przyjazne dla człowieka zamodelowanie rzeczywistości i przetłumaczenie rzeczywistości na język zrozumiały przez komputer, np. mogą być obiekty lekarze, przyjmujące obiekty pacjent itp. I to jest wg mnie ważne w OOP, pewna wartość dodana, atrakcyjność tego paradygmatu. Z drugiej strony podobne rzeczy można modelować w sposób relacyjny w bazach danych, więc raczej postawiłbym obok siebie OOP a relacyjność a la bazy danych, jako 2 sposoby na rozwiązanie podobnych problemów.

Chociaż w OOP jest położony nacisk na zachowanie, interakcję, a w bazach danych na konkretny stan, w jakim się dana rzecz znajduje w danym momencie (czyli np. pola w rekordzie).

LukeJL napisał(a):

No i dalej każdy samodzielny lub będący modułem kod pisany funkcyjnie jest wedłóg twej zachłannej teorii kodem zorientowanym obiektowo.

Kompletnie nie zrozumiałeś i nadintepretujesz moją wypowiedź. Siedem razy użyłem słowa "postrzegać". Przypominam, że wg słownika:
zobaczyć i ocenić kogoś w określony sposób
https://sjp.pwn.pl/szukaj/postrzega%C4%87.html
co oznacza, że zawsze mamy do czynienia z osobą, która dokonuje oceny. Tą osobą jest programista.

No to my tu rozmawiamy o paradygmacie, czyli zdefiniowanym zbiorze założeń i praktyk, czy o percepcji świata w stylu filozoficznym?

I znów będzie to kod zorientowany obiektowo.

Nic takiego nie napisałem.

Owszem. Wynika to z twojej definicji. Zawęź definicję a unikniesz takich wpadek. To, że nie podobają ci się wnioski które z niej płyną, nie oznacza jeszcze, że inni ją źle interpretują.

Raczej jest tak, że masz:

1. rzeczywistość
2. pewne słowo / pojęcie (np. "OOP", "funkcje" itp.)
3. człowieka, który używa tego pojęcia

ja twierdzę, że patrząc na rzeczywistość (1) człowiek (3) może używać różnych słów (2). Nie znaczy to, że automatycznie rzeczywistość (1) się zamieni.

To że ktoś coś nazwie obiektem, nie oznacza, że ma to związek z programowaniem obiektowym.

Programiści wymyślają sobie różne teorie (np. OOP) ale nie znaczy to, że OOP istnieje w sposób realny. Więc nie mógłbym argumentować I znów będzie to kod zorientowany obiektowo. bo byłby to jakiś absurd (żaden kod nie jest zorientowany obiektowo ani w jakikolwiek inny sposób, bo to bezduszne literki. To ludzie orientują kod).

There is no spoon!

Znajdź mi w ogóle artykuł naukowy stosujący twoją definicję,

Odsyłam do podstaw logiki najpierw, do semiotyki, lingwistyki, filozofii...

Dziękuję, ale ukończyłem edukację kierunkową z informatyki na czołowej uczelni. Mieliśmy tam wystarczająco dużo logiki i teorii mnogości, żeby widzieć dziury w twoim konstrukcie. Poza tym chodzi o prace w zakresie informatyki. Jak będę dyskutować o czasie w kontekście fizyki, to będę w ramach fizyki właśnie, a nie filozoficznych. Zmienisz dziediny tam gdzie jest ci to wygodne.

Generalnie do wszystkiego, co pozwoli ci lepiej rozumieć relacje między rzeczywistością("odpalam program, działa"), językiem (np. OOP, programowanie funkcyjne itp) a użytkownikiem języka(programistą). Ew. jak chcesz czegoś łatwiej strawnego, to nawet NLP czy obejrzenie Matrixa albo obradów Sejmu by pomogło, żeby uświadomić sobie, że słowa(pojęcia/teorie/myśli itp.) a rzeczywistość to nie jest to samo.

Zmieszałeś ze sobą kilka dziedzin, tam gdzie nie ma takiej potrzeby.

Bo na razie to tkwisz w przekonaniach rodem z podstawówki.

Ty tak sądzisz. Jakbyś pisał rozprawy naukowe tak jak swoje posty o OOP to byś wyleciał ze swojego instytutu naukowego za lanie wody bez treści.

Co nie jest dobre, programista akurat powinien umieć rozróżniać abstrakcję od rzeczywistości/empirii,

No właśnie dajesz medalowy popis braku umiejętności rozróżnienia jednego od drugiego. Tylko czemu to mi przypisujesz takie cechy? To ta słynna projekcja?

w końcu na tym polega między innymi programowanie. Więc jeśli nie jesteś w stanie dojrzeć tego, że OOP, programowanie funkcyjne, proceduralne czy cokolwiek innego to zaledwie abstrakcja, system pojęciowy a nie rzeczywistość, to nic dziwnego, że masz problem ze zrozumieniem posta i tego, że nigdzie nie napisałem, że "coś jest kodem zorientowanym obiektowo", tylko, że można to tak postrzegać. Czyli zaakceptowałem możliwość, że ktoś to tak postrzega.

Dużo słów, mało treści. Reagujesz ślinotokiem na temat ogólników, tam gdzie pytają cię o szczegóły.

Dużo słów, (...) Reagujesz ślinotokiem na temat ogólników, tam gdzie pytają cię o szczegóły.

Bo chciałem być wreszcie osobą, która w jednym długim poście rozwiąże problem, który przewija się przez 25 stron, a polega na tym, że nie rozumiesz postów innych użytkowników i po prostu trollujesz/trollujecie (bo nie wiem czy jesteś 1 osobą, czy w kilka osób dyskutujecie, bo macie inne nicki, ale styl pisania podobny. Jeszcze jakieś banowanie było po drodze). Niestety mam wrażenie, że jak ktoś chce trollować, to zawsze będzie to robić, bo osoby poddające się trollingowi nie myślą nawet, żeby próbować zrozumieć cokolwiek, co druga osoba pisze, a tylko o tym, żeby przepchnąć swoje z góry postawione tezy, niezależnie od argumentów (co sprawia, że jakakolwiek sensowna dyskusja staje się niemożliwa)

mało treści.

Akurat treści jest dużo. To, że nie rozumiesz, to twoja sprawa.

To że ktoś coś nazwie obiektem, nie oznacza, że ma to związek z programowaniem obiektowym.

Programowanie obiektowe to sposób nazywania rzeczywistości, więc jakiś związek ma.

Owszem. Wynika to z twojej definicji. Zawęź definicję a unikniesz takich wpadek.
To, że nie podobają ci się wnioski które z niej płyną, nie oznacza jeszcze, że inni ją źle interpretują.

Chwyt erystyczny nr. 12. Spoko. Jeszcze parę innych by się znalazło.

LukeJL napisał(a):

Dużo słów, (...) Reagujesz ślinotokiem na temat ogólników, tam gdzie pytają cię o szczegóły.

Bo chciałem być wreszcie osobą, która w jednym długim poście rozwiąże problem, który przewija się przez 25 stron, a polega na tym, że nie rozumiesz postów innych użytkowników i po prostu trollujesz/trollujecie (bo nie wiem czy jesteś 1 osobą, czy w kilka osób dyskutujecie, bo macie inne nicki, ale styl pisania podobny. Jeszcze jakieś banowanie było po drodze). Niestety mam wrażenie, że jak ktoś chce trollować, to zawsze będzie to robić, bo osoby poddające się trollingowi nie myślą nawet, żeby próbować zrozumieć cokolwiek, co druga osoba pisze, a tylko o tym, żeby przepchnąć swoje z góry postawione tezy, niezależnie od argumentów (co sprawia, że jakakolwiek sensowna dyskusja staje się niemożliwa)

mało treści.

Akurat treści jest dużo. To, że nie rozumiesz, to twoja sprawa.

No cóż, nie każdy wspina się na te same szczeble ewolucji mózgu jak twój. Pytanie, czy to, że wypowiedź jest zrozumiała tylko dla ciebie to dobra strona twej wypowiedzi, czy nie?

To że ktoś coś nazwie obiektem, nie oznacza, że ma to związek z programowaniem obiektowym.

Programowanie obiektowe to sposób nazywania rzeczywistości, więc jakiś związek ma.

Nie. Programowanie zorientowane obiektowo to paradygmat, a nie rozmówki starszych panów przy ciasteczku i herbatce o tym czym jest rzeczywistość w oparciu o cienie rzucane na ściane jaskini.

Owszem. Wynika to z twojej definicji. Zawęź definicję a unikniesz takich wpadek.
To, że nie podobają ci się wnioski które z niej płyną, nie oznacza jeszcze, że inni ją źle interpretują.

Chwyt erystyczny nr. 12. Spoko. Jeszcze parę innych by się znalazło.

Tu nie trzeba się uciekać do erystyki, wystarczy że nie umiesz zakreślić łam obiektu w paradygmacie obiektowym.

Podsumowując: nikt nie wie czym jest ów Object w OOP. Czyli OOP to buzzword może nawet i scam.

OOP to szerokie pojęcie, tak samo jak FP. W przypadku FP też można się sprzeczać czy dany język jest FP lub na ile jest FP, a na ile nie. Podobnie samo pojęcie język programowania jest dość nieuchwytne. Czy SQL jest językiem programowania? Okazuje się, że wykorzystując CTE (common table expressions) i windowing można w PostgreSQL osiągnąć kompletność Turinga bez procedur: https://stackoverflow.com/q/900055

Zamiast się przypieprzać do szczegółów i na ich podstawie kwestionować całą systematykę pojęć programistycznych trzeba spojrzeć na języki badając ich przystosowanie do konkretnego podejścia do organizacji kodu. Mimo iż da się w C programować obiektowo to jednak C nie jest do tego przystosowany - dla przykładu C nie ma wsparcia dla hermetyzacji. Można to wsparcie osiągnąć dodatkowymi narzędziami, ale dalej nie zmienia to nic w kwestii języka C.

Narzędzie X + język C to już zupełnie inna kwestia niż sam język C. Podobnie transpiler z języka X do języka JavaScript to zupełnie coś innego niż sam JS. Mamy implementacje Haskellopodobnych języków z kompilatorami tłumaczącymi kod na JSa (np PureScript) - czy to oznacza, że JS jest funkcyjny? Absolutnie nie. Czy można ręcznie pisać kod w JS taki jak wypluwa PureScript? Tak, ale to zupełnie nie ma sensu.

Java, C#, C++ itd są językami OOP, ale wcale nie utrudniają programowania proceduralnego. Można zrezygnować z hermetyzacji, dziedziczenia, itd posługiwać się tylko i wyłącznie statycznymi metodami oraz obiektami bez metod (czyli faktycznie strukturami). Nie jest to wcale bolesne w momencie pisania takiego kodu. Natomiast programowanie zorientowane obiektowo w C jest już upierdliwe. To co w Javce jest naturalne (np metody wirtualne), w C trzeba okodować ręcznie. Podobnie to co kompilator Javy sam sprawdza (np hermetyzacja) w C trzeba sprawdzić dodatkowym narzędziem.

Każdą abstrakcję można nadużyć. Można nadużyć dziedziczenia, ale można też nadużyć funkcji wyższych rzędów i składać je w niepotrzebnie skomplikowane hierarchie (to jest szczególnie bolesne jeżeli organizujemy tak kod biznesowy, zamiast używać funkcji wyższych rzędów w kombinatorach z bibliotek ogólnego przeznaczenia). Nawet klepiąc ręcznie w C mechanizmy, które w językach wyżej poziomowych są wbudowane można się zapędzić i zakodować mnóstwo rzeczy niepotrzebnie. Moim zdaniem jest to ludzka rzecz, bo zwykle zanim się dojdzie do elegancko i sensownie napisanego prostego w zrozumieniu kodu to trzeba go wielokrotnie przerzeźbić. W momencie rzeźbienia wchodzi w grę wsparcie od IDE - jeżeli IDE nas wspiera w tym procesie to refaktor idzie gładko i szybko dochodzimy do kodu, który jest w miarę dobrze napisany. Jeśli IDE nie daje rady automatyzować wielu rzeczy to refaktor jest żmudny i się go olewa. Programowałem w wielu językach (C, C++, JavaScript, Python, Java, Scala, Rust itd) i moim zdaniem najlepsze narzędzia są do Javy - IntelliJ IDEA potrafi mocno wesprzeć proces analizy kodu i jego refaktoru. Dzięki temu stałe podnoszenie jakości kodu (mimo wrzucania nowych funkcjonalności na bieżąco) jest zadaniem wykonalnym i jak najbardziej rozsądnym.

Ostatnio do powrotu do tematu OOP zainspirowała mnie dyskusja dwóch panów: autora książki "Clean Code", oraz autora nagrania "Clean code, horrible performance". Panowie prowadzą sobie teraz pisemną dyskusję pod adresem: https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md, ale akcja rozwija się raczej powoli. Jednak zainspirowali mnie, aby samemu coś się na ten świetny temat wypowiedzieć.

Jest w programowaniu, czy ogólnie w informatyce, jakaś pula bardzo udanych abstrakcji: deskryptor pliku, system plików w ogólności, sterownik urządzenia danej kategorii,... I te przykłady są wykorzystywane przez zwolenników OOP jako argumenty, że podejście OOP jest właściwe. Według mnie jednak te dobre abstrakcje, to rzadkie wyjątki a nie norma. Do większości problemów, z którymi w ramach programowania się stykamy, nie daje się dobrać dobrej abstrakcji, więc "zorientowanie" się na ich tworzenie (jak w programowaniu "zorientowanym obiektowo"), jest błędem. Należy zorientować się na rozwiązywanie problemów metodami proceduralnymi, a nie obiektowymi.

Zorientowanie się na obiekty mógłbym porównać do tego, jakby jakaś drużyna piłkarska prowadziła grę zorientowaną na gole z przewrotki, albo zza połowy. Takie bramki oczywiście się zdarzają i sprawiają wiele radości, ale orientując swoją grę na takie rzadko kiedy skuteczne zagrania, osiągnie się gorszy wynik, niż orientując grę na coś prostszego. Ktoś jeszcze może zechce się wypowiedzieć?

Nie czytałem jeszcze polemiki, ale póki co obejrzałem ten filmik. I trochę gość odkrywa Amerykę w tym momencie.

To, że pisanie w celu wydajności nie zawsze się pokrywa z pisaniem eleganckim jak w książkach przykazali, to od dawna wiadomo. Przy czym istnieją bardziej stonowane analizy, gdzie ludzie opowiadają, jak robią soft (szczególnie gamedev) i że okazuje się, że książkowo pojmowany czysty kod, OOP itp. nie zawsze się sprawdzają pod kątem wydajności czy skalowalności i że lepsze jest podejście data driven, ECS (entity component model) i że wskaźniki złe, żeby dbać o "locality" w dostępie do danych itp.

Przy czym ten filmik "Clean" Code, Horrible Performance być może jest również wartościowy jako pewna analiza, ale nie podoba mi się ton tego gościa, który bardzo zero jedynkowo stawia sytuację i okazuje się nagle, że czysty kod jest głównym powodem zamulania apek. I że jak tylko zrezygnujemy z niego, to nagle magicznie przyśpieszą, bo jakiś microbenchmark tak pokazuje XD

Trochę bullshit. Obstawiam, że większość apek zamula nie dlatego, że ludzie piszą czysty kod, tylko dlatego, że większość programistów ani się nie zna na wydajności ani nie zwraca na nią uwagi, a muszą zaimplementować setkę nowych ficzerów zamówionych przez biznes, który też ma w dupie wydajność.

Troll anty OOP napisał(a):

Należy zorientować się na rozwiązywanie problemów metodami proceduralnymi, a nie obiektowymi.

To jest ciekawe ale ja jednak wolę podejście trochę zalatujące realizmem magicznym. Jak np. w SQL - mówisz i masz.

Zgadzam się z @LukeJL. Mnie też irytuje jak się opisuje tylko jako białe, albo czarne. Ja na przykład mogę sobie pozwolić na pisanie OOP i sobie klocki układać jak należy, bo wydajność u mnie nie jest taka ważna (poza kilkoma obszarami krytycznymi) i czy mi się kod wykona w 100ms czy w 2s to wsio ryba - użytkownik nie zauważy.

A co do jakości aplikacji, to nie wiem czy widzieliście kod powstały w innych firmach? Ja pracuję dużo z zewnętrznymi SDK i powiem wam, że poraża mnie nie raz jakie badziewie ludzie produkują. Prym wiodą Chińczycy, ale i ja bym się wstydził na miejscu niektórych naszych rodzimych programistów.

Mnie akurat ton nie irytuje oraz łatwo jestem w stanie zrozumieć skąd on się bierze: z powszechności poglądów pro-OOP i przedstawiania OOP jako bezdyskusyjnie lepszego sposobu programowania, z punktu widzenia utrzymania. Ta lepszość w utrzymaniu wcale nie jest taka oczywista i wymagałaby jakiegoś poważniejszego argumentu, niż że piszący książkę tak sądzi. Albo stwierdzenia że to jego osobista preferencja, a wielu innych programistów lepiej utrzymuje kod w innych stylach (mam nadzieję, że zalinkowana dyskusja nie skończy się na tym, że pro-OOP-owiec próbuje zbyć dyskutanta, że jest to łatwiejsze w utrzymaniu, a wydajność w jego konkretnych przypadkach nie jest ważna; bo na razie do tego punktu doszła).

Troll anty OOP napisał(a):

Mnie akurat ton nie irytuje oraz łatwo jestem w stanie zrozumieć skąd on się bierze: z powszechności poglądów pro-OOP i przedstawiania OOP jako bezdyskusyjnie lepszego sposobu programowania, z punktu widzenia utrzymania.

Ale czy w tym filmiku chodziło o OOP konkretnie? W sumie coś tam pokazywał, ale ja nawet się nie dowiedziałem, skąd wynikała różnica wydajności. Odniosłem wrażenie, że skok wydajności pojawił się z powodu tego, że autor zoptymalizował swój program używając różnych sztuczek (na dodatek minął się z prawdą, że go nie zoptymalizował - a sorry, przerobienie programu z jednej formy na drugi w celu przyśpieszenia to właśnie optymalizacja).

No i atakowanie polimorfizmu jako idei jest słabe, biorąc pod uwagę, że wiele jest jego odmian (nawet to, co tam napisał, też można by nazwać polimorfizmem - i teraz - co jeśli mielibyśmy na tyle zaawansowany kompilator, który by zamieniał polimorfizm pisany w sposób OOP do serii tego typu bardziej prymitywnych instrukcji? Wtedy cała argumentacja przestaje mieć sens).

zalinkowana dyskusja nie skończy się na tym, że pro-OOP-owiec próbuje zbyć dyskutanta, że jest to łatwiejsze w utrzymaniu, a wydajność w jego konkretnych przypadkach nie jest ważna; bo na razie do tego punktu doszła).

Ale jak ma się skończyć, skoro autor filmików przybrał pozę oblężonej twierdzy? Że oto jest możliwość pisania optymalnego kodu, ale ideologia Czystego Kodu chce ją zniszczyć? To trochę jak z LGBT w tym momencie...

Wolałbym, żeby to było tak, że autor pokazuje te swoje sztuczki, ale potem tłumaczy dlaczego to jest szybsze. Niby coś tam tłumaczył, ale jakoś krótko i skupił się na atakowaniu Czystego Kodu.

Z drugiej strony gdyby ten filmik był merytoryczny, to pewnie byśmy o nim nawet nie usłyszeli, bo pełno jest bardziej merytorycznych filmów na YT w tym temacie i jakoś nie dyskutujemy o tym. Jednak click baiting i kontrowersje się klikają.

LukeJL napisał(a):

Ale czy w tym filmiku chodziło o OOP konkretnie?

O co konkretnie chodziło, było podane w nagraniu - używanie funkcji wirtualnych zamiast switch-case i bezpośredniego dostępu do pól struktury.

W sumie coś tam pokazywał, ale ja nawet się nie dowiedziałem, skąd wynikała różnica wydajności. Odniosłem wrażenie, że skok wydajności pojawił się z powodu tego, że autor zoptymalizował swój program używając różnych sztuczek (na dodatek minął się z prawdą, że go nie zoptymalizował - a sorry, przerobienie programu z jednej formy na drugi w celu przyśpieszenia to właśnie optymalizacja).

Zgodzę się, że te kroki dalsze po przerobieniu na switch-case, to już optymalizacja, ale optymalizacja niewiele wymagająca, a niewykonalna w implementacji "clean code". A skąd konkretnie różnica wydajności to by trzeba analizować kod asemblerowy, a to już by wymagało dużo więcej czasu. Ja rozumiem jego "nie optymalizował", że nie eksperymentował z technikami, które mogłyby zwiększyć wydajność, kosztem zwiększonej komplikacji kodu.

No i atakowanie polimorfizmu jako idei jest słabe, biorąc pod uwagę, że wiele jest jego odmian (nawet to, co tam napisał, też można by nazwać polimorfizmem - i teraz - co jeśli mielibyśmy na tyle zaawansowany kompilator, który by zamieniał polimorfizm pisany w sposób OOP do serii tego typu bardziej prymitywnych instrukcji? Wtedy cała argumentacja przestaje mieć sens).

Kompilatory istnieją już dziesięciolecia i nie ma powodu by sądzić, że co prawda takiego rozwiązania nie ma obecnie, ale jego pojawienie się jest tuż-tuż. Z resztą, wtedy dyskusja dodatkowo traciłaby sens z tego powodu, że taką translację w locie z jednego stylu na drugi, mógłby wykonywać także edytor - i wtedy osoba preferująca jeden styl pisałaby w nim, druga mogłaby sobie zmienić przełącznik w edytorze i obejrzeć ten sam kod ale przetłumaczony na styl preferowany przez nią. Ale nie mamy takich rozwiązań, więc dyskusja o tym, który styl lepszy, ma sens.

Ale jak ma się skończyć, skoro autor filmików przybrał pozę oblężonej twierdzy? Że oto jest możliwość pisania optymalnego kodu, ale ideologia Czystego Kodu chce ją zniszczyć? To trochę jak z LGBT w tym momencie...

Ja odbieram tę dyskusję inaczej. Moim zdaniem Casey pisze wprost o co mu chodzi, natomiast Bob rozwadnia dyskusję jakimiś wstawkami o tym, że cieszy się że dyskusja jest kulturalna itp. Nie odbieram sposobu pisania tego pierwszego jako "oblężona twierdza", lecz oszczędzanie słów.

Z drugiej strony gdyby ten filmik był merytoryczny, to pewnie byśmy o nim nawet nie usłyszeli, bo pełno jest bardziej merytorycznych filmów na YT w tym temacie i jakoś nie dyskutujemy o tym. Jednak click baiting i kontrowersje się klikają.

Film w oczywisty sposób jest merytoryczny - zilustrowany przykładami i pomiarami. Kontrowersyjność i merytoryczność mogą iść z sobą w parze.

Co ciekawe ktoś przeportował to do Rusta i też porobił benchmarki: https://www.reddit.com/r/rust/comments/11fkfib/i_ported_casey_muratoris_c_example_of_clean_code/
wychodzi na to, że dużą wagę ma uporządkowanie danych w pamięci: https://www.reddit.com/r/rust/comments/11fkfib/comment/japvaoa/?utm_source=reddit&utm_medium=web2x&context=3

OOP jest scentralizowane. Jeden obiekt rządzi wszystkim i woła obiekty, które bezpośrednio mu podlegają, a te podlegające odnoszą się do swoich itd

W takim układzie uznaję, że pierwsze skrzypce w OOP gra kompozycja i to za jej sprawą dochodzi do operowania na współdzielonym mutowalnym stanem. Tu z miejsca płacimy ekstra narastający podatek od mutowalności, i również z miejsca utrudniamy sobie zadania na pograniczu synchronizacji i zachowania spójności w systemie.

Kompozycja obiektów prowadzi również do powstania nadmiernej specyficzności, niemal każde powiązanie obiektów skutkuje powstaniem jakiegoś osobnego i nieplanowanego API.

Każde API wznosi kod na wyższy semantyczny poziom (dodatkowy szum, i dodatkowe sztuczne ograniczenia narzucone przez interfejs). Przykładowo kod wewnątrz klasy mógłby robić jakieś requesty, ale klasa i tak stara się to ukryć więc gdy dojdzie do jakiegoś problemu to prędzej rzuci własnym wyjątkiem.

Te 3 powyższe punkty osobno nie są tak groźne, ale razem sprawiają, że zrozumienie biznesowej procedury pod kątem poprawności wymagań, zachowania spójności znacząco się komplikuje. Nie można tego czytać linia po linii z pełnym zrozumieniem, lecz trzeba to badać, a właściwie skakać po definicjach w kodzie, a co jakiś czas na nowo wracać, bo coś znów się zmieni.

Doświadczenie porównywalne z czytaniem umów od ubezpieczalni.

Muszę przyznać, że jestem rozczarowany dyskusją, o której wspomniałem i która odbywa się pod linkami:
https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md
https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa-2.md

Myślałem, że autor "Clean code", skoro skusił się na taką dyskusję, będąc osobą bardziej rozpoznawalną, będzie miał coś więcej do przekazania. Aktualnie ostatnie przemyślenie, na zarzut że stosując techniki "clean code", traci się wydajność, nie zyskując nic w zamian (łatwości tworzenia programu), autor miał do powiedzenia w przybliżeniu tyle:

"I have a style that I have refined through hard experience over the last 50 years; and I believe saves me cycles. I recommend it to others based upon that experience and that belief." [...] "Can I prove my belief? Not mathematically; just as I am sure that you cannot mathematically prove that your favorite style saves more or less programmer cycles than mine."

Po autorze książki oczekiwałbym więcej.