Nicht tot zu kriegen: FORTRAN 2018 veröffentlicht

Es war nur eine kurze Meldung, die mir letzte Woche unter die Augen gekommen ist: Von der Programmiersprache FORTRAN wurde jetzt eine neue Fassung, FORTRAN 2018, freigegeben. Es handelt sich dabei um eine geringfügige Modifikation des 2010 herausgebrachten FORTRAN 2008-Standards. Anlass für einen kurzen persönlichen Rückblick in Sachen IT-Technik und meine erste Begegnung mit FORTRAN.


Anzeige

60 Jahre sind es her, seit die FORmula TRANslation Language (FORTRAN) in einer ersten Fassung von IBM veröffentlicht wurde. Diese war für den Einsatz in Wissenschaft, Technik und Forschung vorgesehen. 2010 kam die letzte Überarbeitung in Form von FORTRAN 2008 heraus. Die neue Überarbeitung FORTRAN 2018 ist jetzt als ISO/IEC TS 29113:2012 Norm veröffentlicht. Ein paar Details lassen sich im Fortran-Wiki nachlesen.

Persönliche Begegnung mit FORTAN

Wäre normalerweise kein Thema hier im Blog. Aber FORTRAN stellt für mich die erste Begegnung mit der real existierenden Computertechnik dar – und letztlich ist FORTRAN Schuld, dass ich nicht als Hufschmied, sondern als nutzloser Blogger geendet bin. Es war so 1977, als ich als junger Ingenieurstudent einen Pflichtkurs Programmierung mit FORTRAN belegen musste. Hieß, nachdem der Dozent uns die ersten Syntax-Regeln vermittelt hatte, kleine Programme (5 Zeiler) im 'Computerraum', wo zwei Hollerith-Lochkartenstanzer standen, auf Lochkarten unterzubringen.

Lochkarte
(Lochkarte, Quelle: Wikimedia)

Diese Lochkarten wurden dann zur nahen Kernforschungsanlage Jülich (heute Forschungszentrum Jülich, Nähe zum Hambacher Forst, der uns damals schon beschäftigte) gekarrt, um in einem Batchlauf ausgeführt zu werden. Am nächsten Tag bin ich dann erwartungsvoll zum Kasten mit den zurückgegebenen Lochkarten und den beiliegenden Ausdrucken gewandert. Und fast jedes Mal wurde ich am Anfang von einem mehrseitigen Error-Report überrascht. Hier fehlte ein Punkt in einer Zahl, dort war die Syntax einer Anweisung falsch. Es brauchte immer mehrere Anläufe, bis die Fünfzeilen FORTRAN-Code syntaktisch korrekt vom IBM-Großrechner akzeptiert wurden.


Anzeige

Gut, meine Syntax-Fehler waren nicht so dramatisch, wie der Lapus eines US-Kollegen. Ein FORTAN-Programm, in dem ein Punkt statt eines Kommas stand, wird mutmaßlich für das Scheitern der Mariner 1-Mission der Amerikaner zur Venus im Jahr 1962 verantwortlich gemacht (siehe).

Ab diesem Zeitpunkt galt es dann die Fehler in der Programmlogik zu beheben, damit das Programm machte, was ich mir so vorstellte. Zwei Dinge habe ich aus dieser Zeit mitgenommen:

  • Ich habe die Programme irgendwann auf Papier aufgeschrieben, um die Syntax mehrfach vor der Übertragung auf Lochkarten prüfen zu können.
  • Und ich habe die auf Papier notierten Programmanweisungen quasi per 'Papier-Computer' vor meinem geistigen Auge ablaufen lassen, um logische Fehler zu finden.

Hat irgendwann ganz gut hingehauen – im Laufe des Kurses liefen dann die Programmübungen in der Regel spätestens beim zweiten Schuss fehlerfrei. Mach ich heute noch, wenn ich komplexere Sachen zu erledigen habe. Das obige Prozedere führte aber dazu, dass von unserem Jahrgang gut 90% der Studenten die Programmierung nach den Pflichtkursen an den Nagel hängten und um das Thema einen Bogen machten.

Ich selbst habe, nach den ersten Gehversuchen und Flüchen, irgendwie Feuer gefangen – zumal ich seit diesem Zeitpunkt immer genügend Schmierpapier für meine Vorlesungsmitschriften hatte. Und die Rückseiten der Fehlausdrucke ließen sich auch für Entwürfe von Maschinenelementen verwenden – ich hatte im Studium der Physikalischen Technik auch eine ganze Menge Maschinenbauvorlesungen mit Konstruktions- und Feinwerktechnikaufgaben zu absolvieren.

So kam es, dass ich dann als Student noch PL/1 als Wahlkurs belegte und der Dozent mir erlaubte, an einem Mulby 3-Rechner der Aachener Firma Kranz, der im Raum mit den Lochkartenstanzern stand, direkt, interaktiv in BASIC zu programmieren. Zu dieser Zeit hatte Bill Gates längst die Firma Microsoft gegründet und ein paar Jährchen Programmierung in Basic auf DEC PDP-Rechnern hinter sich.

Ich selbst kam erst während der Diplomarbeit, im Jahr 1979, mit PDP 11-Rechnern in Kontakt. Programmieren war nicht erforderlich, aber ich stand staunend vor dem Zeugs. Denn die 'kleinen Rechner' hatten entweder Lochstreifen zum Laden der Programme, oder eine 8-Zoll-Diskette. Und ein RT 11-Betriebssystem mit Befehlen wie DIR, PIP, COPY, DELETE etc. gab es auch. War so ganz anders, als das Erstellen von Programmen auf Lochkarten.

Später kam mir dann im Flugzeugbau eine PDP 11/04 mit Teletype zur Bedienung in die Quere. Meine Aufgabe war es, in INTRAN (ein Real-Time-Fortran der Firma Instron) geschriebene Prüfprogramme anzupassen. Anschließend habe ich ab 1981 Mikrocomputer (Intel 8085) für Steuer- und Regelungsaufgaben in der Großchemie eingesetzt. Mit dabei: FORTRAN, PL/M und Assembler. Dort sind sogar Betriebssystemteile in FORTAN-Code von mir geschrieben worden.

Lang ist es her, aber vor 25 Jahren habe ich 'diese Schuhe' ausgezogen, um als Schreiberling zwischen Entwicklern und Anwendern zu vermitteln. Gab zwar kurzzeitige Rückfälle in die Programmierung in Turbo Pascal, Turbo Basic, Quick Basic, Visual Basic und C# – alles im Rahmen von Buchprojekten. Aber die letzten Zuckungen sind nun auch schon 10 Jahre her – und ich habe quasi alles verlernt. Nach diesem Ausflug in die Frühzeit: Irgend jemand von euch, der ähnliche Erfahrungen gemacht hat?


Anzeige

Dieser Beitrag wurde unter Allgemein abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Antworten zu Nicht tot zu kriegen: FORTRAN 2018 veröffentlicht

  1. Exi sagt:

    Ich habe vor 3-4 Jahren an der Uni noch eine Fortran 95 Vorlesung "genießen dürfen". Das Zeug ist also nichtmal in den Lehrveranstaltungsplänen mancher Universitäten totzukriegen ;-)

  2. Wolle sagt:

    Mein erster Kontakt mit der Progammierung war im Jahre 1976 im Studium. Ich hatte von Anfang an meine Zweifel, ob es denn der Weisheit letzter Schluss sei, wenn ein Punkt statt eines Kommas aus einer Laufschleife eine gültige Zuweisung macht. Auch die default-mäßige Zuordnung von Variablen-Namen zu Typen empand ich als riskant. Alle Variablen-Namen, die mit I,J,K,L,M,N beginnen sind vom Typ Integer, der Rest ist Real. Das führt dazu, dass ein Programm mit der Masse der Erde (MERDE) nicht funktioniert, mit dem Gewicht der Erde (GERDE) aber doch. Schlimm sowas.

    Das ebenfalls angebotene Algol-60 (blockorientiert, Vorläufer von Pascal, C, Java, usw) war ein abschreckendes Stück Software. Die Sprache ansich hat schon Ihre Reize, aber Macken im Compiler können schon lästig sein…

    Ich kam dann mit Intel 8080-Assembler in Kontakt. Das war eher meine Welt. Aber Fortran und Algol in der Schule und Assembler im Studenten-Job ging nicht. Ich habe mir deshalb einen Studentenjob als Kraftfahrer gesucht. Das funktionierte gut zusammen.

    Nach dem Studium fand ich Arbeit in einer Firma, die mit Mikrocomputern arbeitete, zunächst mit 8080 und 8085, dann 8086. Programmiert wurde in Assembler und PL/M (eine Variante von PL/1 für Mikrocomputer). Es gab ein selbst geschriebenes Betriebssystem, Multiprozessor- und Multitasking-fähig, auf dem die Anwendungs-Software entwickelt wurde. In dieser Firma lernte ich eigentlich erst, wie man richtig programmiert.

    Ein paar Jahre später wechselte ich in eine Unternehmensberatung in der Realisierung von Projekten. Pascal als Programmiersprache sollte verboten werden. C dagegen war durchaus geeignet. Zu der Zeit lernte ich auch UNIX kennen. Das Konzept dahinter fand ich genial. Leider quälte man mich über längere Zeiträume mit Pascal.

    Ich bin dann wieder in die Entwicklung gewechselt (C auf 8051). Das war durchaus OK so. Zu der Zeit (1993) hatte ich meinen ersten Rechner mit einem CD-Laufwerk. Der Händler schenkte mir eine Shareware-CD mit Spielen. Eines der 'Spiele' hieß "Linux". BOAH, dat is ja UNIX. Ich war Feuer und Flamme. Es brauchte einige Tage, dann hatte mit Hilfe der Entwickler sogar die graphische Oberfläche am Laufen: X-Server mit FVWM. Geil…, aber es fehlten Anwendungsprogramme. Vi als Textprozessor ist einfach zu wenig.

    Danach wurde ich DV-Leiter. Alles voller Windows: zunächst WfW 3.11, dann W95, NT 3.51 und NT 4.0 und unendlich viel Arbeit. Ich hatte keine Zeit mehr für meine Liebe UNIX. Das änderte sich erst, als ich den Job geschmissen habe. S.U.S.E 7.0 mit eine KDE2-Beta brauchte zwar immer noch einen halben Tag, bis der X-Server lief, aber es gab bereits die von mir so schmerzlich vermissten Anwendungen. KWord und Co waren nutzbar. Ein Jahr später habe ich meinen Ente-Vier-Server (als Dektop-System) durch Formattierung mit ext2 ins Daten-Nirvana befördert. Vorsätzlich. Ich brauchte das Zeug nicht mehr, es hatte mich auch genug geärgert.

    Heute bin ich Selbstständig im Bereich IT. Ich lebe ich zwar immer noch von Windows, setze es aber für eigene Zwecke nicht operativ ein. Programmierung findet meist nur in ein bisschen Bash-Scripting statt. Es entlockt mir aber ein Lächeln, dass ich demnächst meinen 40-jährigen Abschied von Fortran feiern kann. Trauer? keine Spur.

  3. Sam sagt:

    Die Werft hier vor Ort setzt in ihrer Forschungs- und Entwicklungs-Abteilung wohl immer noch Fortran ein. Haben halt zig Programme um Schiffe zu berechnen in Fortran liegen und woher die Manpower nehmen um das alles neu zu programmieren.
    Ich selber hab Programmieren auf einem Apple ][ gelernt, vor fast vier Jahrzehnten. Und programmiere auch heute noch, mit Begeisterung!

  4. Martin Feuerstein sagt:

    Gerade den hier gesehen: https://www.golem.de/news/job-portraet-die-cobol-cowboys-auf-wichtiger-mission-1812-138054.html – musste ich doch glatt an dich denken ;-)

  5. Axel sagt:

    Hier auf der Arbeit wird auch noch Fortran angewendet – und ich empfinde es nicht als schlimm – eher das Gegenteil.
    Gerade das man Ausdrücke wie a=b*c+d für Arrays schreiben kann und der Compiler sehr einfach AVX512 Code sdaraus generiert hat grosse Vorteile bei der Programmierung.

    Sobald man jedoch mit Strings hantieren will ….

  6. Joachim Maruhn sagt:

    Habe selbst Fortran seit 1968 verwendet. Am Anfang war es wie beschrieben, keine strukturierte Programmierung, was zu dem gefürchteten Spaghetti-Code führte. Noch heute ist es mir ein Horror, alten Fortran-Code zu entschlüsseln, mit "computed GOTO" arithmetischem IF usw. Damals konnte man auch mit Assembler Größenordnungen in Effizient erzielen. Nach einem Ausflug in die PL/1-Welt und Experimenten mit C und C++ ging ich dann zu Fortran-90 und späteren Versionen über. Die Sprache war damit auf de modernen Standard angekommen. Meine Überzeugung ist, dass für meine Art von Problemen: Quantenmechanik mit komplexen Arrays Fortran die beste Sprache ist. Wenn ein Programm in Fortran korrekt kompiliert wird, läuft es meistens auch korrekt, während man etwa in C++ dann nach Speicherlücken sucht. Auch solche Dinge wie "NAMELIST" Input sind überaus nützlich.

    Natürlich sollte jeder Profi mehrere Programmiersprachen beherrschen. Ein Dialogprogramm mit Windows-Interface würde ich nicht in Fortran schreiben.

  7. ralf sagt:

    zu "Wenn ein Programm in Fortran korrekt kompiliert wird, läuft es meistens auch korrekt, während man etwa in C++ dann nach Speicherlücken sucht"

    fortran scheint ja auch die moeglichkeit zur dynamischen speicherallokation zu bieten. da stellt sich mir, als fortran unkundigem, natuerlich die frage, warum genau fortran unempfaenglicher fuer speicherlecks sein soll als etwa c++?

    • Joachim Maruhn sagt:

      Das ist natürlich richtig und zeigt, warum ich Fortran nicht für Probleme mit komplexer Speicherverwaltung empfehlen würde. Meist hat man es mit dynamischen Arrays zu tun (obwohl manche unserer Nutzer dann Probleme mit der Stackgröße bekommen), oder man hat ein ALLOCATE/DEALLOCATE am Anfang und Ende einer Routine. Dabei ist hilfreich, dass man dabei einfach die Variable mit ihren Dimensionen angeben kann. Übrigens finde ich auch die Definition von Argumenten mit "INTENT(IN/OUT/INOUT)" wesentlich einfacher verwendbar als die C++ Versionen von "const/const */* const/const &/" usw. Andererseits habe ich durchaus die Definition von neuen Datentypen sehr hilfreich genossen, so habe ich einen komplexen integer typ definiert und verwendet.

      Zusammengefasst: die Sprache sollte der Anwendung entsprechen. Am meisten überzeugend fand ich Lisp und Smalltalk, aber leider sind diese beiden für die Praxis nicht effizient genug. Jedenfalls sollte jeder, der objektorientiert programmieren will, sich mit Smalltalk beschäftigen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.