Unterstützen Programmiersprachen die Anwender optimal? (mit Kommentaren)

[Dieser Beitrag wurde am 11. 4. 2013 von dem Kollegen Hans-Jürgen Hoffmann aus Darmstadt im Detail kommentiert. Er vertrat während seiner aktiven Zeit als Hochschullehrer das Fachgebiet Programmiersprachen. Mit so viel Zustimmung hatte ich nicht gerechnet. Hoffmann hat seine Kommentare in meinen Text hineingeschrieben - ein Novum für diesen Blog. Ich habe sie dort gelassen und nur mit eckigen Klammern eingefasst. Normalerweise erscheinen sie in roter Farbe]

Mit dieser Frage stoße ich mal wieder mitten ins Herz der Informatik. Sie berührt das professionelle Selbstverständnis von Informatikerinnen und Informatikern. Die Frage interessiert natürlich Nicht-Informatiker ebenso. Dabei bezieht sich das ‚ebenso‘ nur auf die Intensität, nicht auf die Richtung des Interesses. Zu den Lesern dieses Blogs rechne ich fast so viele Informatiker wie Nicht-Informatiker. Dieser Beitrag verfolgt nicht den Zweck, letztere abzuhängen. Also bitte etwas Geduld, auf beiden Seiten!

Die meisten Aktivitäten von Informatikerinnen und Informatikern haben das Ziel, die Benutzung von Computern zu erleichtern. [Leider wird das oft missachtet!] Wie weit man dabei gehen kann und gehen soll, darf durchaus diskutiert werden. Eine extreme Position wurde von Edsger Dijkstra, einem Altvater der Informatik, ausgedrückt, als er sagte: ‚Software Engineering ist der Versuch, Leuten, die nicht Programmieren können, das Programmieren zu ermöglichen.‘ (EWD1036) Mit anderen Worten: Nur Menschen mit ungewöhnlicher Begabung sind als Programmierer geeignet. [Na ja, etwas abgehoben! Ich denke da z.B. an das Verwenden von EXCEL, was ja auch eine Form von Programmieren ist; selbst Sekretärinnen und Kaufleute können das und viele mehr. VISICALC war da der Durchbruch!] Das andere Extrem steckt in dem Buchtitel ‚Anwendungsentwicklung ohne Programmierer‘ von James Martin. [Tut mir leid, jede Anwendungsentwicklung enthält Programmieraufgaben.] Martin ist bei Informatik-Anwendern etwa so bekannt wie Dijkstra bei Informatikern. [Sie schreiben von Extrema; heutzutage sollte da an einen Mittelweg gedacht sein.] Dass Computer-Nutzung nicht an individuelles Programmieren gebunden ist, ist ein anderer wichtiger Aspekt, auf den hier nicht eingegangen werden kann.

Über den Umfang des Begriffs Programmiersprachen wurde auch immer wieder diskutiert. Viele Kollegen vertreten die Meinung, dass jede Kommunikation mit einem Rechner (wie zwischen Menschen) nur mittels Sprache erfolgt. Es ist dann alles nur eine Frage von Syntax, Semantik und Pragmatik. Die Bewegungen und Tasten einer Maus kann man als Sprache interpretieren, ebenso wie die Eintragungen in einem Spreadsheet. [Diesen  Kollegen schließe ich mich an.] Im Folgenden denken wir nur an spezielle Notationen, deren Semantik es erlaubt, ablauffähige Maschinenprogramme zu erzeugen. [O.k.] Der Begriff der Turing-Vollständigkeit geistert durch die Fachwelt. Je nachdem wie man zählt, wird geschätzt, dass  es zwischen 1000 und 2000 Programmiersprachen gibt. [Sie kennen sicher auch noch die Zusammenstellungen, die Jean Sammet in den 70ern jährlich in den SIGPLAN Notices veröffentlichte; kam sie damals nicht schon auf solche Zahlen?]  Etwa ein Dutzend davon haben [betrachtet aus heutiger Sicht,] eine Verbreitung erreicht, die für den Anwender von Belang ist. (Einige) Andere davon sind nur noch von historischer Bedeutung, d.h. [sie haben sich nicht bewährt, benötigte Rechnerplattformen sind nicht mehr verfügbar, sie waren gar nicht oder nur mangelhaft vermarktet,] ihre Benutzer sind nicht mehr beruflich aktiv oder bereits verstorben.

Als Anwender bezeichne ich im Folgenden primär Ingenieure. Kaufleute und andere Nicht-Informatiker. Denkt ein Ingenieur oder Kaufmann ans Programmieren, dann denkt er vor allem an technische oder kaufmännische Berechnungen, weniger an Systemprogramme. Das gilt für Bau- und Vermessungsingenieure, aber auch für Maschinenbauer und Elektro-Ingenieure. Aber auch für Buchhalter, Statistiker, Vertriebsmitarbeiter und Planer. Für den Fortschritt der Technik ist die Automatisierung technischer Berechnungen und technischer Prozesse von ausschlaggebender Bedeutung. Auch die immer größer werdenden Massen betrieblicher Daten sind nur noch durch Computer in vertretbarer Zeit zu bewältigen. Kein Problem ist daher wichtiger, als mit dieser Vielfalt von Daten und Anwendungen fertig zu werden.

Stattgefundene Entwicklung

Vor etwa 40 Jahren waren Programmiersprachen und deren Übersetzer mein Hauptarbeitsgebiet. Es war dies die Zeit der problem-orientierten Sprachen (engl. problem oriented language, Abk. POL). Nach Erfahrungen in der Anwendung von Commercial Translator, COBOL und Fortran war ich an der Definition von PL/I beteiligt. Das primäre Ziel dieser Bemühung war es, die Zersplitterung der Nutzergemeinde von Rechnern zu verhindern. Der Kampf tobte primär zwischen technischen und kaufmännischen Nutzern. Durch die Schaffung der Architektur des System/360 durch Gene Amdahl, Fred Brooks und Gerry Blaauw war es gelungen, die auseinander strebenden Hardware-Familien wieder zu vereinen. Die Software-Gemeinde der IBM erhielt den Auftrag, das gleiche Ziel für die höheren Programmiersprachen anzustreben und in entsprechende Produkte umzusetzen. Das Team um George Radin, Jim Fox, Paul Rogoway, Bernice Weitzenhofer und andere stellten sich der Aufgabe. Das Ergebnis war die Sprache PL/I. Waren die beiden genannten Ziele bereits unverträglich, so kam während ihrer Definition noch eine dritte Zielsetzung hinzu. Die neue Sprache sollte auch die Anforderungen einer System-Implementierungssprache (engl. system implementation language, Abk. SIL) erfüllen. Auch dieses Ziel wurde durch die Addition von Datentypen wie Bit-Ketten [ich verwende da lieber den Begriff „Reihe“: „Reihe“ ist auch eine mögliche Übersetzung für „string“ und m.E. sinngemäßer – mittlere „Reihenglieder“ haben immer genau zwei Nachbarn, eine Vorstellung bei diesen Datentypen; das trifft zwar meist auch für mittlere „Kettenglieder“ zu, es gibt aber auch die Möglichkeit, dass noch ein drittes oder weiteres Glied daran eingehängt ist (und das wäre nicht sinngemäß)] und Zeiger gelöst. Die sich ergebende Sprache war erst recht überladen.

Das Schicksal von PL/I interessiert heute nur noch Historiker. Es war eine Illusion zu glauben, kommerzielle und technische Anwender würden sich mit einer gemeinsamen Sprache abfinden. Im Ergebnis wurde PL/I zur populärsten Zweitsprache. Wollten COBOL-Nutzer etwas mehr Formeln [wie bei Algol] haben, oder Fortran-Nutzer bessere Datei- und I/O-Formate [die es bei Algol nicht gab, wenn ich diese Programmiersprache sozusagen als Referenzsprache wähle] dann griffen sie zu PL/I. [in beschränktem Umfang bot PL/I die Möglichkeit,  an die jeweilige Programmieraufgabe angepasste Datentypen in einem Programm zu definieren, die dann besonders Pascal als Referenzsprache aufnahm]  Durch Minirechner und PCs wurden alle (drei) [fünf] Sprachen in den Hintergrund gedrängt – im wörtlichen Sinne. Algol war und blieb ein Steckenpferd europäischer Hochschulen. [Pascal fand mehr Verbreitung, besonders auch bei Hobby-Programmierern und zu Unterrichtszwecken, ist aber bedauerlicherweise auch schon (fast) vergessen, too small to survive.]  Da die neuen, zunächst leistungsschwächeren Rechner sich nicht den Komfort einer guten kommerziellen und einer guten technischen Sprache leisten konnten, machten neben BASIC die eigentlichen SILs das Rennen. Dank Unix wurde es vor allem die Sprache C. Über C++ ging die Entwicklung zu Java. Der Rest ist Geschichte. Kaufleute und Ingenieure hatten das Nachsehen. Das ist – sehr verkürzt  ̶  meine persönliche Sicht der Dinge. [obwohl ich auch Eiffel-Fan war und bin, würde ich es stattdessen vorziehen, Smalltalk aufzunehmen – Wegfall des Programmier-Übersetz-Binde-Ausführ-Zyklus beim (Weiter-)Programmieren, interaktiv, selbst-reflektiv, ein Vorgehen/eine Möglichkeit, die sich leider in den heute verbreiteten Sprachen kaum realisiert findet. Aus Eiffel sollte selbstverständlich das Verständnis by contract mit Vor- und Nachbedingungen und Objektbedingungen – die Bezeichnung „Klassenbedingung“ finde ich nicht so glücklich – weitere Verbreitung erhalten, auch und besonders überprüfbar zur Übersetzungszeit, leider eine ziemliche Vision meinerseits!] 

In der ersten der beigefügten Skizzen stellt jede Schicht etwa ein Jahrzehnt dar. Die unterste Schicht entspricht der Zeit um 1960. Alle Neuentwicklungen drängten nach rechts. [Da würde ich Assembler nach links setzen, ebenso auf der zweiten Schicht Algol – sonst sehr anschaulich! Diesem Vorschlag folgend müsste allerdings die Bildüberschrift neu bedacht werden.] Die linke Seite verödete. Es ist mein Eindruck, dass die Autoren von frühen Sprachen sehr stark auf ihre Kunden hörten. Sie taten es, weil sie noch glaubten, Anwendern entgegenkommen zu müssen. Sie bemühten sich, deren Wünsche zu erfüllen. Spätere Sprachen wie Pascal, C und Eiffel wurden von Systementwicklern für Systementwickler entworfen. Die Anwender in der Wirtschaft mussten nehmen, was sie bekamen. Als erstes fiel die Dezimalarithmetik weg. Sie war der Kern von COBOL und ein dicker Brocken in PL/I. Das Konzept der Sätze (engl. records), ein anderer zentraler Baustein von COBOL, wurde in Pascal neuentdeckt. Das Konzept der Formate (engl. pictures) versank im Orkus.  Die Rettungsanker der Techniker und Kaufleute wurden Pakete wie Mathematica und SAP R/3. Da sich immer mehr Anwender an sie klammerten, ist dies beiden Seiten, d.h. ihren Entwicklern und Nutzern, nicht schlecht bekommen.

Generell ist die explizite Beschreibung von Formaten (ebenso von Text-Layouts) weitgehend ersetzt worden durch eine oft interaktiv gewonnene implizite Festlegung anhand von Beispielen. In der Textverarbeitung spricht man vom WYSIWYG-Prinzip. In dem Maße, wie die Ausgabe eher auf einen Bildschirm als auf einen Drucker gelenkt wird, werden die exakten Datenformate nicht im Programm selbst, sondern durch einen grafischen Editor separat spezifiziert und weggespeichert. Es würde zu weit führen, auf die Vielzahl möglicher Lösungen einzugehen. In der Tendenz wird das eigentliche Programmieren immer mehr reduziert auf die Festlegung der reinen Verarbeitungslogik. Davon losgelöst erfolgt eine starke Strukturierung und Selbstbeschreibung der Daten. Besonders geglückt ist dies bei Text-, Bild- und Tondaten (Beispiel MIME-Protokolle).

[In obiger Skizze treten auch zwei als „objektorientiert“ bezeichnete Sprachen auf – C++ und Java –, ab der vierten Schicht, also etwa ab 1990 – obwohl es da auch Vorläufer in tieferen Schichten gab/gibt, würde ich da der begrifflichen Klarheit wegen als Referenzsprache auch Smalltalk aufnehmen wollen – eine Entwicklung, zu der m.E. noch etwas gesagt werden sollte].

Nicht stattgefundene Entwicklung

Obwohl im Prinzip große Fortschritte erzielt wurden, möchte ich im Folgenden andeuten, was Ingenieuren und Kaufleuten bisher entgangen ist. Es besteht nach meiner Ansicht immer noch ungenutztes Potential vor allem bei technischen Anwendungen. Ich beziehe mich im Folgenden im Wesentlichen auf einen Vorschlag, der in [1] (S. 348-368) dokumentiert wurde. Ich würde dieses Konzept heute als problem-orientierte oder konkrete Typen bezeichnen. Der Vorschlag [ich unterstütze dieses sehr] geht auf den früheren Kollegen Ed Lowry [2] zurück und stammt aus dem Ende der 1960er Jahre. Es gab um diese Zeit bereits Intervall-Arithmetik [Neben-bemerkung, Hinweis auf die Dissertation von Dr. Kunstmann [3], von mir um die Jahrtausendwende betreut, die dieses Konzept (Intervall-Arithmetik) bei einem in Smalltalk unter Ausnützen auch von Interaktion und Selbst-Reflexion programmierten Kalkulationsprogramm realisierte, einschl. dem Mitführen physikalischer bzw. kommerzieller(!) Maßeinheiten (!!). Herr Gunzenhäuser war da freundlicherweise Korreferent], aber auch Sprachen [im Stil von APL], die Vektoren und Matrizen als das behandeln, was sie für Ingenieure sind, nämlich Datentypen, die man geschlossen manipulieren kann, d.h. ohne ihre interne Struktur und ihre Speicherung zu kennen.

Der Kern des Vorschlags bestand darin, Programmen mehr als nur die elementaren Trägertypen (integer, float, char) mitzuteilen. In der Technik sowohl wie im Kaufmännischen gibt es nur wenige Fälle so genannter dimensionsloser Zahlen. Fast immer haben Zahlen eine Dimension (hier im ingenieurmäßigen Sinne). Sie stellen dann nicht nur abstrakte Werte dar, sondern Größen. Im Kaufmännischen sind es Währungsbeträge (€, US$, £, ¥) [und Zeiträume (pro Jahr oder pro Person, Geschäftsvorfall, … z.B.)], im Technischen sind es Längen, Gewichte, Zeiten, Spannungen, Widerstände oder Leistungen. Diesen Dimensionen einer Größe sind Maßeinheiten zugeordnet. Alle Zahlen erhalten einen Sinn erst durch die Einheit, in der sie ausgedrückt sind. Die Zahl 42  ̶  den Anhängern von Douglas Adams bestens bekannt  ̶  kann Millimeter, Meter oder Kilometer sein, oder aber Stunden oder Tonnen. Selbst dann sagt sie noch nicht allzu viel. Es fehlt die Semantik.

Viele Verbesserungen, die in der Programmierung möglich sind, haben damit zu tun, wie Wertebereiche von Variablen spezifiziert werden, und wieweit eine daraus sich ergebende maschinelle Prüfung möglich ist. Oder umgekehrt, viele Probleme, die beim Testen von Programmen oder später auftreten, sind dadurch verursacht, dass Wertebereiche zugelassen waren, die man nicht überblickte. [etwas Vergessenes aus Pascal!]

Ich erwarte eigentlich heute von jeder Programmiersprache, dass sie Datentypen verwendet, die aus der Welt der Nutzer stammen. Angenommen, es gäbe den Typ Uhrzeit. Er müsste zusammengesetzt sein aus den Einheiten Stunde (h), Minute (min) und Sekunde (sec). Dabei würden alle drei extern durch ganze Zahlen dargestellt, die wie üblich beschränkt sind. Andere Werte würden nicht zugelassen.

type Uhrzeit: h.min.sec; h: 0..23; min, sec: 0..59

Ich gehe davon aus, das Rechner-intern die benutzten Einheiten eines Typs immer umgerechnet würden auf die jeweils niedrigste Einheit, z. B. eine Minute in 60 Sekunden,  sowie eine Stunde (1 h) in 3600 Sekunden. Erst beim Ausgeben würde automatisch auf das externe Format zurückverwandelt. Bei der Währungseinheit Pfund Sterling würden alle Beträge intern immer in Pence dargestellt.

Ein Typ Kalender_Datum könnte extern als aus drei Teilen bestehend dargestellt werden.

type Kalender_Datum: Jahr.Monat.Tag; Jahr: 1945..2013; Monat: 1..12; Tag: 1..31;

[ganz ausgefeilt sogar die Tagesgrenzen abhängig von dem Monatswert, Schaltjahre nicht vergessen]. Bei diesem Typ würden alle Termine intern in der Form des so genannten Julianischen Tags dargestellt. Durch objektorientierte Sprachen wie [Smalltalk,] C++ und Java lässt sich ein ähnliches Konzept heute implementieren.

Der am weitesten gehende Teil des Vorschlags ließ sich von folgender Überlegung leiten. Schreibt ein Kaufmann eine Zahl, denkt er fast immer an eine Währung. Schreibt ein Techniker eine Zahl, denkt er an eine technische Maßeinheit. Alle Formeln, die ein Ingenieur benutzt, sind im Grunde Größengleichungen. Er muss sicherstellen, dass die Dimension stimmt. Die Operanden von Additionen und Subtraktion, oder die linken und rechten Seiten einer Zuweisung müssen sowohl bezüglich Einheit wie Dimension übereinstimmen, d.h. sie müssen typengleich sein. Durch Multiplikation oder Division entsteht ein neuer Typ, gebildet als Typausdruck der einzelnen Faktoren oder Divisoren. Außerdem können alle Größen zahlenmäßig beschränkt sein. Oft sind sie nur positiv, also größer oder gleich Null.

Unter Verwendung der in der oben stehenden Tabelle erwähnten Einheiten könnte eine Variablen-Erklärung wie folgt vorstellbar sein.

type kW: 1000*W, zeit: h.min.sec, euro: 0..500

var Leistung: kW;  Verbrauch: kW*zeit; Preis: euro/(kW*zeit): Betrag: euro

Hier ist leicht ersichtlich, welche Wertebereiche jeweils erlaubt sind und welche Verknüpfungen der Werte Sinn machen. [der Idee von Pascal folgend, in solchen Erklärungen auch programmweite Konstanten zu verwenden, könnten z.B. an der oberen Grenze von euro sich auch über Inflationserscheinungen hinweg über Jahrzehnte gesicherte Programme entwickeln lassen – in einigen so genannten Scriptsprachen kann man das mit „SET“-Erklärungen ja auch bewerkstelligen] Es werden Myriaden von ungültigen Programmen bereits vor der Kompilation ausgeschlossen. Derartige Fehler durch statische Analyse zu finden, ist wesentlich kostengünstiger als sie durch Testen aufzudecken. [Diesen Überlegungen schließe ich mich voll an – wir sind beide eben von Haus aus Ingenieure!]

Bewertung und Diskussion

Mir ging es bei dem Vorschlag zunächst darum, Informationen, die der Anwender ohnehin haben muss, auch zur Problemspezifikation zu verwenden und nicht im Kommentarteil zu belassen. Nur was dem Rechner anvertraut wird, kann auch genutzt werden. Ein Rechner kann Dinge übernehmen, die bekanntermaßen für den menschlichen Programmierer schwierig sind. Dazu gehört alles, was mit  Bereichsüberschreitungen und Mannigfaltigkeit von Datenelementen zu tun hat. Deshalb sind Vektoren und Matrizen so nützlich.  

Ich wollte außerdem in der Lage sein, eine Klasse von Fehlern so früh wie möglich zu erkennen und zu beseitigen. Dadurch dass Information hinzugefügt wird [z.B. das „by contract“-Konzept], kann eine viel gründlichere Analyse von Programmen vorgenommen werden, als dies normalerweise der Fall ist. Der Wert des Quellcodes als Dokumentation steigt. Was nicht Teil des Quellcodes ist, muss mit großem Aufwand synchron gehalten werden, soll es überhaupt nützlich sein. Es kann auch in vielen Fällen das Schreiben der Anwendung vereinfachen. Das ist aber sekundär. Die  Komplexität von zugelassenen Ausdrücken kann radikal beschränkt werden. Nur als Nebenbemerkung: Für eine von mir entwickelte Theorie des Programmtestens ist dies ein wichtiger Baustein.

Die Begründung, mit der dieser Vorschlag seinerzeit abgelehnt wurde, will ich den heutigen Lesern nicht vorenthalten. Den Satz werde ich nie vergessen. ‚Dafür haben wir Mathematiker doch abstrakte Zahlen nicht erfunden, damit Ingenieure sie wieder abschaffen.‘ [vergessen Sie bitte nicht, das Zitat genauer einem Autor zuzuschreiben! War das Dijkstra, Hoare, Bauer? Es würde mich interessieren [4]] Wer sich wunderte, dass ich oft vor einer Überbetonung der Mathematik warnte, hier mag die Ursache liegen.

Die obigen Vorschläge wurden nie [teilweise in der Dissertation von Kunstmann [3] – siehe oben] implementiert und bei Nutzern getestet. Sie erfordern sicherlich eine beträchtliche Menge an Arbeit. Die Entwicklung nahm eine andere Richtung. Wir sind pfadabhängig, d.h. es gibt kein Zurück. Die Anforderungen, die sich zuerst durch Client-Server-Strukturen und später durch das alles bestimmende Internet ergaben, ließen die Unterschiede zwischen den einzelnen Nutzergruppen verblassen. Neue Probleme verdrängten die ehemaligen Differenzen. Eine Weiterentwicklung der Programmiersprachen, die stärker auf die unterschiedlichen Nutzergruppen eingegangen wäre,  ̶  also im Sinne von POLs  ̶  wäre ein alternativer Pfad gewesen. Hin und wieder gab es Fachtagungen, die sich dem Fernziel der anwendungs- oder problemorientierten Sprachen widmeten. Das war es aber auch schon. Oft wird der Ausdruck auch nur missbraucht, etwa um damit Datenbank-Abfrage-Sprachen oder Listprogramme zu bezeichnen.

Ich kann nicht ausschließen, dass ich Einiges übersehen habe, was dieses Bild etwas anders erscheinen lässt. Dann wäre ich den Lesern dankbar, die mich darauf hinweisen würden. Jeder hat das Recht, die Geschichte, die er erlebt hat, mit eigenen Augen zu sehen. Es wäre jammerschade, wenn es nur eine einzige Sicht gäbe.

[Prima, danke, weiterverbreiten! Und bitte, bitte, mich als den Ober-Ober-Lehrer entschuldigen, HJH]

Zusätzliche Referenzen

1. Endres, A.: Analyse und Verifikation von Programmen, München: Oldenbourg 1977; 405 Seiten; ISBN 3-486-21361-X
2. Lowry, E.S.: Proposed language extensions to aid coding and analysis of large programs. IBM Poughkeepsie, Tech. Report, TR 00.1934 (1969)
3. Kunstmann, T. :  Rechnergestützte Simulation und Planung auf der Grundlage von Tabellenkalkulation.  ISBN-10: 3830006314;  ISBN-13: 978-3830006312
4. Es gibt keine Literaturreferenz. Es war ein Firmenkollege, vermutlich Nat Rochester, dessen ich in diesem Blog gedachte, oder George Radin.

Nachtrag am 17.3.2013 und Kommentar von Hartmut Wedekind:

Das Thema Dimensionen hat Hartmut Wedekind  zu einem Kommentar veranlasst. Wie er darin zum Ausdruck bringt, sollte man auch heute (also 50 Jahre nach dem ursprünglichen Vorschlag) Größen nur als ‘Benutzerdefinierte Datentypen‘ in die Programmierung einführen dürfen. Obwohl Wirtschaftsingenieur scheint er auch vom mathematischen Purismus infiziert zu sein. Meine Hoffnung liegt jetzt ganz bei denjenigen Lesern, die in der Mathematik das große Repertoire hilfreicher Methoden und Werkzeuge schätzen, nicht jedoch die Zwänge einschränkender Denkschulen.

Es bedarf keiner tiefen Einsicht, um zu erkennen, dass im Falle einer Parfümmarke, die nach der Kölner Hausnummer 4711 benannt ist, die vier Ziffern nicht mehr als Zahl, sondern nur noch als Bezeichner benutzt werden. Dasselbe gilt auch für Teilenummern.