Kritik an OOP

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
Nocta
User
Beiträge: 290
Registriert: Freitag 22. Juni 2007, 14:13

Dass OOP nicht immer sinnvoll und notwendig ist, hab ich mittlerweile verstanden, aber was sagt ihr zu dieser Kritik auf Wikipedia?
http://de.wikipedia.org/wiki/Objektorie ... ung#Kritik
Richard Stallman schrieb 1995: „Hinzufügen von OOP zu Emacs ist ganz klar keine Verbesserung; ich verwendete OOP bei der Arbeit am Fenstersystem der Lisp-Maschine und ich stimme dem häufig gehörten ‚der überlegene Weg zu programmieren‘ nicht zu.“[2]
Eine Studie von Potok et al. [3] zeigte keine signifikanten Produktivitätsunterschiede zwischen OOP und Prozeduralen Ansätzen.
Alexander Stepanow schlug vor, OOP beschreibt eine mathematisch-begrenzte Betrachtungsweise und nannte sie „fast einen genauso großen Schwindel wie die künstliche Intelligenz (KI)“[4][5].
Edsger W. Dijkstra:
„… die Gesellschaft lechzt nach Schlangenöl. Natürlich hat das Schlangenöl die eindrucksvollsten Namen – sonst würde man es nicht verkaufen können – wie ‚Strukturierte Analyse und Design‘, ‚Software Engineering‘, ‚Maturity Models‘, ‚Management Information Systems‘, ‚Integrated Project Support Environments‘ ‚Object Orientation‘ und ‚Business Process Re-engineering‘ (die letzten drei auch bekannt als IPSE, OO and BPR).“ – EWD 1175: The strengths of the academic enterprise
Benutzen wir dann also nur OOP in Python, weil es sich gut anhört (Schlangenöl)?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Nocta hat geschrieben:Benutzen wir dann also nur OOP in Python, weil es sich gut anhört (Schlangenöl)?
Hallo Nocta!

Nein, aber die "reine" Lehre ist -- wie immer -- zu engstirnig gedacht.

Es kommt immer darauf an, wie der Programmierer oder das Team "tickt". Oft ist eine durchdachte "Mischung" viel einfacher zu programmieren, einleuchtender und wartungsfreundlicher.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Ronnie
User
Beiträge: 73
Registriert: Sonntag 21. März 2004, 17:44

Objektorientierung hat ihre Berechtigung, wenn sie Code übersichtlicher, wartbarer und wiederverwendbarer macht. Nicht immer ist sie die beste Lösung. Wenn man sich betrachtet welche Klimmzüge in stark typisierten objektorientierten Sprachen nötig sein können, läuft es einem kalt den Rücken runter. Wenn man Delegates sieht (ein Mechanismus um einen Callback zu realisieren), oder Interfaces (ein Mechanismus um Objekte verschiedener Klassen gemeinsam behandeln zu können), dann merkt man erst wie sehr einem die Skriptsprachen an dieser Stelle entgegenkommen. Letzten Endes ist Objektorientierung ein gutes Werkzeug, nur eben nicht immer für jede Problemstellung.
Achtung: User ist ein Python-Lehrling!
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Nocta hat geschrieben:Benutzen wir dann also nur OOP in Python, weil es sich gut anhört (Schlangenöl)?
Nein, würde ich auch nicht sagen. Da gibt es immer ein vernünftiges Maß in dem OOP sinnvoll ist und ab dem OOP erzwungen wirkt. Damit meine ich OOP-Features nutzen nur um sie mal genutzt zu haben, entsprechend dem OverUseOfPatterns-Antipattern. Der Code sollte so klar wie möglich sein (ohne notwendigerweise primitiv und ausdrucksschwach zu sein) und das Problem auf die möglichst simpelste Art und Weise lösen. Wenn man in einer Sprache arbeitet, bei der OOP der für dieses Problem gängige Lösungsansatz ist, dann ist das eine durchaus empfehlenswerte Heransgehensweise. Jedoch sollte man eben Useless Use of Classes vermeiden. Ebenfalls sollte man es nach Möglichkeit vermeiden sein eigenes Objektsystem zu bauen außer man hat gute Gründe dafür (GObject und Moose etwa), nur um das Problem mit OOP erschlagen zu können.

Das Produktivitätsargument ist etwas seltsam, den wie produktiv man prozedural oder objektorientiert ist hängt nicht nur von OOP ab, sondern zu einem großen Teil mit der eigenen Erfahrung und der API ab, mit der man arbeitet. Man kann auch mit OOP Komplexitätsmonster schaffen die der Verständlichkeit stark abträglich sind, und man kann mit prozeduralem Code wunderbar klare und verständliche Programme hinbekommen. Oder auch andersrum. OOP impliziert eben keine besseren Programme, ich vermute das meinte Dijkstra mit Snake-Oil.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Nocta
User
Beiträge: 290
Registriert: Freitag 22. Juni 2007, 14:13

Danke für eure Antworten.
Ich habe die Frage bewusst provozierend gestellt und habe ja jetzt auch ganz brauchbare Antworten erhalten :)

@Leonidas was meinst du mit "eigenem Objektsystem"? Ich kenne Moose oder GObject leider nicht und kann damit also nichts anfangen.

Bei dem Produktivitätsargument hast du vermutlich recht und man müsste genau wissen, wie und was die Studie da überprüft hat, bevor man das Argument benutzen kann.
BlackJack

Ich denke Dijkstra meint auch die Schlagwörter an sich. Es wurden in der OOP-Hurra-Phase Systeme als "OOP" bezeichnet, die damit nicht wirklich etwas zu tun hatten, wo das einfach nur ein Marketinglabel war, weil sich's so gut verkauft.

Ausserdem glaube ich, dass viele gute "prozedurale" Systeme teilweise OOP sind. Auch ohne das die Entwickler das so genannt haben, oder das es ihnen bewusst sein musste. Wenn man sich unter Unix zum Beispiel mal die Dateioperationen ansieht, hat man da eine Menge Funktionen auf Dateien, die als ein Argument einen "file deskriptor" entgegennehmen. Und "Dateien" sind in diesem Zusammenhang ziemlich plymorph -- das können Dateien auf Platte sein, Sockets, und vieles andere mehr. Wenn man sich jetzt mal denkt das "file deskriptor"-Argument würde `self` oder `this` heissen, sieht man Parallelen zu Objektorientierung. Da wo OOP oder Teile davon Sinn machen, wurde das also auch schon immer angewendet, auch wenn's nicht explizit so genannt wird.

Stepanow würde ich zustimmen wenn er mit der begrenzten Betrachtungsweise meint, dass man andere Ansätze von vorneherein ausschliesst. Das wird ja letztendlich in der Praxis nicht gemacht, denn auch bei Java sieht man Bibliotheken, die funktionale Programmierung mühsam mit Objekten, Generics, und dem massiven Problem mit "checked exceptions" versuchen nachzubauen. Ist eben halt nur recht umständlich im Gegensatz zu Sprachen die nicht so OOP bzw. klassenfixiert sind. Man kommt auch bei reinem OOP nicht ohne "Prozeduren" aus. In Java sind das statische Methoden die massenhaft in Klassen zusammengepfercht werden, deren Name mit dem Postfix "Util" enden.

Und echte, reine OOP Sprachen wie Io fühlen sich IMHO sogar ziemlich funktional an. Nur mit dem Unterschied, dass nicht alle Werte unveränderlich sind.

Stallmann beschreibt was IMHO auch für gute Python-Programme gilt: Klassen nur da benutzen, wo sie Sinn machen, und keine OOP nur um der OOP willen einsetzen.
Nocta
User
Beiträge: 290
Registriert: Freitag 22. Juni 2007, 14:13

@BlackJack: Wenn deine Vermutungen zutreffen, ist die Kritik im Wikipedia Artikel ziemlich nutzlos und irreführend. Die dort zitierten Aussagen bekommen mit deinen Erklärungen/Vermutungen natürlich eine ganz andere Bedeutung.
Das klingt da eher so wie "OOP hört sich gut an, ist aber Scheiße", was mich auch etwas verwundert hat, da es ja auch sehr viele sehr erfahrene Programmierer gibt, die öfter auf OOP zurückgreifen.
lunar

@Nocta: Nutzlos und irreführend? Was hast Du denn erwartet? Wikipedia möchte ein Lexikon sein, keine umfassende kritische Aufarbeitung. Stallman und Dijkstra sind nicht unbedeutend, und müssen ergo zitiert werden, um dem Thema im Überblick gerecht zu werden, aber nicht mehr. Wikipedia hat keine Meinung, die musst Du Dir schon selbst bilden … unabhängig davon aber ist eine Meinung, die nur auf Wikipedia aufbaut, eine ziemlich armselige Meinung.
Nocta
User
Beiträge: 290
Registriert: Freitag 22. Juni 2007, 14:13

Wikipedia möchte ein Lexikon sein, keine umfassende kritische Aufarbeitung.
Aber unter einem Kritik-Abschnitt könnte man doch auch eine Kritik erwarten, die wenigstens die Zitate im richtigen Kontext bringt, oder?
Denn sonst ist das alles andere als Kritik, als viel mehr Propaganda (etwas überspitzt ausgedrückt)
Das ist jedenfalls meine Meinung.
lunar

@Nocta: Und dieser „richtige Kontext“, was ist das Deiner Meinung nach?

Wikipedia will nun mal ein Lexikon sein, und nur eine Übersicht geben. Ob das immer oder überhaupt gelingt, sei dahin gestellt, aber in jedem Fall ist Wikipedia halt nicht alles. Ein bisschen mehr musst Du schon lesen, wenn Du Dir eine vernünftige Meinung bilden willst. Ein Anfang wäre beispielsweise, die Quellen der Zitate zu lesen, das ist der „richtigste“ Kontext, den Du finden wirst …

Und dann wäre da ja noch der "Wiki"-Part in Wikipedia …
Nocta
User
Beiträge: 290
Registriert: Freitag 22. Juni 2007, 14:13

lunar hat geschrieben:@Nocta: Und dieser „richtige Kontext“, was ist das Deiner Meinung nach?
Ein Kontext, in dem die ursprüngliche Aussage des Autors nicht verfälscht wiedergegeben wird.
Ich meine was bringt es denn, Zitate zu geben, die aber ohne entsprechenden Kontext bzw eine kurze Erklärung einen veränderten Sinn ergeben?

Wir können jetzt natürlich darüber diskutieren, ob es überhaupt möglich ist, eine Textaussage völlig objektiv wiederzugeben (vermutlich nicht), aber ich denke das ist in diesem Fall nebensächlich :D
Ein bisschen mehr musst Du schon lesen, wenn Du Dir eine vernünftige Meinung bilden willst. Ein Anfang wäre beispielsweise, die Quellen der Zitate zu lesen, das ist der „richtigste“ Kontext, den Du finden wirst …

Ist es nicht gerade der Sinn von Zitaten, dass man nicht in der Quelle lesen muss, was damit gemeint ist?

Wir vertreten da wohl verschiedene Ansichten. Ich empfinde diese Zitate jedenfalls so wie sie da stehen nicht als sachliche Kritik sondern eher als Propaganda.

Wikipedia will nun mal ein Lexikon sein, und nur eine Übersicht geben. Ob das immer oder überhaupt gelingt, sei dahin gestellt, aber in jedem Fall ist Wikipedia halt nicht alles.
Gehört es zu einer Übersicht, ein falsches Bild zu erzeugen? Sicherlich muss man bei einer Übersicht auf einige Aspekte verzichten und erzeugt per se ein falsches bzw unkomplettes Bild, aber das muss man ja nicht noch durch sowas unterstützen.
lunar

@Nocta: Man zitiert nicht, um dem Leser die Lektüre der Quelle zu ersparen. Zu diesem Zweck hat man noch nie zitiert, zumindest nicht in Literatur, Rede und Wissenschaft.

Ein Zitat, dessen Quelle der Leser nicht kennt, hat in der Regel seine Wirkung verfehlt, da dem Leser dann Hintergrundwissen zur Deutung des Zitat fehlt. Das Zitat taugt dann zu gar nichts. Weder kann es die Aussage des Texts belegen, noch kann es Renommee und Glaubwürdigkeit des Verfassers durch die Demonstration von Wissen und Belesenheit stärken, noch kann es durch intelligentes und gewitztes Spiel mit Aussage und Quelle amüsieren.

Auch der strittige Abschnitt der Wikipedia zitiert nicht, damit der Leser nicht selbst lesen muss. Im Gegenteil, er zitiert, damit der Leser überhaupt weiß, wo und bei wem er nachlesen kann und muss. Diese Zitate dienen dem Zweck, eine (abweichende) Meinung neutral zu präsentieren, um dem Leser eine Übersicht über verschiedene Ansichten zu geben. Da wird nichts verfälscht oder propagiert, und schon gar nicht mit dem Vorsatz, den diese Worte zwangsläufig unterstellen. Du übertreibst, und zwar gewaltig. Irgendwo ist Dir da das gesunde Maß verloren gegangen …

Zitate in den „richtigen Kontext“ zu rücken, ist seltenst eine gute Idee, vor allem nicht, wenn man einen neutralen Artikel verfassen möchte. Meist bedeutet das, den Sinn des Zitats ziemlich zu pervertieren. Diese fixe Idee ist daher vor allem auch solchen Personen zu eigenen, die Zitate anderer an die eigene Ideologie anpassen wollen (e.g. das „Überleben des Stärkeren“). Das ist dann auch wirklich Propaganda.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Wenn es Stallmann nicht gefallen hat, objektorientiertes Lisp zu programmieren und er im Emacs-Code es so machen will, wie es schon immer war, dann ist das sein Problem. Aus einem kurzen Newsgroup-Statement kann man IMHO keine allgemeine Aussage ableiten. Den Rest der Zitate habe ich mir nicht angeschaut, aber ich bin mir sicher, die Menge der Kritiker ist wesentlich kleiner als die Menge der Befürworter. Diese werden (natürlich) nicht genannt, und so entsteht aus dem IMHO falschen Ansinnen, auch der Minderheit Raum in der Wikipedia einzuräumen, ein verschobenes Bild.

Man muss eines sehen: Die Software-Probleme, die wir stemmen, werden immer komplexer und das ist zum Teil dem objektorientierten Paradigma zu verdanken. Ohne die Idee, dass es Objekte gibt, die Aktionen durchführen, hätten wir keine der "modernen" GUIs (will sagen, dass, was der MacIntosh bekannt gemacht hat). Dann wäre immer noch eine Modus-behaftete Kontrolle, bei der man zunächst einen Kontext definiert und dann spezielle Befehle hat zu denen man dann Parameter sucht (der vi ist ein Relikt aus dieser Zeit) state-of-the-art.

Der Modus-freie Texteditor, bei dem ich einfach Text markieren und überschreiben kann und nicht in einen Lösch-Modus wechseln muss, ist eine Erfindung von Smalltalk und somit eine Konsequenz aus dem objektorientierten Paradigma.

Um OO zu würdigen, ist IMHO eine reine OO-Sprache notwendig. Python ist keine und daher ist dort OO auch nicht immer die beste Lösung. In Smalltalk hingegen, wo es einfach gar nicht anders geht, ist OO der natürliche Weg. Self oder Io sind noch extremer, da sie auf Klassen verzichten und ermöglichen einen noch radikalen Einsatz von OO.

Irgendwer schrieb, Hilfsfunktionen wären immer nötig. Das möchte ich bezweifeln. NewSpeak schafft es, komplett ohne statische Variablen auszukommen. Dort hält sich das Objektnetz komplett selbst in der Schwebe. Es scheint mir (vom Überfliegen der Dokumentation) schon ein bisschen umständlicher, bei jedem neuen Objekt immer den Namensraum (ein weiteres Objekt) hineinzureichen, doch es erinnert das Konzept der Dependency-Injection wie sie Spring bei Java populär gemacht hat und dort lernt man schnell, dass der Preis der etwas höheren Komplexität es wert ist, bezahlt zu werden.

Ein statisches Typsystem ist noch mal ein ganz anderes Problem. Für primitive Sprachen lassen sich einfache statische Typsysteme (die "sound" sind - wie heißt denn das auf Deutsch?) finden. Doch meist möchte man als Entwickler deutlich komplexere Strukturen abbilden und dann wird es so kompliziert (man vergleiche Scala), dass die dynamische Alternative (wo man meist ein instiktives Typverständnis entwickelt, das hoffentlich bei allen Beteiligten das Selbe ist) einfacher ist.

Leonidas schrieb, dass Produktivität vom API abhängt. Ich würde zustimmen, aber zu bedenken geben, dass Objektorientierung hilft, beherrschbare APIs zu schaffen. Man stelle sich nur einmal vor, dass die 5000+ Klassen von Java mit ihren (keine Ahnung) 100.000+ Methoden entsprechend 100.000 globale Funktionen wären. Selbst Namensräume ohne Polymorphie (die ich zur OO zählen würde) machen das nicht beherrschbar.

Wir fanden ja damals schon die 1000+ Klassen von VisualWorks Smalltalk mit etwa 27.000 Methoden schon extrem umfangreich. Und CommonLisp, das mal mit mehr als 800 vordefinierten Funktionen als komplex galt, war dagegen unbeherrschbar.

Für mich ist die Idee, dass ich Objekte habe, deren Verhalten Methoden beschreiben, so selbstverständlich, dass ich z.B. Scheme, mit speziellen Funktionen für den Element-Zugriff Strings, Array, Vektoren und Listen total befremdlich finde.

Die IMHO berechtigtste Kritik an OO (und speziell Java) ist IMHO die von Steve Yegge in seinen Essay "Execution in the Kingdom of Nouns". Somit liegt für mich der beste Kompromiss in einer funktionalen objektorientierten Sprache, wobei ich funktional jetzt nicht als "Datentypen sind immer unveränderlich" verstanden wissen will, sondern in der Betonung des Verhaltens gegenüber den Objekten.

Aber das ist auch keine neue Idee, sondern schon vor 30 Jahren wollte Kay das so verstanden wissen auch wenn alle damaligen Größen der Objektorientierung immer die Objekte (und ihre Klassen) betont haben (man vergleiche Rumbaughs OMT oder schaue sich einfach UML an, wo statische Klassendiagramme mit Abstand die beliebteste Modellierungsform sind).

Stefan
Antworten