Ansicht umschalten
Avatar von Ulriko
  • Ulriko

mehr als 1000 Beiträge seit 26.06.2001

Schnörkellose Sprache für algorithmische und numerische Probleme

1983 habe ich am RZ in Karlsruhe nacheinander den Fortran- und den Pascalkurs besucht. Für Fortran hatten wir noch ein Skript für FORTRAN IV, der Compiler auf dem Großrechner (eine Univac 1100, Eingabe über Lochkarten, Ausgabe über große Schnelldrucker mit Endlospapier) war aber bereits auf Fortran 77 umgestellt worden.

Während man in Fortran genau das machen konnte, was man damals als Ingenieur brauchte (z.B. habe ich anschließend für verschiedene Institute an umfangreichen Programmpaketen für Strömungsberechnungen mit überlagterter Verbrennung und Festigkeitsberechnungen mit der Finite-Elemente-Methode mitgearbeitet) und auch beim Tippen kaum etwas Überflüssiges im Weg stand, fühlte sich das damals vor allem als Lehrsprache eingesetzte, neuere Pascal schwerfällig und "bürokratisch" an. Es hatte z.B. noch keine standardmäßige Exponentiationsfunktion, was es für Ing-Studenten quasi unbrauchbar machte (bzw. sehr umständlich) und man musste bei der Werzuweisung vor das Gleichheitszeichen einen Doppelpunkt setzen und jede Zeile mit einem Strichpunkt abschließen. Auch gab es die geniale Fortranmethode der impliziten Typzuweisung nicht (Variablen, die im Alfabet im Bereich von i bis n lagen waren automatisch Integer, alle anderen Realzahlen, man konnte das aber überschreiben). Die Möglichkeiten von Pascal, die im Standard über die von Fortran hinausgingen, waren dagegen für Ingenieure völlig uninteressant (z.B. eigene Aufzählungstypen definieren, z.B. "Wochentag", bestehend aus "Sonntag" bis "Samstag" o.ä.) Ich habe damals überhaupt nicht verstanden, wie man auf so ein überflüssiges Konstrukt wie Pascal kommen kann.

Über die Jahrzehnte habe ich ein gutes Dutzend anderer Programmiersprachen kennen und (verschieden tief) benutzen gelernt (u.a. C, Cobol und Java). Besonders positiv fand ich aber nur eine Einzige davon, und das war Perl. Und bei Java habe ich immer mal gedacht: "Mein Gott, was für ein Aufwand!" und an die Schlichtheit von Fortran gedacht. Das natürlich auf vielen nichtmathematischen Gebieten Java funktional nicht das Wasser reichen konnte.

Der Mehrwert, den Sprachen wie Java (und auch damals Cobol) aufgrund ihrer Zwangsstrukturierung und aufgrund mächtiger Makrobefehle liefer(te)n (etwa dass ich in Java den Inhalt einer Exceltabelle quasi mit einem einzigen Befehl auslesen konnte) ist mir sehr wohl bewusst. Trotzdem fragte ich mich immer wieder: Muss man dafür, dass manche schwieigen Dinge so einfach gehen, wirklich die einfachen Dinge so umständlich machen?

Aus

A = B + C

in Fortran wurde schon in Pascal

A, B, C : real;
A := B + C;

was schon die dreifache zu tippende Anzahl Zeichen ist. Aber richtig lustig wird es in Java, wo ich gleich mit so vielen Deklarationen einsteigen muss ("public static void main( String[] args )"), dass ich das Gefühl habe, ich beschäftige mich weniger mit dem zu lösenden Problem als mit Begrüßungsfloskeln für die JVM. Auch die Klammersetzung finde ich nervig, Klammern sind klein und unscheinbar, können stehen wo immer jemand möchte und auch die regelmäßige Setzung systematischer Menschen ist unterschiedlich. Da man in Fortran gar keine solchen Klammern hat, um den Scope von Befehlen anzuzeigen (der Scope wird dort durch ein END angezeigt) bin ich mit diesem Stil, den heute nahezu alle Sprachen benutzen (außer Python) nie war geworden. Und trotz dessen, dass zwei Klammern weniger Zeichen sind als ein Fortran-END, ist insgesamt der Tippaufwand in Bezug zum "Nutzen" bei Java sehr, sehr viel höher, wenn es nur um mathematische Probleme geht. Schlimmer als Java ist da eigentlich nur noch XML, wo der Anteil der eigentlichen Nutzdaten an der gesamten Zeichenmenge des Codes oft unter 10% liegt.

Jedenfalls schreibe ich es meiner frühen Prägung durch Fortran zu, dass mir später Sprachen wie Perl und Python sehr viel sympathischer waren als Java.

Ulriko

Bewerten
- +
Ansicht umschalten