Warum Arc nicht besonders objektorientiert ist

Es gibt im Moment eine Art Manie für objektorientierte Programmierung, aber einige der klügsten Programmierer, die ich kenne, sind einige der am wenigsten begeistert davon.

Mein eigenes Gefühl ist, dass objektorientierte Programmierung in einigen Fällen eine nützliche Technik ist, aber es ist nichts, das in jedem Programm, das Sie schreiben, allgegenwärtig sein muss. Sie sollten neue Typen definieren können, aber Sie müssen nicht jedes Programm als die Definition neuer Typen ausdrücken.

Ich denke, es gibt fünf Gründe, warum Leute objektorientierte Programmierung mögen, und dreieinhalb davon sind schlecht:

1. Objektorientierte Programmierung ist aufregend, wenn Sie eine statisch typisierte Sprache ohne lexikalische Closures oder Makros haben. Bis zu einem gewissen Grad bietet sie einen Weg um diese Einschränkungen herum. (Siehe Greenspun's Tenth Rule.)

2. Objektorientierte Programmierung ist in großen Unternehmen beliebt, weil sie zu der Art und Weise passt, wie sie Software schreiben. In großen Unternehmen wird Software tendenziell von großen (und häufig wechselnden) Teams mittelmäßiger Programmierer geschrieben. Objektorientierte Programmierung zwingt diese Programmierer zu einer Disziplin, die verhindert, dass einer von ihnen zu viel Schaden anrichtet. Der Preis ist, dass der resultierende Code mit Protokollen aufgebläht ist und voller Duplizierung steckt. Dies ist für große Unternehmen kein zu hoher Preis, da ihre Software wahrscheinlich ohnehin aufgebläht und voller Duplizierung sein wird.

3. Objektorientierte Programmierung erzeugt viel, was wie Arbeit aussieht. Früher, zu Zeiten von Fanfold, gab es eine Art von Programmierer, der nur fünf oder zehn Codezeilen pro Seite schrieb, gefolgt von zwanzig Zeilen aufwendig formatierter Kommentare. Objektorientierte Programmierung ist wie Crack für diese Leute: Sie können all dieses Gerüst direkt in Ihren Quellcode einbauen. Etwas, das ein Lisp-Hacker vielleicht durch das Hinzufügen eines Symbols zu einer Liste erledigen würde, wird zu einer ganzen Datei von Klassen und Methoden. Es ist also ein gutes Werkzeug, wenn Sie sich selbst oder jemand anderen davon überzeugen wollen, dass Sie viel Arbeit leisten.

4. Wenn eine Sprache selbst ein objektorientiertes Programm ist, kann sie von Benutzern erweitert werden. Nun, vielleicht. Oder vielleicht können Sie sogar noch bessere Ergebnisse erzielen, indem Sie die Unterkonzepte der objektorientierten Programmierung à la carte anbieten. Überladung zum Beispiel ist nicht intrinsisch an Klassen gebunden. Wir werden sehen.

5. Objektorientierte Abstraktionen passen gut zu den Domänen bestimmter spezifischer Arten von Programmen, wie Simulationen und CAD-Systemen.

Ich persönlich habe nie objektorientierte Abstraktionen benötigt. Common Lisp hat ein enorm mächtiges objektorientiertes System und ich habe es nie benutzt. Ich habe viele Dinge getan (z. B. Hash-Tabellen voller Closures erstellen), die in schwächeren Sprachen objektorientierte Techniken erfordert hätten, aber ich musste CLOS nie benutzen.

Vielleicht bin ich einfach dumm oder habe an einer sehr begrenzten Teilmenge von Anwendungen gearbeitet. Es besteht die Gefahr, eine Sprache basierend auf der eigenen Programmiererfahrung zu entwerfen. Aber es scheint gefährlicher zu sein, Dinge hineinzunehmen, die man nie gebraucht hat, weil man denkt, dass es eine gute Idee ist.