Świetna dyskusja dlaczego OOP ssie.

Kwadratowy pomidor napisał(a):

Błękitny Kot napisał(a):

Hanibal napisał(a):

Ktoś mądry napisał w necie o obiektówce coś takiego
"połowę rzeczy w programowaniu obiektowym jest łatwe i intuicyjne, druga połowa jest nieintuicyjna, i niepotrzebnie skomplikowana"

To raczej szło tak:
“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ – Paul Graham
"Termin ''zorientowane obiektowo'' mieści w sobie wiele rzefczy. Połowa z nich jest oczywista, reszt jest pomyłką " – Paul Graham

Trzeźwy Karp napisał(a):

Ja glownie programuje w pracy w C++, ale w domu chetnie poznaje inne paradygmaty. Gdy uczylem sie F# to zauwazylem, ze moj kod C++ w pracy staje sie coraz mniej obiektowy i coraz bardziej proceduralny i funkcyjny (na ile to C++ pozwala). Wciaz uzywalem klas ale w znacznie mniejszym stopniu niz robilem to kiedys.

No i bardzo dobrze. Tworzenie klas do wszystkiego co się da w obecnych czasach to plaga. Zwłąszcza im młodsze pokolenie, tym bardziej wypaczone mózgi. Jeszcze trochę a dojdziemy do poziomu, gdzie będą tworzyć hierarchię klas, żeby tylko napisać program "Hello Wordl!".

Zgadza się - jest to plaga. Najgorzej jak ktoś kto wcześniej programował wielowątkowo na super wypasionych 64-ro rdzeniowych prockach nagle dostaje do zaprogramowania system embedded. Przykład z życia wzięty: prosty programik niskopoziomowy do forwardowania danych pomiędzy serialem a ethernetem w systemie embedded Linux. Był najpierw napisany w C. Działało to w miarę dobrze i zajmowało kiladziesiąt lub kilkaset kB. Ale niektórzy "mądrzy" stwierdzili, że C jest passe i trzeba to przepisać na C++. No i przepisali. Specjaliści. Program w nowej wersji napisanu już w C++ zajmował ponad 9MB. Zżerał 70-80% czasu procka. Pamięć flash miała na tym systemie 32MB. Czyli 9MB z tych 32MB poszło na jeden program. Dodam może, że cała reszta systemu - kernel i kilkaset binarek pisanych w C zajmowała w sumie 11MB a tu jeden prosty program w C++ zżera 9MB. Ten program w C++ nie miał żadnego GUI - to był daemon po prostu. No ale tak musiało być - obiektowo. Do tego ci którzy zadecydowali o przepisaniu kodu z C do C++ twierdzili, że C++ ma bardzo niewielki narzut w stosunku do C. Właśnie widać - kilkaset kB w C w stosunku do 9MB w C++ - to niewiele, prawda?

Nawet jeśli wynikało to z nieumiejętnego linkowania bibliotek, to trzeba naprawdę nieźle przywalić "warstwami abstrakcji" i "wzoracami projektowymi" i "sprawdzonymi szablonami i przetestowanymi biblotekami" żeby coś tak prostego jak forwardowanie bitów z A do B zaciągnęło 9MB kodu i zżerało tyle czasu procesora. Jak to w ogóle skomentowali, co na to klient/szef zespołu?

tamtamtu napisał(a):

Jak czytam osoby twierdzace OOP jest najlepsze/OOP jest do d**y to z doswiadczenia wiem ze rozmowcy brakuje doswiadczenia

A ja z doświadczenia wiem, że nie wiesz nic o doświadczeniu wielu krytyków, które jest dłuższe niż niektórzy z nas żyją, i nie mam tu na myśłi wcale najmłodszej grupy zarejestrowanych użytkowników forum. Oczywiście nie przeszkadza to w każdej internetowej dyskusji komuś wyskoczyć z tekstem o niskiej inteligencji lub małym doświadczeniu krytyka. Zwykle potem następuje zbiorowe głaskanie tego filipa z konopii po główce przez zwolenników "racjonalności OOP, tam gdzie on pasuje" (czytaj ludzi, którzy piszą w OOP praktycznie wszystko). Więc radzę sobie odpuścić dywagowanie nad poziomem doświadczenia ludzi, których nie znasz osobiście. Zwłąszczas, że w drugą stronę podjazdów tego typu w tych dyskusjach nie widziałem.

Świetny Orzeł napisał(a):

Kwadratowy pomidor napisał(a):

Błękitny Kot napisał(a):

Hanibal napisał(a):

Ktoś mądry napisał w necie o obiektówce coś takiego
"połowę rzeczy w programowaniu obiektowym jest łatwe i intuicyjne, druga połowa jest nieintuicyjna, i niepotrzebnie skomplikowana"

To raczej szło tak:
“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ – Paul Graham
"Termin ''zorientowane obiektowo'' mieści w sobie wiele rzefczy. Połowa z nich jest oczywista, reszt jest pomyłką " – Paul Graham

Trzeźwy Karp napisał(a):

Ja glownie programuje w pracy w C++, ale w domu chetnie poznaje inne paradygmaty. Gdy uczylem sie F# to zauwazylem, ze moj kod C++ w pracy staje sie coraz mniej obiektowy i coraz bardziej proceduralny i funkcyjny (na ile to C++ pozwala). Wciaz uzywalem klas ale w znacznie mniejszym stopniu niz robilem to kiedys.

No i bardzo dobrze. Tworzenie klas do wszystkiego co się da w obecnych czasach to plaga. Zwłąszcza im młodsze pokolenie, tym bardziej wypaczone mózgi. Jeszcze trochę a dojdziemy do poziomu, gdzie będą tworzyć hierarchię klas, żeby tylko napisać program "Hello Wordl!".

Zgadza się - jest to plaga. Najgorzej jak ktoś kto wcześniej programował wielowątkowo na super wypasionych 64-ro rdzeniowych prockach nagle dostaje do zaprogramowania system embedded. Przykład z życia wzięty: prosty programik niskopoziomowy do forwardowania danych pomiędzy serialem a ethernetem w systemie embedded Linux. Był najpierw napisany w C. Działało to w miarę dobrze i zajmowało kiladziesiąt lub kilkaset kB. Ale niektórzy "mądrzy" stwierdzili, że C jest passe i trzeba to przepisać na C++. No i przepisali. Specjaliści. Program w nowej wersji napisanu już w C++ zajmował ponad 9MB. Zżerał 70-80% czasu procka. Pamięć flash miała na tym systemie 32MB. Czyli 9MB z tych 32MB poszło na jeden program. Dodam może, że cała reszta systemu - kernel i kilkaset binarek pisanych w C zajmowała w sumie 11MB a tu jeden prosty program w C++ zżera 9MB. Ten program w C++ nie miał żadnego GUI - to był daemon po prostu. No ale tak musiało być - obiektowo. Do tego ci którzy zadecydowali o przepisaniu kodu z C do C++ twierdzili, że C++ ma bardzo niewielki narzut w stosunku do C. Właśnie widać - kilkaset kB w C w stosunku do 9MB w C++ - to niewiele, prawda?

Nawet jeśli wynikało to z nieumiejętnego linkowania bibliotek, to trzeba naprawdę nieźle przywalić "warstwami abstrakcji" i "wzoracami projektowymi" i "sprawdzonymi szablonami i przetestowanymi biblotekami" żeby coś tak prostego jak forwardowanie bitów z A do B zaciągnęło 9MB kodu i zżerało tyle czasu procesora. Jak to w ogóle skomentowali, co na to klient/szef zespołu?

Klient dostawał gotowy produkt i nic nie wiedział o tym co jest w środku. Tak gwoli ściśłości to poza forwardowaniem było tam trochę przetwarzania tych danych (sorry, ale z wrażenia nie napisałem o tym). Ale mimo wszystko porównanie wielkości kodu i zajętości procka było straszne. Ten program miał nawet swoje thready i pluginy :) Całość z pluginami zajmowała te 9MB. A szef zespołu? Dał przyzwolenie programiście - bo to właśnie szef zespołu był autorem powiedzenia, że C++ ma niewielki narzut w stosunku do C. A kiedy zwracało się uwagę na głupotę stosowania C++ w tym systemie podając za przykład porównianie obu rozwiązań w C i C++ to niektórzy zwolennicy C++ stawali się wręcz agresywni. Lepiej było dać sobie spokój.

Klient dostawał gotowy produkt i nic nie wiedział o tym co jest w środku. Tak gwoli ściśłości to poza forwardowaniem było tam trochę przetwarzania tych danych (sorry, ale z wrażenia nie napisałem o tym). Ale mimo wszystko porównanie wielkości kodu i zajętości procka było straszne. Ten program miał nawet swoje thready i pluginy :) Całość z pluginami zajmowała te 9MB. A szef zespołu? Dał przyzwolenie programiście - bo to właśnie szef zespołu był autorem powiedzenia, że C++ ma niewielki narzut w stosunku do C. A kiedy zwracało się uwagę na głupotę stosowania C++ w tym systemie podając za przykład porównianie obu rozwiązań w C i C++ to niektórzy zwolennicy C++ stawali się wręcz agresywni. Lepiej było dać sobie spokój.

Argumenty, że coś było wolniejsze w C++ niż w C, to ma się nijak do samego OOP. Przecież w C też można wydziergać "obiektową" strukturę" (wskaźnik do struktury zawierający wskaźnik do funkcji, która przyjmuje wskaźnik do ...).

yarel napisał(a):

Klient dostawał gotowy produkt i nic nie wiedział o tym co jest w środku. Tak gwoli ściśłości to poza forwardowaniem było tam trochę przetwarzania tych danych (sorry, ale z wrażenia nie napisałem o tym). Ale mimo wszystko porównanie wielkości kodu i zajętości procka było straszne. Ten program miał nawet swoje thready i pluginy :) Całość z pluginami zajmowała te 9MB. A szef zespołu? Dał przyzwolenie programiście - bo to właśnie szef zespołu był autorem powiedzenia, że C++ ma niewielki narzut w stosunku do C. A kiedy zwracało się uwagę na głupotę stosowania C++ w tym systemie podając za przykład porównianie obu rozwiązań w C i C++ to niektórzy zwolennicy C++ stawali się wręcz agresywni. Lepiej było dać sobie spokój.

Argumenty, że coś było wolniejsze w C++ niż w C, to ma się nijak do samego OOP. Przecież w C też można wydziergać "obiektową" strukturę" (wskaźnik do struktury zawierający wskaźnik do funkcji, która przyjmuje wskaźnik do ...).

Zgadzam się, trochę odjechałem w moim poście od tematu wątku, ale za bardzo mnie to wkurzało, musiałem gdzieś o tym napisać :)

Kwadratowy pomidor napisał(a):

Klient dostawał gotowy produkt i nic nie wiedział o tym co jest w środku.

To wiele wyjaśnia

Tak gwoli ściśłości to poza forwardowaniem było tam trochę przetwarzania tych danych (sorry, ale z wrażenia nie napisałem o tym).

Co pewnie dawało pole do popisu dla "warst abstrakcji" i zaciągania "zorientowanych obiektowo struktur danych".

Ale mimo wszystko porównanie wielkości kodu i zajętości procka było straszne.

Wręcz horror.

Ten program miał nawet swoje thready i pluginy :) Całość z pluginami zajmowała te 9MB.

Pluginy? WUT?

A szef zespołu? Dał przyzwolenie programiście - bo to właśnie szef zespołu był autorem powiedzenia, że C++ ma niewielki narzut w stosunku do C.

"Niewielki" to pojęcie względne. Zależy od drabiniastości zastosowanych rozwiązań i mówię to jako hejter zaróœno OOP jako takiego jaki i języka C++.

A kiedy zwracało się uwagę na głupotę stosowania C++ w tym systemie podając za przykład porównianie obu rozwiązań w C i C++ to niektórzy zwolennicy C++ stawali się wręcz agresywni. Lepiej było dać sobie spokój.

Nie jestem zdziwiony, agresja słowna i przewracanie oczami "jaki to jesteś głupi i zacofany" to częsta reakcja. Oczywiście jak się domyślam przedstawione przykłady "niczego nie dowodziły" i były "gorszymi rozwiązaniami", względnie "kulawymi implementacjami funkcjonalności OOP" jeśli rozmówca widział chociaż śladowe podobieństwo. Oczywiście ta gorszość brała się z definicji. Definicji na zasadzie "OOP jest lepszy, bo tak". Przynajmniej takie są moje doświadczenia.

Czyli - ponownie wychodzi na to, co pisałem wcześniej :D

OOP to jedno z podejść/technologii. I nie ma jednoznacznej odpowiedzi, czy jest wporzo, czy raczej kolejnym wcieleniem szatana.
Przede wszystkim - zależy od projektu, nad którym się w danej chwili pracuje.

oraz

OOP ma swoje plusy i minusy, trzeba wiedzieć kiedy jest sens z tego korzystać, a kiedy wybrać coś innego.
I tyle w temacie.

Naprawdę - nie ma sensu dalej ciągnąc tej litanii. W podanym przykładzie (jakiś system embedded) mamy ewidentnie źle dobrane narzędzie do zadania. I nawet nie chodzi już o samo OOP lub jego brak, ale ogólnie o podejście do tematu. Ktoś się wykazał "najwyższej klasy fachową wiedzą" i tyle.

yarel napisał(a):

Klient dostawał gotowy produkt i nic nie wiedział o tym co jest w środku. Tak gwoli ściśłości to poza forwardowaniem było tam trochę przetwarzania tych danych (sorry, ale z wrażenia nie napisałem o tym). Ale mimo wszystko porównanie wielkości kodu i zajętości procka było straszne. Ten program miał nawet swoje thready i pluginy :) Całość z pluginami zajmowała te 9MB. A szef zespołu? Dał przyzwolenie programiście - bo to właśnie szef zespołu był autorem powiedzenia, że C++ ma niewielki narzut w stosunku do C. A kiedy zwracało się uwagę na głupotę stosowania C++ w tym systemie podając za przykład porównianie obu rozwiązań w C i C++ to niektórzy zwolennicy C++ stawali się wręcz agresywni. Lepiej było dać sobie spokój.

Argumenty, że coś było wolniejsze w C++ niż w C, to ma się nijak do samego OOP. Przecież w C też można wydziergać "obiektową" strukturę" (wskaźnik do struktury zawierający wskaźnik do funkcji, która przyjmuje wskaźnik do ...).

Co w tym takiego obiektowego niby? To nie wskaźniki na funkcje w strukurach czynią obiektowość, a sposób organizacji danych i funkcji, implementowany najczęściej przez vtable który jest tylko jednym ze szczególnych przypadków "wskaźników w strukturach". Zaś jeśli chodziło ci o to, że piętrzenie abstrakcji w C również spowalnia całłość i powiększa rozmiary programu, to się zgadzam.

Dyskutowanie o wadach OOP na podstawie C++ jest jak udowadnianie na przykładzie pieca hutniczego, że Polska to kraj tropikalny.

cerrato napisał(a):

Czyli - ponownie wychodzi na to, co pisałem wcześniej :D

OOP to jedno z podejść/technologii. I nie ma jednoznacznej odpowiedzi, czy jest wporzo, czy raczej kolejnym wcieleniem szatana.
Przede wszystkim - zależy od projektu, nad którym się w danej chwili pracuje.

oraz

OOP ma swoje plusy i minusy, trzeba wiedzieć kiedy jest sens z tego korzystać, a kiedy wybrać coś innego.
I tyle w temacie.

Naprawdę - nie ma sensu dalej ciągnąc tej litanii. W podanym przykładzie (jakiś system embedded) mamy ewidentnie źle dobrane narzędzie do zadania. I nawet nie chodzi już o samo OOP lub jego brak, ale ogólnie o podejście do tematu. Ktoś się wykazał "najwyższej klasy fachową wiedzą" i tyle.

Kogo cytujesz? Czy po prostu zgadasz się sam ze sobą?

somekind napisał(a):

Dyskutowanie o wadach OOP na podstawie C++ jest jak udowadnianie na przykładzie pieca hutniczego, że Polska to kraj tropikalny.

Nikt tu tego jak dotąd nie robił. Ilekroć ktokolwiek podejmuje temat krytykowania OOPU, ktoś wyskakuje z tekstem "ale C++ to kiepski przykłąd OOP" - nawet jeśli nikt nie wspominał nawet o C++. Te dyskusje są tak przewidywalne, że normalnie wystarczy zacząć temat i z zegarkiem w ręku odmierzać czas do momentu kiedy zaraz ktoś wyskoczy ze "standardowym zestawem tekstów" - o byciu gupim (ukończyłem czołową polską uczelnię), niedoświadczonym(niedługo mi stuknie dwie dekady odkąd zacząłem programować), czy włąśnie z tym "C++ nie jest pdostawą do dyskutowania o OOP". Swoją drogą w ten sposób można zbijać rozmowę w nieskończoność aż na polu boju pozostanie tylko Smalltalk i Commion Lips ze swoim CLOS.

somekind napisał(a):

Dyskutowanie o wadach OOP na podstawie C++ jest jak udowadnianie na przykładzie pieca hutniczego, że Polska to kraj tropikalny.

Ja bym zastosował bardziej programistyczną analogię: C++ jest równie dobrym przedstawicielem OOPa co COBOL programowania proceduralnego.

Nie bardzo też widzę jak rozmiar binarki w jakimś tam przypadku (nękającym kogoś w koszmarach) ma dyskwalifikować konkretny paradygmat programowania. Rust jest językiem strukturalnym i nieobiektowym, a Hello World w Ruście domyślnie produkuje kilkumegabajtowe binarki. Duży rozmiar binarek Rusta wynika z tego, że biblioteki Rustowe są statycznie wiązane. A są statycznie wiązane bo trudno jest oczekiwać ich obecności w standardzie u użytkownika.

Najmniejsze binarki zwykle wychodzą jak programuje się bezpośrednio w asemblerze. Dla przykładu mój algorytm kompresji (tzn implementacja): http://www.maximumcompression.com/TarsaLZP.zip (opis można znaleźć na http://mattmahoney.net/dc/text.html ). Encode.exe zajmuje 6656 bajtów, a po spakowaniu 7zipem 3160 bajtów.

No i przepisali. Specjaliści. Program w nowej wersji napisanu już w C++ zajmował ponad 9MB. Zżerał 70-80% czasu procka. Pamięć flash miała na tym systemie 32MB. Czyli 9MB z tych 32MB poszło na jeden program. Dodam może, że cała reszta systemu - kernel i kilkaset binarek pisanych w C zajmowała w sumie 11MB a tu jeden prosty program w C++ zżera 9MB.

A więc program nie dość, że się spokojnie mieścił na pamięci flash (i jeszcze sporo wolnego zostało) to jeszcze spokojnie wyrabiał na docelowym procku, bo przecież zostało mu 20%-30% zapasu.

Wibowit napisał(a):

somekind napisał(a):

Dyskutowanie o wadach OOP na podstawie C++ jest jak udowadnianie na przykładzie pieca hutniczego, że Polska to kraj tropikalny.

Ja bym zastosował bardziej programistyczną analogię: C++ jest równie dobrym przedstawicielem OOPa co COBOL programowania proceduralnego.

Nie bardzo też widzę jak rozmiar binarki w jakimś tam przypadku (nękającym kogoś w koszmarach) ma dyskwalifikować konkretny paradygmat programowania. Rust jest językiem strukturalnym i nieobiektowym, a Hello World w Ruście domyślnie produkuje kilkumegabajtowe binarki. Duży rozmiar binarek Rusta wynika z tego, że biblioteki Rustowe są statycznie wiązane. A są statycznie wiązane bo trudno jest oczekiwać ich obecności w standardzie u użytkownika.

Nie wiem, czy czytamy ten sam wątek, bo jedyne podjazd jaki widzę, to ten do zastosowanie OOPu w aplikacji, gdzie nie ma to sensu. Co zilustrowało patologiczny stan umysłu nie tak małego grona programistów pchających OOP gdzie mogą. Nie widzę by przykład tej aplikacji był przedstawiony jako dyskwalifikujący OOP.

Nie wiem, czy czytamy ten sam wątek, bo jedyne podjazd jaki widzę, to ten do zastosowanie OOPu w aplikacji, gdzie nie ma to sensu.

A dlaczego stosowanie programowania niskopoziomowego ma mieć sens dla kogoś kto jest przyzwyczajony do OOP lub FP? Tłumaczenia typu oszczędzaj RAM gdziekolwiek jesteś nie przekonają inwestorów. No i jeszcze odnieś się do Rusta - co jeśli ktoś wybierze język strukturalny Rust i wyprodukuje 10 megową binarkę? Czy to dyskwalifikuje Rusta? Czy to znaczy, że twórcy Rusta kłamią pisząc "Rust is a systems programming language that runs blazingly fast"?

Jeśli boli cię, że programy nie mieszczą ci się na dysku to kup większy dysk. Nie ma sensu pałować się z niskopoziomowym kodem, żeby zaoszczędzić te kilka megabajtów.

Wibowit napisał(a):

Nie wiem, czy czytamy ten sam wątek, bo jedyne podjazd jaki widzę, to ten do zastosowanie OOPu w aplikacji, gdzie nie ma to sensu.

A dlaczego stosowanie programowania niskopoziomowego ma mieć sens dla kogoś kto jest przyzwyczajony do OOP lub FP?

Zacznijmy od pytanie - po kiego ta działająca przecież aplikacja została przepisana? Bo jedyny powód jaki został przedstawiony to "ona nie została napisana w C++". WIęc zanim zaczniemy dyskutować nad tym co dla kogo ma sens lub nie zastanówmy się nad tym pytaniem.

Tłumaczenia typu oszczędzaj RAM gdziekolwiek jesteś nie przekonają inwestorów.

Zastanówmy się co przekonało w ogóle inwestorów do płacenia za przepisanie działającej aplikacji. Jeśli więc człowiek który nam o niej tutaj napisał przedstawi jakieś informacje na ten temat, twoje pytania może nabiorą jakiegoś sensu. Na razie przyjmujesz postawę defensywną przed atakiem, który nie nastąpił i nie widzę sensu, by miał nastąpić.

No i jeszcze odnieś się do Rusta - co jeśli ktoś wybierze język strukturalny Rust i wyprodukuje 10 megową binarkę? Czy to dyskwalifikuje Rusta? Czy to znaczy, że twórcy Rusta kłamią pisząc "Rust is a systems programming language that runs blazingly fast"?

Ale jaki sens ma brnięcie w ten offtop? To o czym piszesz jest odległe, od tego co tu poruszaliśmy do tej pory.

Jeśli boli cię, że programy nie mieszczą ci się na dysku to kup większy dysk. Nie ma sensu pałować się z niskopoziomowym kodem, żeby zaoszczędzić te kilka megabajtów.

Piękne w teorii, w praktyce wiele urządzeń wbudowanych ma wlutowany na stałe flash i nie posiada interfejsów do podłączenie innych pamięci.

Ale jaki sens ma brnięcie w ten offtop? To o czym piszesz jest odległe, od tego co tu poruszaliśmy do tej pory.

No dobra, to podsumujmy: OOP ssie, bo ktoś przepisał aplikację w C do C++ i binarka zaczęła więcej ważyć. "Solidny" argument. Gdyby wybrali Rusta to też binarka zaczęłaby więcej ważyć - i z tego wynikałoby, że programowanie strukturalne ssie. Jedynym słusznym językiem jest więc tylko i wyłącznie C - wtedy programowanie strukturalne nie ssie.

PS:
Mozilla przepisuje Firefoksa z C++ do Rusta i w miarę przepisywania binarki mocno puchną. Nowy silnik CSSów napisany w Ruście zajmuje kilka razy więcej po kompilacji niż stary napisany w C++.

Świetny Orzeł napisał(a):

tamtamtu napisał(a):

Jak czytam osoby twierdzace OOP jest najlepsze/OOP jest do d**y to z doswiadczenia wiem ze rozmowcy brakuje doswiadczenia

A ja z doświadczenia wiem, że nie wiesz nic o doświadczeniu wielu krytyków, które jest dłuższe niż niektórzy z nas żyją, i nie mam tu na myśłi wcale najmłodszej grupy zarejestrowanych użytkowników forum. Oczywiście nie przeszkadza to w każdej internetowej dyskusji komuś wyskoczyć z tekstem o niskiej inteligencji lub małym doświadczeniu krytyka. Zwykle potem następuje zbiorowe głaskanie tego filipa z konopii po główce przez zwolenników "racjonalności OOP, tam gdzie on pasuje" (czytaj ludzi, którzy piszą w OOP praktycznie wszystko). Więc radzę sobie odpuścić dywagowanie nad poziomem doświadczenia ludzi, których nie znasz osobiście. Zwłąszczas, że w drugą stronę podjazdów tego typu w tych dyskusjach nie widziałem.

Zieff. Uncle Bob zaczal komercyjnie programowac na poczatku lat 70 i nie zgadza sie z opinia ze OOP jest mierny. Gosc za mlody? Twierdzenie ze podjazdow w druga strone nie ma jest dziwne. Znaczy nie ma 111923810493 tekstow ze OOP jest do d**y a funkcyjne/proceduralne super? Faktycznie po proceduralnym sie czasem jedzie bo to jest sposob najlatwiejszy do przyjecia i czesto programuja tak juniorzy w dziwny sposob. Pisanie ze FP jest super, swietne i bez wad tez jest zabawne. Porozmawiaj w produkcjach gdzie sa bardziej skomplikowane rzeczy. Co sie dzieje gdy senior nagle odchodzi? Nowy senior przychodzi i zaczyna walke aby zalapac co autor mial na mysli (nie, kod jest dobry). FP ma swoje plusy i swoje koszty (ktorych nie widac w malych aplikacyjkach) o ktorych czesc osob nie chce pamietac. Tak poza tym nie pamietam tez aby Matin Fowler jechal po OOP albo Greg Young albo Eric Evans itp. No ale rozumiem goscie nie maja doswiadczenia.

Kojarze natomiast wielu "doswiadczonych" programujacych komercyjnie max 5 lat krzyczacych oop jest super/do d**y, orm jest super/do d**y, czysty sql jest najlepszy/ssie, soa to przyszlosc/gowno itp. Zazwyczaj opinie wynikaly z jednostronnego podejscia do tematu i tyle. No ale w koncu udowodnij ze OOP ktore jest pisane dobrze ssie, albo proceduralne tworzone przez juniora jest super... Taka krytyka przypomina mi krytyke typu audi a8 ssie bo nie da sie nim zaorac pola po duzym deszczu...

Wibowit napisał(a):

Ale jaki sens ma brnięcie w ten offtop? To o czym piszesz jest odległe, od tego co tu poruszaliśmy do tej pory.

No dobra, to podsumujmy: OOP ssie, bo ktoś przepisał aplikację w C do C++ i binarka zaczęła więcej ważyć.

Nikt z nas nie twierdzi nic takiego. Piszę to już co najmniej 3ci raz. Widzę, że nie dociera.

"Solidny" argument. Gdyby wybrali Rusta to też binarka zaczęłaby więcej ważyć - i z tego wynikałoby, że programowanie strukturalne ssie. Jedynym słusznym językiem jest więc tylko i wyłącznie C - wtedy programowanie strukturalne nie ssie.

To twoja opinia. Jeśli chcesz nam ją przypisać, to nikt z nas nic takiego ni pisał. Idź stosować erystykę na kimś innym.

tamtamtu napisał(a):

Świetny Orzeł napisał(a):

tamtamtu napisał(a):

Jak czytam osoby twierdzace OOP jest najlepsze/OOP jest do d**y to z doswiadczenia wiem ze rozmowcy brakuje doswiadczenia

A ja z doświadczenia wiem, że nie wiesz nic o doświadczeniu wielu krytyków, które jest dłuższe niż niektórzy z nas żyją, i nie mam tu na myśłi wcale najmłodszej grupy zarejestrowanych użytkowników forum. Oczywiście nie przeszkadza to w każdej internetowej dyskusji komuś wyskoczyć z tekstem o niskiej inteligencji lub małym doświadczeniu krytyka. Zwykle potem następuje zbiorowe głaskanie tego filipa z konopii po główce przez zwolenników "racjonalności OOP, tam gdzie on pasuje" (czytaj ludzi, którzy piszą w OOP praktycznie wszystko). Więc radzę sobie odpuścić dywagowanie nad poziomem doświadczenia ludzi, których nie znasz osobiście. Zwłąszczas, że w drugą stronę podjazdów tego typu w tych dyskusjach nie widziałem.

Zieff. Uncle Bob zaczal komercyjnie programowac na poczatku lat 70 i nie zgadza sie z opinia ze OOP jest mierny. Gosc za mlody? Twierdzenie ze podjazdow w druga strone nie ma jest dziwne. Znaczy nie ma 111923810493 tekstow ze OOP jest do d**y a funkcyjne/proceduralne super? Faktycznie po proceduralnym sie czasem jedzie bo to jest sposob najlatwiejszy do przyjecia i czesto programuja tak juniorzy w dziwny sposob. Pisanie ze FP jest super, swietne i bez wad tez jest zabawne. Porozmawiaj w produkcjach gdzie sa bardziej skomplikowane rzeczy. Co sie dzieje gdy senior nagle odchodzi? Nowy senior przychodzi i zaczyna walke aby zalapac co autor mial na mysli (nie, kod jest dobry). FP ma swoje plusy i swoje koszty (ktorych nie widac w malych aplikacyjkach) o ktorych czesc osob nie chce pamietac. Tak poza tym nie pamietam tez aby Matin Fowler jechal po OOP albo Greg Young albo Eric Evans itp. No ale rozumiem goscie nie maja doswiadczenia.

Kojarze natomiast wielu "doswiadczonych" programujacych komercyjnie max 5 lat krzyczacych oop jest super/do d**y, orm jest super/do d**y, czysty sql jest najlepszy/ssie, soa to przyszlosc/gowno itp. Zazwyczaj opinie wynikaly z jednostronnego podejscia do tematu i tyle. No ale w koncu udowodnij ze OOP ktore jest pisane dobrze ssie, albo proceduralne tworzone przez juniora jest super... Taka krytyka przypomina mi krytyke typu audi a8 ssie bo nie da sie nim zaorac pola po duzym deszczu...

Zieeeew. No fajnie, anegdotical evidence jako podstawa do wysnuwania uogólnień. Czy to trzeba komentować?

Nikt z nas nie twierdzi nic takiego. Piszę to już co najmniej 3ci raz. Widzę, że nie dociera.

No to konkretnie o co biega? Przecież narzekasz, że w C++ więcej waży i to jest dramat. Ciężko stwierdzić co się najbardziej prześladuje. To, że komuś nie chciało się babrać w C, więc przepisał do C++ i dołożył potem kolejne funkcjonalności?

Ja tylko prostuję twoje bolączki, ale nie wiem które są ważne, a które nie. Jeśli do czegoś nie powinienem się odnosić to najlepiej tego nie pisz i zamiast tego zachowaj to dla siebie.

Zresztą twoja polityka jest nielogiczna i zalatuje fanatyzmem C. Przy startowaniu projektu powiesz "po co stosować nie-C do projektu, który dopiero powstaje?", a jak już powstanie i się rozrośnie to powiesz "po co przerabiać na nie-C program, który działa w C?"

Nudni jesteście. Paradygmaty to narzędzia, która można wybierać, jak ze skrzynki z narzędziami

Weźmy przykładowo OOP i jakiś inny paradygmat. Niech to będzie paradygmat funkcyjny (bez wyraźnego powodu, ot tak).

Czasem wszystko piszemy OOP.

Czasem olewamy OOP i piszemy funkcyjnie (czyli albo-albo, na zasadzie wyboru "programowanie funkcyjne się lepiej nada do projektu").

Czasem piszemy część aplikacji funkcyjnie (np. jakieś kalkulacje), a część aplikacji OOP (np. jakieś interakcje między obiektami na większą skalę).

Czasem się podejścia łączy (np. programujemy funkcyjnie w obiektowym języku używając do tego klas i niemutowalnych obiektów).

Poza tym kwestia definicji. O ile definicje programowania funkcyjnego i cały aparat pojęciowy jest (tak mi się wydaje) dość ścisły i można łatwiej określić, czy coś jest programowaniem funkcyjnym, ma to jakieś podstawy matematyczne - to z OOP już tak łatwo nie ma. Przez to ~50 lat używania obiektówki powstało mnóstwo definicji tego, jak powinno wyglądać właściwe programowanie obiektowe (wliczając w to paradygmaty takie jak actor-model czy DDD, które używają pojęć "actor" czy "entity" zamiast "object", ale koncepcyjnie idee są podobne).

Więc generalnie cała wasza dyskusja przez ostatnie posty nie ma sensu. Należałoby się zastanowić nad tym, co uważamy za programowanie obiektowe, i w jaki sposób się do tego orientujemy, czy faktycznie ssie, podając jakieś merytoryczne argumenty, a nie trollować/offtopować/obrażać się.

Wydaje się niektórym, że istnieje jakaś wojna między OOP a innymi paradygmatami, a to raczej nie jest najważniejsze w tej dyskusji (wątek jest "dlaczego OOP ssie" a nie "OOP kontra inne paradygmaty". Przecież tu nie ma żadnej wojny, wszystkie paradygmaty można łączyć albo wybierać)

Co do OOP to mało osób umie pisać obiektowo w taki sposób, żeby dało się to później łatwo utrzymywać. Większość kodu OOP jaki widuję to jakiś przeinżynierowany spaghetti kod (co nie znaczy, że OOP ssie, tylko raczej, że ludzie, którzy twierdzą, że piszą OOP, piszą tak naprawdę jedno wielki spaghetti kod. Możliwe, że większość ludzi po prostu nie dorosła do obiektówki (w szczególności: każdą poznaną technikę stosują gdzie popadnie, np. nauczą się dziedziczenia, to dziedziczą wszędzie, poczytają o wzorcach, to będą je wszędzie stosować, bo im będzie się wydawało to profesjonalne itp.).

Czyli nasza dyskusja to rozważania o kondycji ludzkiej i o tym, że ludzie są głupi, a nie o samym OOP. Zobaczcie zresztą na ten wątek, że niektórzy nawet nie umieją dyskutować, obrażają się, albo wysuwają jakieś pseudoargumenty...

Większość kodu OOP jaki widuję to jakiś przeinżynierowany spaghetti kod

A ja jeszcze raz powtórzę: hierarchie klas z OOP to betka w porównaniu z hierarchiami typów w FP. Polecam zaznajomić się z: https://github.com/scalaz/scalaz

Z drugiej strony programowanie niskopoziomowe nie ma żadnych "przeinżynierowanych" typów, ale za to prowadzi do dużego grafu mutowalnych struktur, a to jest gorsze jeżeli projekt jest duży.

Skomplikowane narzędzia jakimi są OOP i FP wymagają poświęcenia wielu lat na osiągnięcie wprawy, ale za to po ich opanowaniu i dobrym zastosowaniu łatwiej analizować nowy dla nas kod niż proceduralną nietestowalną plątaninę. Większość kodu jest dla nas nowa, bo zmieniamy projekty i pracujemy w zespołach, gdzie wiele osób pisze kod, a ponadto projekty są duże więc kodu i tak nie jesteśmy w stanie spamiętać. Wszystko zależy od tego w czym ktoś siedzi - jeśli siedzi nad prostymi małymi programikami to OOP i FP są niespecjalnie potrzebne, ale też nie przeszkadzają jeśli wszyscy w zespole już ogarnęli ten OOP czy FP.

Wielki Krawiec napisał(a):

Argumenty, że coś było wolniejsze w C++ niż w C, to ma się nijak do samego OOP. Przecież w C też można wydziergać "obiektową" strukturę" (wskaźnik do struktury zawierający wskaźnik do funkcji, która przyjmuje wskaźnik do ...).

Co w tym takiego obiektowego niby?

Sposób myślenia i organizowania struktury rozwiązania, a nie samo korzystanie z mechanizmów języka. Nie każde użycie konstruktów językowych sprawi, że rozwiązanie będzie "obiektowe", tak samo jak ich brak nie stanowi przeszkody w myśleniu i tworzeniu rozwiązania w sposób obiektowy. Każda dodatkowa warstwa podnosi złożoność rozwiązania, ale nie wprowadza ich się bez powodu, tylko żeby mieć pewnego rodzaju elastyczność. Po co elastyczność? Zazwyczaj im mniej wiemy o istocie problemu, tym więcej chcemy tej elastyczności mieć. W przypadkach, gdy mamy dobrze zdefiniowaną domenę (np. przez jakąś standaryzację), to nie ma takiej potrzeby, żeby robić założenia odnośnie tego co może się zmieniać.

Wielki Krawiec napisał(a):

Te dyskusje są tak przewidywalne, że normalnie wystarczy zacząć temat i z zegarkiem w ręku odmierzać czas do momentu kiedy zaraz ktoś wyskoczy ze "standardowym zestawem tekstów" -

Oczywiście, że jest przewidywalna. To nie pierwszy raz, gdy jakiś anonimowy troll zakłada na tym forum wątek o tym jak to strasznie OOP ssie nie podając przy tym żadnych własnych argumentów i czeka z zegarkiem w ręku na flame.
Niby można byłoby merytorycznie podyskutować na ten temat - bo w sumie nadmierny rozrost abstrakcji jest faktem, za to tak reklamowana "intuicyjność" OOP już nie (gdyby tak było, to wszyscy, nawet najgłupsi pisaliby w nim dobrze, a przecież to nieprawda, a elementy OOP są często używane bez zrozumienia)... Tylko nie ma sensu dyskutować z trollem, który nie przytacza żadnych argumentów, za to ma kretyńsko protekcjonalny ton i skupia się na atakach ad personam poprzez nieudolną psychoanalizę interlokutorów.

o byciu gupim (ukończyłem czołową polską uczelnię)

Krystyna Pawłowicz i Antoni Macierewicz również.

TL;DR - Idź pan w c**** na jakiś wykop.

Zamieniłbym typowe dziedziczenie na Typestate-Oriented Programming. Czyli takie wsparcie dla programowania maszyny stanów. Rust trochę to wspiera dzięki temu, że metody mogą "konsumować" obiekt z którego zostały wywołane. Według mnie to jest super (pomaga wyeliminować całą klasę błędów typu IllegalStateException) i nowe języki powinny iść w tym kierunku.

Wibowit napisał(a):

Nikt z nas nie twierdzi nic takiego. Piszę to już co najmniej 3ci raz. Widzę, że nie dociera.

No to konkretnie o co biega? Przecież narzekasz, że w C++ więcej waży i to jest dramat.

Nic takiego nie napisałem.

Ciężko stwierdzić co się najbardziej prześladuje. To, że komuś nie chciało się babrać w C, więc przepisał do C++ i dołożył potem kolejne funkcjonalności?

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ę.

Ja tylko prostuję twoje bolączki, ale nie wiem które są ważne, a które nie. Jeśli do czegoś nie powinienem się odnosić to najlepiej tego nie pisz i zamiast tego zachowaj to dla siebie.

Dziękuję za zainteresowanie moim tyłkiem, ale nie jesteś w moim typie. Tak widziałem twoje zdjęcie.

Zresztą twoja polityka jest nielogiczna i zalatuje fanatyzmem C. Przy startowaniu projektu powiesz "po co stosować nie-C do projektu, który dopiero powstaje?", a jak już powstanie i się rozrośnie to powiesz "po co przerabiać na nie-C program, który działa w C?"

Jaka polityka? Napisanie czegoś w sposób prosty i nieskomplikowany to fanatyzm programisty C? Poza tym tamten człowiek wciąż nam nie dostarczył szczegółów, więc nie wiem do jakich aspektów tamtego projektu pijesz? Byłeś w niego zaangażowany? Jak nie to po co ta przemowa w jego obronie? Solidarność programistów OOP? Ktoś rzucił anegdotę o przepisaniu kawałka kodu w C++, a ty robisz z tego litanię w obronie OOPu. No bez jaj.

Trolling trollingiem, ale na stronie wrzucanej w pierwszym poście ( http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html ) przy każdym tym cytacie znajduje się link do oryginalnych wypowiedzi tych ludzi (w szerszym kontekście).

To, że ktoś tu trolluje (nawet nie wiem czy 1 czy więcej osób, bo autogenerowane nicki są inne, ale agresywno-obrażalski styl wypowiedzi podobny), to nie znaczy, żeby hejtować od razu stronę z linkami, którą wrzucił.

yarel napisał(a):

Wielki Krawiec napisał(a):

Argumenty, że coś było wolniejsze w C++ niż w C, to ma się nijak do samego OOP. Przecież w C też można wydziergać "obiektową" strukturę" (wskaźnik do struktury zawierający wskaźnik do funkcji, która przyjmuje wskaźnik do ...).

Co w tym takiego obiektowego niby?

Sposób myślenia i organizowania struktury rozwiązania, a nie samo korzystanie z mechanizmów języka. Nie każde użycie konstruktów językowych sprawi, że rozwiązanie będzie "obiektowe", tak samo jak ich brak nie stanowi przeszkody w myśleniu i tworzeniu rozwiązania w sposób obiektowy. Każda dodatkowa warstwa podnosi złożoność rozwiązania, ale nie wprowadza ich się bez powodu, tylko żeby mieć pewnego rodzaju elastyczność. Po co elastyczność? Zazwyczaj im mniej wiemy o istocie problemu, tym więcej chcemy tej elastyczności mieć. W przypadkach, gdy mamy dobrze zdefiniowaną domenę (np. przez jakąś standaryzację), to nie ma takiej potrzeby, żeby robić założenia odnośnie tego co może się zmieniać.

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? ;)

LukeJL napisał(a):

Trolling trollingiem, ale na stronie wrzucanej w pierwszym poście ( http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html ) przy każdym tym cytacie znajduje się link do oryginalnych wypowiedzi tych ludzi (w szerszym kontekście).

To, że ktoś tu trolluje (nawet nie wiem czy 1 czy więcej osób, bo autogenerowane nicki są inne, ale agresywno-obrażalski styl wypowiedzi podobny), to nie znaczy, żeby hejtować od razu stronę z linkami, którą wrzucił.

Nie hejtuję tej strony - ja się nawet zgadzam z wieloma tamtymi stwierdzeniami. Tylko osobiście nie mam ochotę na silenie się na poważną dyskusję z trollami stosującymi wszystkie możliwe błędy argumentacyjne. - somekind 5 minut temu

No świetni, po prostu wspaniale, jak ktoś się z wami nie zgadza, to oczywiście trolluje, bo wasza opinia w tym temacie jest jedyną słuszną. Wybornie.

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ł.