Świetna dyskusja dlaczego OOP ssie.

Niemutowalne struktury danych są esencją programowania funkcyjnego. Za Wikipedią:

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements.

Podzbiorem stylu funkcyjnego jest programowanie czysto funkcyjne, gdzie cały program musi być czysto funkcyjny: https://en.wikipedia.org/wiki/Purely_functional_programming

A purely functional language is a language which only admits purely functional programming. Purely functional programs can however be written in languages which are not purely functional.

Jeżeli w jakiejś metodzie czy funkcji unikniesz mutowalności (w tym polegania na mutowalnym stanie z zewnątrz) to ta funkcja jest napisana w stylu funkcyjnym. Ilość takich metod czy funkcji możesz zwiększać (dopóki uznasz to za stosowne) zastępując nimi imperatywne poprzedniki i wtedy mieszasz styl funkcyjny z imperatywnym. Mieszając FP z OOP najwięcej sensu jest gdy cały obiekt jest napisany w stylu funkcyjnym, a nie tylko części, bo

1. w stylu imperatywnym i tak są funkcje czy metody nie modyfikujące stanu,
2. łatwiej zapamiętać, że cały obiekt jest funkcyjny, a nie konkretne jego metody - jeśli wrzucę obiekt z mutatorami gdzieś dalej to nie jestem pewien czy nie zostanie zmieniony - obiekt bez mutatorów na pewno nie zostanie

Z funkcyjnością jest związana jeszcze jedna sprawa - otóż można mieć funkcję, która z zewnątrz zachowuje się jakby była czysto funkcyjna, ale w środku używa mutowalnych struktur danych. Dla przykładu:

def sum(ints: Seq[Int]): Int = {
  var result = 0
  ints.foreach(result += _)
  result
}

Mimo iż użyliśmy zmiennej to metoda dalej nie zależy od zewnętrznego mutowalnego stanu, nie ma efektów ubocznych widocznych z zewnątrz i spełniony jest warunek, że dla tego samego wejścia zawsze dostaniemy to samo wyjście. Dostajemy więc szereg zalet związanych z funkcyjnym stylem programowania, ale dodatkowo zoptymalizowaliśmy sobie wydajność używając lokalnej zmiennej.

Niemutowalne kolekcje w Scali zawierają szereg takich optymalizacji opartych o nieobserwowalną z zewnętrz lokalną mutowalność.
Więcej dyskusji: https://softwareengineering.stackexchange.com/q/196112

No i jeszcze jedna sprawa, bo nie jestem pewien czy dokładnie zrozumiałem argument. Oczywiście da się używać niemutowalnych obiektów nie myśląc o funkcyjności, ale chcąc je szerzej używać szybko wejdzie się w schematy znane z podejścia funkcyjnego. No chyba, że nasza niemutowalność oznacza rzucanie wyjątku przy odpalaniu mutatora.

W paradygmacie imperatywnym mozna uzywac funkcji/method, ktore Nie zmieniaja obiektow, tylko zwracaja wynik.

Krolik napisał(a):

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.

Jeśli tak sobie zorganizujesz kod to tak będzie. W obiektówce też można sę pokaleczyć na wiele ciekawych sposobów.

Wszyscy się uczą na pierwszych zajęciach z programowania, że globalne zmienne to zło.

Nie przypominam sobie. Ale może to wina mojej czołowej uczelni w kraju.

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.

Do spaghetti prowadzi brak dyscypliny, nie paradygmat, czy publiczność lub jej brak. Zresztą programować proceuralnie można bez ani jednej zmiennej globalnej. Sam mam na koncie takie projekty.

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.

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Rozwiązanie drugie to droga obrana przez paradygmat funkcyjny.

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

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

No i?

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

No i?

Można zabronić współdzielenia stanu (tj. stanem zarządza tylko jeden właściciel - obiekt) i zarazem zabronić jego modyfikowania.

No można. Można zarządzać też stanem w ramach odrębnego modułu i zabronić jego modyfikowana z zewnątrz. I napisać to wszystko w przykładowo C lub Google GO. Które nie są ani funkcyjne, ani obiektowe.

W ten sposób dostajemy programowanie obiektowo-funkcyjne

Nie.

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Hmm co wybrać paradygmat, który ogranicza błąd ludzki, czy taki, który tego nie robi i modlić się, że w twoim projekcie będą tylko zdyscyplinowani ludzie. :^)

Nie trzeba nawet zmieniać paradygmatu. Można programować w języku strukturalnym takim jak Rust i korzystać z narzędzi podobnych (lub nie) co w OOPie, np:

• można tworzyć skomplikowane hierarchie zależności typów i parametrów generycznych dostosowanych do rozwiązywanych problemów
• można kontrolować dostęp do pól i metod zapewniając enkapsulację
• można kontrolować mutowalność zarówno dla pól struktur jak i parametrów metod (modyfikator mut)
• można korzystać ze skomplikowanego mechanizmu wskaźników z posiadaniem (ownership), zapożyczeniami (borrows) i cyklami życia (lifetimes) których poprawność jest sprawdzana na etapie kompilacji

Problem z fanatykami C jest raczej taki, że oni wolą się gapić na swój prostacki kod i zastanawiać się czy gdzieś się nie walnęli zamiast skorzystać z współczesnych narzędzi, które automatyzują robotę głupiego.

Krolik napisał(a):

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.

Ja rozumiem że tu każdy przejaskrawia żeby było ciekawiej, ale to nie do końca tak jest.

W C możesz mieć prywatne dane w strukturze:
https://www.embeddedrelated.com/showarticle/166.php
ale nie musisz:
https://stackoverflow.com/questions/10498321/how-to-define-a-global-struct-variable-in-c

To od programisty zależy czy będzie pisał kaszanę czy nie.

Dla porównania, w Javie też możesz pisać proceduralnie:
https://stackoverflow.com/a/7486111

Może idealizuję, ale C "globalny współdzielony stan" owszem występuje, ale głównie na 8-bitowcach albo podobnych platformach, gdzie nie jest używana pamięć alokowana dynamicznie (albo nie jest jedyną formą pamięci):
https://www.arduino.cc/reference/en/language/variables/variable-scope--qualifiers/scope/

Jeśli chodzi o zakres czy mutowalność to w standardowych przypadkach proceduralnie pisze się w ten sposób że jeden z argumentów procedury/funkcji odpowiada jednemu lub więcej wskaźnikowi "this". I niekoniecznie te argumenty muszą być modyfikowane.
Funkcje biblioteczne które mają jakikolwiek stan (czyli bardziej procedury niż funkcje, np. rand, strtok) nie są specjalnie lubiane.

Prawdziwa różnica wychodzi wtedy gdy chcemy mieć polimorfizm (albo co gorsza interfejsy) w języku proceduralnym.

vpiotr napisał(a):

Prawdziwa różnica wychodzi wtedy gdy chcemy mieć polimorfizm (albo co gorsza interfejsy) w języku proceduralnym.

Interfejsy da się zrealizować bez obiektowści - patrz google Go. Polimorfizm? Nigdy nie czułem potrzeby go używać. Można bez niego żyć.

Interfejsy i polimorfizm są w Ruście, bez obiektowości.

Crude Monte Carlo napisał(a):

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Hmm co wybrać paradygmat, który ogranicza błąd ludzki,

Żaden paradygmat nie ogranicza istotnie błędu ludzkiego. Wręcz często tworzy nowe pola do popisu ułatwiając poełnianie błędów wymagających w innym paradygmacie zbyt wiele wysiłku by ich popełnienie było statystycznie zauważalne. Jednocześnie przenosząc te łatwe do popełnienia w innym, do strefy gdzie wymagałyby więcej wysiłku. Zresztą w obiektowości wiele rzekomych "ułatwień wynikających z dizajnu" są de facto efektem trzymania się pewnej dyscypliny, a nie tego, że są jedynymi możliwymi rozwiązaniami zapobiegającymi popełnianie konstruktów uznawanych za kijowe.

czy taki, który tego nie robi i modlić się, że w twoim projekcie będą tylko zdyscyplinowani ludzie. :^)

Jakoś Linux, git i masa innych projektów sobie radzi. Nie tylko dla tego, że Torvalds wyzywa od kretynów, tych którzy łamią wyznaczone zasady. Wszelakie warianty *BSD też funkcjonują, a korzenie jego kodu sięgają czasów przed narodzinami wielu z nas.

Crude Monte Carlo napisał(a):

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Hmm co wybrać paradygmat, który ogranicza błąd ludzki, czy taki, który tego nie robi i modlić się, że w twoim projekcie będą tylko zdyscyplinowani ludzie. :^)

Tylko ze co ciekawe, piewcy OOP mowia, ze aby uzywac go dobrze, trzeba zdobyc doswiadczenie - a to doswiadczenie jest doswiadczeniem m.in. w trzymaniu dyscypliny. OOP w zadnym razie nie ogranicza bledu ludzkiego, bo gdyby bylo tak jak piszesz, to daloby sie zatrudniajac samych niedoswiadczonych ludzi, uzyskiwac doskonale dzialajace programy - wystarczy tylko narzucic im OOP.

Jakoś Linux, git i masa innych projektów sobie radzi. Nie tylko dla tego, że Torvalds wyzywa od kretynów, tych którzy łamią wyznaczone zasady. Wszelakie warianty *BSD też funkcjonują, a korzenie jego kodu sięgają czasów przed narodzinami wielu z nas.

Systemy bankowe napisane w COBOLu też dają radę, tylko mało kto chce w tym języku pisać, więc przepisuje się je na Javę. Poza tym niestety, ale to co daje radę przy pisaniu sterowników nie musi się sprawdzać w innych zastosowaniach.

Tylko ze co ciekawe, piewcy OOP mowia, ze aby uzywac go dobrze, trzeba zdobyc doswiadczenie - a to doswiadczenie jest doswiadczeniem m.in. w trzymaniu dyscypliny. OOP w zadnym razie nie ogranicza bledu ludzkiego, bo gdyby bylo tak jak piszesz, to daloby sie zatrudniajac samych niedoswiadczonych ludzi, uzyskiwac doskonale dzialajace programy - wystarczy tylko narzucic im OOP.

OOP nie jest magicznym przewodnikiem prowadzącym za rączkę, ale opłacalnym wyborem. Nie bez powodu najwięcej kasy leży w projektach opartych o języki obiektowe. Gdyby w C dałoby się równie szybko naklepać program (o akceptowalnej jakości) co w innych językach to C byłby częściej wybierany.

Szalony Czubek napisał(a):

Crude Monte Carlo napisał(a):

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Hmm co wybrać paradygmat, który ogranicza błąd ludzki,

Żaden paradygmat nie ogranicza istotnie błędu ludzkiego. Wręcz często tworzy nowe pola do popisu ułatwiając poełnianie błędów wymagających w innym paradygmacie zbyt wiele wysiłku by ich popełnienie było statystycznie zauważalne. Jednocześnie przenosząc te łatwe do popełnienia w innym, do strefy gdzie wymagałyby więcej wysiłku. Zresztą w obiektowości wiele rzekomych "ułatwień wynikających z dizajnu" są de facto efektem trzymania się pewnej dyscypliny, a nie tego, że są jedynymi możliwymi rozwiązaniami zapobiegającymi popełnianie konstruktów uznawanych za kijowe.

czy taki, który tego nie robi i modlić się, że w twoim projekcie będą tylko zdyscyplinowani ludzie. :^)

Jakoś Linux, git i masa innych projektów sobie radzi. Nie tylko dla tego, że Torvalds wyzywa od kretynów, tych którzy łamią wyznaczone zasady. Wszelakie warianty *BSD też funkcjonują, a korzenie jego kodu sięgają czasów przed narodzinami wielu z nas.

Troll anty OOP napisał(a):

Crude Monte Carlo napisał(a):

Lub dyscyplinę programisty piszącego kod w innym paradygmacie.

Hmm co wybrać paradygmat, który ogranicza błąd ludzki, czy taki, który tego nie robi i modlić się, że w twoim projekcie będą tylko zdyscyplinowani ludzie. :^)

Tylko ze co ciekawe, piewcy OOP mowia, ze aby uzywac go dobrze, trzeba zdobyc doswiadczenie - a to doswiadczenie jest doswiadczeniem m.in. w trzymaniu dyscypliny. OOP w zadnym razie nie ogranicza bledu ludzkiego, bo gdyby bylo tak jak piszesz, to daloby sie zatrudniajac samych niedoswiadczonych ludzi, uzyskiwac doskonale dzialajace programy - wystarczy tylko narzucic im OOP.

Wystarczy przejrzeć ten dział, czy działy poszczególnych języków mających cokolwiek wspólnego z obiektowością, oraz "portfolia" wrzucane przez początkujących w dziale Kariera, żeby oglądać masy zorientowanego obiektowo makaronu i mnożenia bytów (klas, obiektów) ponad miarę i potrzebę itp. Wiele z tych błędów jest strasznie trudna do popełnienia proceduralnie, acz nie niemożliwa. Więc modlitwy o zdyscyplinowanych będą potrzebne również przy projektach OOP, jeśli ktoś jest wierzący.

Wystarczy przejrzeć ten dział, czy działy poszczególnych języków mających cokolwiek wspólnego z obiektowością, oraz "portfolia" wrzucane przez początkujących w dziale Kariera, żeby oglądać masy zorientowanego obiektowo makaronu i mnożenia bytów (klas, obiektów) ponad miarę i potrzebę itp. Wiele z tych błędów jest strasznie trudna do popełnienia proceduralnie, acz nie niemożliwa. Więc modlitwy o zdyscyplinowanych będą potrzebne również przy projektach OOP, jeśli ktoś jest wierzący.

Tracisz czas na oglądanie wypocin amatorów? Chyba nie masz co ze swoim czasem robić. Przejrzyj projekty, które mają jakąś tam popularność.

Wibowit napisał(a):

Tracisz czas na oglądanie wypocin amatorów? Chyba nie masz co ze swoim czasem robić. Przejrzyj projekty, które mają jakąś tam popularność.

No jeśli jakiś paradygmat ma tak bardzo ułatwiać, być tak bardzo intuicyjny, to u kogo jak nie u amatorów te akurat cechy powinny się objawiać najmocniej? A tak mamy okazję widzieć, że ktoś tworzy sobie zupełnie sztuczne problemy, których w programowaniu proceduralnym by nie miał.

Wibowit napisał(a):

Jakoś Linux, git i masa innych projektów sobie radzi. Nie tylko dla tego, że Torvalds wyzywa od kretynów, tych którzy łamią wyznaczone zasady. Wszelakie warianty *BSD też funkcjonują, a korzenie jego kodu sięgają czasów przed narodzinami wielu z nas.

Systemy bankowe napisane w COBOLu też dają radę, tylko mało kto chce w tym języku pisać, więc przepisuje się je na Javę. Poza tym niestety, ale to co daje radę przy pisaniu sterowników nie musi się sprawdzać w innych zastosowaniach.

A co stoi za wybieraniem Javy? Jej obiektowość (przez wielu zresztą krytykowana za obrany przez język model), czy popularność i duża baza siły roboczej, któara przyswoiła język i jest zatrudniona w bankach przy klepaniu nowości od podstaw? Pamiętaj, że za Javą stał bardzo mocny hype dzięki pewnej korporacji z nim związanej, która miała swego czasu sporo do powiedzenia i miała możliwości lansowania wielu trendów, na zasadzie "bo to ich produkt", a nie dla tego, że był on jakiś lepszy niż konkurencyjny. Do tego śmiem podkreślić nie związany z OOPem fakt, że Java zawdzięcza wiele przede wszystkim maszynie wirtualnej i garbage collectorowi. Czyli elementom nie mającym z OOP ścisłego związku, ani nawet nie narodziły się one jako elementy języka obiektowego.

Tylko ze co ciekawe, piewcy OOP mowia, ze aby uzywac go dobrze, trzeba zdobyc doswiadczenie - a to doswiadczenie jest doswiadczeniem m.in. w trzymaniu dyscypliny. OOP w zadnym razie nie ogranicza bledu ludzkiego, bo gdyby bylo tak jak piszesz, to daloby sie zatrudniajac samych niedoswiadczonych ludzi, uzyskiwac doskonale dzialajace programy - wystarczy tylko narzucic im OOP.

OOP nie jest magicznym przewodnikiem prowadzącym za rączkę, ale opłacalnym wyborem. Nie bez powodu najwięcej kasy leży w projektach opartych o języki obiektowe. Gdyby w C dałoby się równie szybko naklepać program (o akceptowalnej jakości) co w innych językach to C byłby częściej wybierany.

Co ty znowu wyskaujesz z C? Rozmawiamy o paradygmatach, a ty przenosisz dyskusję na poziom konkretnych języków.

Ale jak już tak cię swędzą palce żeby brnąć w offtop. C powstał jako język do pisania systemu UNIX. Zresztą coraz więcej projektów powstaje w Goole GO, który wiele po nim dziedziczy i trochę dodaje. Też nie jest obiektowy jak i C.

Poza tym, żeby w ogóle operować w rozmowie twierdzeniami, że OOP przyczynia się do powstawania "szybciej kodu o akceptowalnej jakości", to trzeba by dysponować wynikami weryfikowalnych i powtarzalnych badań naukowych na ten temat. Inaczej to gadanie po próżnicy, na podstawie "anegdotical evidence". W drugą stronę też można w ten sposób konstruować zarzuty. To będzi licytowanie się, na to kto jest bardziej przekonany do swojej racji. Do tego akceptowalności kodu już tak obiektywnie się nie da zmierzyć jak szybkości powstania kodu. Więc to droga do nikąd.

Troll anty OOP napisał(a):

Wibowit napisał(a):

Tracisz czas na oglądanie wypocin amatorów? Chyba nie masz co ze swoim czasem robić. Przejrzyj projekty, które mają jakąś tam popularność.

No jeśli jakiś paradygmat ma tak bardzo ułatwiać, być tak bardzo intuicyjny, to u kogo jak nie u amatorów te akurat cechy powinny się objawiać najmocniej? A tak mamy okazję widzieć, że ktoś tworzy sobie zupełnie sztuczne problemy, których w programowaniu proceduralnym by nie miał.

W punkt!

No jeśli jakiś paradygmat ma tak bardzo ułatwiać, być tak bardzo intuicyjny, to u kogo jak nie u amatorów te akurat cechy powinny się objawiać najmocniej? A tak mamy okazję widzieć, że ktoś tworzy sobie zupełnie sztuczne problemy, których w programowaniu proceduralnym by nie miał.

1. nabieranie doświadczenia to głównie uczenie się na błędach (własnych i cudzych). Jeśli się czegoś od razu nie zrozumie, to popełni się błąd, ale potem się zrozumie ten błąd i go poprawi.
2. uczepiłeś się tych klas jak rzep psiego ogona i nie widzisz nic poza tym.
3. pokaż swoje projekty w C, wszyscy będziemy podziwiać kunszt wielkiego eksperta od programowania
4. schizofrenia ci się nasila :)

Do tego śmiem podkreślić nie związany z OOPem fakt, że Java zawdzięcza wiele przede wszystkim maszynie wirtualnej i garbage collectorowi. Czyli elementom nie mającym z OOP ścisłego związku, ani nawet nie narodziły się one jako elementy języka obiektowego.

No to już zaprzeczasz sam sobie. Java przyniosła to co już było i dlatego się wybiła. Ma to "sens".

Poza tym, żeby w ogóle operować w rozmowie twierdzeniami, że OOP przyczynia się do powstawania "szybciej kodu o akceptowalnej jakości", to trzeba by dysponować wynikami weryfikowalnych i powtarzalnych badań naukowych na ten temat. Inaczej to gadanie po próżnicy, na podstawie "anegdotical evidence". W drugą stronę też można w ten sposób konstruować zarzuty. To będzi licytowanie się, na to kto jest bardziej przekonany do swojej racji. Do tego akceptowalności kodu już tak obiektywnie się nie da zmierzyć jak szybkości powstania kodu. Więc to droga do nikąd.

Po co mi jakieś badania, skoro mamy działający wolny rynek? Jak chcesz to możesz założyć firmę razem z resztą fanatyków czystego C i klepać programy, które zwykle robi się w Javce. Unikniesz tworzenia klas i będziesz wprowadzał produkty X razy szybciej i X razy taniej (gdzie X < 1 oczywiście).

Wibowit napisał(a):

1. schizofrenia ci się nasila :)

Nie wiem gdzie ty widzisz objawy schizofreni u Troll anty OOP. Czy ty w ogóle umiesz prowadzić rozmowę bez wycieczek osobistych pod adresem czyjejś psychiki, tylko dla tego, że się nie zgadasz z rozmówcą? Dla ciebie każdy kto ma odmienne poglądy jest niezrównoważony psychicznie? To dość niskie i żałosne podejście.

Wibowit napisał(a):

1. uczepiłeś się tych klas jak rzep psiego ogona i nie widzisz nic poza tym.

Pomimo że nazwałem się jak nazwałem, to nie jestem tą samą osobą, co drugi dyskutant. Natomiast byłem już w tym wątku, ale osoby o przeciwnym poglądzie w kwestii OOP nazywa się na tym forum trollami, więc dobrałem sobie adekwatny login.

1. pokaż swoje projekty w C, wszyscy będziemy podziwiać kunszt wielkiego eksperta od programowania

Podejrzewam, że wielu z Was je widziało, ale w działaniu. Bo ja nie przygotowuję kodu źródłowego na wystawę, tylko przygotowuję programy mające spełniać jakąś funkcję. Perfekcja wymagałaby dużo więcej czasu. Kodu źródłowego póki co nie pokażę. Skrytykować każdy potrafi.

Wibowit napisał(a):

Po co mi jakieś badania, skoro mamy działający wolny rynek?

Świetnie! Po co badać skuteczność leków? Mamy wolny rynek! Skoro snake oil się sprzedaje, znaczy, że leczy! Hura! Wolny rynek dowodem na skuteczność! Oczywiście fakt, że tanie i kijowe jakościowo chińskie wyroby na wolnym rynku się sprzedają, też dowodzi wyższości jakości nad krajowymi produktami! Bez jaj.

Jak chcesz to możesz założyć firmę razem z resztą fanatyków czystego C i klepać programy, które zwykle robi się w Javce. Unikniesz tworzenia klas i będziesz wprowadzał produkty X razy szybciej i X razy taniej (gdzie X < 1 oczywiście).

Istnieje masa takich firm, wiele istniej na rynku od dekad. I co teraz?

Podejrzewam, że wielu z Was je widziało, ale w działaniu. Bo ja nie przygotowuję kodu źródłowego na wystawę, tylko przygotowuję programy mające spełniać jakąś funkcję. Perfekcja wymagałaby dużo więcej czasu. Kodu źródłowego póki co nie pokażę. Skrytykować każdy potrafi.

Tak, skrytykować każdy potrafi. Zwłaszcza gdy ktoś zrobi o kilka klas za dużo.

No to nie wiem o czym dalej rozmawiać. Czepiasz się, że OOP ci się nie podoba, a sam produkujesz dziadostwo.

Świetnie! Po co badać skuteczność leków? Mamy wolny rynek! Skoro snake oil się sprzedaje, znaczy, że leczy! Hura! Wolny rynek dowodem na skuteczność! Oczywiście fakt, że tanie i kijowe jakościowo chińskie wyroby na wolnym rynku się sprzedają, też dowodzi wyższości jakości nad krajowymi produktami! Bez jaj.

Jak niby chciałbyś zbadać języki? Stworzyć duże aplikacje biznesowe w kilku językach? Koszt takiego badania szedłby w dziesiątki milionów dolarów.

Poza tym mówimy o zupełnie różnych badaniach. Badania leków są prowadzone pod kątem bezpieczeństwa, a nie konkurencyjności. Konkurencyjność leków jest sprawdzana dzięki wolnemu rynkowi - klienci wybierają jedne leki częściej niż inne.

A jeśli chodzi o snake oil, to sprzedaż jest (niestety) legalna. Przykładem jest "lek" oscillococcinum.

Istnieje masa takich firm, wiele istniej na rynku od dekad. I co teraz?

Podaj przykład webowej aplikacji biznesowej napisanej w czystym C.

No to nie wiem o czym dalej rozmawiać. Czepiasz się, że OOP ci się nie podoba, a sam produkujesz dziadostwo.

Nie produkuję dziadostwa, tylko programy gdzie priorytetem jest to, czego zamawiający oczekiwał, a nie zgodność z wyznawaną przeze mnie programistyczną ideologią. I staram się oszczędzać swój czas. Zarówno czas tworzenia jak i późniejszego naprawiania błędów.

Nie produkuję dziadostwa, tylko programy gdzie priorytetem jest to, czego zamawiający oczekiwał, a nie zgodność z wyznawaną przeze mnie programistyczną ideologią. I staram się oszczędzać swój czas. Zarówno czas tworzenia jak i późniejszego naprawiania błędów.

No to jak ktoś z rozbiegu naprodukuje kilka klas za dużo to dostajesz białej gorączki, natomiast jeśli sam naprodukujesz dziadostwo to jest to oznaką rozsądku. Podwójne standardy.

Napisz też ile dziadostwa robiłeś na początku przygody z programowaniem, a ile teraz. Zmieniło się to jakoś?

Troll anty OOP napisał(a):

Wibowit napisał(a):

1. uczepiłeś się tych klas jak rzep psiego ogona i nie widzisz nic poza tym.

Pomimo że nazwałem się jak nazwałem, to nie jestem tą samą osobą, co drugi dyskutant. Natomiast byłem już w tym wątku, ale osoby o przeciwnym poglądzie w kwestii OOP nazywa się na tym forum trollami, więc dobrałem sobie adekwatny login.

No bo wiesz, jak ktoś na tym forum jest przeciwko OOP, to na bank tylko jedna osoba. ;)
Ja obrałem sobie nick na podstawie diagnozy Pana Profesora Medycyny w Specjalizacji Psychiatrycznej Wibowita.

1. pokaż swoje projekty w C, wszyscy będziemy podziwiać kunszt wielkiego eksperta od programowania

Podejrzewam, że wielu z Was je widziało, ale w działaniu. Bo ja nie przygotowuję kodu źródłowego na wystawę, tylko przygotowuję programy mające spełniać jakąś funkcję. Perfekcja wymagałaby dużo więcej czasu. Kodu źródłowego póki co nie pokażę. Skrytykować każdy potrafi.

Może zacznijmy od przejechania się po kodzie pana Profesora Psychiatrii, skoro jest taki ochoczy do oceniania naszego kodu żeby zapoznać się kto chce nas sądzić. Oto jego repozytoria na githubie:

https://github.com/tarsa

Może zacznijmy od przejechania się po kodzie pana Profesora Psychiatrii, skoro jest taki ochoczy do oceniania naszego kodu żeby zapoznać się kto chce nas sądzić. Oto jego repozytoria na githubie:
https://github.com/tarsa

Zapraszam do konstruktywnej krytyki. Tylko nie zapomnij pokazać własnego idealnego kodu.

Wibowit napisał(a):

Podejrzewam, że wielu z Was je widziało, ale w działaniu. Bo ja nie przygotowuję kodu źródłowego na wystawę, tylko przygotowuję programy mające spełniać jakąś funkcję. Perfekcja wymagałaby dużo więcej czasu. Kodu źródłowego póki co nie pokażę. Skrytykować każdy potrafi.

Tak, skrytykować każdy potrafi. Zwłaszcza gdy ktoś zrobi o kilka klas za dużo.

No to nie wiem o czym dalej rozmawiać. Czepiasz się, że OOP ci się nie podoba, a sam produkujesz dziadostwo.

Świetnie! Po co badać skuteczność leków? Mamy wolny rynek! Skoro snake oil się sprzedaje, znaczy, że leczy! Hura! Wolny rynek dowodem na skuteczność! Oczywiście fakt, że tanie i kijowe jakościowo chińskie wyroby na wolnym rynku się sprzedają, też dowodzi wyższości jakości nad krajowymi produktami! Bez jaj.

Jak niby chciałbyś zbadać języki? Stworzyć duże aplikacje biznesowe w kilku językach? Koszt takiego badania szedłby w dziesiątki milionów dolarów.

Brawo! W końcu przyznałeś, że wziąłeś dane o "szybszym kodzie lepszej jakości" z sufitu. Dziękuję.

Poza tym mówimy o zupełnie różnych badaniach. Badania leków są prowadzone pod kątem bezpieczeństwa, a nie konkurencyjności. Konkurencyjność leków jest sprawdzana dzięki wolnemu rynkowi - klienci wybierają jedne leki częściej niż inne.

A konkurencyjność zaś jest składową wielu czynników, nie zaś samej jakości i czasu powstania,. Więc nic z mojej wypowiedzi nie obaliłeś.

Podaj przykład webowej aplikacji biznesowej napisanej w czystym C.

Nie podam z głowy przykładów, wiem, że istnieją, oraz, że istnieją frameworki do ich pisania. Do tego C nie jest jedynym, proceduralnym językiem, w którym takie aplikacje są pisane. A dyskutować winniśmy o wszystkich językach proceduralnych, a nie zawężać do wygodnych dla ciebie przedstawicieli. Google Go ma zresztą całą bibliotekę do pisania aplikacji webowych w standardowym zestawie bibliotek. Zresztą strona tego języka jest w nim napisana. Po całą resztę odsyłam na github czy wyszukiwarki internetowej. Materiałów jest sporo. W dziale Praca są nawet ogłoszenia dla programistów Go jasno dające do zrozumienia, że chodzi pisanie systemów webowych w tym języku. Więc da się proceduralnie? Da. Ludzie to robią i na tym zarabiają.

Nie podam z głowy przykładów, wiem, że istnieją, oraz, że istnieją frameworki do ich pisania.

Jakby w LOGO istniał framework do aplikacji webowych to też byś o tym wspomniał? Pytałem o konkretne produkty na których można zarobić.

Nie podam z głowy przykładów, wiem, że istnieją, oraz, że istnieją frameworki do ich pisania. Do tego C nie jest jedynym, proceduralnym językiem, w którym takie aplikacje są pisane. A dyskutować winniśmy o wszystkich językach proceduralnych, a nie zawężać do wygodnych dla ciebie przedstawicieli.

Najpierw napisz jaki masz problem z OOPem. Nie wiem którą wersją trolla jesteś, ale problemem z OOP była zbyt rozbudowana składnia przede wszystkim (czyli hierachia typów, generyki, itd). Są języki proceduralne mniej i bardziej skomplikowane. Tyle, że te bardziej skomplikowane to zbliżają się mocno do tych OOPowych.

Wibowit napisał(a):

Nie podam z głowy przykładów, wiem, że istnieją, oraz, że istnieją frameworki do ich pisania.

Jakby w LOGO istniał framework do aplikacji webowych to też byś o tym wspomniał? Pytałem o konkretne produkty na których można zarobić.

Przecież ci napisałem, nie rozumiesz czytanego tekstu? Masz:

Go / Golang Software Engineer

do tego masa innych ofert w Go w kontekście webdevu z całego świata do wygooglowania. Dotarło, czy mam narysować? ;)

Nie podam z głowy przykładów, wiem, że istnieją, oraz, że istnieją frameworki do ich pisania. Do tego C nie jest jedynym, proceduralnym językiem, w którym takie aplikacje są pisane. A dyskutować winniśmy o wszystkich językach proceduralnych, a nie zawężać do wygodnych dla ciebie przedstawicieli.

Najpierw napisz jaki masz problem z OOPem. Nie wiem którą wersją trolla jesteś, ale problemem z OOP była zbyt rozbudowana składnia przede wszystkim (czyli hierachia typów, generyki, itd). Są języki proceduralne mniej i bardziej skomplikowane.

Wszystkiego po trochu, najwięcej z programistami.

Tyle, że te bardziej skomplikowane to zbliżają się mocno do tych OOPowych.

Taaa, jasne. Może to OOP po prostu jest zbliżony do proceduralnego? ;) A czemu nie do funkcyjnych czy do innych paradygmatów? Poza tym bliskość to jednak spora różnica. Polska leży blisko Niemiec, jednak Niemcami nie jest. ;)

Hm a tak finalnie - dlaczego ten OOP ssie? Oczywiscie pomijamy punkty ktore wynikaja z tego ze programista jest slaby oraz braku trzymania dyscypliny - bo to dotyczy wszystkiego.