Czy paradygmat programowania zorientowanego obiektowo jest przestarzały, ponieważ jest on modułowy i nierównoległy? [Zamknięte]

23

Przeczytałem kontrowersyjny artykuł Nauczanie FP studentom pierwszego roku napisany przez Roberta Harpera, który jest profesorem CMU. Twierdził, że CMU nie będzie już uczyć programowania obiektowego we wstępnym kursie, ponieważ „nie nadaje się do nowoczesnego programu CS”.

I twierdził, że:

Programowanie obiektowe jest całkowicie wyeliminowane ze wstępnego programu nauczania, ponieważ z natury jest zarówno modułowe, jak i antyrównoległe.

Dlaczego warto uważać OOP za antymodularne i antyrównoległe?

xiao
źródło
14
Buhwaaaah ?! OO sprawia, że ​​modułowość i równoległość są łatwiejsze niż proceduralne i nie wykluczają się wzajemnie dla PR. Kolor mnie zmieszany.
Matt Ellen,
4
Przeprojektowali swój program nauczania, więc musi sprzedać nowy program i robi śmiałe roszczenia poparte absolutnie bez danych. Nie ma dowodów na to, że złożone programy funkcjonalne są bardziej równoległe lub modułowe niż ich odpowiedniki OOP.
davidk01 24.04.11
4
@Matt Ellen: OOP zdecydowanie wyklucza się z FP. FP opiera się na kilku kluczowych pojęciach, z których jedną jest brak stanu zmiennego. OOP opiera się na istnieniu stanu zmiennego, którego dostęp jest kontrolowany przez zawijanie go w „obiektach”. Stan zmienny i stan niezmienny wzajemnie się wykluczają z definicji. Tak, to prawda, że ​​możesz programować w funkcjonalnym stylu z wieloma językami OOP, ale to nie to samo, co przy użyciu języka FP. I tak, to prawda, że ​​nie wszystkie języki FP są czyste. Nie oznacza to jednak, że FP jest kompatybilny z OOP.
PO PROSTU MOJA poprawna OPINIA,
2
@ JUST: Mam inny pomysł na wzajemną wyłączność. Widzę czyste i nieczyste FP jako podzbiory FP, więc OOP nie wyklucza się wzajemnie z FP, jeśli założymy, że zmienność jest niezbędna dla OOP. Również nie zgadzam się, że zmienność jest niezbędna dla OOP. Możesz osiągnąć i całkowicie OO system za pomocą przekazywania wiadomości i nigdy niczego nie mutować.
Matt Ellen,

Odpowiedzi:

30

Proszę wziąć pod uwagę, że potrzeby Harpera dotyczące nauczania wstępnej klasy CSbardzo różne od potrzeb projektu z prawdziwego życia . Jego zadaniem jest nauczanie studentów podstawowych pojęć (np. Modułowości, równoległości, indukcji). Jako takie jest bardzo ważne, aby wybrany język (i paradygmat) mógł wyrażać te pojęcia z możliwie najmniejszą ceremonią (składniową i konceptualną). Znajomość, obsługa narzędzi, dostępne biblioteki, wydajność wykonywania itp. Są w tym kontekście całkowicie nieistotne. Pamiętaj o tym, rozważając następujące kwestie ...

Pogląd, że OO jest antymodułowy, wynika z dużej liczby zależności od innych klas, a nawet obiektów dobrze zaprojektowanych klas. To, że jest to problem - nawet w oczach zwolenników OO - staje się jasne, gdy spojrzysz na rozprzestrzenianie się szkieletów , artykułów, książek i postów na blogu w ciągu ostatnich lat (ciekawe jest również pojawienie się próbnych i pośredniczących artykułów).

Inną wskazówką jest znaczenie Wzorów projektowych i złożoność ich wdrażania - w porównaniu z innymi paradygmatami programowania - np. Fabryki, Konstruktor, Adapter, Most, Dekorator, Fasada, Dowodzenie, Iterator, Mediator, Obserwator, Strategia i Metoda szablonów i może Composite są w jakiś sposób związane z poprawą modułowości kodu OO.

Dziedziczenie jest również problematyczne (np. Problem delikatnej klasy bazowej ) i polimorfizm (podtypu) uwodzi jednego do rozlania implementacji algorytmu między wieloma klasami, w którym zmiany mogą falować w całym łańcuchu dziedziczenia (w górę iw dół!).

Zarzut bycia nierównoległym wiąże się z naciskiem na stan w porównaniu do obliczeń (czyli np. Zmienność vs. niezmienność). Pierwszy z nich bardziej angażuje się w wyrażanie zależności podliczeń (co Harper przyjmuje na paralelizm!), Ponieważ zwykle nie można wywnioskować z lokalizacji, w której zarządzany jest stan (czyli pliku, w którym deklarowana jest zmienna instancji), które podmioty zewnętrzne zmieni to w jakim momencie.

Nacisk na niezmienność i obliczenia sprawia, że ​​wyrażanie zależności podliczeń jest znacznie łatwiejsze, ponieważ nie ma zarządzania stanem, tylko funkcje / obliczenia, które są łączone w miejscu, w którym chcesz wyrazić zależności podliczeń.

Alexander Battisti
źródło
10
Twierdzenia o równoległości z obozu funkcjonalnego są często przesadzone. Kompilatory dla języków funkcjonalnych działają z czystszą podstawową teorią, więc implementatorzy mają więcej sposobów reorganizacji kodu, zanim zostanie on przekształcony w kod maszynowy, ale to nie znaczy, że jeśli dasz programistom OO odpowiednie abstrakcje dla równoległości, nie będą w stanie pisać czysty równoległy kod. Do tej pory programiści proceduralni otrzymywali tylko blokady i wątki i całkiem nieźle radzili sobie z tymi narzędziami.
davidk01 24.04.11
2
Chociaż ogólnie zgadzam się ze wszystkim, co tu mówisz, chciałbym zauważyć, że wzorce projektowe występują we wszystkich paradygmatach programowania. W przypadku programowania funkcjonalnego wskazałbym takie rzeczy, jak monady i mapowanie / redukowanie.
Anm
@ davidk01 Take Go na przykład. Obsługuje programowanie obiektowe i ma świetne operacje podstawowe. Co ważniejsze, naprawdę startuje do programowania współbieżnego, ale nie jest czysto funkcjonalny.
weberc2,
19

Prawdopodobnie jest to śmiałe twierdzenie, ale jakoś podejrzewam, że ten Robert Harper nigdy tak naprawdę nie napisał prawdziwego oprogramowania w swoim życiu. Wydaje się, że zajmuje się wyłącznie ML i systemami typu statycznego. Jakkolwiek może to być duży wkład, nie rozumiem, jak ważne są jego twierdzenia na temat OOP.

Ten artykuł nie jest kontrowersyjny. Kontrowersje obejmują badanie, spór i dyskusję. To, co tu masz, to jakiś ignorant akademicki, który wysuwa dwa dość fundamentalne zarzuty w jednym oświadczeniu, nie zawracając sobie głowy przedstawieniem jakichkolwiek argumentów.

  1. Twierdzenie, że OOP jest antymodułowy, jest po prostu bzdurą. Nie wiem nawet jak na to odpowiedzieć, nie tylko nie podano żadnych argumentów, ale również OOP z założenia jest podejściem do ustanowienia modułowości z bardzo niskim sprzężeniem między poszczególnymi modułami poprzez enkapsulację i abstrakcję.

  2. Twierdzenie, że OOP jest antyrównoległe, po prostu pokazuje brak zrozumienia. OOP nie blokuje żadnych decyzji dotyczących współbieżności. OOP nakazuje jedynie ich ukrycie: Jeśli jest poprawnie zbudowany, nie można powiedzieć, czy implementacja obiektu jest równoległa, czy nie.
    Zatem ostatecznie OOP i programowanie równoległe są ortogonalne. Model aktora jest eleganckim modelem współbieżności, który można bezpośrednio odzwierciedlić w systemie obiektowym (ale nie musi tak być), uzyskując potężną kombinację obu.

Problem z OOP polega na tym, że niewiele osób to rozumie w takim znaczeniu, w jakim zdefiniował to Alan Kay .

  1. OOP to podejście. W niektórych językach jest implementowany za pomocą wzorców, w innych można bezpośrednio używać wbudowanych idiomów językowych (np. Ruby, Objective-C, Smalltalk, Io ).
  2. Wbrew powszechnemu przekonaniu, OOP nie dotyczy klas. Chodzi o przedmioty, a przedmioty dotyczą przekazywania wiadomości lub równie nieszczelnego sposobu enkapsulacji i abstrakcji.

Właśnie dlatego Java ma na celu OOP, co wskazuje na kije do walki na morzu. Dotyczy to również wielu innych tak zwanych „języków OOP”, ale w Jawie chodzi o to, że na uniwersytetach panuje powszechne przekonanie, że Java powinna być używana do nauczania OOP.

Zgadzam się ze wszystkimi, którzy uważają, że wprowadzenie do OOP z Javą powinno zostać usunięte z programów CS. Uważam również, że ludzie, którzy wyraźnie nie rozumieją zasad OOP, nie powinni tego uczyć. Prawdopodobnie więc lepiej, jeśli Bob pozostanie na kursach ML i po prostu uczy tego, co rozumie.
Obecnie OOP to bardziej modna etykieta, którą ludzie lubią trzymać się wszystkiego. To szkodzi OOP i powiedziało ludziom. OOP nie jest przestarzały. Złoty wiek OOP jest jeszcze przed nami, kiedy ludzie w końcu zrozumieć, co to jest, co to jest nie na temat (np rozwiązywania wszelkich możliwych problem za pomocą słowa kluczowego class500 razy).

back2dos
źródło
1
+1 za przekazywanie wiadomości i +1 za „z Javą”. Niestety, gdyby usunęli Javę, po prostu zastąpiliby ją C # i kontynuowali jej dziedzictwo.
gbjbaanb
@ back2dos +1 dla krytyków, -1 dla Java. Z pewnością Smalltalk to „znacznie więcej OO” niż Java, ale kto z niego korzysta? Cel C jest trudny dla początkujących, podobnie jak C.
maaartinus
@maaartinus: Przekonasz się, że Squeak jest szeroko stosowany w dziedzinie edukacji i nauki, jeśli to odpowiada na twoje pytanie. Także jeśli chodzi o Javę: może ci się spodobać, a może nie. Podobnie jak kawa, jest to kwestia osobistych preferencji i nie ma sensu o tym dyskutować. Jednak Java nie nadaje się do wprowadzenia do OOP, jest IMHO niezaprzeczalną implikacją natury Javy i koncepcji OOP i to jest dokładnie to, co powiedziałem. Popularność Javy nie sprawi, że zniknie. Jeśli chodzi o C, proponuję przeczytać joelonsoftware.com/articles/ThePerilsofJavaSchools.html .
back2dos 24.04.11
@ back2dos Squeak może być używany w tych obszarach, ale na uniwersytecie nauczyłem się ML. Oba są równie bezużyteczne w branży i oba są warte nauki, ze względu na ich koncepcje. Wskazany artykuł jest najgorszym artykułem Joela, jaki kiedykolwiek czytałem, jest zbyt długi i na pierwszy rzut oka wydaje się, że znaczenie ma radzenie sobie z segfaultami. : D Naprawdę nadal sugerowałbym Javę do nauczania OOP.
maaartinus
@maaartinus: To, czego nauczyłeś się na uniwersytecie, nie ma większego znaczenia w kwestii, czego należy uczyć . Nadal nie podałeś powodów, dla których warto używać Javy do nauczania OOP, a ja podałem, co uważam za dość solidny powód, aby tego nie robić. Oczywiście nie zrozumiałeś też istoty tego artykułu: ludzie, którzy nie potrafią poradzić sobie z problemami podobnie mocno jak C, nie powinni przede wszystkim studiować CS. Myślę, że CS nie powinno być głupie do tego, co każde dziecko, które lubi komputery, może zrozumieć. Jeśli nie możemy się z tym zgodzić, dalsza dyskusja jest stratą twojego czasu i mojego.
back2dos 24.04.11
12

Dostajesz fanatyków każdego paska.

Programowanie obiektowe nie jest srebrną kulą. Nigdy tak nie było. Co to jest, jest ofiarą szumu. Nieuchronnie ludzie mają dość szumu i zaczyna się rozwijać luz (niezależnie od faktycznej użyteczności paradygmatu).

Za dwadzieścia lat bez wątpienia będziemy mieli jeszcze trochę sprzeciwu wobec programowania funkcjonalnego.

Frank Shearar
źródło
1
Już jest!
quant_dev 24.04.11
1
++ „Dostajesz fanatyków każdego paska.” Byłem akademikiem i moje doświadczenie było takie . Naukowcy uwielbiają wyrażać prowokujące opinie, robiąc wrażenie na swoich studentach.
Mike Dunlavey
5

Nie potrafię w pełni odpowiedzieć na to pytanie, ponieważ można jedynie odgadnąć niejasne myśli autora. Podejrzewam, że ten artykuł może nieco zawstydzić jego autora. W OOP nie ma nic, co sugerowałoby, że nie jest ono ani modułowe, ani równoległe:

Modułowość : Głównym aspektem OOP jest to, że jest rzeczywiście modułowy (ale modułowość oznacza różne rzeczy w różnych kontekstach). Bez względu na to, czy autor mówi o uogólnieniu czy programowaniu statycznym, jest niepoprawny.

Równoległość : Podobnie jak w przypadku programowania równoległego, większość frameworków obsługuje interupty, a następnie wątki, a teraz właściwą równoległość, taką jak to, co widzimy w .Net Framework 4.0 i języki OOP, które się do niego przyczepiają.

Podejrzewam, że autor stał się ofiarą mody, ponieważ istnieje błędne przekonanie, że programowanie funkcjonalne i OOP wzajemnie się wykluczają. Istnieją języki funkcjonalne w językach OOP, które są dobrze udokumentowane, np. Oliver Sturm opublikował w tym obszarze.

CarneyCode
źródło
4

Autor utrzymuje, że programista OOP jest zbyt trudny do zrozumienia dla początkujących programistów, co może być prawdą - choć wątpię, biorąc pod uwagę wymagania wstępne dla CMU! Stwierdzenia antymodularne i antyrównoległe mogą być prawdziwe w wąskim kontekście w porównaniu z językami czysto funkcjonalnymi, ale nie są prawie potępieniem całego paradygmatu (który wydaje się działać dobrze dla tych, którzy wiedzą, jak go używać).

Proponowany program nauczania uczy programowania funkcjonalnego w jednej klasie, programowania imperatywnego (proceduralnego) w innej klasie i struktur danych w innej klasie. Gdy student pierwszego roku opanuje te 3 rzeczy, powinien być gotowy do nauki OOP.

Osobiście uważam, że to przesada, ale naukowcy lubią próbować nowych i ekstremalnych rzeczy. Jako przeciwwagę, MIT zwykł (i nadal może) uczyć wszystkich głównych paradygmatów programowania w jednej klasie studentów pierwszego roku.

Co dziwne, obie szkoły stworzyły naprawdę dobrych programistów. Domyśl.

Steven A. Lowe
źródło