Ist das objektorientierte Programmierparadigma veraltet, da es antimodular und antiparallel ist? [geschlossen]

Ich habe den kontroversen Artikel Teaching FP für Studienanfänger von Robert Harper, Professor für CMU, gelesen . Er behauptete, dass die CMU im Einführungskurs kein objektorientiertes Programmieren mehr lehren würde, da es "für einen modernen CS-Lehrplan ungeeignet" sei.

Und er behauptete, dass:

Objektorientiertes Programmieren entfällt vollständig aus dem Einführungscurriculum, da es von Natur aus sowohl antimodular als auch antiparallel ist.

Warum sollte man OOP als antimodular und antiparallel betrachten?

Bitte beachten Sie, dass Harpers Anforderungen für den Unterricht eines CS-Einführungslehrplans sich stark von den Anforderungen eines realen Projekts unterscheiden . Seine Aufgabe ist es, Neulingen grundlegende Konzepte (zB Modularität, Parallelität, Induktion) beizubringen. Daher ist es sehr wichtig, dass die gewählte Sprache (und das gewählte Paradigma) diese Konzepte mit möglichst wenig Zeremonie (syntaktisch und konzeptuell) zum Ausdruck bringen kann. Vertrautheit, Werkzeugunterstützung, verfügbare Bibliotheken, Ausführungsleistung usw. spielen in diesem Zusammenhang keine Rolle. Denken Sie also bitte daran, wenn Sie Folgendes berücksichtigen ...

Die Ansicht , dass OO ist anti-modular ergibt sich aus der großen Anzahl von Abhängigkeiten zu anderen Klassen auch Objekte von gut gestaltete Klassen mit am Ende neigen. Dass dies ein Problem ist - auch in den Augen der Befürworter von OO - wird deutlich, wenn man sich die Verbreitung von Frameworks , Artikeln, Büchern und Blogposts für die Abhängigkeitsinjektion in den letzten Jahren ansieht (auch der Anstieg von Mocks und Stubs ist interessant).

Ein weiterer Hinweis ist die Bedeutung von Entwurfsmustern und die Komplexität ihrer Implementierung - im Vergleich zu einigen anderen Programmierparadigmen - z. B. Fabriken, Builder, Adapter, Brücke, Dekorateur, Fassade, Befehl, Iterator, Mediator, Beobachter, Strategie und Vorlagenmethode und möglicherweise Die Zusammenstellungen haben alle in gewisser Weise mit der Verbesserung der Modularität von OO-Code zu tun.

Vererbung ist auch problematisch (z. B. Fragile Base Class Problem ) und (Subtyp-) Polymorphismus verführt dazu, die Implementierung eines Algorithmus zwischen mehreren Klassen zu beschleunigen, wobei Änderungen die gesamte Vererbungskette durchdringen können (auf und ab!).

Die Anklage, antiparallel zu sein, hängt mit der Betonung des Zustands im Vergleich zur Berechnung zusammen (auch bekannt als Mutabilität vs. Unveränderlichkeit). Ersteres macht es komplizierter, Abhängigkeiten von Teilberechnungen auszudrücken (was Harpers Annahme von Parallelität ist!), Da Sie normalerweise nicht aus dem Ort schließen können, an dem der Zustand verwaltet wird (auch bekannt als die Datei, in der die Instanzvariable deklariert ist), welche externen Akteure wird es zu welchem ​​Zeitpunkt ändern.

Die Betonung auf Unveränderlichkeit und Berechnung erleichtert das Ausdrücken von Abhängigkeiten von Teilberechnungen erheblich, da es keine Zustandsverwaltung gibt, sondern nur Funktionen / Berechnungen, die an der Stelle kombiniert werden, an der Sie die Abhängigkeiten von Teilberechnungen ausdrücken möchten.

Dies ist wahrscheinlich eine kühne Behauptung, aber ich vermute irgendwie, dass Robert Harper nie wirklich Software in seinem Leben geschrieben hat. Er scheint sich nur mit ML und statischen Typsystemen zu befassen. So groß der Beitrag auch sein mag, ich sehe nicht, wie relevant seine Behauptungen über OOP sind.

Dieser Artikel ist nicht umstritten. Kontroverse beinhaltet Prüfung, Argumentation und Diskussion. Was Sie hier haben, ist ein ignoranter Akademiker, der zwei ziemlich grundlegende Anschuldigungen in nur einer einzigen Aussage formuliert, ohne sich die Mühe zu machen, irgendwelche Argumente vorzutragen.

1. Die Behauptung, OOP sei antimodular, ist einfach Unsinn. Ich weiß nicht einmal, wie ich darauf reagieren soll, es wurden nicht nur keine Argumente geliefert, sondern OOP by Design ist ein Ansatz, um Modularität mit sehr geringer Kopplung zwischen einzelnen Modulen durch Kapselung und Abstraktion herzustellen.

2. Die Behauptung, OOP sei antiparallel, zeigt nur einen Mangel an Verständnis. OOP sperrt keine Entscheidungen über die Parallelität. OOP schreibt nur vor, sie auszublenden: Wenn es richtig aufgebaut ist, können Sie nicht sagen, ob die Implementierung eines Objekts parallel ist oder nicht.
   Somit sind letztendlich OOP und parallele Programmierung orthogonal. Das Actor-Modell ist ein elegantes Modell für die Parallelität, das sich direkt in einem Objektsystem widerspiegeln kann (aber nicht muss) und eine beeindruckende Kombination aus beiden ergibt.

Das Problem mit OOP ist, dass nur wenige Leute es tatsächlich so verstehen, wie Alan Kay es definiert hat.

1. OOP ist ein Ansatz. In einigen Sprachen wird es mithilfe von Mustern implementiert, in anderen können Sie direkt integrierte Sprachidiome verwenden (z. B. Ruby, Objective-C, Smalltalk, Io ).
2. Entgegen der allgemeinen Meinung geht es bei OOP nicht um Klassen. Es geht um Objekte, und Objekte handeln von der Weitergabe von Nachrichten oder einer gleichermaßen undichten Art der Verkapselung und Abstraktion.

Aus diesem Grund ist Java zu OOP, was spitze Stöcke zum Seekampf sind. Dies gilt auch für viele andere so genannte "OOP-Sprachen", aber das Problem bei Java ist, dass es an den Universitäten allgemein anerkannt ist, dass Java zum Unterrichten von OOP verwendet werden sollte.

Ich stimme allen zu, die der Meinung sind, dass Einführungen in OOP mit Java aus den CS-Lehrplänen gestrichen werden sollten. Ich denke auch, dass Menschen, denen das grundlegende Verständnis von OOP eindeutig fehlt, es nicht unterrichten sollten. Es ist also wahrscheinlich besser, wenn Bob sich für seine Kurse an ML hält und einfach lehrt, was er genau versteht.
Momentan ist OOP eher eine modische Etikette, an der sich die Leute gerne festhalten. Das schadet der OOP und sagte den Leuten. OOP ist nicht veraltet. Das goldene Zeitalter von OOP steht noch bevor, wenn die Leute endlich verstehen, worum es geht, worum es nicht geht (z. B. jedes mögliche Problem durch class500-maliges Verwenden des Schlüsselworts lösen ).

Sie bekommen Eiferer von jedem Streifen.

Objektorientierte Programmierung ist keine Wunderwaffe. Das war es nie. Was es ist, ist ein Opfer von Hype. Es ist unvermeidlich, dass die Leute den Hype satt haben und sich eine Gegenreaktion entwickelt (ungeachtet des tatsächlichen Nutzens des Paradigmas).

In zwanzig Jahren werden wir zweifellos noch eine Gegenreaktion gegen die funktionale Programmierung haben.

Ich kann diese Frage nicht vollständig beantworten, weil man die vagen Gedanken seines Autors nur zweitens erraten kann. Ich vermute sehr, dass dieser Artikel den Autor in Verlegenheit bringen wird. Es gibt nichts an OOP, was darauf hindeuten würde, dass es weder modular noch parallel ist:

Modularität : Ein wesentlicher Aspekt von OOP ist, dass es in der Tat modular ist (aber Modularität bedeutet verschiedene Dinge in verschiedenen Kontexten). Unabhängig davon, ob der Autor von Verallgemeinerung oder statischer Programmierung spricht, ist er falsch.

Parallelisierung : In Bezug auf die parallele Programmierung haben die meisten Frameworks Interrupts, Threads und jetzt eine ordnungsgemäße Parallelisierung unterstützt, z. B. das, was wir in .Net Framework 4.0 und den darauf aufbauenden OOP-Sprachen sehen.

Ich vermute, dass der Autor ein Opfer der Mode geworden ist, da es einen Irrtum gibt, dass funktionale Programmierung und OOP sich gegenseitig ausschließen. Es gibt Funktionsstile in OOP-Sprachen, die gut dokumentiert sind, zB hat Oliver Sturm in diesem Bereich veröffentlicht.

Der Autor behauptet, dass OOP für Erstsemester-Programmierer zu schwer zu verstehen ist, was wahr sein könnte - obwohl ich es bezweifle, angesichts der Zugangsvoraussetzungen für CMU! Die antimodularen und antiparallelen Aussagen mögen im Vergleich zu rein funktionalen Sprachen in einem engen Kontext zutreffen, sind jedoch kaum eine Verurteilung des gesamten Paradigmas (was für diejenigen, die es zu gebrauchen wissen, gut zu funktionieren scheint).

Der vorgeschlagene Lehrplan würde funktionale Programmierung in einer Klasse, imperative (prozedurale) Programmierung in einer anderen Klasse und Datenstrukturen in einer anderen Klasse lehren. Sobald ein Neuling diese 3 Dinge gemeistert hat, sollte er / sie bereit sein, OOP zu lernen.

Persönlich finde ich das übertrieben, aber Akademiker probieren gerne neue und extreme Dinge aus. Als Gegengewicht hat das MIT alle wichtigen Programmierparadigmen in einer Erstsemester-Klasse gelehrt (und könnte dies auch noch tun).

Seltsamerweise haben beide Schulen einige wirklich gute Programmierer hervorgebracht. Stelle dir das vor.