Wibowit napisał(a):
Błękitny Kot napisał(a):
Kilka podstawowych przewag programowania proceduralnego nad obiektowym:
- większa swoboda i elastyczność
- łatwiejsze debugowanie
- bardziej intuicyjne
Nie zgadzam się z żadnym z punktów. Uzasadnienia nie chce mi się podawać, bo sam uzasadnienia nie podałeś.
A co tu uzasadniać? Wystarczy mieć styczność z oboma paradygmatami przez kilka lat. Ja mam już ponad dekadę.
Dziedziczenie i metody abstrakcyjne można zastąpić do pewnego stopnia domknięciami. Tzn zamiast:
class Klasa {
def metoda: Int =
doNadpisania + 1
def doNadpisania: Int // abstrakcyjna metoda do nadpisania w podklasach
}
można napisać:
class Klasa(doPodaniaZZewnątrz: () => Int) {
def metoda: Int =
doPodaniaZZewnątrz() + 1
}
Ktoś kto bardzo nie lubi OOP, dziedziczenia, metod wirtualnych, etc będzie się bardzo cieszył, ale moim zdaniem nawigacja i analiza kodu bardzo cierpi na tym, przynajmniej w obecnych IDE typu IntelliJ. Mając klasę IntelliJ po jednym skrócie klawiaturowym pokaże mi hierarchię dziedziczenia. Przy metodzie IntelliJ pokaże ikonki dzięki którym szybko można dojść do metod nadpisanych lub nadpisujących/ implementujących. Inaczej mówiąc w przypadku OOP nawigacja w kodzie jest "pierwsza klasa". W przypadku domknięć/ lambd natomiast jest strasznie kiepsko bo te lambdy mają tendencję do bycia przesyłanymi wzdłuż i w poprzek, więc samo ich szukanie wybija mnie z toku myślenia. Dziedziczenie i kompozycja działają dla mnie lepiej niż szastanie lambdami.
Z drugiej strony mamy pojedynek dziedziczenie vs kompozycja i tutaj nie ma wygranego, bo oba podejścia mają sens. Dziedziczenie jest lekkie jeśli hierarchia klas jest lekka i w takich przypadkach dobrze się sprawdza. Kompozycja wprowadza pewien narzut (bolierplate), więc rozdrabnianie wszystkiego na siłę jak najmniejsze komponenty rozdmucha kod nie przynosząc zysku netto. Z drugiej strony jednak w wielu przypadkach ma sens, zwłaszcza jeśli hierarchia dziedziczenia staje się skomplikowana i można ją uprościć rozbijając ją na kompozycję i mniejsze hierarchie dziedziczenia.
Co do programowania funkcyjnego to powtórzę jeszcze raz, że podstawą funkcyjności jest niemutowalność danych, a co za tym idzie kolekcje w bibliotece standardowej muszą wspierać ten sposób pisania. Dodawanie elementu do niemutowalnej mapy ma zwracać nową mapę, a nie rzucać błędem. Tego typu kolekcje są w standardzie w Scali i Haskellu, ale np w C, C++, Ruście, Javie, Kotlinie, C#, Pythonie, JavaScripcie itp itd ich w standardzie nie ma. Gdy ich nie ma to przy pisaniu funkcyjnym trzeba by skorzystać z bibliotek niestandardowych, a potem mieć poważny problem z integracją z kodem, który używa standardowych kolekcji. Bez funkcyjnych kolekcji dane stają się dużym grafem mutowalnych obiektów/ struktur/ czegokolwiek tak jak tu zostało przytoczone.
Co do obiekt vs struktura to jak napisał @zyxist struktury często udają obiekty jeżeli robimy ręcznie to co kompilator zrobiłby za nas. W szczególności takie podejście wydaje się strukturalne:
class Klasa {
val typ: Int
val dane: Int
}
def wyciągnijDane(klasa: Klasa): Int = {
klasa.typ match {
case 0 => klasa.dane + 1
case 1 => klasa.dane + 8
case 2 => klasa.dane * 3
case _ => klasa.dane - 9
}
}
Ale to tak naprawdę zakamuflowane dziedziczenie typu:
class Klasa(dane: Int) {
def wyciągnijDane: Int = dane - 9
}
class KlasaTyp0(dane: Int) extends Klasa(dane) {
override def wyciągnijDane: Int = dane + 1
}
... // kolejne klasy analogicznie
Ifologia emulująca dziedziczenie jest antywzorcem w językach OOP, bo jest zwyczajnie gorsza. Kompilator nie jest w stanie sprawdzić czy ifologia ma sens i jest poprawna, ale jest w stanie to sprawdzić w przypadku hierarchii klas. Podobnie analiza kod i nawigacja działa wygodnie i szybko w przypadku hierarchii klas, ale w przypadku ifologii jest z tym sporo gorzej.
PS:
Podawanie C++ jako przykładowej implementacji OOPa jest jak podawanie COBOLa jako przykładowej implementacji języka strukturalnego. Solidnymi implementacjami OOPa są Java i C#, więc w ich kontekście powinno się analizować skuteczność OOPa.
Ale tu jako alternatywa dla OOP został przedstawiony jakikolwiek inny paradygmat, czy po prostu jedni chwalą proceduralne, inni funkcyjne, a inni tylko narzekają na OOP?
Ja też. - Wibowit dziś, 11:05
I dlatego odpowiadasz po kryjomu pod postem? Czyli to dyskusja czyje niebo jest bardziej niebieskie.
Mały Szczur napisał(a):
Ja też. - Wibowit dziś, 11:05
I dlatego odpowiadasz po kryjomu pod postem? Czyli to dyskusja czyje niebo jest bardziej niebieskie.
WTF?
to nie oop ssie tylko kiepscy programisci ;)
czytywalam wspomniany blog i niektore wpisy byly dosc ciekawe, niemniej sporo bylo oderwanych od rzeczywistosci.
imo nie ma co sie trzymac kurczowo paradygmatu a raczej programowac 'hybrydowo' w zaleznosci od potrzeb.
moja smutna obserwacja jest ze wielu klepaczy popada w skrajnosci typu:
while zamiast for bo szybciej bedzie"o ile takie osoby w teamie czesto wnosza cos ciekawego to na dluzsza mete moga byc meczace, a najgorzej jak dorwa sie do wladzy :)
Wibowit napisał(a):
Mały Szczur napisał(a):
Ja też. - Wibowit dziś, 11:05
I dlatego odpowiadasz po kryjomu pod postem? Czyli to dyskusja czyje niebo jest bardziej niebieskie.WTF?
No sorry, ale jak tak prostej wypowiedzi nie rozumiesz, to się nie dziwię, że się gubisz w kodzie proceduralnym.
Oświeć mnie. Co jest po kryjomu? Jakaś procedurka się nie odpaliła? Coś ci się w ifie zgubiło?
Wibowit napisał(a):
Oświeć mnie. Co jest po kryjomu? Jakaś procedurka się nie odpaliła? Coś ci się w ifie zgubiło?
O widzę, że próbowałeś być dowcipny, ale okazało się że przekazujesz do metody write() Null reference, a miał być obiekt klasy Joke.
Skoro czytając tamten post nie miałeś utworzonego żadnego obiektu klasy ThoughProcess wyjaśniam - odpisując niezarejestrowanemu pod postem
działasz jak cichociemny w burdelu. Niby chcesz coś zainicjować, ale się chowasz. To tyle. Możesz już teraz wywołać destruktor klasy Brain.
BTW dodałbym jeszcze https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
Czarny Młot napisał(a):
No sorry, ale jak tak prostej wypowiedzi nie rozumiesz, to się nie dziwię, że się gubisz w kodzie proceduralnym.
Napisał gość, który gubi się w markdownie. :D :D :D :D :D
somekind napisał(a):
Czarny Młot napisał(a):
No sorry, ale jak tak prostej wypowiedzi nie rozumiesz, to się nie dziwię, że się gubisz w kodzie proceduralnym.
Napisał gość, który gubi się w markdownie. :D :D :D :D :D
hehehe ebin :DDD
Skoro czytając tamten post nie miałeś utworzonego żadnego obiektu klasy ThoughProcess wyjaśniam - odpisując niezarejestrowanemu pod postem
działasz jak cichociemny w burdelu.
Polecam się zarejestrować, a nie manifestować swojej schizofrenii pisząc z wielu kont anonimowych.
Pijany Polityk napisał(a):
BTW dodałbym jeszcze https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
Twoje obecne alter ego dalej wielbi programowanie proceduralne? Jeśli tak to masz poważny problem ze zrozumienim tekstu pisanego. W tekście który podałeś są takie zdania:
This is the second part in a series I’m writing about lessons that can be learned from functional programming. Find the first part here.
Programowanie funkcyjne to coś zupełnie innego niż programowanie imperatywne. Programowanie strukturalne jest podtypem programowania imperatywnego, a programowanie imperatywne zostało obsmarowane w tym artykule.
Ponadto w arykule który podlinkowałeś jest coś takiego:
While I believe the problems with OOP are extensive, I do think it is a valuable mechanism for developing software. But is certainly not the only one. The biggest problem in my mind is thus:
When people overcome the significant hurdle of fully appreciating OOP, they tend to apply it to every problem. OOP becomes the solution, and every problem looks like a nail.
There’s got to be a better way…
Gość więc sam przyznaje, że OOP jest przydatny, ale fanatyczny (przesadzony) OOP jest szkodliwy. Chyba większość się z nim zgadza.
Ta wiki wygląda jakbyś sam ją pisał.
Aktualizacja:
Sprawdziłem kto stoi za c2.com. Jest to Ward Cunningham. c2 zawiera taki wpis na głównej stronie:
We are a small consultancy that has specialized in object-oriented programming.
Hipokryta? A może trolle opanowały jego wiki?
Wibowit napisał(a):
Skoro czytając tamten post nie miałeś utworzonego żadnego obiektu klasy ThoughProcess wyjaśniam - odpisując niezarejestrowanemu pod postem
działasz jak cichociemny w burdelu.Polecam się zarejestrować, a nie manifestować swojej schizofrenii pisząc z wielu kont anonimowych.
Widżę, że masz nie tylko doktorat z zachowywania zimnej krwii w rozmowach w sieci ale i psychiatrii. Powinszować wszechstronnych uzdolnień.
Pijany Polityk napisał(a):
BTW dodałbym jeszcze https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
Twoje obecne alter ego dalej wielbi programowanie proceduralne?
Wszystkie moje wielorakie osobowości zgadzają się, że OOP jest przydatny jedynie w pracy z już istniejącym kodem OOP, bo mieszanie paradygmatu wprowadzałoby za duży chaos. Jesteśmy więc spójni w tej kwestii, tak jak spójny powinien być kod.
Jeśli tak to masz poważny problem ze zrozumienim tekstu pisanego. W tekście który podałeś są takie zdania:
This is the second part in a series I’m writing about lessons that can be learned from functional programming. Find the first part here.
Bardzo freudowska pomyłka, bowiem nigdzie nie pisałem, że ten link cokolweik potwierdza lub obala z moich słów. Tylko daodałem go do dyskusji. Kontekst już sam sobie wymyśliłeś. Nie mogę ponosić odpowiedzialności za nie moją wyobraźnię.
Programowanie funkcyjne to coś zupełnie innego niż programowanie imperatywne. Programowanie strukturalne jest podtypem programowania imperatywnego, a programowanie imperatywne zostało obsmarowane w tym artykule.
Czy ja cokolwiek pisałem na ten temat? Nawet nie poruszałem tej kwestii. Zastanów się więc na przyszłość zanim zarzucisz mi brak umiejętności czytania ze zrozumieniem.
Ponadto w arykule który podlinkowałeś jest coś takiego:
While I believe the problems with OOP are extensive, I do think it is a valuable mechanism for developing software. But is certainly not the only one. The biggest problem in my mind is thus:
When people overcome the significant hurdle of fully appreciating OOP, they tend to apply it to every problem. OOP becomes the solution, and every problem looks like a nail.
There’s got to be a better way…
Gość więc sam przyznaje, że OOP jest przydatny, ale fanatyczny (przesadzony) OOP jest szkodliwy. Chyba większość się z nim zgadza.
A co to zmienia w moim stanowisku? Nic.
Ta wiki wygląda jakbyś sam ją pisał.
Dziękuję, to nie lada komplement. Acz nie ma w niej ani jednego mojego wpisu.
Aktualizacja:
Sprawdziłem kto stoi za c2.com. Jest to Ward Cunningham. c2 zawiera taki wpis na głównej stronie:We are a small consultancy that has specialized in object-oriented programming.
Hipokryta? A może trolle opanowały jego wiki?
Gdzie tu hipokryzja? Wiki może być edytowane przez każdego, kto ma dostęp. Poza tym, co ma prowadzenie konsultingu w sprawach programowania obiektowego do poglądów na jego temat? Wręcz bym powiedział, że krytyczny, czy wręcz alergiczny stosunek do OOP może wnieść do tego typu działalności wiele pozytywnych rzeczy. Nic tak nie działa twórczo na niejeden projekt niż zjechanie wielu jego aspektów z przedsatwieniem rzeczowej argumentacji. Kto będzie lepszym krytykiem projektu OOP, niż zaciekły wróg tego paradygmatu? Zwłąszcza jeśli musi swą krytykę podeprzeć odpowiednią argumentacją? Jak myślisz, do kogo bym poszedł skonsultować mój kod w paradygmacie X - krytyka tego paradygmatu, czy rozkochanego w nim entuzjasty? Oczywiście wybrałbym krytyka. Jakbym dostał rzeczową krytykę, to bym mu jeszcze dopłacił ekstra.
Jak myślisz, do kogo bym poszedł skonsultować mój kod w paradygmacie X - krytyka tego paradygmatu, czy rozkochanego w nim entuzjasty? Oczywiście wybrałbym krytyka. Jakbym dostał rzeczową krytykę, to bym mu jeszcze dopłacił ekstra.
No to ja dołączę do kolegów i też za rozsądną cenę skrytykuję każdy kod, zwłaszcza proceduralny. Tylko ostrożnie, bo możesz się nie wypłacić :]
Kod proceduralny nie ma przede mną tajemnic, bo przed laty programowałem w czystym asemblerze: http://asembler.republika.pl/ Nie było żadnych obiektów oprócz tych wymaganych przez WinAPI. Mało tego - nawet struktur było mało, bo pakowałem mnóstwo zmiennych w globalny zasięg.
Wszystkie moje wielorakie osobowości zgadzają się, że OOP jest przydatny jedynie w pracy z już istniejącym kodem OOP, bo mieszanie paradygmatu wprowadzałoby za duży chaos. Jesteśmy więc spójni w tej kwestii, tak jak spójny powinien być kod.
W pracy piszę w Scali i mieszam paradygmaty. Opłaca się to, bo czerpię korzyści zarówno z FP jak i OOP. Nie idę w skrajności typu wszystko musi być opakowane w monadę albo wszystko musi być obiektem. Korzystam z obiektów i monad tam gdzie to ma sens. Podobnie z danymi mutowalnymi i niemutowalnymi - tych drugich używam częściej, ale te pierwsze czasem się przydają, bo w pewnych przypadkach mogą skrócić kod (upraszczając go) bez utrudnienia zrozumienia globalnego przepływu danych (lokalna mutowalność).
Nic tak nie działa twórczo na niejeden projekt niż zjechanie wielu jego aspektów z przedsatwieniem rzeczowej argumentacji.
Rzeczowa argumentacja w wykonaniu naszego forumowego schizofrenika wygląda tak: "patrzcie ile linków wkleiłem! patrzcie ile ludzi pisze, że OOP jest be!"
Kurcze, a jak ja pisałem funkcyjnie w Turbo Pascalu 5.0 (bo akurat liznąłem Lispa i mi się spodobał) to pod który paragraf podpadam?
:D
Ale rozumiem autora tego wątku. Teraz jest trudny okres dla ludzi którzy nigdy nie opanowali OOP.
Z jednej strony programiści z lat 70-tych potwierdzają że OOP do niczego się nie nadaje.
Z drugiej programiści FP trąbią że OOP to już relikt przeszłości.
A ktoś kto się zatrzymał na PL/1 nie wie, czy ma w końcu się uczyć tego C tak solidnie czy też już wskoczyć na FP, skoro przegapił to całe łołope.
Niechęć do OOP wynika z przyzwyczajeń. Ja po wielu latach pisania proceduralnie i potem obiektowo do języków iście funkcyjnych nie mogę się przekonać.
Na obronę OOP podam trzy rzeczy:
No ładnie, 3 posty pod rząd i jedyna ich treść "patrzcie jacy jesteśmy zajebiści, a krytyka OOP == niska inteligencja". Typowa mentalna masturbacja.
Wibowit napisał(a):
Jak myślisz, do kogo bym poszedł skonsultować mój kod w paradygmacie X - krytyka tego paradygmatu, czy rozkochanego w nim entuzjasty? Oczywiście wybrałbym krytyka. Jakbym dostał rzeczową krytykę, to bym mu jeszcze dopłacił ekstra.
No to ja dołączę do kolegów i też za rozsądną cenę skrytykuję każdy kod, zwłaszcza proceduralny. Tylko ostrożnie, bo możesz się nie wypłacić :]
Oczywiście twoje założenie z góry że będzie to treść za którą dam chociaż złamanego grosza, nie świadczy o twoim wybujałym ego i kompletnym braku jakiejkolwiek pokory? Nie mów "hop" zanim nie podskoczysz, jak mawia mądrość ludowa.
Kod proceduralny nie ma przede mną tajemnic, bo przed laty programowałem w czystym asemblerze: http://asembler.republika.pl/ Nie było żadnych obiektów oprócz tych wymaganych przez WinAPI. Mało tego - nawet struktur było mało, bo pakowałem mnóstwo zmiennych w globalny zasięg.
No istny mistrz z ciebie. Czarny pas w global variables. Such assembler, such wow. Jak myślisz, że programowanie w asm robi na mnie jakieś wielkie wrażenie, to pukasz pod zły adres. Też mam z nim doświadczenie, w tym zawodowe.
Wszystkie moje wielorakie osobowości zgadzają się, że OOP jest przydatny jedynie w pracy z już istniejącym kodem OOP, bo mieszanie paradygmatu wprowadzałoby za duży chaos. Jesteśmy więc spójni w tej kwestii, tak jak spójny powinien być kod.
W pracy piszę w Scali i mieszam paradygmaty. Opłaca się to, bo czerpię korzyści zarówno z FP jak i OOP. Nie idę w skrajności typu wszystko musi być opakowane w monadę albo wszystko musi być obiektem. Korzystam z obiektów i monad tam gdzie to ma sens. Podobnie z danymi mutowalnymi i niemutowalnymi - tych drugich używam częściej, ale te pierwsze czasem się przydają, bo w pewnych przypadkach mogą skrócić kod (upraszczając go) bez utrudnienia zrozumienia globalnego przepływu danych (lokalna mutowalność).
Mowa była o sytuacji kontynuowania projektu i zmiany paradygmatu.
Nic tak nie działa twórczo na niejeden projekt niż zjechanie wielu jego aspektów z przedsatwieniem rzeczowej argumentacji.
Rzeczowa argumentacja w wykonaniu naszego forumowego schizofrenika wygląda tak: "patrzcie ile linków wkleiłem! patrzcie ile ludzi pisze, że OOP jest be!"
Pan profesor psychiatrii nie dość że wnosi do niej dodatkowo podjazdy "ad personam", które sam zaczął, to jeszcze stawia nieprawidłowe diagnozy i leci w zaparte, że ma rację. Radziłbym panie profesorze dokładnie przeanalizować, która z postaw ma więcej znamion przypadku klinicznego.
Czekam na rzeczowe argumenty, bez podrzucania linków.
Jakoś nie widzę tych argumentów na ssanie OOP, za to sporo odjeżdżania od tematu w kierunku medycyny. Mimo to, śledzę wątek z uśmiechem :)
Jakoś nie widzę tych argumentów na ssanie OOP,
@yarel - I nie zobaczysz.
Bo to jest dyskusja w stylu "BMW czy Mercedes" albo o wyższości świąt Bożego Narodzenia nad Wielkanocą.
OOP ma swoje plusy i minusy. Ale jak już (zresztą nie tylko ja) pisałem wcześniej - czy OOP ma sens zależy od danego projektu. Oczywiście - można to wcisnąć wszędzie, ale będzie to bez sensu. Tak samo jak można projekt aż proszący się o obiektowość zrobić bez niej. Tylko to trochę się mija z celem.
Poza umiejętnością kodowania, ważną rzeczą w pracy programisty jest (głównie opiera się to o zdobyte wcześniej doświadczenie) umiejętność oceny zadania oraz doboru odpowiednich narzędzi.
Właśnie, wątek się rozjeżdża, dowodów nie widać, ale to chyba nasz narodowy charakter:). Bo może wszystko zależy od tego co się robi? Jak, na przykład, modelujemy jakiś fizyczny obiekt, czy GUI, to OOP wydaje się naturalne i nieodzowne, natomiast przetwarzając statystycznie tekst, czy jakieś liczby (a może i Word2vec?) to design obiektowy wydaje sie nie mieć sensu. Ale nawet i tutaj się możnaby spróbować; na przykład tworząc sieć neuronową robię sobie obiekt NeuralNetwork z konstruktorem, metodami i potem w programie klienta można sobie stworzyć element klasy i eksperymentować.
Rozszerzalny i modularny kod można napisać w każdym paradygmacie. I w każdym można napisać jego przeciwieństwo. Ale mało który paradygmat przyczynił się do mnożenia poziomów abstrakcji w kodzie tak bardzo jak OOP.
Wibowit napisał(a):
Czekam na rzeczowe argumenty, bez podrzucania linków.
Ale dlaczego ktoś ma podrzucać dowody w tym wątku? Wątek jest o dyskusji na stronie w linku. Nie widzę absolutnie żadnego odniesienia się do tej dyskusji w postach, za to dużo płączu, że ktoś śmie się nie zgadzać (reakcje w stylu stos.push(heretyk)), że paradygmat funkcyjny lub proceduralny może dawać co najmniej równie dobry, jeśli nie lepszy kod niż czysty OOP. Czy to celowe udawanie ślepoty i niepamiętanie o co chodzi w wątku?
Ale dlaczego ktoś ma podrzucać dowody w tym wątku? Wątek jest o dyskusji na stronie w linku.
Jakbym chciał polemizować z jakąś wypowiedzią z innego forum to bym dyskutował z autorem tej wypowiedzi na tym innym forum. Ty podrzucasz linki, ale przy polemice stwierdzasz, że sam się nie zgadzasz w 100% z artykułem. Po co mam czytać i polemizować z tobą o czymś z czym się nie zgadzasz, ale tego od razu nie napiszesz? Czysta strata czasu.
Nie widzę absolutnie żadnego odniesienia się do tej dyskusji w postach, za to dużo płączu, że ktoś śmie się nie zgadzać (reakcje w stylu stos.push(heretyk)), że paradygmat funkcyjny lub proceduralny może dawać co najmniej równie dobry, jeśli nie lepszy kod niż czysty OOP. Czy to celowe udawanie ślepoty i niepamiętanie o co chodzi w wątku?
Ja widzę, że wątek ma tytuł "OOP ssie" i zero twoich głębszych przemyśleń (są tylko majaczenia typu "OOP ssie"), a ty znowu masz przejawy schizofrenii, bo w głowie pojawił ci się kolejny temat.
Jak czytam osoby twierdzace OOP jest najlepsze/OOP jest do d**y to z doswiadczenia wiem ze rozmowcy brakuje doswiadczenia - jest w tym niebezpiecznym okresie kiedy wydaje mu sie ze juz duzo wie. Co do rozmow ze np FP jest lepsiejsze niz OO tekst autorytetu
tamtamtu napisał(a):
Jak czytam osoby twierdzace OOP jest najlepsze/OOP jest do d**y to z doswiadczenia wiem ze rozmowcy brakuje doswiadczenia - jest w tym niebezpiecznym okresie kiedy wydaje mu sie ze juz duzo wie. Co do rozmow ze np FP jest lepsiejsze niz OO tekst autorytetu
Ten artykuł jest strasznie mętny, btw - aktualnie ulubiony język R.C. Martina to Clojure: http://telegra.ph/Why-Clojure-is-better-than-C-PythonRuby-and-java-and-why-should-you-care-12-20
Zabawne ;)
lion137 napisał(a):
Jak, na przykład, modelujemy jakiś fizyczny obiekt, czy GUI, to OOP wydaje się naturalne i nieodzowne
Nie rozpędzałbym się z tym nieodzownym - FRP i temu podobne techniki są coraz popularniejsze.
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 GrahamTrzeź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?