Fortran will never die!

f41thr

f41thr

Well-Known Member
EIn Artikel auf Heise Devloper hat mich mal wieder darauf gebracht in meinen alten Archiven zu schürfen.

Und siehe; gfortran auf OpenBSD nachinstalliert und es läuft.
Da mein Simulationsprogram damals ca. 5 Wochen verteilt auf vielen Rechner von
386.'ern, VAXen. HP-UXen, und andern Kalibern lief (so zusagen GRID Rechner) und die Ergebnisse dann
mühsam zusammengefügt werden mußten.
Um so mehr reizt es mich auf meiner aktuellen Hardware zu rechnen.

Code: 
total 516
-rw-r--r--  1 hil  hil  165969 Apr 14 18:00 2.dat
-rw-r--r--  1 hil  hil    1790 Dec 24  1996 2.plot
-rw-r--r--  1 hil  hil     321 Apr 14 17:56 Makefile
-rw-r--r--  1 hil  hil     545 Apr 19  1997 bragg.f
-rw-r--r--  1 hil  hil    1510 Apr 14 17:56 bragg.o
-rw-r--r--  1 hil  hil    7632 Aug  7  1998 c.f
-rw-r--r--  1 hil  hil    8280 Apr 14 17:56 c.o
-rwxr-xr-x  1 hil  hil   21801 Apr 14 17:56 dyth
-rw-r--r--  1 hil  hil    5714 Apr 14 17:53 dyth.f
-rw-r--r--  1 hil  hil    5711 Nov 21  1998 dyth.f~
-rw-r--r--  1 hil  hil    8916 Apr 14 17:56 dyth.o
-rw-r--r--  1 hil  hil     619 Aug  7  1998 dyth.txt
drwxr-xr-x  2 hil  hil     512 Apr 14 17:36 fprime
-rw-r--r--  1 hil  hil     433 Jul 27  1995 gtheta.f
-rw-r--r--  1 hil  hil    1028 Apr 14 17:56 gtheta.o
-rw-r--r--  1 hil  hil    3829 Jul 27  1995 myeb.f
-rw-r--r--  1 hil  hil    2684 Apr 14 17:56 myeb.o
 
Fortran 2003/2008 ist schon sehr nice und läuft mit gfortran aus der GCC praktisch überall. Dank der iso_c_bindings kann man auch alle möglichen C-Bibliotheken einbinden; SWIG erstellt die dafür nötigen Wrapper (halb-)automatisch.

Mit Photran existiert auch eine moderne IDE auf Basis von Eclipse. Vim geht aber auch sehr gut.

Schade, dass das moderne Fortran so wenig Aufmerksamkeit bekommt, es ist nämlich eine tolle Sprache.
 
Der verlinkte Artikel neigt ja mal wieder zu schlimmem Nichtjournalismus.

[Fortran-Codebeispiele] widersprechen nahezu allen Paradigmen guter, strukturierter oder gar objektorientierter Softwareentwicklung. (...) Ein Vorteil von Fortran 77 ist die leichte Ähnlichkeit zu C-Code.
Zum Vergrößern anklicken....

Seufz.
Aber es ist tatsächlich erfreulich, dass nicht jeder diesen "neue Sprachen sind besser"-Unfug unwidersprochen hinnimmt. :)
 
CrimsonKing schrieb:
Aber es ist tatsächlich erfreulich, dass nicht jeder diesen "neue Sprachen sind besser"-Unfug unwidersprochen hinnimmt. :)
Zum Vergrößern anklicken....
Oooch, so sagt das ja niemand. Man muss rur irgendeine Aussage bis ins absurde verallgmeinern dann wird sie in der tat zu Unsinn, So etwas ist einfach rhetorischer Unfug!

Neue Sprachen entstehen vor dem Hindergrund von Erfahrungen mit älteren Sprachen und der Kritik an ihnen. Manches was so entsteht ist tatsächlich eine Verbesserung, manches eine Verschlimmbesserung, andere erweist sich als Unsinn. Nur weniges ist tatsächlich inovativ. Einiges ist auch nur aus den veränderten Rahmenbedingungen zu verstehen. Und dann setzt eine beinharte Selektion ein: Die am besten angepassten ins Kröpfchen, die anderen ins Töpfchen (wodurch manche gute Idee verloren geht). Der normale Gang einer jeden Evolution eben...

Und manche alte Sprachen werden an neuere Erkenntnisse angepaßt so dass sie evtl. kaum noch zu erkennen sind. Dafür ächzen sie dann unter dem Gepäck von 30, 40 oder 50 Jahren Entwicklung das sie mit sich herumschleppen.
 
Ich glaube, hier liegt vielmehr eine Devolution vor. Die immer weiter gehende Abstraktion der Funktionalität eines Computers sorgt dafür, dass immer mehr Leute immer weniger verstehen.
 
Nun gut, bei Fortran 200x kann ich nicht mitreden, meine Erfahrungen endeten bei Fortran 77 unter RSX auf PDP11 ... und ich wüsste auch nicht, was ich seitdem vermisse ... dennoch gibt es uralte Sprachen, deren Exotenniesche schade ist. Ich denke da zuerst mal an Forth.
Wenn ich heute noch zum Taschenrechner greife, dann zu einem alten HP mit umgekehrter polnischer Notation!
 
CrimsonKing schrieb:
Die immer weiter gehende Abstraktion der Funktionalität eines Computers sorgt dafür, dass immer mehr Leute immer weniger verstehen.
Zum Vergrößern anklicken....
Das ist notwendigerweise so denn zunehmende Funktionalität läßt sich nur mit zunehmender Abstraktion bewältigen und das heißt in der Konsequenz dass es immer mehr Spezialisten für begrenzte Bereiche und immer weniger Generalisten mit einem tieferen Verständnis des Gesammtzusammenhanges gibt. Und auch die Generalisten sind letztlich nur Spezialisten in einem begrezten Bereich. Das gleiche Phänomen kannst du in allen wissenschaftlich-technischen Disziplinen und weit darüber hinaus beobachten. Das mag man bedauern, ist aber so.

Die Evolution der Sprachen ist zwar darin verwickelt, wird aber von einer Vielzahl unterschiedlichster interner und externer Faktoren angetrieben. Das kann man dann nur im konkreten Fall unter Abwägung des Anwendungsbereiches beurteilen. In jedem Falle sind auch hier allzu pauschale Be- und Verurteilungen verfehlt.
 
CrimsonKing schrieb:
Dann gäbe es aber immer weniger und nicht immer mehr Code in ASM oder C.
Zum Vergrößern anklicken....
Ist das so ? Und falls ja, was ist die Bezugsgröße? Sicherlich hat das Gesammtvolumen an Softare in den letzten 2-3 Jahrzehneten enorm zugenommen. Bestimmte Bereiche, wie z.B. Betriebssyteme, Interfaces von HL-Sprachen, vermutlich auch Datenbanken und einige wenige andere werden wohl nach wie vor von C, schon aus Bestandsgründen, abgedeckt. Aber die ganze Applikationslogik, die das Volumen dieser Bereiche sicherlich zunehmend weit überschreitet (absolut und funktional gesehen) ist heute die Domain von Sprechen wie C#, Java, Swing, Go, C++, Scriptsprachen etc pp. Da geht es aus Kostengründen darum möglicht viel Funktionalität in möglichst wenig Code zu packen. Und da werden andere Kompetenzen benötigt als nur die Beherrschung der jeweils verwendeten Sprache, das wird eh vorausgesetzt.

Ich denke C wird seine Bedeutung insbesondere als Schnittstelle zwischen den unterschiedlichsten Komponenten komplexer Zusammenhänge behalten. Insofern bleibt es sicherlich die Lingua Franka der Programmierung. Angesichts der Fortschritte in der Compilertechnologie sind seine Nachteile aber auch nicht zu übersehen...

PS: Es wird immer Nischen für bestimmte Sprachen geben, wie anscheinend Fortran für numerische Berechnungen, sogar solche Exoten wie Cobol oder APL. Da spielt der Bestand von vielen MIllionen Zeilen Code sicherlich eine große Rolle. Programmierer die sich da auskennen haben gute Chancen für einträgliche Jobs.:rolleyes:
 
CrimsonKing schrieb:
Dann gäbe es aber immer weniger und nicht immer mehr Code in ASM oder C.
Zum Vergrößern anklicken....

Das eine widerspricht nicht dem anderen: der Anteil von ASM und C an Neuentwicklungen nimmt zwar ab; die Gesamtmenge an Code steigt aber nach wie vor so gewaltig, so dass unterm Strich auch in ASM und C mehr Code entsteht als weggeschmissen wird.
 
Hallo

ich denke, daß viele naturwissenschaftliche und technische FORTRAN Anwender und Anwendungen Ende der 90er auf numerische Skriptsprachen wie Scilab, mathematica, wave etc. geschwenkt sind. Die nötige Rechenpower und Rechensicherheit ist über deren Bibliotheken da und es ist einfacher zu programmieren und die Programmentwicklung geht vor allem viel schneller.
Das nächste Problem wird wohl sein, daß für Fortran >2000 die Lehrenden an den Unis dies umsetzen müssten. Aber da "wissen" viele und vor allem die Studenten daß "C++" die tollste objektorientierte Sprache der Welt ist ("Die Erde ist eine Scheibe - weiß jeder"). Der legitime Nachfolger wäre wohl tatsächlich ADA (sollte man sich aus Prog-Sprachen Sicht mal mit beschäftigen).
Ich denke mal, daß die Scriptsprachen in Zukunft viel machen (auch im bereich embedded). Aus Sicht Codesicherheit (der Code tut was man will und genau das) ist m.E. C jedenfalls nicht optimal.

Serie300
 
Aus eigener Beobachtung:
Numeriker die "nur" Konvergenzraten beobachten wollen, nehmen Matlab, Numeriker, die kompiliziertere Probleme berechnen wollen (CFD,....) nehmen eigenen Code, wenn kein eigener Legacycode vorhanden ist in Richtung C++, bei Legacycode macht man dann keine so genauen Angaben mehr.
 
Wo wir schon dabei sind: ich habe das Problem, dass ein per Poudriere kompiliertes gfortran bei mir nicht läuft. Ich baue meine Pakete auf einem Server mit Intel Xeon D-1541 und FreeBSD 11, darunter auch GCC 4.9 und und GCC 5.4. Während gfortran49/54 auf dem Server einwandfrei funktioniert, kann ich auf anderen Rechnern, hier ein Intel Core i7-3520M mit FreeBSD 11, keine Programme kompilieren:
Code: 
> gfortran49 hello.f08 -o hello
<built-in>: internal compiler error: Illegal instruction
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Das gleiche Programm ("Hello, World!") baut auf dem Server problemlos. Woran kann das liegen?
 
Ein Xeon D-1541 ist ein Broadwell, während der i7-3520M ein Ivy Bridge ist. Der Broadwell hat einen etwas größeren Instruktionssatz, nämlich AVX 2 statt AVX 1. Wenn GCCs legendär defektes Autobreak-Buildsystem aus irgendeinem beknackten Grund auf die Idee kommt gegen die jeweilige CPU zu optimieren, baut er AVX 2 Instruktionen ein, die der i7-3520M nicht ausführen kann und es bricht mit "Illegal instruction" ab. Dagegen kann man sicher was machen, aber das überlasse ich lieber jemanden, der Poudriere nicht nur alle paar Wochen mal halbherzig nutzt.
 
Sorry, wenn ich den Thread noch mal vorkrame, aber Flang, das Fortran Front-End für LLVM, gibt es auch als FreeBSD-Port: devel/flang. Ich habe nur kurz getestet, aber Fortran 2003 scheint vollständig unterstützt zu werden.
 
CrimsonKing schrieb:
Der verlinkte Artikel neigt ja mal wieder zu schlimmem Nichtjournalismus.



Seufz.
Aber es ist tatsächlich erfreulich, dass nicht jeder diesen "neue Sprachen sind besser"-Unfug unwidersprochen hinnimmt. :)
Zum Vergrößern anklicken....

Zu beidem meine Zustimmung. Als Initiator dieses Treads EIN PAAR ergänzende Bemerkungen.

Erfreulicherweise läuft mein Fortran Code mit leichten Anpassungen immer noch. Ich kann mittlerweile die in Fortran implementierte CEXP verwenden, damals musste
ich mir einen eigene, mit Hauptwertzerlegung, usw..., selber schreiben. Das komplizierteste war die Anpassung des Makefiles ,-<.
Das ich den Code heute immer noch verstehe liegt daran, dass ich als Atarianer mit C anfing und erst während der Diplomarbeit Fortran auf einer Mainfram verwenden musste.
Delorie und seinem DJGPP sei Dank, dass ich dann erst auf die I386 Architektur und DOS migrieren konten und Linus für das damals wirklich tolle Linux.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben