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

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?

Proszę wziąć pod uwagę, że potrzeby Harpera dotyczące nauczania wstępnej klasy CS są bardzo 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ń.

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

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.

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.

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.