Diskussion:Fortran

Altes Material

Hierhin ausgelagert, weil:

• Wer soll sich bitte für Neuerungen von F77 gegenüber F66 interessieren ? Zumal über F66 sonst nichts gesagt wurde.
• Warum bitte sollen wir Fortran ausgerechnet mit einer so unzulänglichen Sprache wie Pascal vergleichen ? -- Weialawaga 19:14, 22. Aug 2004 (CEST)

Wichtige Neuerungen in Fortran 77

• Datentyp CHARACTER
  Hier kann man Texte speichern. Außerdem wird dieser Datentyp für internal I/O verwendet - Daten werden statt auf ein Ausgabegerät in einen Hauptspeicherbereich geschrieben beziehungsweise von dort gelesen. In früheren Versionen gab es für internal I/O keinen einheitlichen Standard. Daher schufen verschiedene Hersteller eigene Verfahren für internal I/O. CDC und IBM verwendeten ENCODE/DECODE, HP dagegen CALL CODE gefolgt von einer WRITE- oder READ-Anweisung. Mit FORTRAN 77 erfolgt internal I/O einfach durch WRITE / READ auf eine Variable vom Typ CHARACTER.

• Standards für Ein- und Ausgabe
  Vorher fehlten Standards für Ein- und Ausgabe. Wieder schufen mehrere Hersteller eigene Lösungen. So gab es für den Zugriff auf Direct-Access-Dateien bei IBM die DEFINE FILE Anweisung. Fortran 77 ermöglicht mit der OPEN-Anweisung den Zugriff auf verschiedene Dateitypen. Bei allen I/O-Anweisungen kann man mit IOSTAT= ERR= END= die Fehlerbedingungen oder das Dateiende abfragen und geeignet im Programm verzweigen.

• IMPLICIT NONE (weitverbreite Erweiterung, ab Fortran-90 Standard)
  Der Programmierer kann sich nun dazu zwingen, alle Variablen explizit zu deklarieren. Damit erkennt man Schreibfehler bei Variablen (alpha, alhpa) schon beim Compilieren. Dies reduziert die Fehleranfälligkeit und verkürzt eventuell die Testphase. Ohne dieses IMPLICIT NONE-Anweisung wendet Fortran (in allen Versionen) eine implizite Deklaration an: Variablen, die mit "I" - "N" beginnen sind von Typ INTEGER, alle anderen vom Typ REAL. Lediglich die CHARACTER-Variablen müssen explizit deklariert werden. Damit werden Schreibfehler eventuell erst beim Programmtest erkannt.

• IF - THEN - ELSE
  In früheren Versionen musste man für solche Abfragen mindestens eine GOTO-Anweisung verwenden. Mit der neuen Syntax kann man diese Abfragen übersichtlicher formulieren und gleichzeitig die Anzahl der GOTOs reduzieren.

• PARAMETER-Anweisung
  Mit der PARAMETER-Anweisung kann man symbolische Konstanten definieren. Mit solchen Konstanten lassen sich beispielsweise ARRAYs dimensionieren. Man kann sie auch noch anderswo im Programm verwenden, zum Beispiel bei Schleifen (Anzahl der Schleifendurchläufe). Damit ist es möglich, dass man mit der Änderung der PARAMETER-Anweisung sofort alle betroffenen Dimensionierungen und alle anderen betroffenen Programmstellen anpasst. Symbolische Konstanten haben gegenüber "normalen" Variablen den Vorteil, dass sie nicht versehentlich überschrieben werden können - eine Anweisung <symbolische Konstante> = n + 1 weist der Compiler zurück.

Insbesondere die Standardisierung im Bereich Ein-/Ausgabe und bei internem I/O erleichtern die Portierung auf eine andere Plattform erheblich.

Schwächen von Fortran

Gegenüber anderen Programmiersprachen, beispielsweise Pascal, weist Fortran einige Schwächen auf. Der Programmierer hat mehr Möglichkeiten, Fehler zu produzieren. Die Folge sind verlängerte Testphasen und häufig fehlerhafte Programme in der Produktionsphase.

• Implizite Deklaration
  Der Programmierer hat die Möglichkeit, alle Variablen implizit deklarieren zu lassen. (siehe Punkt "IMPLICIT NONE" im Abschnitt "Wichtige Neuerungen in Fortran 77" ). Zwar erspart sich der Programmierer damit die explizite Deklaration, also einige Schreibarbeit, aber damit werden Schreibfehler in Variablennamen eventuell erst in der Testphase erkannt. Pascal erzwingt eine explizite Deklaration. Schreibfehler werden sofort beim Compilieren gemeldet. Durch IMPLICIT NONE kann bei Fortran-90 Programmen der gleiche Effekt erreicht werden.

• ungeprüfter Aufruf von Unterprogrammen
  Fortran prüft nicht, ob ein Unterprogramm formal korrekt aufgerufen wird. Es wird weder die Anzahl der übergebenen Variablen noch deren Datentyp auf Übereinstimmungen mit dem aufgerufenen Unterprogramm verglichen (Typprüfung). Beispielsweise kann man das Unterprogramm SUBROUTINE test (a, b, n) aufrufen mit CALL test (x, 9). In der Regel handelt es sich bei solchen Aufrufen um ungewollte Fehler, die frühestens in der Testphase gefunden werden können. Pascal dagegen prüft die Aufrufe der Unterprogramme. Ist ein Pascalprogramm erfolgreich compiliert, dann weiß man sicher, dass alle Unterprogrammaufrufe formal korrekt sind. Unterprogramme, die in MODULEn (Fortran-90) deklariert sind, können nur mit korrekten Parameterlisten aufgerufen werden.

• Überschreiten von Feldgrenzen wird nicht notwendigerweise erkannt.
  Die meisten Fortran-Systeme erzeugen keinen Code, der überprüft, ob alle Feld-Indices innerhalb der erlaubten Bereiche liegen. Dies kann allerdings bei allen Fortran-Systemen eingeschaltet werden. Ohne eine solche Überprüfung könnte es passieren, dass ein Feld über seine deklarierte Grenze hinaus beschrieben wird. Dabei kann zum Beispiel vorhandener Programmcode überschrieben werden. Die Folgen sind nicht vorhersehbar, der Fehler ist oft schwer zu finden, weil das Programm zur Laufzeit an einer ganz anderen Stelle abbrechen kann.

• Vergleichsweise geringer Verbreitungsgrad.
  Diese Schwäche ist zwar nicht wie die anderen unmittelbares technisches Merkmal von FORTRAN, aber in der Praxis gleichermaßen hinderlich. Typischerweise nach dem beruflichen Umstieg von der Forschung an einer Universität zu Kundenprojekten in einem Industrie-Unternehmen kann es für einen FORTRAN-erfahrenen Wissenschaftler zum Problem werden, dass in seinem neuen beruflichen Umfeld niemand außer ihm FORTRAN kann und schlimmstenfalls noch nicht einmal ein brauchbarer FORTRAN-Compiler verfügbar ist.

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich down ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.guilherme.tk/
  • In Fortran on Sun Jan 22 03:07:02 2006, HTTP Error: HTTP/1.0 bad gateway

• • In Fortran on Sun Jan 29 22:48:23 2006, HTTP Error: HTTP/1.0 bad gateway

--Zwobot 22:48, 29. Jan 2006 (CET)

Bei mir funktioniert der Link immer !?!

Bitte Artikel ergänzen

Ich bin hier auf den Artikel gestoßen, weil Fortran angeblich noch eine Bedeutung bei den Ingeneurswissenschaften hat, und ich gehofft hatte, das der Artikel mir sagen würde was Fortran leistet.

Ein Enzyklopädie sollte zumindest in der Einleitungsphase so ausgerichtet sein, dass auch Leute ohne Ahnung von Programmiersprachen verstehen, was der Inhalt des Textes ist.

Da ist dringend Ergänzungsbedarf!

Was genau ist denn unklar? Ich finde den Artikel sehr verständlich. --Einmaliger 23:02, 7. Apr 2006 (CEST)

Man könnte zum Beispiel angeben bei welcher Art von Problemstellung Fortran eingesetzt wird, was die Vorteile dabei gegenüber anderen Sprachen ist, welche Gruppen Fortran bevorzugt verwenden. Dinge dieser Art könnten ergänzt werden.

"Optimierte" Schleife

Das angegebene Beispiel ist Unsinn, da iFunc nicht die Iterationsvariable darstellt sondern nur die obere Grenze. Äquivalenter C-Code:

ifunc = iFunc(...); for (int i = 0; i < ifunc; i++) {

   ...

}

Unter C++ (C99?) kann damit sogar (unter güngstigen Umständen) die ganze Schleife aufgelöst werden. Wenn überhaupt ist Fortran also sicherer, dahingehend das i nicht zugewiesen werden kann und die Schleife auf jeden Fall beendet wird. --Volatile 14:38, 24. Apr 2006 (CEST)

Alternativen

Bei Ratfor handelt es sich um einen Praeprozessor, der die Restriktionen von FORTRAN77 hinsichtlich Format des Quellcodes, Länge von Namen von Variablen, Subroutinen etc. weitestgehend beseitigt. IMHO handelt es sich damit also nicht um eine Programmiersprache.

Nastran ist mit Sicherheit nicht das einzige kommerzielle Programmpaket, welches (aufgrund seines Alters) im Kern im wesentlichen aus FORTRAN77 Code besteht. Man schaue sich beispielsweise mal an, wie Matlab Matrizen abspeichert ;-)

Freie Fortran Compiler

Ich bin mir nicht ganz sicher, ob die Aussage, G95 sei weiter fortgeschritten als gfortran nach wie vor stimmt. Ich würde sie daher gerne entfernen.

Funktionsbeispiele

"CALL Bla( Argument1= 1.0, Argument2= 'Tach auch' )" - ganz toll!

Code-Beispiel

Im Artikel steht: Viele Fortran-Compiler arbeiten mit Zeigern zur Übergabe von Parametern. Das führt zu teilweise amüsanten Ergebnissen, z. B. folgendes Programmbeispiel 2: <Beispiel entfernt> Dieses würde bei manchen Compilern die Zahl 42 ausgeben. Das Programm ist allerdings so nicht korrekt.

Was soll der letzte Satz ("nicht korrekt") bedeuten? Ist das Code, der nicht dem Standard entspricht und deshalb von korrekten Compilern zurückgewiesen werden müsste? Wenn dem so ist, ist das kein Problem von Fortran.

Es sollte klarer herauskommen, ob das Problem in der Sprachdefinition selbst liegt oder ob es nur fehlerhafte Compiler sind, die zu unsinnigen Ergebnissen führen. --80.121.106.133 01:12, 13. Apr. 2008 (CEST)

Code-Beispiel-Ansicht

Das Grau und Gelb(?) in den Code-Beispielen ist sehr schlecht leserlich, ich schlage andere Farben vor. (nicht signierter Beitrag von 91.128.189.4 (Diskussion) 17:38, 25. Feb. 2011 (CET))

aktuelle Bedeutung von Fortran

Ich fände es wichtig Informationen über die Aktuelle Bedeutung und den Einsatzbereich aufzunehmen. Gerade jemand der nicht programmieren kann, hat wenig von diversen Codebeispielen und verlgeichen zu anderen Sprachen. . --Pelzi1989 11:51, 28. Mär. 2009 (CET)

Wenn auch etwas verspätet: Stellenausschreibungen für Ingenieure beinhalten ab und zu Fortran als Programmiersprache. Ob es außerhalb dieser Berufsfelder Bedeutung hat weiß ich nicht. --Tiktaalik 20:26, 20. Dez. 2010 (CET)

Es gibt im technischen und in bestimmten naturwissenschaftlichen Bereichen noch etliche über Jahrzehnte entwickelte Fortran-Programme, in denen viel fachliche Expertise steckt und die gepflegt werden müssen. Komplette Neuentwicklungen sind ab 1995/2000 allmählich auf C++ etc. umgestiegen. Eine Entscheidung, heute ein komplett neues Projekt damit zu schreiben, sollte sehr gute und konkrete Gründe haben. Man sähe sich unter anderem vor das Problem gestellt, künftig nicht genügend Programmierer mehr zu finden. Parallelisierung könnte ein Grund sein, aber das geht in C++ auch. Programmbibliotheken lassen sich aus unterschiedlichen Sprachen kombinieren. --PerfektesChaos 00:16, 30. Apr. 2011 (CEST)

Hello World?

Ich als Nicht-Fortran-Könner vermisse im Artikel ein obligatorisches Hello World Programm und würde einen entsprechenden Könner gerne bitten, dieses der Vollständigkeit halber zu ergänzen. --Equilibrium 16:28, 29. Apr. 2011 (CEST)

Habe ich mir angeschaut; aber da stehen genug Quellcode-Brösel. Einen geeigneten Platz für das Einfügen von Hello World konnte ich bei der gegenwärtigen Struktur nicht finden.

Gleichwohl: Liste von Hallo-Welt-Programmen/Programmiersprachen #Fortran

Dafür stehen allerlei Weblinks mitten im Artikelrumpf.

--PerfektesChaos 00:01, 30. Apr. 2011 (CEST)

Fortran 90 statt Fortran90

Ich nehme an, ausser in den Buchtiteln "... Fortran90/95" immer mit Leerzeichen vor 90. --Helium4 00:17, 13. Jun. 2011 (CEST)

Allgemein: beides geht, ganz nach Geschmack. Manche Compiler haben es als Produkt- oder Dateinamen ausdrücklich ohne Leerzeichen; die Schreibung ohne Leerzeichen war auch schon bei Fortran66 und Fortran77 häufig zu sehen, war aber wohl nie zwingend gewesen. In Norm-/Standard-Dokumenten anscheinend immer mit Leerzeichen. – Man wollte wohl jeweils betonen, dass die jetzt neue Version eine so gut wie neue, eigenständige Programmiersprache geworden sei; als Abfolge von Versionsnummern hatte man es nicht gesehen. Für den WP-Artikel außerhalb von Titeln einheitlich; dann halt mit Leerzeichen. VG --PerfektesChaos 10:37, 13. Jun. 2011 (CEST)

eine objektorientierte Programmiersprache ?

ab welcher version dar das möglich? (nicht signierter Beitrag von 90.186.254.49 (Diskussion) 16:03, 8. Jun. 2012 (CEST))

Ab Fortran 90.

Wobei „objektorientierte Programmiersprache“ etwas hoch gegriffen ist; es gibt einige Grundelemente der objektorientierten Programmierung. An das Vollprogramm von C++ oder wenigstens Java oder die Crack-Sprachen reicht es aber nicht heran.

Grüße --PerfektesChaos 16:50, 8. Jun. 2012 (CEST)

Infobox kontrollieren

Die InfoBox war broken (Wiki zeigt Fehlermeldungen). Habe ein fehlendes Feld (Designer) ergänzt und ein leeres Feld (Beeinflusst_von) mit einem blanko gefüllt. Die Informationen müsste vielleicht jemand nachtragen bzw. kontrollieren. --SaarPhil (Diskussion) 19:42, 13. Sep. 2020 (CEST)