Anwendung: Prototyping

Übersicht:

• Warum Prototyping / Einleitung
• Das NSCW-Experiment

Eine ernsthafte Anwendung funktionaler Sprachen in echten (Real-Welt) Programmen ist das (disziplinierte) Prototyping.

Ein kritischer Punkt, der das Werkzeug Prototyping herausstellt ist einfach: Bei den meisten Programmen ist das Problem ansich nicht gut verstanden, oder schlimmer: falsch verstanden . Das Ziel des Prototyping ist es den Problemraum als auch den Lösungsraum besser zu verstehen. Effekt ist das Reduzieren von Risiko: Die Kosten einen Fehler früh zu beheben, sind exponentiell geringer als später.
Das Design von grossen Systemen ist von Natur aus iterativ. Gerade das Testen von Subsystemschnittstellen macht das Werkzeug in grossen Projekten so wertvoll. Je grösser das Projekt, desto wichtiger ist die Fähigkeit schnelle Tests durchzuführen. [5]

Das NSCW-Experiment

Problemstellung:

• Erstellung eines voll funtionstüchtigen Prototyps eines sog. "Geometric-Region-Servers" (Geo-Server) für das amerikanische Militär
• Dabei sollten verschiedene konventionelle Programmiersprachen, sowie das damals (1993) neue Haskell zu diesem Zweck getestet werden.
• Beobachten der Entwicklungszeit, sowie des Umfanges von Code und Dokumentation.
• Ziele:
  • Arbeit zu minimieren, um früh auszuliefern
  • Raum für inkrementelles Erweitern zu lassen
• Kriterien der Beurteilung: Erweiterbarkeit, Verständlichkeit, Angemessenheit, Genauigkeit/Korrektheit, sowie Kompaktheit.

Rahmenbedingungen:

• Vereinfachte Version eines "Real-Welt-Problems", also keine massgeschneiderte Aufgabe für eine bestimmte Sprache.
• Informelle "Black-Box"-Beschreibung in englischer Sprache, ohne Performance-Bedingungen
• sehr kurzes Zeitfenster, ohne direkte Rücksprache mit den Auftraggebern
• den 10 Teilnehmern wurde vertraut
• Problem: Vergleichbarkeit des Codes (was bedeutet eine Zeile..)

Warum war das Ergebniss trotzdem wertvoll ?

Der Auftraggeber war nicht akademischer Herkunft, es handelte sich um ein reales Problem. Keiner der Programmierer schrieb zwei Programme (ausser der C++/awk Lösung). Imperativer Code wurde nicht portiert, sondern jeder Programmierer fing von vorne an. Ausserdem wurde die Zeit und die Codelänge gemessen: kleine Programme haben ihre Vorteile, solange sie nicht so kompliziert werden, dass man die doppelte Zeit braucht, um sie zu entwickeln.

Die folgende Skizze zeigt die Ergebnisse:

Der Haskell-Prototyp wurde in signifikant kürzerer Zeit entwickelt und war wesentlich prägnanter und einfacher zu verstehen als die beteiligten imperativen Sprachen incl. Ada und C++.
Dabei waren (von 85 Zeilen Code):

• 20 Zeilen zum Encodieren der Eingabe
• 29 Zeilen Typsynonyme und Signaturen
• und nur 36 Zeilen 'dynamischer' Code

Das Ergebniss wurde vom Prüfer als exakt, erweiterbar, verständlich und kompakt gewürdigt.

Warum schnitt Haskell derart gut ab ? Dafür gab es im wesentlichen 4 Gründe:

• Prägnanz:
  1. Haskell einfache Syntax (Layout-Rule, keine begin . .end Konstrukte)
  2. Higher-Order-Funktionen (Abbilden der Regions durch Higher-Order-Fkt.)
  3. Benutzung von Standard-Listen-Manipulationsfunktionen der Bibliothek
• Dokumentation
  Der grösste Teil der Zeit ging für die Dokumentation drauf. Hier spielte auch die Kompaktheit des Codes eine Rolle.
• Erweiterbarkeit
  Die Erweiterbarkeit wurde mit zwei weiteren Versionen des Programms getestet. Diese bewiesen die Erweiterbarkeit und Skalierbarkeit des Programms
• Formale Methoden
  Funktionale Programme lassen sich mit Hilfe eines mathematischen Modells sehr gut auf Korrektheit und Verhalten überprüfen. Bewiesen wurden u.A. die additve Natur der Region-Translation, sowie distributive und kommutative Eigenschaften der Regionen-Schnittmenge und Vereinigung.
  

Schlussfolgerung:

Fehler im Design oder der Implementierung früh zu beheben ist günstiger als später, wobei Designfehler mehr Kosten verursachen als Implementierungsfehler. Auch hier gilt: je grösser das Projekt, desto wertvoller das Prototyping. Das kann dazu führen das man Subsystemschnittstellen früher fertigstellen und testen kann. Dies wiederum kann den Overhead bei der Koordination des Projektes reduzieren.
Die Autoren [5] halten das Ergebniss für beachtenswert, den Wert der funktionalen Programmierung herauszustellen.
Weiters unter [Haskell vs. C++ vs Ada vs... - An Experiment in Software Prototyping Productivity].