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

23

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?

xiao
quelle
14
Buhwaaaah ?! OO macht Modularität und Parallelität einfacher als prozedural und schließt sich für FP nicht gegenseitig aus. Färbe mich verwirrt.
Matt Ellen
4
Sie haben ihr Curriculum umgestaltet, damit er das neue Programm verkaufen muss und mutige Behauptungen aufstellt, die mit absolut keinen Daten unterlegt sind. Es gibt keine Hinweise darauf, dass komplexe Funktionsprogramme paralleler oder modularer sind als ihre OOP-Gegenstücke.
Davidk01
4
@Matt Ellen: OOP schließt sich mit FP entschieden aus. FP basiert auf mehreren Schlüsselkonzepten, von denen eines das Fehlen eines veränderlichen Zustands ist. OOP basiert auf dem Vorhandensein eines veränderlichen Zustands, dessen Zugriff gesteuert wird, indem er in "Objekte" eingeschlossen wird. Der veränderbare Zustand und der unveränderliche Zustand schließen sich per Definition gegenseitig aus. Ja, es ist wahr, dass Sie in einem funktionalen Stil mit vielen OOP-Sprachen programmieren können, aber dies ist nicht dasselbe wie die Verwendung einer FP-Sprache. Und ja, es stimmt, dass nicht alle FP-Sprachen rein sind. Dies bedeutet jedoch nicht, dass FP mit OOP kompatibel ist.
NUR MEINE STELLUNGNAHME
2
@JUST: Ich habe eine andere Vorstellung von gegenseitiger Exklusivität als Sie. Ich sehe reines und unreines FP als Teilmengen von FP, und daher schließt sich OOP von FP nicht gegenseitig aus, wenn Sie annehmen, dass die Wandlungsfähigkeit für OOP wesentlich ist. Ich stimme auch nicht zu, dass die Wandlungsfähigkeit für OOP wesentlich ist. Sie könnten ein OO-System mit Message-Passing erreichen und es niemals verändern.
Matt Ellen

Antworten:

30

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.

Alexander Battisti
quelle
10
Die Parallelitätsansprüche aus dem Funktionslager sind oft übertrieben. Compiler für funktionale Sprachen arbeiten mit einer saubereren Grundlagentheorie, sodass die Implementierer mehr Möglichkeiten haben, den Code zu reorganisieren, bevor er in Maschinencode umgewandelt wird. Dies bedeutet jedoch nicht, dass OO-Programmierern die richtigen Abstraktionen für Parallelität gegeben werden, die sie nicht können sauberen parallelen Code zu schreiben. Bisher haben prozedurale Programmierer nur Sperren und Threads erhalten, und ich denke, sie haben sich mit diesen Tools ziemlich gut geschlagen.
Davidk01
2
Während ich im Allgemeinen mit allem, was Sie hier sagen, einverstanden bin, möchte ich darauf hinweisen, dass Designmuster in allen Programmierparadigmen vorkommen. Bei der funktionalen Programmierung möchte ich auf Dinge wie Monaden und Map / Reduce hinweisen.
Anm
@ davidk01 Take Go zum Beispiel. Es unterstützt die objektorientierte Programmierung und verfügt über hervorragende Parallelitätsprimitive. Noch wichtiger ist, dass es für die gleichzeitige Programmierung wirklich gut läuft, ohne rein funktional zu sein.
weberc2
19

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

back2dos
quelle
1
+1 für das Weiterleiten von Nachrichten und +1 für 'mit Java'. Wenn sie Java entfernen würden, würden sie es leider einfach durch C # ersetzen und sein Vermächtnis fortsetzen.
gbjbaanb
@ back2dos +1 für die Kritiker, -1 für Java. Sicher, Smalltalk ist "viel mehr OO" als Java, aber wer benutzt es? Objective-C ist für Anfänger genauso schwierig wie C.
Maaartinus
@maaartinus: Sie werden feststellen, dass Squeak im pädagogischen und akademischen Bereich weit verbreitet ist, wenn dies Ihre Frage beantwortet. Auch für Java: Sie mögen es vielleicht, ich mag es nicht. Ähnlich wie bei Kaffee ist es eine Frage der persönlichen Präferenz, und es macht keinen Sinn, darüber zu diskutieren. Java, das für eine Einführung in OOP ungeeignet ist, ist meiner Meinung nach eine unbestreitbare Implikation von Javas Wesen und dem Konzept von OOP, und genau das habe ich gesagt. Die Popularität von Java lässt das nicht verschwinden. Für C empfehle ich Ihnen, joelonsoftware.com/articles/ThePerilsofJavaSchools.html zu lesen .
back2dos
@ back2dos Squeak kann in diesen Bereichen verwendet werden, aber an der Universität habe ich ML gelernt. Beide sind in der Branche gleichermaßen unbrauchbar und aufgrund ihrer Konzepte lohnenswert. Der spitze Artikel ist der schlechteste Artikel von Joel, den ich je gelesen habe, er ist zu lang und auf den ersten Blick scheint die Botschaft die Bedeutung des Umgangs mit Segfaults zu sein. : D Ich würde Java immer noch empfehlen, um OOP zu unterrichten.
Maaartinus
@maaartinus: Was du an der Universität gelernt hast, hat wenig mit der Frage zu tun , was gelehrt werden soll . Sie gaben immer noch keine Gründe an, warum man Java zum Unterrichten von OOP verwenden sollte, während ich einen meiner Meinung nach soliden Grund dafür anführte, dies nicht zu tun. Auch Sie haben offensichtlich das Wesentliche des Artikels nicht verstanden: Menschen, die mit ähnlich schwierigen Problemen wie C nicht fertig werden können, sollten CS überhaupt nicht studieren. Ich denke, CS sollte nicht darauf beschränkt sein, was jedes Kind, das Computer mag, verstehen kann. Wenn wir uns nicht darauf einigen können, ist eine weitere Diskussion eine Verschwendung Ihrer und meiner Zeit.
back2dos
12

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.

Frank Shearar
quelle
1
Gibt es schon!
quant_dev
1
++ "Von jedem Streifen bekommt man Fanatiker." Ich war ein Akademiker und meine Erfahrung war dies . Akademiker lieben es, provokative Meinungen zu äußern und vielleicht ihre Schüler zu beeindrucken.
Mike Dunlavey
5

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.

CarneyCode
quelle
4

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.

Steven A. Lowe
quelle