http://www.2CentsOfWisdom.de/dev0005.html

Ich habe hier eine neue Seite für diesen Artikel eröffnet, weil ich zur Diskussion über Wiederverwenbarkeit und die Thesen des Artikels anregen möchte.

-- JuergenLindemeyer

Diskussion

Interessanter Artikel. Produktionsbereiche wie Bau oder Auto lassen andere Rationalisierungmöglichkeiten zu, weil Komponenten wie Ziegel wirklich milliardenfach verbaut werden können. Softwarekomponenten werden zwar auch milliardenfach verwendet, aber nur tausender-Stückzahlen oder darunter verbaut, dann nur kopiert. Es gibt kein Interesse z. B. für WYSIWYG-Textverarbeitungs-Komponenten, weil jeder Produzent sein eigenes Produkt forciert und kein Interesse hat, Konkurrenten die Arbeit leichter zu machen - es gibt keinen Markt, der hunderte verschiedene Textverarbeitungen tragen könnte. Nicht einmal DonKnuth hat seine Software so aufgebaut, dass man sein immense Know-How von außen bibliothekshaft verwenden könnte. Die Instabilität von Betriebssystem-Plattformen und Programmiersprachen verhindert imho zusätzlich das Interesse an langfristigen Investitionen in die Wiederverwendung. Eine simple und moderne Compilersprache wie SpracheD - herstellerunabhängig, universalistisch, performant und speicherschonend - könnte vielleicht mal die Basis für neue Anstrengungen werden. -- HelmutLeitner

Ähnliche Fragen diskutiert auch DanBricklin in seinem Artikel Software That Lasts 200 Years.

In SpracheLava haben wir zu Fragen der Modularisierung und Wiederverwendbarkeit unter den Schlagworten "Object-Oriented Problem Separation (OOPS)" und "Many Irreducible Mini-Methods (MIMM)" eine eigene Philosophie entwickelt (siehe OOPS-MIMM), von der wir hoffen, dass sie durch SpracheLava in vielfältiger und gezielter Weise unterstützt wird, zum Beispiel durch geschachtelte Deklarationen, Packages und Klassen mit virtuellen Typen, syntaktische Trennung von Interface und Implementation einer Klasse, Refactoring-Unterstützung, Komponenten-Unterstützung, Attached Assertions (was in Eiffel Design-by-Contract heißt).

Attached Assertions (Pre- und Post-Conditions an Methoden, Invarianten an Klassen) scheinen mir besonders wichtig zu sein, weil die ersteren streng formal spezifizieren, unter welchen Voraussetzungen eine Methode anwendbar ist und welches Ergebnis sie garantiert, während Invarianten ergänzend beschreiben, welche Eigenschaften von Klassenobjekten durch die Methoden der Klasse garantiert nicht verändert werden. Für das Beurteilen der Wiederverwendbarkeit von Methoden ist das sicher eine wesentliche Voraussetzung.

Programmiersprachen sollten jedenfalls von der Ebene der einzelnen Anweisungen und Ausdrücke, über die Methoden- und die Klassen-Ebene, über die Ebene der mit Typparametern versehenen Familien kooperierender Klassen (oder Packages in SpracheLava), bis hin zur Ebene der wiederverwendbaren Komponenten (= persistente, mit innerem Gedächtnis behaftete, in verschiedene Anwendungen einklinkbare Objekte) alle erdenklichen Möglichkeiten bieten, gemeinsam nutzbare Strukturen und Algorithmen herauszufaktorisieren und diese Strukturen auch leicht umzukonfigurieren ("Refactoring"). In meinem Artikel Lava: Bausteinbasiertes Programmieren mit Struktureditoren in der Zeitschrift ObjektSPEKTRUM habe ich dies seinerzeit herauszuarbeiten versucht.

Aber ich denke auch, dass man Programmierer nicht zu ihrem Glück zwingen kann. Monolithische Spaghetti-Programme wird es immer geben. Man kann nur die Konzepte und Werkzeuge zu ihrer Vermeidung bereitstellen. Sinnvollen Gebrauch davon zu machen wird immer ein gehöriges Maß an Einsicht, Durchblick, Geschick und Erfahrung erfordern. (Gott sei Dank, denn das macht das Programmieren ja so interessant!) --kg