Świetna dyskusja dlaczego OOP ssie.

Wiesz, jak ktoś lubi dokładać sobie roboty i sadzić sążniste abstrakcje (musiały takie być, skoro wyprodukowano 9MB binarkę w C++) tam gdzie wystarczy kilka funkcji na skrzyż, to jego sprawa. Ale ja tego optymalnym, ani szybszym (tak w sensie zasobów jak i szybkości powstania kodu) rozwiązaniem nie nazwę.

Cały zespół pracował nad programem w którym jest kilka funkcji na krzyż? Pracujesz w zakładzie pracy chronionej?

Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.

Pokaż kod, który nie da się napisać z użyciem obiektów bądź monad, bo coś się popsuje.

Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.

W takim razie Rust odpada w przedbiegach, bo produkuje binarki cięższe od C++.

W ogóle Rust obala mit, że programowanie strukturalne jest lżejsze (ważąc binarki) od obiektowego, bo Rust jest cięższy od C++ mimo iż Rust jest strukturalny, a C++ obiektowe. Składniowo Rust też nie jest jakoś znacznie prostszy od C++, ale znaczącą przewagą nad C++em jest to, że kompilator sprawdza wiele błędów, które programista C++ musi śledzić samodzielnie (np poprawność wykorzystania sprytnych i zwykłych wskaźników, indeksy tablic, itd).

zabawni sa ci przeciwnicy oop motywujacy to wydajnoscia :)
kto by pomyslal ze tylu kernel devow sie tu zbiegnie, no ale w sumie nawet na zywo miewam bardzo opozniajace umyslowo dyskusje na temat wydajnosci oop w javie vs wydajnosci kodu proceduralnego w c/c++ do tych samych zadan.
niektorzy "low levelowcy" co to koduja od lat 80 bardzo narzekaja ze java ciezka, oop malo wydajne itp i co najsmieszniejsze to po odpaleniu profilera doskonale widac na czym tracimy cenne mikrosekundy i w 99% przypadkow jest to zwiazane z pisaniem kodu spaghetti i brakiem kontroli nad tym kiedy i jak robione jest i/o, a to cos o czym adepci asm/c powinni wiedziec.
no ale lepiej robic winowajce z oop zamiast przyznac ze jest sie dziadem i zamiast nauczyc sie rzemiosla na dzisiejszym poziomie to siedziec w strefie komfortu i narzekac na milenialsow ;)

katelx napisał(a):

[...]

Nie będę cytował całej wypowiedzi, ale to jest wręcz sztandarowy przykład, jaką argumentację stosuje mnóstwo osób podzielających mainstream-owe poglądy - czy to w kwestii OOP, czy czegokolwiek innego. Całkowity brak zainteresowania tym, by zrozumieć drugą stronę, skoro można już na starcie założyć, że dyskutant jest kretynem.

Coredump napisał(a):

Też trochę "potrolluję", jako że jestem kolejnym przeciwnikiem OOP.

Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania, ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP. I nie ma się co dziwić emocjonalnemu tonowi wielu przeciwników OOP, bo jest to na prawdę irytujące, że aby nie stosować OOP to w praktyce trzeba założyć własną firmę - swoją drogą wszechobecność OOP była jednym z czynników, że sam się na taki krok zdecydowałem.

Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.

Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.

Fajnie, że ktoś to napisał. Możecie wyśmiewać podejście programistów embedded, ale może sami kiedyś traficie na projekt gdzie nie można sobie pozwolić na rozbudowanie pamięci, bo np. system już jest gotowy i nie możemy go zmienić bo kupujemy go w całości od producenta, albo tak jak napisał przedmówca wiąże się to z kosztownymi testami EMI. Tak swoją drogą to ten projekt embedded o którym była mowa to był aplikowany w samolocie bezzałogowym. A tam nad wszystkim trzeba było panować - nad poborem prądu, masą płytki i innymi rzeczami. Przecież nie podwiesimy PC-ta pod samolotem bo dysku brakuje, bo procek nie wystarcza, prawda? Się faktycznie off-topic zrobił. EOT

Się faktycznie off-topic zrobił. EOT

No właśnie. Co ma liczenie kilku dodatkowych megabajtów do paradygmatu?

Ja czekam tylko na to, aż nasz forumowy troll przyzna się, że nieobiektowy Rust też ssie, bo ma ciężkie binarki i trudną składnię (w porównaniu do C). Mało tego - w Ruście jest dynamic dispatch (metody wirtualne) przy użyciu trait objects. Rust po prostu musi ssać.

Trzeźwy Szewc napisał(a):

Którą definicję obiektowości wykorzystujesz? Bo jest ich tak wiele, że można przebierać jak w ulęgałkach. Jeśli dla ciebie samo używanie warst abstrakcji to obiektowość, to sorry, ale ja tego nie kupuję. W ten sposób można pod OOP podciągnąć każdy większy modularny kod podciągnąć pod OOP . Co jest absurdem. Dodatkowo wytrącasz argument z rąk ludziom krzyczącym, że "C++ to nie jest prawdziwy OOP". Taka mała dywersja wewnątrz obozu? ;)

C++ to język, a OOP to paradygmat, więc jeśli ktoś nie rozumie tej różnicy, to o czym dyskutuje? Nie wiem dlaczego zakładasz, że uważam warstwy abstrakcji za tożsame za OOP. To nadinterpretacja, w oparciu o którą wyciągasz pochopne wnioski.

Jak dla mnie OOP, to naturalne przedłużenie OOA i myślenia o istocie rzeczy (żeby nie pisać brzydko ontologii), a nie programowanie w oderwaniu od zamodelowanej (OOA) "rzeczywistości". Podział na mniejsze części możesz robić niezależnie od przyjętego paradygmatu (strategia "dziel i zwyciężąj"), ale w jaki sposób tworzysz abstrakcje w kodzie? x[i] będzie abstrakcją kliknięcia w przycisk, czy może Request ? ;-) Może łatwiej myśleć o LancuchDNA, a nie o "foo **bar;"? (Dla kogoś kto to będzie później utrzymywał/rozwijał/próbował zrozumieć)

Przykład na pałę, bo nie znam się na genetyce, ale mi (może innym nie) łatwiej byłoby operować na pojęciach z tej dziedziny projektując jakiś rozwiązanie, i wiedzieć jakie są zależności między pojęciami, a nie modelować te zależności w kodzie w oderwaniu od rzeczywistych pojęć (i później napotykać sytuacje "las... (odwróć stronę) krzyży..." ), skutkujące (przypuszczenie) zmianami w kodzie wynikającymi z niekorzystania przejścia od OOA do OOP.

Trzeba używać interfejsu białkowego do oceny wyboru narzędzia w kontekście konkretnego problemu. Na pewno OOP to nie jest 42 (dla niewtajemniczonych: google: douglas adams 42), ale nie zgadzam się, że ssie.

@yarel:

x[i] będzie abstrakcją kliknięcia w przycisk, czy może Request ? ;-) Może łatwiej myśleć o LancuchDNA, a nie o "foo **bar;"?

Ni chu chu nie wiem co chciałeś tutaj przekazać.

sztandarowy przykład, jaką argumentację stosuje mnóstwo osób podzielających mainstream-owe poglądy

gdzie tam - napisalam konkretny powod dla ktorego oprogramowanie stworzone przy uzyciu oop miewa problemy z wydajnoscia.
mainstreamowe to jest gadanie ze wydajny kod to pisze sie w asm/c/c++, byle gimbus to "wie" i powtarza :)

Całkowity brak zainteresowania tym, by zrozumieć drugą stronę, skoro można już na starcie założyć, że dyskutant jest kretynem.

nie robie tak daleko idacych zalozen i jak zreszta zaznaczylam - komunikat "nie uzywam oop ze wzgledu na wydajnosc" odbieram jako "nie przyznam sie ze nie umiem pisac wydajnego kodu przy uzyciu oop bo to obciach, duzo lepiej zabrzmi jak powiem ze jestem hardkorem, low levelowcem, oop jest za wolne, ram taki cenny, kernel jest w c, napisz sterownik w javie frajerze itd itp" ;)
brak umiejetnosci kodowania w kilku roznych paradygmatach to nie jest kretynizm, to po prostu brak umiejetnosci kodowania w kilku roznych paradygmatach, za to dosc glupie jest np. hejtowanie czegos tylko dlatego ze sie tego nie ogarnia.

Coredump napisał(a):

Też trochę "potrolluję", jako że jestem kolejnym przeciwnikiem OOP.

Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania, ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP. I nie ma się co dziwić emocjonalnemu tonowi wielu przeciwników OOP, bo jest to na prawdę irytujące, że aby nie stosować OOP to w praktyce trzeba założyć własną firmę - swoją drogą wszechobecność OOP była jednym z czynników, że sam się na taki krok zdecydowałem.

Jaka w przybliżeniu działka BTW?

Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.

Otóż to. Sam ile razy w dyskusjach podawałem przykładowe rozwiązania, to zaraz kod okazywał się być "zorientowany obiektowo", bo wykorzystywał strukturę, albo wskaźnik na funkcję gdzieśtam. Ręce opadają.

Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.

W ogóle nie wiem czego oni się uczepili tego embedded, przykład został podany jako anegdotyczna ilustracja kodu mnożącego poziomy abstrakcji, tam gdzie zupełnie naturalnym, wystarczającym i optymalnym jest użycie kilku funkcji na skrzyż. W sumie nie wiem, czy to kwestia jakichś problemów ze zrozumieniem czytanego tekstu, czy braku wiary w optymalność, naturalność i czytelność takiego kodu. Do tego ten nagły skok ze środowiska embedded do desktopów i podśmiechujki "kup więcej ramu/dysku. No proszę, i to my tutaj "trollujemy"? I ja i tamta osoba jasno powiedzieliśmy, że abstrakcje można mnożyć w każdym paradygmacie, ale nie, oni dalej ciągną temat i twierdzą że to jest użyte jako argument przeciw OOP, pomimo zaprzeczenia wprost z mojej strony już jakieś 3, czy 4 razy. Ale nie, oni wiedzą lepiej.

Kwadratowy pomidor napisał(a):

Coredump napisał(a):

Też trochę "potrolluję", jako że jestem kolejnym przeciwnikiem OOP.

Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania, ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP. I nie ma się co dziwić emocjonalnemu tonowi wielu przeciwników OOP, bo jest to na prawdę irytujące, że aby nie stosować OOP to w praktyce trzeba założyć własną firmę - swoją drogą wszechobecność OOP była jednym z czynników, że sam się na taki krok zdecydowałem.

Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.

Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.

Fajnie, że ktoś to napisał. Możecie wyśmiewać podejście programistów embedded, ale może sami kiedyś traficie na projekt gdzie nie można sobie pozwolić na rozbudowanie pamięci, bo np. system już jest gotowy i nie możemy go zmienić bo kupujemy go w całości od producenta, albo tak jak napisał przedmówca wiąże się to z kosztownymi testami EMI. Tak swoją drogą to ten projekt embedded o którym była mowa to był aplikowany w samolocie bezzałogowym. A tam nad wszystkim trzeba było panować - nad poborem prądu, masą płytki i innymi rzeczami. Przecież nie podwiesimy PC-ta pod samolotem bo dysku brakuje, bo procek nie wystarcza, prawda? Się faktycznie off-topic zrobił. EOT

Zauważ zabawną sytuację - jednym z argumentów, że przeciwnicy OOP są przeciwnikami, który jest przez OOPowców wysnuwany praktycznie za każdym razem, jest "brak doświadczenia" (oczywiście biorą ten "argument" z sufitu, bez nawet zadawania sobie trudu o zapytanie wprost o doświadczenie). A tutaj proszę - rekomendacja "dokupienia więcej ramu" oraz "co się czepiać, przecież jest jeszcze miejsce i 20% procesora". Pytanie retoryczne - o czym to świadczy z ich strony?

katelx napisał(a):

sztandarowy przykład, jaką argumentację stosuje mnóstwo osób podzielających mainstream-owe poglądy

gdzie tam - napisalam konkretny powod dla ktorego oprogramowanie stworzone przy uzyciu oop miewa problemy z wydajnoscia.
mainstreamowe to jest gadanie ze wydajny kod to pisze sie w asm/c/c++, byle gimbus to "wie" i powtarza :)

Całkowity brak zainteresowania tym, by zrozumieć drugą stronę, skoro można już na starcie założyć, że dyskutant jest kretynem.

nie robie tak daleko idacych zalozen i jak zreszta zaznaczylam - komunikat "nie uzywam oop ze wzgledu na wydajnosc" odbieram jako "nie przyznam sie ze nie umiem pisac wydajnego kodu przy uzyciu oop bo to obciach, duzo lepiej zabrzmi jak powiem ze jestem hardkorem, low levelowcem, oop jest za wolne, ram taki cenny, kernel jest w c, napisz sterownik w javie frajerze itd itp" ;)

Opowiem ci małą anegdotę - istnieją sterowniki pisane w C implementujące vtable. Po to by stworzyć całą jedną instancję jakiegoś obiektu. Zgadnij co się dzieje, po usunięciu wszelkich usilnych starań tworzenia obiektowościu z kodu? Sterowniki nagle dostają przyśpieszenia. Zagadka - czy wynika to z braku umiejętności programisty zakodowania obiektowości w C w sposób efektywny, czy po prostu obiektowość jednak jest narzutem. Pozostawiam je do refleksji.

brak umiejetnosci kodowania w kilku roznych paradygmatach to nie jest kretynizm, to po prostu brak umiejetnosci kodowania w kilku roznych paradygmatach, za to dosc glupie jest np. hejtowanie czegos tylko dlatego ze sie tego nie ogarnia.

No w sumie, wielu przeciwników programowania proceduralnego, z którymi rozmawiałem przyznawało się (bywało, że z dumą) do tego nieumiejętności pisania w tym paradygmacie większych rzeczy. Oczywiście wylewali przy tym na ten paradygmat tony pomyj. Więc coś jest na rzeczy w tym co piszesz.

Zagadka - czy wynika to z braku umiejętności programisty zakodowania obiektowości w C w sposób efektywny, czy po prostu obiektowość jednak jest narzutem.

Wydajność metod wirtualnych zależy od obecności dobrego JITa z dewirtualizacją metod, escape analysis i szeregiem innych optymalizacji które uprzyjemniają programowanie. Jak chcesz zobaczyć do czego 7-letnia Java jest zdolna to zapraszam tutaj: przykład z Javy 6u24 Bez dobrego JITa OOP rzeczywiście może być zauważalnie wolniejszy od kodu proceduralnego. Jednak metody wirtualne nie są nierozerwalnie związane z OOP, bo istnieją też w nieobiektowym Ruście.

Poza tym sprawa najważniejsza: czy Rust ssie?

Wibowit napisał(a):

Zagadka - czy wynika to z braku umiejętności programisty zakodowania obiektowości w C w sposób efektywny, czy po prostu obiektowość jednak jest narzutem.

Wydajność metod wirtualnych zależy od obecności dobrego JITa z dewirtualizacją metod, escape analysis i szeregiem innych optymalizacji które uprzyjemniają programowanie. Jak chcesz zobaczyć do czego 7-letnia Java jest zdolna to zapraszam tutaj: przykład z Javy 6u24 Bez dobrego JITa OOP rzeczywiście może być zauważalnie wolniejszy od kodu proceduralnego.

Jaki JIT? Mowa o gołym sterowniku w C z vtable. Co ma do tego "wydajny JIT"? Ty naprawdę nie potrafisz trzymać się tematu kiedy zwraczasz się do współrozmówcy?

Poza tym sprawa najważniejsza: czy Rust ssie?

Nie wiem, mam to gdzieś. Chcesz się dowiedzieć to załóż sobie na to odrębny wątek, a nie wprowadzasz offtop.

Jaki JIT? Mowa o gołym sterowniku w C z vtable. Co ma do tego "wydajny JIT"? Ty naprawdę nie potrafisz trzymać się tematu kiedy zwraczasz się do współrozmówcy?

Temat brzmi "OOP ssie" czy "OOP w sterownikach ssie"?

Nie wiem, mam to gdzieś. Chcesz się dowiedzieć to załóż sobie na to odrębny wątek, a nie wprowadzasz offtop.

Rust nie jest obiektowy, a ma mnóstwo wad języków obiektowych - zwłaszcza tych, które cię prześladują.

Określ się - przeszkadzają ci metody wirtualne czy OOP sam w sobie? Tyle postów, a ty ciągle masz nowe problemy.

Python z OOPem jest gorszy czy lepszy od Pythona bez OOPa?

Mimo wszystko chcę definitywnej odpowiedzi na pytanie: czy Rust ssie?

Opowiem ci małą anegdotę (...) Pozostawiam je do refleksji.

to ja tez mam jedna. kiedys bralam udzial w ubijaniu systemu napisanego w c i zastepowaniu go napisanym w javie, identyczny interfejs sieciowy.
trwalo to miesiacami glownie przez to ze "starzy wyjadacze" (autorzy systemu w c ktorzy juz nie kodowali od lat, a zarzadzali projektem) rzucali klody pod nogi.
oryginalny system przetwarzal do ~50k komunikatow na sekunde zazynajac cpu i zajmujac do 25-30GB po 10h od startu
na tym samym sprzecie nowy obslugiwal ~500k komunikatow w tym samym czasie zajmujac srednio 20% cpu i maksymalnie 4-5GB pamieci, z uptime 99.9 na dobe
kod javowy oczywiscie nie byl standardowa enterprise java, ale poza paroma natywnymi hackami i prealokacja generalnie kod byl oop.
nie chodzi mi o pokazanie wyzszosci czy nizszosci, po prostu rezultat zalezy od umiejetnosci i doboru technologii/paradygmatow do zadania.

No w sumie, wielu przeciwników programowania proceduralnego, z którymi rozmawiałem przyznawało się (bywało, że z dumą) do tego nieumiejętności pisania w tym paradygmacie większych rzeczy. Oczywiście wylewali przy tym na ten paradygmat tony pomyj. Więc coś jest na rzeczy w tym co piszesz.

oczywiscie dziala to w dwie strony, przynajmniej tu sie zgadzamy :)

Oczywiscie, ze Python jest lepszy z OOP, w Pythonie wszystko jest zreszta obiektem, nawet obiekt:)

Wibowit napisał(a):

Jaki JIT? Mowa o gołym sterowniku w C z vtable. Co ma do tego "wydajny JIT"? Ty naprawdę nie potrafisz trzymać się tematu kiedy zwraczasz się do współrozmówcy?

Temat brzmi "OOP ssie" czy "OOP w sterownikach ssie"?

Czy to prośba o lekscję czytania ze zrozumieniem? Okej, niech będzie. A więc...

Temat brzmi " Świetna dyskusja dlaczego OOP ssie", dyskusja w sensie dyskusja pod tekstem.

Jeszcze jakieś pytania w tym temacie?

Nie wiem, mam to gdzieś. Chcesz się dowiedzieć to załóż sobie na to odrębny wątek, a nie wprowadzasz offtop.

Rust nie jest obiektowy, a ma mnóstwo wad języków obiektowych -

No i? Jeśli nie jest obiektowy nie widzę związku z tematem dyskusji. Brainfuck też obiektowy nie jest mam o nim też ci napisać opinię? Może przelecieć od razu cały "alfabet" języków programowania?

zwłaszcza tych, które cię prześladują.

Czyli?

Określ się - przeszkadzają ci metody wirtualne czy OOP sam w sobie?

Zależy co definiujesz przez OOP.

Tyle postów, a ty ciągle masz nowe problemy.

Nie mam wciąż nowych roblemów, to ty mi przypisujesz coraz to nowe problemy, które niby to mam i poglądy, które to niby głoszę. Szkoda, że w tej rozmowie to ty jesteś osobą, która uważa je za moje probelmy i za moje poglądy. Ja jakoś z tym co mi zarzucasz w ogóle się nie identyfikuję i odrzucam.

Python z OOPem jest gorszy czy lepszy od Pythona bez OOPa?

Nie wiem, nie widziałem pythona bez oopu. Wszelkie znane mi implementacje implementują go z OOP. Do tego nie jestem programistą Pythona. To, że coś nie jest OOP, nie znaczy że nie ssie jeszcze bardziej niż OOP.

Mimo wszystko chcę definitywnej odpowiedzi na pytanie: czy Rust ssie?

A skąd ja mam to wiedzieć? Na oczy go nie widziałem. Poza tym, nie ma on związku z żadnym z poruszanych, przeze mnie tematów. Więc po kija w tej rozmowie Rust?

Zależy co definiujesz przez OOP.

To ty zdefiniuj, bo ty twierdzisz, że OOP ssie. Mam się znowu domyślać co cię boli?

dyskusja w sensie dyskusja pod tekstem.

Czyli co? Mamy spadać stąd i gadać gdzieś indziej?

A skąd ja mam to wiedzieć? Na oczy go nie widziałem. Poza tym, nie ma on związku z żadnym z poruszanych, przeze mnie tematów. Więc po kija w tej rozmowie Rust?

Jak to nie ma? Twierdzisz, że OOP jest źródłem zła, ale to zło czai się wszędzie, nawet bez OOP.

katelx napisał(a):

Opowiem ci małą anegdotę (...) Pozostawiam je do refleksji.

to ja tez mam jedna. kiedys bralam udzial w ubijaniu systemu napisanego w c i zastepowaniu go napisanym w javie, identyczny interfejs sieciowy.
trwalo to miesiacami glownie przez to ze "starzy wyjadacze" (autorzy systemu w c ktorzy juz nie kodowali od lat, a zarzadzali projektem) rzucali klody pod nogi.
oryginalny system przetwarzal do ~50k komunikatow na sekunde zazynajac cpu i zajmujac do 25-30GB po 10h od startu
na tym samym sprzecie nowy obslugiwal ~500k komunikatow w tym samym czasie zajmujac srednio 20% cpu i maksymalnie 4-5GB pamieci, z uptime 99.9 na dobe
kod javowy oczywiscie nie byl standardowa enterprise java, ale poza paroma natywnymi hackami i prealokacja generalnie kod byl oop.
nie chodzi mi o pokazanie wyzszosci czy nizszosci, po prostu rezultat zalezy od umiejetnosci i doboru technologii/paradygmatow do zadania.

Widzę, że się nie zrozumieliśmy. Istnieje ograniczony poziom efektywności i wydajności, w C będzie on w skrajnym przypadku wisiał tuż nad rejestrami w systemie typu bare - metal. Czy istnieją systemy bare - metal w Javie? Jak tak to da się przeprowadzić benchmark programu Hello world, i kilku innych implementacji tej samej funkcjonalności, który sotatecznier rozwiąże temat. Jak już pisałem - brak efektywności jakiegoś kodu w dowolnym paradygmacie nie jest argumentem przeciwko paradygmatowi. Za to efektywność skrajnych optymalizacji i trudność ich osiągnięcia w jednym, a łatwość w innym już jest jakimś argumentem w dyskusji. Bo tak to dwa kody proceduralny i obiektowy - przykłądowo C i Java nie mają nawet wspólnego mianownika do rozmowy, o ile ktoś nie zacznie implementować wodotrsyków typu vtable w C i maszyny wirtualnej do tego.

Wibowit napisał(a):

Zależy co definiujesz przez OOP.

To ty zdefiniuj, bo ty twierdzisz, że OOP ssie. Mam się znowu domyślać co cię boli?

To się zdecyduj, czy wiesz co mnie boli, bo w poprzednim poście aż emanowałeś pewnością, że to wiesz. Teraz nagle nie wiesz.

dyskusja w sensie dyskusja pod tekstem.

Czyli co? Mamy spadać stąd i gadać gdzieś indziej?

A rób sobie co chesz. Nie rozumiem czemu by mnie to miało obchodzić, ani czemu byś miał mnie pytać o pozwolenie.

A skąd ja mam to wiedzieć? Na oczy go nie widziałem. Poza tym, nie ma on związku z żadnym z poruszanych, przeze mnie tematów. Więc po kija w tej rozmowie Rust?

Jak to nie ma? Twierdzisz, że OOP jest źródłem zła, ale to zło czai się wszędzie, nawet bez OOP.

WUT?

To się zdecyduj, czy wiesz co mnie boli, bo w poprzednim poście aż emanowałeś pewnością, że to wiesz. Teraz nagle nie wiesz.

Przedstawiałeś konkretne problemy typu:

• plik dużo waży
• są abstrakcje
• są metody wirtualne
• coś tam wolno działa i zjada dużo pamięci

Winą obarczyłeś OOP. Zmierzyłem się z konkretnymi problemami i udowodniłem że nie są nierozerwalnie związane z OOPem - chociażby dlatego, że wszystkie te problemy istnieją w nieobiektowym Ruście. Jednak ty dalej twierdzisz, że OOP jest źródłem zła.

Ostatnio wyszło, że metody wirutalne są złe. Czy o to ci konkretnie chodzi?

Czy istnieją systemy bare - metal w Javie

Co to ma do paradygmatu? Równie dobrze można by zapytać - czy są systemy bare metal w Pythonie, JavaScripcie, Haskellu, COBOLu, C# itd.

Natomiast w Ruście da się napisać system operacyjny: https://www.redox-os.org/

Skoro nie chcesz odpowiedzieć na pytanie dotyczące Rusta to zapytam inaczej: czy jakikolwiek język poza C nie ssie?

Wibowit napisał(a):

To się zdecyduj, czy wiesz co mnie boli, bo w poprzednim poście aż emanowałeś pewnością, że to wiesz. Teraz nagle nie wiesz.

Przedstawiałeś konkretne problemy typu:

• plik dużo waży
• są abstrakcje
• są metody wirtualne
• coś tam wolno działa i zjada dużo pamięci

W odniesieniu do konkretnego przykładu konkretnego wykonania aplikacji, nie do OOPu w całości. Naprawdę aż tylu postó było potrzeba, żeby to załapać. Zakładając, że załapiesz po przeczytaniu tych słów.

Winą obarczyłeś OOP. Zmierzyłem się z konkretnymi problemami i udowodniłem że nie są nierozerwalnie związane z OOPem - chociażby dlatego, że wszystkie te problemy istnieją w nieobiektowym Ruście. Jednak ty dalej twierdzisz, że OOP jest źródłem zła.

Że co proszę?

Ostatnio wyszło, że metody wirutalne są złe. Czy o to ci konkretnie chodzi?

Nie.

Czy istnieją systemy bare - metal w Javie

Co to ma do paradygmatu? Równie dobrze można by zapytać - czy są systemy bare metal w Pythonie, JavaScripcie, Haskellu, COBOLu, C# itd.

Natomiast w Ruście da się napisać system operacyjny: https://www.redox-os.org/

Ba, nawet w Javie da się napisać system operacyjny, jak pokazuje przykłąd JNode. Tylko jaka jest tego efektywność w praktyce w porównaniu z gołym kodem bare metal w jakimkolwiek języku nie implementującym funkcjonalności typowo obiektowych. Jeśli coś opiera się na określonych pochłaniających pamięć i czas procesora konstruktach, to siłą rzeczy będzie ich potrzebować więcej niż kod, który jest ich pozbawiony. To naprawdę, jest takie "rocket science" żeby to zrozumieć?

Skoro nie chcesz odpowiedzieć na pytanie dotyczące Rusta to zapytam inaczej: czy jakikolwiek język poza C nie ssie?

A to C nie ssie? Wszystkie ssą. Jedne bardziej, drugie mniej.

Coredump
Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania,
ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP.

A jestem "miłośnikiem OOP", a często uważam zadanie, które wykonuje za niepasujące do OOP.

Np. jeśli robię coś, co obrabia jakieś dane

Np. obróbka tablicy obiektów, przefiltrowanie tych obiektów po jakichś kryteriach, wyłuskanie z nich informacji o id obiektu w innej tablicy, połączenie tego z inną tablicą (wg danego id) to raczej zadanie dla programowania funkcyjnego albo proceduralnego. Albo do programowania deklaratywnego (jeśli tego typu operacje będziemy robić np. w SQL). Albo do programowania reaktywnego (jeśli będziemy to robić asynchronicznie, dla każdego nowego kawałka danych, który dojdzie, i będziemy chcieli potem np. zapdejtować GUI automatycznie po każdej zmianie.

W takich przypadkach OOP raczej odchodzi w kąt (co prawda nie znika, bo można zrobić całą aplikację na OOP, ale w środku gdzieś odpalić jakieś obliczenia. Paradygmat w gdzieś tam w środku metody nie musi być wcale taki sam, jak paradygmat całego projektu.

W OOP natomiast ładnie się modeluje coś na poziomie całej aplikacji, interakcję(i integrację) poszczególnych części aplikacji ze sobą.

Albo jeśli mamy pewnego rodzaju symulację (w końcu OOP powstało do robienia symulacji), np. jak chcemy robić grę, to jednostki mogą być obiektami. Albo GUI. Każdy przycisk może być obiektem i reagować na kliknięcia myszy (i po kliknięciu może wyświetlić okienko dialogowe, które też będzie obiektem itp.). Jest mnóstwo usecase'ów dla obiektówki, jest też mnóstwo usecase'ów, gdzie się słabo ona nadaje...

Jeśli coś opiera się na określonych pochłaniających pamięć i czas procesora konstruktach, to siłą rzeczy będzie ich potrzebować więcej niż kod, który jest ich pozbawiony. To naprawdę, jest takie "rocket science" żeby to zrozumieć?

Każdy program pochłania pamięć i czas procesora. Po to w ogóle programy istnieją. Konstrukty wbudowane w język są często lepsze, także pod względem efektywności, niż kulawe imitacje (typu switche na enumach). Jeśli chcesz miec 100%-ową kontrolę nad tym co wykonuje procesor to koduj w czystym asemblerze. Droga wolna. Jednak tracąc czas na żyłowanie stałej w złożoności obliczeniowej nie zdążysz zoptymalizować programu pod względem rzędu złożoności. Sortowanie bąbelkowe zakodowane w czystym asmie jest potwornie wolne w porównaniu do sortowania szybkiego zaimplementowanego w Pythonie.

A to C nie ssie? Wszystkie ssą. Jedne bardziej, drugie mniej.

Wow. W końcu doszliśmy do meritum wątku. Wszystko ssie. No i co teraz?

LukeJL napisał(a):

A jestem "miłośnikiem OOP", a często uważam zadanie, które wykonuje za niepasujące do OOP.

Np. jeśli robię coś, co obrabia jakieś dane
[...]
Np. obróbka tablicy obiektów, przefiltrowanie tych obiektów po jakichś kryteriach

Trochę co innego miałem na myśli pisząc "zadanie". Miałem na myśli cały program realizujący jakąś funkcjonalność. Na zasadzie - pojawiło się zapotrzebowanie/klient na coś - robimy - to w swoim wpisie rozumiałem przez "zadanie". Nie jakąś najmniejszą dającą się wydzielić część składową.

W OOP natomiast ładnie się modeluje coś na poziomie całej aplikacji, interakcję(i integrację) poszczególnych części aplikacji ze sobą.

I właśnie w tej kwestii się nie zgadzam i bardzo przeszkadza mi ten monopol OOP w umysłach programistów. U miłośników OOP jest to praktycznie odruch - trzeba zrobić program? - na pewno trzeba go zrobić obiektowo.

I właśnie w tej kwestii się nie zgadzam i bardzo przeszkadza mi ten monopol OOP w umysłach programistów. U miłośników OOP jest to praktycznie odruch - trzeba zrobić program? - na pewno trzeba go zrobić obiektowo.

Jak mają w tym wprawę i szybciej im idzie obiektowo to czemu nie? Dopóki kod jest dobrze otestowany, zrozumiały i da się go efektywnie refaktorować to jest dobrze. To są najważniejsze cechy kodu (z perspektywy programisty, a nie użytkownika) nad którym pracuje się w zespole.

Coredump:
Trochę co innego miałem na myśli pisząc "zadanie". Miałem na myśli cały program realizujący jakąś funkcjonalność.
Na zasadzie - pojawiło się zapotrzebowanie/klient na coś -
...
I właśnie w tej kwestii się nie zgadzam i bardzo przeszkadza mi ten monopol OOP w umysłach programistów.
U miłośników OOP jest to praktycznie odruch - trzeba zrobić program? - na pewno trzeba go zrobić obiektowo.

Dokładnie tak jest. OOP to filozofia myślenia i jak mam napisać duży program, to zanim go zacznę robić, to zaczynam o nim myśleć w kategoriach obiektów, i tego w jaki sposób poszczególne obiekty na siebie wpływają. Tak się nauczyłem programować i jest to dla mnie skuteczne. Myślenie w innych paradygmatach niż te, które znam, bywa trudne (już nawet zaawansowana funkcyjność mnie przerasta).

Wibowit napisał:
Jak mają w tym wprawę i szybciej im idzie obiektowo to czemu nie?

optymalizacja myślenia :)

Coredump:
Na zasadzie - pojawiło się zapotrzebowanie/klient na coś -

Szczególnie jeśli jest realne zapotrzebowanie biznesowe - ponieważ jest duża szansa, że klient też myśli obiektowo i wymagania biznesowe są obiektowe, np.

• stwórz aplikację, która będzie miała czat, który będzie pozwalał na rozmowę z naszym pracownikiem po drugiej stronie oceanu. Stwórz też możliwość wyboru produktów i wrzucania ich do koszyka.

czat, rozmowa, pracownik, produkt, koszyk - to wszystko to jakieś obiekty (no dobra, rozmowa to raczej pewien "proces", coś co się dzieje, niż obiekt, ale mimo wszystko...). Dlatego moim zdaniem OOP to mainstreamowy sposób programowania przez tyle lat (i dlatego powstają takie filozofie jak choćby DDD), bo taki sposób myślenia jest bliski wymaganiom biznesowym (niezależnie czy jest, czy nie jest słuszny pod kątem programistycznym).

Z drugiej strony w OOP powstają potworki typu AbstractSingletonProxyFactoryBean, które już nie mają większego odniesienia do realnego świata, więc można przesadzić.

bardzo przeszkadza mi ten monopol OOP w umysłach programistów

Tak? To chyba nie widziałeś monopolu FP w umysłach niektórych XD Szczególnie wśród fanów Reduxa, którzy jeszcze 2,5 roku temu pewnie nie wiedzieli, co to jest funkcyjność, a teraz będą jej bronić jako jedynego słusznego paradygmatu i hejtować obiektówkę, gdzie się da, nic o niej nie wiedząc (mnie to bawi, bo Redux ma bardzo dużo wspólnego z OOP i gdyby ludzie, którzy używają tej biblioteki o tym wiedzieli, to mogliby na tym tylko skorzystać zamiast ciągle odkrywać koło na nowo).

Wibowit napisał(a):

Jeśli coś opiera się na określonych pochłaniających pamięć i czas procesora konstruktach, to siłą rzeczy będzie ich potrzebować więcej niż kod, który jest ich pozbawiony. To naprawdę, jest takie "rocket science" żeby to zrozumieć?

Każdy program pochłania pamięć i czas procesora. Po to w ogóle programy istnieją. Konstrukty wbudowane w język są często lepsze, także pod względem efektywności, niż kulawe imitacje (typu switche na enumach). Jeśli chcesz miec 100%-ową kontrolę nad tym co wykonuje procesor to koduj w czystym asemblerze. Droga wolna. Jednak tracąc czas na żyłowanie stałej w złożoności obliczeniowej nie zdążysz zoptymalizować programu pod względem rzędu złożoności. Sortowanie bąbelkowe zakodowane w czystym asmie jest potwornie wolne w porównaniu do sortowania szybkiego zaimplementowanego w Pythonie.

Widzę, że jesteś nieuleczalny w kwestiach brania z sufitu jakichś absurdalnych teorii i poglądów i przypisaywania ich współrozmówcom, których rzeczywiste poglądy ci się nie podobają i dyskutowaniu nad tymi urojonymi, zamiast rzeczywistymi.

A to C nie ssie? Wszystkie ssą. Jedne bardziej, drugie mniej.

Wow. W końcu doszliśmy do meritum wątku. Wszystko ssie. No i co teraz?

Nic, a co ma być?

Nic, a co ma być?

No jakiś morał. Ciągle piszesz, że coś ssie, gdzieś jest bullshit, itd i co mamy z tym zrobić? Po co ten wątek założyłeś? Po to by się pożalić, że wszystko ssie? Obraziłeś się na programowanie i nie chcesz by inni mieli swoje ulubione podejścia do programowania?

Aaaaale o co chodzi?

Programowanie proceduralne - globalny, współdzielony, mutowalny stan, gdzie każdy kawałek kodu może grzebać w dowolnych danych ----> bałagan, brak kontroli, ukryte zależności.
Wszyscy się uczą na pierwszych zajęciach z programowania, że globalne zmienne to zło. Myślę też że większość programistów miała w życiu epizod pisania programu, gdzie wszystko było globalne i publiczne, i jak szybko prowadziło to do spaghetti.

Problem ten rozwiązać można na dwa sposoby:

1. Zabronić współdzielenia stanu (lub dostarczyć mechanizmy ścisłej kontroli kto do czego ma dostęp)
2. Zabronić modyfikowania stanu (lub dostarczyć mechanizmy ścisłej kontroli efektów ubocznych)

Rozwiązanie pierwsze to droga obrana przez paradygmat obiektowy.
Rozwiązanie drugie to droga obrana przez paradygmat funkcyjny.

Obydwa atakują ten sam problem, tylko od dwóch różnych stron, żaden nie jest ani lepszy ani gorszy.

Przy czym chciałbym zauważyć, że się wcale ze sobą nie kłócą. BA! One się uzupełniają!

Można zabronić współdzielenia stanu (tj. stanem zarządza tylko jeden właściciel - obiekt) i zarazem zabronić jego modyfikowania. W ten sposób dostajemy programowanie obiektowo-funkcyjne, gdzie po prostu wszędzie latają niemutowalne obiekty i mamy mechanizmy zarówno kontroli dostępu jak i kontroli efektów ubocznych. Oiekty nie mogą modyfikować swojego stanu, ale można obiekty przekształcać w inne obiekty za pomocą metod, które są zarazem funkcjami. Z drugiej storny mamy wszelkie fajne mechanizmy typowe dla OOP np. enkapsulację / polimorfizm czasu wykonania itp.

Zaraz, ale chyba nieumutowalność to nie koniecznie musi być paradygmat funkcyjny. Oczywiście jest to podstawa tego paradymatu, ale to nie znaczy że musimy korzystać z funkcyjnego jak chcemy niemutowalne obiekty ;)