# Fortran's Enduring Role in HPC and Scientific Computing

**Podcast:** Engineering Kiosk
**Published:** 2026-03-17

## Transcript

Willkommen to an new episode of the Engineering Kiosk Podcast.
Heute is nostalgic, nerd and relevant.
We spread about Fortran.
Yeah, now the spray of the era of Lochkarten in the programming.
And trotzdem stayed Fortran in the Tobe Index.
What is that loss?
Daference for Stärkung geh.
Zu Gast is Martin Diel, professor on the KU Löwen in Belgium and Fortran ecosystem, open source and wisdom simulation.
We showed what modern Fortran since 1990 can include module, typisation, and interoperability with Cine, and new compiler of LLVM Basis wie F Lang.
And Martin has also a Fortran Flachwitz gewünscht.
Also, here comes to the Einstein.
What is the Lieblingsessen of Fortran Compilers?
Lochkartensalat.
Okay, that was relatively.
Naja, good.
When you have more to Fortran and where Legacy did and where Fortran vielleicht more zucchine has to, then bleib doch mal dran.
Los geht's.
It's not the besten Erinneries.
It was a HPC-Kurs.
Manchmal must have C programming and manchmal mussten wir Fortran programming.
We have so ein Fable teilweise, or I personally, zumindest der Andi, aber grundsätzlich auch, wenn er mal upseits of seinem Go unterwegs is, dass wir auch über Sprachen sprechen, die jetzt vielleicht nicht so im Vordergrund staan.
Wobei I have heute gerade mal beim Diobe Index nachgeschaut.
Kurze Frage, Andi, was glaubst du, in welcher Position Fortran steht?
The T Yobe Index macht das Ranking auf Basis, ich glaube, unter anderem von Google-Suchtreffern.
Bei Fortran denke ich, wirft das relativ weit nach hinten.
Platz 29.
Tja, da bist du knapp vorbei.
Platz 12, 2024, sogar auf Platz 8.
Das heisst, es ist immer noch ein großes Thema.
Und wenn man sich den Graphen anschaut, ab 2022 is this, or ab 2020 eigentlich, is it auch nochmal ganz stark nach oben gegangen.
I've won, bei mir was damals HPC, also High Performance Computing in the Wissenschaft is this, glaube ich, noch immer sehr verbreitet.
Also darum haben wir das damals auch gemacht in dem Kurs.
And nachdem mir as einziges noch im Kopf ist, dass die Arrays in an Memory Layout gespeichert werden as in C.
This is this, what I was in Kurs mitgenommen, the Spaltenorientiert, das andere ist Zeilenorientiert.
Dann hört es aber bei mir schon auf.
Haben wir uns natürlich überlegt, okay, wir brauchen auf jeden Fall jemanden, der mehr Ahnung hat than we, when es um diese Sprache geht.
And daher haben wir jemanden gefunden, der da sehr tief drinnen steckt und den wir jetzt auch bei uns im Engineering Kiosk Studio begrüßen können.
Hi Martin.
Ja, hallo.
Hoffmann, du drehst dir die Welt mal wieder, wie sie dir gefällt.
Also A haben wir nicht gesucht, yeah, ja.
Und wir won't überlegt, wenn man so möchte.
Then the Transparenz halber.
Der Martin hat das Thema auch gepitcht bei uns.
Martin hat sich bei uns gemeldet.
Und ich zu meinem, wie soll man sagen, Trauer vielleicht, weiß ich nicht, hab noch nie Fortran programmiert.
Ich habe es mir ja zur Vorbereitung, habe mir Fortran-Code mal angesehen.
Martin, willkommen.
Erstmal, ganz schön, dass du hier bist.
Vielen Dank für die Zeit.
Und wie gesagt, in der Regel lehnen wir sogenannte Selbsteinladungen ab.
Doch in letzter Zeit kommt es immer öfter vor, dass uns einfach richtig gute Pitches gemacht werden.
Und Martin, du warst so einer, du hast einen Pitch zum Thema Fortran gemacht, weil du Fortran auch, ja, kann man sagen, produktiv einsetzt.
Ich würde schon sagen, produktiv einsetzt.
Und das hat unsere Interesse geweckt, weil wir haben nämlich schon lange auf dem Zettel mal Podcast-Episoden zu machen zum Thema Programmiersprachen.
Und natürlich können wir dann mit Java starten oder mit PHP oder mit GoDorust oder sowas.
Aber wer wären wir, wenn wir das tun würden?
Wir starten einfach mal mit etwas, was kaum jemand kennt.
Und was ich sagen würde, ist nicht so weit verbreitet wie Rust oder Go.
Deswegen.
Und jetzt die Frage, wer nutzt heute eigentlich noch Fortran in Produktion?
Und deswegen stelle ich dich jetzt einmal ganz kurz vor, Martin.
Du hast nach meiner Recherche einen akademischen Bilderbuchlaufbahn hingelegt.
Diplomstudent, PhD-Student, Postdoc, Gruppenleiter und das alles in der Nachbarstadt Düsseldorf, wenn man von meiner Perspektive aus spricht, denn ich sitze gerade in Duisburg.
Aktuell bist du Professor an der KU Leuven in Belgien.
Ich weiß nicht, ob ich Läuven.
Löwen, Entschuldigung.
So wie es dir an dir, ganz einfach zu machen.
Genau.
Auf Deutsch wird es ja auch so geschrieben.
Ganz genau.
Also, ich bin eher der deutschen Aussprache mächtig und nicht der Belgischen.
Aber das liegt direkt neben Brüssel.
Und was machst du da?
Du machst dort Nano- und Mikrostrukturdesign von Werkstoffen und nutzt dabei Computersimulationen als Werkzeug, um Materialien besser zu verstehen und zu verbessern.
Ist das richtig?
Das stimmt so, ja genau.
Vielleicht noch eine Sache zu meinem Studium.
Also, ich habe in München studiert und bin dann nur für meine Diplomarbeit nach Düsseldorf gewechselt, ans Max-Planck-Institut für Eisenforschung, jetzt Max-Planck-Institut für nachhaltige Materialien, bis ich nach Löwen gewechselt bin, dort geblieben.
Und jetzt könnte man meinen, da du ja seit fünf Jahren Professor bist, stehst du nur vorne, unten an der Tafel von diesen riesen Hörseelen und sagst, wie es geht, weil du das mal irgendwo gelernt hast.
Aber nein, wenn man sich mal dein Gitterprofil ansieht, dann sieht man unten relativ viele grüne Dots mit 84 Contributions im letzten Jahr.
Deswegen, es freut mich natürlich sehr, dass du ein toller Open Source-Contributor bist.
Du bist nicht nur einer, der sagt, okay, Open Source ist cool und wir sollten das alle anwenden, sondern du kontribui das auch sehr viel dazu und auch sehr viel Vortrangut, weil du da bist auch in der Community aktiv bist.
Habe ich irgendwas vergessen?
Nee, das stimmt soweit.
Vielleicht noch eine Sache.
Als Professor definiere ich immer meine Aufgabe als zweigeteilt mindestens.
Also eine Sache ist Forschung und in dem Fall fällt dann wirklich da die Programmierung oder Softwareentwicklung für wissenschaftliches Rechnen auch darunter.
Das machen dann auch meine Doktoranden und das andere ist an der Tafel stehen.
Und auch da ist es vielleicht ein bisschen anders.
Materialwissenschaften wird in der Regel von eher kleineren Gruppen besucht.
Von daher sprechen wir da eigentlich nicht über die ganz große Tafel und den ganz großen Hörsaal.
Hast du gerade geglaubt, irgendwas ist kaputt?
Yeah.
Siehst du, so geht's mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, ein Kaffee.
Und für diese Koffeinenergie, die ihr uns durch diese Kaffee-Spenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel, Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name.
Elias, Björ, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Kaffee sponsert oder vielleicht sogar ein Café-Abo wieder Fabian oder einen ganzen Monatsbedarf an Café wieder David.
Wir schätzen jeden einzelnen Kaffee und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir.
Und jetzt geht es auch schon wieder zurück zur Episode.
Jetzt, wenn wir über Tafel sprechen, jetzt würde dich schon mal interessieren, verwendest du wirklich noch eine Tafel?
Also so mit Kreide und sowas?
Ich eher weniger.
Ich bin ja hier auch in einer Gruppe mit Mathematikern und die machen das durchaus noch gerne.
Aber ein Whiteboard habe ich natürlich dann doch.
Und gerade wenn ich dann spontan irgendwas erklären will, was jetzt nicht auf einer PowerPoint steht, dann benutze ich die durchaus.
Ich kann mich auch noch immer erinnern, die Mathematiker und Physiker, die waren da immer ganz hart ganz viel runterschreiben an der Tafel.
Okay, also bei den Materialwissenschaftlern ist es dann maximal das Whiteboard.
Aber haben wir da jetzt als Materialwissenschaftler auch einen absoluten Fortran-Fan vor uns sitzen?
Also bist du wirklich eingefleischter Fortran-Fan oder ist es für dich nur ein Tool?
Wie blickst du auf Fortran, ist es deine Lieblingssprache?
Also ich würde nicht sagen, dass es meine Lieblingssprache ist.
Ich denke, es ist ein Werkzeug, was gute und schlechte Seiten hat.
Ich programmiere auch viel Python.
Das sind eigentlich die Sprachen, die ich so am meisten einsetze, inzwischen auch mehr C<unk>, vielleicht mehr dazu.
Ja, fortan hat, glaube ich, gerade aus Sicht der Ingenieure oder Wissenschaftler den Vorteil, dass es für Ingenieure und Wissenschaftler geschrieben ist.
Zum Beispiel aus der Einleitung des Row Major versus Column Major, also die transponierte Matrix.
Das kommt einfach daher, dass das in der Mathematik so definiert ist.
Und dann muss jeder, der dann eine Formel 1 zu 1 aus einer Überlegung herschreibt, muss es für C oder C, Python einmal transponieren.
Kannst du das gerade kurz erklären, weil ich sehe schon das Stirn runzeln bei Andi.
Klar, er hat keine Ahnung von was du gerade sprichst.
Vielleicht als einfachstes Beispiel, eine Matrix ist, sagen wir mal, eine quadratische Anordnung von Zahlen.
Und das kleinste Beispiel wären dann zweimal zwei.
Also ich habe vier Zahlen angeordnet, zweimal zwei, und dann ist die Frage, zähle ich erst die Zeilen?
Also ist die Reihenfolge 1, 1, 1, 2, 2, 1, 2, 2.
Oder erst die Spalten, dass ich sage, 1, 1, 2, 1, 1, 2, 2, 2.
Das sind eben die beiden Konventionen, die man machen kann.
Im Speicher liegt es natürlich einfach linear.
Der Speicher hat nur eine Zahl nach der anderen, meinetwegen Double Precision.
Und die Frage ist nur, wie ich das indiziere.
Wo schreibe ich meine Indizes hin?
Auch ich hatte im Studio, ich glaube, mit Statistik 1 und 2 ziemlich viel Matrizenrechnung.
Ich war kein Fan davon, aber ich bin auch nicht der stärkste Mathematiker in diesem Call hier deswegen.
Aber ich bin gerne der praktische Typ hier.
Und deswegen stelle ich oft die Frage, warum machen wir das überhaupt?
Welches Problem wollen wir denn hier lösen?
Und diese Frage stelle ich jetzt auch dir, Martin.
Warum wurde Fortran überhaupt entwickelt und welches Problem sollte Fortran eigentlich lösen?
Ja, damals waren die Probleme auf jeden Fall noch anders.
Und Fortran ist die erste realisierte höhere Programmiersprache.
Das heißt, vor Fortran hat man Assembler programmiert.
Und ich glaube, da ist jedem klar heute, dass das ein Problem ist.
Wenn ich keine Ahnung, eine Web-GUI in Assembler programmieren würde, hätten wir wahrscheinlich nicht so viele GUIs oder überhaupt irgendwelche Sachen.
Und das Problem, das fortran damals lösen wollte und sicherlich auch gelöst hat, war eben Mathematikern, Naturwissenschaftlern eine Sprache an die Hand zu geben, in der sie für die damalige Sicht zumindest ihre Probleme in natürlicher Sprache ausdrücken können.
Wir reden hier über so 1950, 1953.
Also Computing war damals weniger verbreitet als heute, aber es kam eben dann hauptsächlich in zwei Bereiche.
Einerseits diese technisch-naturwissenschaftliche Schiene, wo dann Fortran dominiert hat und lange die wichtigste Sprache war.
Und eben auch im Business-Bereich, da gibt es ja, glaube ich, ähnliche Ideen in Richtung Cobold, wo dann sich so eine Sprache entwickelt hat, mit dem gleichen Ziel, aber für Leute, die in der Buchhaltung arbeiten.
Also ist im Prinzip Fortran dann das Cobold für die Wissenschaftler.
Ich denke, das kann man so sagen, ja, ohne dass ich jetzt Cobold wirklich kenne.
Aber das war, glaube ich, damals ein relativ starke Trennung von der HP her, weiß ich nicht genau, aber von den Programmiersprachen war es dann offensichtlich so, dass fortan mit der Matrizenberechnung mit dem Fokus auf natürliche Sprache für Mathematiker oder Naturwissenschaftler eben in die Schiene gegangen ist und Cobold dann in die Schiene für eine anderen Anwendungsfall.
Und vielleicht nochmal, wie ich mir das damals vorstelle, jeder hat Assembler programmiert, and auf einmal kommt IBM und sagt, ja, das ist alles viel zu kompliziert, das kann ja kein Mensch, wir müssen das viel einfacher machen.
Ich glaube, das war damals vielleicht so eine Revolution wie jetzt seit seit zwei, drei Jahren LLMs.
Auf einmal kommt man weg von Assembler-Programmieren zu Hochsprache und heute haben wir dann so den Switch von Hochsprache programmieren zu Ideen in recht natürlicher Sprache zu erklären und dann von einem Werkzeug, was ja auch im Endeffekt so eine Art Compiler ist, übersetzen zu lassen.
Jetzt hatte ich gerade kurz überlegt, wie du gesagt hast, in den 50er Jahren haben wir gedacht, irrt sich da jetzt, das war doch in den 60ern, aber ich habe jetzt wirklich nachgeschaut, das war 57.
Ich habe gar nicht gewusst, dass es damals schon Programmiersprachen gab, ehrlich gesagt, das sind jetzt 70 Jahre.
Und erfunden ist es ja von John Backuswoden, was man vielleicht von der Backusnauer Form kennt.
Alle, die da im mathematischen Bereich unterwegs waren.
Andi, hast du die erst schon mal gehört?
Die kenne ich auch, aber jetzt hast du mich gerade auch mein Interesse geweckt, so nach dem Motto, weil hier ist ja doch schon der Name Kobold gefallen.
Da frage ich mich, Moment mal, erste höhere Programmiersprache Fortran 57 Kobold war doch auch irgendwie in der Ecke.
Kobold kam 59.60, aber gut, ja.
Fragen Wikipedia dran auf jeden Fall.
Welche AI hast du wieder genutzt, um Wikipedia-Artikel.
Ja, ich bin auch im Wikipedia-Artikel.
Bist du auf at.wikipedia.org, weil auf DE.wikipedia.org steht Erscheinungsjahr 1959 bei COVID.
Ich bin im englischen Artikel, da steht First Appeared 1960.
Aber ich glaube, so genau kann man das auch nicht sagen.
Also Fortran wurde seit 1953 entwickelt, nach meinen Informationen, dann gab es was funktionierendes, 1954, was ich absolut beeindruckend finde.
Es gibt jetzt neue Fortran-Compiler, die vor kurzem entwickelt wurden, die bauen alle auf LLVM auf, also auf dieser Compiler-Infrastructure, die super viel vereinfacht.
And that is from Start bis Entwicklung with viel Geld von ARM oder Nvidia, braucht man 10 Jahre.
Und die haben es damals geschafft, einen Prototyp nach vier Jahren oder nach einem Jahr auf den Markt zu bringen.
And then, ich glaube, einer von euch hat es gesagt, 1957 kam es auf den Markt.
Das sind vier Jahre.
Das ist, glaube ich, heute unvorstellbar.
Und jetzt sprechen wir von einer Sprache, die 70 Jahre alt oder mehr als 70 Jahre wahrscheinlich sogar.
Und die ist immer noch auf Platz 12 oder vor kurzem Platz 8 gewesen.
Warum?
Warum ist es eine revolutionäre Sprache immer noch, oder damals war sie revolutionär, aber warum noch, wird sie überhaupt weiterentwickelt noch?
Wie schaut denn das aus?
Warum sitzen wir heute da und sprechen wir über Fortran und scheinbar ist das immer noch eine Sprache, die sehr, sehr häufig verwendet wird in gewissen Bereichen?
Also ich glaube, es sind zwei Punkte, die vielleicht auch ein bisschen gegensätzlich klingen.
Das eine ist, Fortran wird weiterentwickelt, und so wie Fortran 1960 außer sieht es heute nicht mehr aus.
Das wäre wahrscheinlich auch niemanden von irgendwie niemandem zuzumuten.
Also da gibt es einfach Statements, viel go-To, merkwürdige Konventionen, die sich dann nachher einfach als nicht so zielführend herausgestellt haben.
Also Fortran wird weiterentwickelt.
Der neueste Standard is jetzt drei Jahre alt, vier Jahre alt von 2023.
Es wird einerseits weiterentwickelt, andererseits wird bei der Weiterentwicklung aber auch viel Wert auf Rückwärtskompatibilität gelegt.
Und das ist natürlich eine attraktive Kombination, wenn ich einerseits neuen Code schöner, moderner, in der Regel kürzer schreiben kann, ohne aber jetzt darauf verzichten zu müssen, dass den Code nicht vielleicht seit 30, 40 Jahren habe, dass ich den wegschmeißen muss.
Ist das jetzt Fortran 23 dann?
Ich kann mich erinnern, ich habe glaube ich Fortran 77 oder was war mit 90, ich kann mich gar nicht mehr genau erinnern, aber ich glaube, es war fast 77, wo man noch die Zahlen vorne hinschreiben muss von den einzelnen Zeilen, oder?
Ich glaube, das war 77, schätze ich mal.
Genau, also Fortran 77 ist so der letzte Standard, der diese Zeilenbasierte, oder diese nicht nicht Zeilen, sondern diese Spaltenbasierte strenge Einteilung hatte.
Da waren die ersten sechs Balten, glaube ich, für Kommentare und danach begann dann das Programm.
Offensichtlich hängt es damit zusammen, dass die ersten Fortran-Programme auf Lochkarten geschrieben wurden.
Und so hat sich das dann immer weiterentwickelt.
Und dann kam der große Schritt mit Fortran 90, 13 Jahre später, das hat damals wohl auch wirklich lange gedauert, in eine Konvention, die als Freeformat eben benannt wird.
Und das ist dann ohne diese Limitierung, und dann kamen halt in den nächsten Jahren 1995, 2003, 2008, 2018 und dann eben 2023 Ergänzungen zu dem Standard.
Und Fortran 77 sieht auch aus meiner Sicht, ich habe das selbst nie aktiv geschrieben, doch sehr altertümlich aus.
Also jetzt wird hier dieser Theobe-Index ja immer noch erwähnt und er hat mich jetzt gerade nicht losgelassen.
Ich möchte jetzt nur mal ganz kurz hier klären, und die Frage geht auch an dich, Martin, warum du denkst, Fortran ist auf Platz 12.
Also erstens, Fortran ist auf dem absteigenden Ast.
Ja, es hat einen roten Pfeil nach unten.
Es ist Downtrending.
Da müssen wir mal jetzt hier.
Aber ja, es war ja auf 8 eben.
TypeScript ist gerade auf Platz 32.
Und da habe ich dann mal geguckt, okay, jetzt ist irgendwo.
Was ist hier los?
Wie wird dieser Index eigentlich zusammengesetzt?
Suchvolumen.
Der Hauffaktor ist die Häufigkeit der Suchanfragen, die den Namen der Programmiersprache enthalten.
Zum Beispiel Fortran Programming.
Dann bei Google.
Okay.
Dann Quellen.
Es werden über 25 Suchmaschinen und Webseiten wie Wikipedia, YouTube und Bing und Google genutzt.
Okay.
Und jetzt kommt es qualifizierte Entwickler-Drittanbieter.
Anzahl der Entwickler, die die Sprache nutzen, so wie die Verfügbarkeit von Kursen.
Also, ihr könnt mir doch nicht erzählen, dass Fortran in allen drei Segmenten TypeScript schlägt oder Go oder Rust, weil die sind alle hinter Fortran.
Martin, jetzt du.
Ja, also was der Index misst, ist wahrscheinlich für alle so ein großes Rätsel.
In der Fortran-Community wird eigentlich immer gesagt, wenn Fortran nach oben geht, hat er recht.
Wenn Fortran nach unten geht, hat er nicht recht.
Also es gibt eine relativ klare Regel, die auch jeder so versteht.
Ein Problem, das mir irgendwie nie so ganz klar war, ist die Namen.
Fortran, wenn jemand nach Fortran sucht, dann ist es entweder ein Typo oder er sucht nach der Programmiersprache.
Wenn jemand nach Rust sucht, ist vielleicht einfach sein Auto irgendwie kaputt gerostet.
Wenn jemand nach Go sucht, sucht er vielleicht auch einfach irgendeiner Fitness-App, ich weiß nicht was.
TypeScript und Fortran sollten da eigentlich in der gleichen Kategorie sein.
Warum TypeScript da so schlecht abschneidet, weiß ich nicht.
Ein Punkt, der natürlich auch immer klar ist, wenn niemand nach dem Begriff suchen muss, vielleicht weil die Sprache so klar und gut ist, dass man es einfach schreiben kann, ohne danach zu googeln, dann sucht man da nicht.
Vielleicht ist es einfach, dass Fortran so verwirrend ist, aber das würde ich jetzt persönlich nicht sagen.
Ich mag deine Argumentation, aber auf der anderen Seite, um dir wieder herauszufordern, wenn ich nach Rust Programming suche, müsste das nicht, wenn das nach rostigen Stellen auf meinem Auto ist.
Bist du das nicht eigentlich zur Folge haben, dass dort mehr Suchtreffer kommen als bei Fortran?
Schon, aber die Frage ist halt natürlich, was machen die für Datenmanipulation, um da auf ihre Zahl zu kommen.
Ich weiß es nicht.
Es ist mir auch nicht so klar.
Eine Sache, die ich weiß, ist, dass Fortran war schon mal deutlich schlechter.
Also vor zehn Jahren vielleicht auf 20, 25, so in der Gegend.
Und seit inzwischen vielleicht acht Jahren, ich weiß es nicht so genau, gibt es eine Fortran-Lang-Website, also eine relativ informative Website, die auch nicht so aussieht wie aus den 1990er Jahren.
Also wenn ihr irgendwie mal gucken wollt, wie eine Website von 1990 aussieht, dann geht auf Fortran.com oder sowas.
Also es gibt da auch wirklich Sachen, den sieht man das alte an, auf Fortran-lang.org, glaube ich.
Das ist einfach eine Up-to-Date-Seite.
Es gibt einen Fortran-Discours, wo dann die Sachen diskutiert oder Themen diskutiert werden können.
Das hat der Sprache auf jeden Fall im Kiobe-Index ein Push gegeben.
Ob das jetzt echte Relevanzverbreiterung ist, würde ich jetzt fast ein bisschen bezweifeln.
Aber nochmal, ich habe es eben schon mal gesagt, es gibt zwei neue Fortran-Compiler, die in den letzten zehn Jahren entwickelt worden sind.
Es gibt FLANG, basierend auf LLWM und dann direkt kompatibel mit Klang, also dem Apple-Compiler oder diesem Open Source Compiler, der viel gebraucht wird.
Und dann gibt es L-Fortran, auch basierend auf LLWM mit einem bisschen anderen Fokus.
Also es ist jetzt auch nicht so, dass sich da nichts tut.
Und die Standardisierung geht auch immer weiter.
Ich glaube, das Grundproblem ist einfach, dass da Andi gesehen hat, dass Go auf Platz 16 ist.
Und das geht dann überhaupt nicht, dass das schlechter ist als Fortran.
Und ich glaube, darum springt er jetzt so auf auf diesen Index.
Nee, nee, nee, nee, nee, nee.
Ich habe ich habe einfach nur mal geguckt, okay, auf welche Datenbasis beziehen wir uns denn hier?
Und deswegen.
Aber wo ich gerade so ein bisschen die Top-Level-Domains durchgegangen bin, Fortran.org ist zu verkaufen.
Also, falls wer eine Top-Level-Domain haben möchte, kann man die kaufen.
Jetzt ist einer dieser Sprüche in diesem Podcast Legacy verdient das Geld.
Und jetzt sprechen wir über eine sehr alte Programmiersprache.
Deswegen nehme ich einfach mal an, da ist sehr viel Code drin geschrieben worden.
Und deswegen nehme ich auch nochmal darauf an, dass sehr viel Code davon immer noch in Produktion ist.
Und wenn ich das einfach mal so weiterführe, dieses Gedankenspiel, dann denke ich mir, wir haben so viel gelernt in der Programmierung, wie man gute Software schreibt.
Habe ich da immer nur einen Haufen Spaghetti-Code vor mir oder bietet Fortran auf Englisch würde ich sagen Guardrails.
So beschützt sich so ein bisschen vor der Code-Mess.
Oder ja, wie strukturiert man guten Code?
Oder wird der alte Code noch modernisiert?
Ich gehe stark davon aus, auch du hast mal alten Fortran-Code irgendwo gesehen oder vielleicht sogar täglich in den Händen.
Also täglich in den Händen zum Glück nicht.
Und ich denke, es ist auf jeden Fall was dran, dass viele Software einfach geschrieben wurde und sie wird weiter eingesetzt.
Also heute in der Produktentwicklung ist es ja eigentlich immer so, jedes technische Produkt startend von dem Material, das wäre dann meine Domäne, bis zu Festigkeit bei einem Auto, vielleicht von einem Wi-Fi, die Antenne, wie die abstrahlt, das wird ja alles erstmal simuliert, bevor da überhaupt jemand das erste Produkt herstellt.
Und ich würde mal fast behaupten, in jedem jedes technischen Produkt, was wir verwenden, hat sicherlich in irgendeiner, in irgendeiner Form, vielleicht nicht super wichtig, irgendeine Simulation stattgefunden, wo Fortran drin war.
Es gibt LAPAC, Linear Algebra Package, was eigentlich die Grundlage für viele Simulationen ist, für die grundlegenden linearen Algebra Probleme.
Das ist in Fortran.
Und wenn man dann auch sowas benutzt, wie gesagt, ich gebraucht viel Python, da werden dann für Simulationen sowas gebraucht wie SciPy oder NumPy.
Das sind Wrapper auf Fortran-Code.
Also, wenn ich ein Eigenwert in Sci-Py oder NumPy ausrechne, dann habe ich ein schönes Python-Interface und im Hintergrund wird fortran oder auch C oder C aufgerufen.
Und viele von den Sachen sind Stand heute meines Wissens nach immer noch Fortran-Routinen.
Man sieht es natürlich nicht mehr.
Und warum?
Also, warum sind es keine C-Implementierungen zum Beispiel?
Ich denke einfach, die Fortran-Routinen sind da.
Man kann sie verwenden.
Sie sind oft meiner Meinung nach nicht so getestet, wie man es heute testen würde.
Aber sie sind Battle-Pro.
Also, sie sind einfach, dadurch, dass keiner in den letzten 30 Jahren ein Fehler gefunden hat, kann man trotzdem davon ausgehen, dass sie gut sind.
Das ist, glaube ich, ein Argument.
Das andere ist ja für vielleicht ein bisschen mehr in Richtung der Sprache.
Sie hat halt eben doch auch ein Fokus auf Performance.
Also, es gibt so Sachen wie die Reihenfolge der Statements kann zum Beispiel ausgetauscht werden.
Das heißt, der Compiler hat die Möglichkeit, Optimierungen durchzuführen, die zum Beispiel bei C nicht so einfach sind.
In C gibt es ja immer die Pointer-Thematik mit Aliases.
In Fortran muss ich explizit sagen, diese Zahl oder diese Variable kann möglicherweise ein Alias haben.
Das heißt, das ist dann so eine Art Warnung an den Compiler zu sagen, okay, vielleicht kann ich damit bestimmte Optimierung nicht machen.
Wenn ich normal ein C-Code schreibe, ist immer die Frage, zeigt da nicht noch irgendein Pointer drauf, der dann vielleicht ein Argument zu einer Routine ist und irgendwas wird übersehen.
Also Fortran hat schon den Anspruch und die Idee, schnellen Code zu ermöglichen.
Die alten Routinen sind dann halt oft noch Fortran 77.
Da gibt es viele Sachen, die heute verwendet werden, noch nicht.
Aber jetzt bei modernerem Fortran, das bietet dann, glaube ich, schon die Möglichkeiten, guten Code zu schreiben.
Also ich habe multidimensionale Arrays.
Das gibt es jetzt, glaube ich, in C mit dem Kommenden Standard.
MD-Span ist gerade standardisiert.
In Fortran gibt es das seit 1990.
Dynamische Memory ist natürlich auch kein Unique Selling Point heute, aber mit dieser Matrix-Notation, dass ich einfach Ideen relativ nah am Problem ausdrücken kann.
Das macht es für mich auch heute noch interessant.
Man hört schon ziemlich viel raus, dass Fortran sehr stark in der Mathematik ist.
Das bedeutet Zahlen, Berechnungen, Matrizenkalkulation und so weiter und so fort.
Und vor kurzem haben wir auch in dem Podcast über die Sprache F-Sharp gesprochen, beziehungsweise haben wir ganz kurz erwähnt, dass die Sprache F Sharp unter anderem Datentypen zur Datentypen zur physikalischen Maßeinheit habe.
Das bedeutet irgendwie Geschwindigkeit und Meter und Sekunden und sowas.
Was die ganze Sache wirklich stark typisiert in der Sprache.
Jetzt frage ich mich, wie sieht es denn mit der Typisierung in Fortran aus?
Also ist das spezialisiert irgendwie auf Floating Point Numbers und Dezimals oder Integer und das war's.
Oder dynamisch typisiert wie PHP oder vielleicht sogar Python.
Und ja, vielleicht kannst du mal zu dem Typensystem ein bisschen was sagen.
Ja, also statisch und stark.
Und was es gibt, sind Floating Points, die heißen Real, Integers, Complex und Logical Boolean.
Und dann kann man noch so etwas wie Derived Types, also Compound-Datentypen machen.
Es gibt Enums.
Das ist, glaube ich, so ein bisschen der absurdere Teil von Fortran, weil ein Enum-Typ wurde eingeführt, hauptsächlich für Interoperabilität mit C.
Also, das ist ja heute so, glaube ich, der Standard, dass jede Sprache spricht irgendwie zusammen mit C.
Das heißt, wenn ich Python mit Fortran verbinden will, macht man das oft über so ein C-Layer oder mit C.
Auf jeden Fall wurden E-Nums eingeführt, die waren, die gibt es im Sprachstandard, die sind relativ beschränkt und dann ein paar Jahre später wurden nochmal Enums eingeführt, die heißen anders, fragt mich nicht genau wie, die einen heißen E-Num und die anderen Enumerator oder irgendwie sowas.
Aber das ist schon etwas absurd.
Und generell ist es wirklich so der Fokus auf diese Basisdatentypen.
Und dadurch, dass es stark und statisch ist, weiss der Compiler sozusagen zu jedem Zeitpunkt, was ihn erwartet.
Und ein Unterschied ist dann natürlich zwischen Array und Liste.
Eine Liste, die vielleicht verschiedenartige Typen enthalten kann, ist natürlich viel, viel schwieriger zu optimieren als ein Array, wo ich den Zugriff einfach über Zahl mal Offset oder sowas berechnen kann.
Und das macht es natürlich auch sehr einfach zu optimieren, wenn ich sozusagen da einen Limit habe oder eine Einschränkung habe, zu sagen, okay, wenn da ein Array kommt, dann weiß ich einfach, der 500-Eintrag ist 500 mal Size of.
Das habe ich in der Liste nicht, da muss man sich dann dann durchkämpfen.
Okay, du sagtest gerade, dass es auch Listen gibt und dass Listen unterschiedliche Typen enthalten können.
Das klingt jetzt so ein bisschen nach irgendwie, das klingt jetzt so gar nicht stark typisiert.
Nee, das gibt es in Fortran nicht.
Ah, okay.
Deshalb gibt es das nicht.
Man kann das natürlich selbst implementieren und das wird auch gemacht.
Dann muss ich mir eben, oder auch da mit Hinblick auf die Interoperabilität mit C, gibt es in Fortran heißt es Unlimited Polymorphic, also praktisch jeder Typ.
In C ist das so ein Void.
Das heißt aber, in jedem Zugriff, wenn ich dann irgendwas mit meinen Datentypen oder mit meinen Daten machen will, dann muss ich so ein Typeguard einbauen.
Das heißt, wenn dieser Typ jetzt ein Integer ist, dann macht das.
Wenn dieser Typ ein Float ist, dann macht das.
Das heißt, es gibt keine Listen in der Sprache.
Man kann sie sich selbst programmieren, aber das fühlt sich dann wirklich schwierig an.
Vor allem, wenn man dann irgendwie weiß, in Python sind es zwei Zeilen und es funktioniert einfach.
Es funktioniert natürlich mit einer ganz anderen Geschwindigkeit, aber der Komfort ist da in Fortran relativ gering.
Das heißt aber, man hat vollen Speicherzugriff, klassisch wie in C, wenn du dir das selber bauen musst.
Gute Frage.
Man kann schon viel machen.
Es gibt in Fortran auch Pointer, die werden eigentlich relativ wenig gebraucht.
Aber das Memory Management liegt bei dir.
Also es gibt jetzt keinen Garbage Collector oder sowas, sondern du musst alllockieren und damit umgehen.
Genau, also allokieren muss man auf jeden Fall.
Das ist teilweise doch ein bisschen komfortabler als in C.
Also ich kann zum Beispiel einfach, wenn ich meinem dynamischen Array drei Einträge zuweise, dann versteht der Compiler, okay, das soll auf Länge 3 allokiert werden und dann direkt zugewiesen werden.
Also es ist ein bisschen komfortabler als Mallock, aber im Endeffekt ist natürlich ein ganz normales Mallock darunter.
Garbage Collection gibt es nicht, aber es gibt natürlich diese Regeln, wenn Sachen out of scope gehen.
Also wenn ich ein Array in einer Funktion definiere, dann kann ich das in der Funktion verwenden, aber wenn die Funktion endet, wird es automatisch wieder freigegeben.
Jetzt klingt das alles sehr nach direkten alten Konzepten und sehr nach Spaghetti-Code.
Und wenn ich mich so zurückerinnere, das, was ich damals geschrieben habe, war auch sehr spaghetti-artig.
Aber das waren halt sehr kleine Geschichten.
Gibt es da mittlerweile in irgendeiner Form Modularisierung, irgendwelche neuen Features, Objekte, Objektorientierung, vielleicht sogar Generics, was mal so von anderen Sprachen kennt, oder ist es immer noch eigentlich das gleiche Fortran wie vor 30 Jahren?
Also Module gibt es seit 1990, Fortran 90 gibt Module.
Und da würde ich auch sagen, ist Fortran C deutlich voraus.
Also ich schreibe nicht irgendwo mein Header und dann in andere Datei die Implementierung, sondern ich schreibe einmal die Implementierung.
Der Compiler kann dann checken, rufe ich die Funktion, die ich irgendwo in dem Modul definiert habe, mit den richtigen Argumenten auch.
Also sowas, was ich in C machen kann, dass ich verwechsel, den Datentyp oder sowas, das kann der Compil kann in Fortran-Compiler sehr effektiv dadurch feststellen.
Das gibt dann eben ein Fehler während des Kompilierens.
Also Module gibt es auf jeden Fall.
Ein bisschen merkwürdig implementiert, weil wenn ich an Module denke, auch wieder von Python, dann denke ich natürlich direkt an Namespaces.
Die gibt es komischerweise in Fortran nicht.
Vielleicht ein bisschen das Problem, wenn man, wenn man sich überlegt, 1990, ich weiß nicht, was da der Stand bei anderen Programmiersprachen war, aber ich denke, da waren Module.
Naja, Java war noch gar nicht auf der Welt 1990.
Die gab es damals noch gar nicht.
Da waren Module noch relativ neu und vielleicht war da die Erkenntnis, dass Module mit Namespaces zusammen sind, eine richtig gute Idee.
Module ohne Namespaces waren damals wahrscheinlich auch eine gute Idee, aber heute fühlt es sich ein bisschen komisch an.
Objektorientiert gibt es auch, also ich kann Methoden an Typen binden.
Sicherlich nicht so, wie soll ich sagen, vom Gefühl her gut gemacht wie in C<unk> oder Python, aber das geht.
Die Frage ist da dann so ein bisschen von der Fortran-Seite, ist es noch schnell?
Wir haben ja diskutiert, Fortran ist eigentlich dafür da oder wird verwendet, weil es eine schnelle Programmiersprache ist.
Und da muss man leider feststellen, in dem Moment, wo ich viel objektorientierten Code schreibe, können zumindest die existierenden Compiler das nicht mehr so gut optimieren.
Das heißt, da habe ich dann schon den Trade-off, will ich diese modernen Features benutzen oder soll mein Code schnell sein?
Das letzte, was du gefragt hast, Generics, das ist im Moment in der Diskussion für einen der nächsten Standards.
Siehst du?
Fortran und Go sind gar nicht so weit auseinander.
Generics sind inzwischen in Go, hat aber auch ein paar Jahre gedauert.
Aber nun gut.
Wieso, Martin hat gerade gesagt, es gibt keinen Spaghetti-Code mehr.
Wurfang, war schön mit dir zu sprechen.
Ich wünsche dir einen schönen Tag.
Dankeschön.
Ich mache von hier alleine weiter.
Die Frage ist ja, wir haben gerade ein bisschen über Performance gesprochen.
Du sagtest gerade, dann ist Fortran nicht mehr schnell oder das ist immer noch die Frage ab, welche Funktionalität wird denn vom Compiler da weg optimiert und co.
Und der Wolfgang hat diese Podcast-Episode auch mit High-Performance Computing begonnen.
Und du arbeitest ja auch in dem Feld.
Wir haben Simulationen und Co.
Ich gehe stark davon aus, du führst die Simulationen nicht auf deinem kleinen MacBook durch, sondern auf einer etwas größeren, hoffentlich verteilteren Kiste.
Und immer wenn ich von High Performance Computing spreche, beziehungsweise von verteilten Kisten, spreche ich natürlich auch von Shared versus Distributed Memory.
Und wenn Fortran wollte ich gerade sagen, wenn Fortran genau auf mathematische Operationen ausgelegt ist und Co.
kann ich mir auch vorstellen, das wird auch für Wettersimulationen genutzt.
Ich weiß es nicht.
Das bedeutet aber für mich aber, mit einem Terabyte Memory oder vielleicht mit einem bisschen mehr, vielleicht kommst du damit nicht aus, also brauchen wir ein bisschen mehr CPU-Power, ein bisschen mehr RAM.
Wie geht denn Fortran oder wie löst Fortran denn das Thema Shared versus Distributed Memory?
Greift das auf irgendwie Standard Libraries wie aus dem C, C<unk> Bereich zurück wie MPI und Co.
Oder gibt es da irgendwie was Eigenes, was speziell optimiert ist?
Ja, zwei Antworten.
Also es gibt im Prinzip die Äquivalente zu C<unk> und C im Bereich OpenMP, also OpenMP als Pragma, so eine Art Kommentar, die ich in den Code schreibe, die dann, wenn die Library vorhanden ist, dazu führt, dass Schleifen im Shared Memory parallelisiert werden.
Das sieht im Endeffekt genauso aus wie in C und wird dann im Backend sind es eigentlich nur Threads.
Also es ist so eine Art glorifizierte Threads, wo man als Programmierer sich keine Gedanken machen muss, wie starte ich den, wie join ich den, sondern ich sage einfach, da ist eine große Schleife, teile die doch einfach auf, dass auf meinem System die vier Prozessoren, die ich habe, einfach einer macht den ersten Teil, der nächste macht den zweiten Teil und so weiter.
Das ist Shared Memory.
Da sehe ich kein Unterschied zu C<unk> oder C.
Für Distributed Memory, also alles, was dann wirklich auf Cluster geht, auf High Performance, hat sich auch da MPI, also Message Passing Interface durchgesetzt.
Das kann man eben in den meisten Sprachen, die verwendet werden, benutzen.
Also C<unk>C sind, glaube ich, ist in einer der Sprachen die native Implementierung, dann gibt es Bindings zu Fortrun und man kann das dann auch mit anderen Programmiersprachen dann benutzen, so etwas wie Julia oder Python.
Also da gibt es keinen großen Unterschied.
Fortran selbst hat aber eine Spezialität und das sind sogenannte Co-Arrays.
Und das ist im Endeffekt der Versuch, dieses einfache Paradigma vom Shared Memory.
Das heißt, wenn ich einen Datenpunkt von einem anderen Thread oder Prozess haben will, dann sage ich einfach, gib mir den Datenpunkt 5 und ob der jetzt auf meinem, in meinem Speicher liegt oder in dem anderen, das ist ja das Schöne an Shared Memory, zu übertragen auf Distributed Memories.
Das heißt, in Co-Array Fortran, was Teil des Standards ist, kann man neben den normalen Matrix-Dimensionen eine Co-Dimension spezifizieren.
Und die bedeutet dann, auf welchem anderen Prozess liegen die Daten.
Das heißt, wenn ich jetzt sage, ich will Eintrag 1.1 von der Matrix haben, dann nehme ich mein 1.1-Index.
Und wenn ich jetzt aber den 1.1-Index von Prozessor 5 haben will, und ich bin jetzt selbst nicht gerade Prozessor 5, dann sage ich einfach 1,1 und dann in der, glaube ich, eckigen Klammer 5.
Und das ist so eigentlich der Versuch in der Sprache, das einfache Shared Memory Access auf Distributed Memory zu übertragen.
Vielleicht noch als Funfact, im Endeffekt zumindest eine Implementierung, von der ich gehört habe, basiert es dann wieder auf MPI.
Also man benutzt MPI, um diese ganzen Datentransfer von einem Knoten zum anderen zu machen, aber baut es dann in der Sprache so ein, dass ich da keinen explizites Send oder Receive mehr brauche.
Ich habe mir gerade Co-Arrays in Fortran gegoogelt und komm auf den Wikipedia-Artikel.
Und da denkst du dir wieder, das kann doch nicht euer Ernst sein.
Warum ist Benamung eigentlich so schwer?
Also, nur mal ganz kurz, wir haben eine Sprache, die nennt sich C<unk>.
Wir haben eine Sprache, die nennt sich F Sharp.
Und Co-Array Fortran wurde ehemals F-genannt.
Ist das dein Ernst?
Also, sorry, wie kann man, gut, 1990, als das rauskam, gab es noch kein Google.
Alter Wissler oder weiß ich nicht oder auch noch gar nichts.
Aber F-C, das ist doch nicht deren Ernst.
Darum hast du es ja echt geändert.
Ja.
Wusste ich ehrlich gesagt auch noch nicht.
Heute ist es, wie gesagt, einfach Teil des Standards.
Ist auch oft so passiert, dass das erst die Compiler-Entwickler und in den 60er Jahren gab es da auch wirklich, jeder hatte seine eigene Hardware, jeder verkaufte oder hat dann den Compiler dazu verkauft.
Das heißt, wenn ich damals im High-Performance-Computing-Bereich was verkaufen wollte, Hardware verkaufen wollte, dann musste ich den Compiler dann dazu geben.
Und dann haben die Hersteller auch versucht, sich über bessere Features in Fortran zu unterscheiden.
Und eine so eine Möglichkeit oder eine so eine Unterscheidung war dann eben Co-Array Fortran.
Ich weiß nicht wer, aber irgendeiner der Hersteller hat dann gesagt, okay, auf meinem System habt ihr jetzt dieses neue Feature, also kauft die Hardware, dann kriegt ihr den Compiler dazu und danach wurde das dann standardisiert.
Also, das war dann oft so, die Hersteller haben sich überlegt, wie soll sich die Sprache entwickeln?
Dann haben sich alle zusammengesetzt und haben gesagt, okay, die und die Syntax, die und die Semantik übernehmen wir und nennen das jetzt, keine Ahnung, Fortran 95.
Jetzt hast du schon ein bisschen aufgezeigt, dass das vor allem für die parallelen Systeme natürlich sehr angenehm ist oder ein paar Features zumindest diesbezüglich gibt.
Jetzt hast du aber auch erwähnt, du verwendest sonst Python sehr stark.
Die Ober-Index Nummer 1 übrigens, by the way.
Und zwar viel, viel weiter oben, irgendwie so 20 Prozent, all der anderen Sprachen haben sie irgendwie 3% oder so irgendwas.
Also scheint sehr hip zu sein, dieses Spython.
Hab schon mal davon gehört.
Aber wann verwendest du jetzt Python und wann verwendest du fortan?
Und warum verwendest du nicht nur Python?
Oder wie entscheidest du das?
Oder ist es dann, ob du bei altem Zeug herumschraubst oder bei neuem?
Ja, also es ist relativ häufig so im technisch-wissenschaftlichen Rechnen, dass man zuerst seine Simulation aufsetzt.
Also ich definiere Randbedingungen, Anfangsbedingungen, eine Geometrie, irgendwelche numerischen Inputwerte für ein Materialverhalten.
Dann führe ich die Simulation durch und dann habe ich eine große Menge Daten, keine Ahnung, mehrere Gigabyte oder sowas.
Und dann muss ich die analysieren.
Und die traditionelle Auftrennung ist, dass man die Vorbereitung nicht in Fortran macht.
Da ist Performance nicht so wichtig, aber Ease of Use, so etwas wie, was wir eben besprochen haben, Listen oder Dictionaries, um Daten zusammenzuführen, brauche ich da eben, um effektiv zu arbeiten.
Dann führe ich meine Simulation aus und da ist dann Performance mein Hauptkriterium.
Und dann habe ich wieder meine Daten.
Und da brauche ich eigentlich auch oft eine Flexibilität, um die dann zu untersuchen, um Statistiken zu bilden, Daten zu visualisieren, Plotten und so weiter.
Und das ist bei mir und bei vielen dann so die typische Aufteilung, zu sagen, okay, die Simulation selbst läuft auch fortrang und das Pre- und Post-Processing läuft in Python oder vielleicht auch MATLAB, eben in einer Sprache, die, oder R für Statistik, in einer Sprache, die eben darauf abzielt, den Benutzer viel Komfort in der Regel auf Kosten der Performance zu geben.
Und dieses Problem und ein Problem deshalb, weil man eben zwei Sprachen gleichzeitig beherrschen muss, zumindest wenn man wirklich sowohl die Simulation Software entwickelt, als auch Simulation ausführt.
Das wurde dann so ein bisschen von Julia, Julia Lang von der neuen Programmiersprache gekoint als Tool-Language Dilemma.
Und Julia ist eben angetreten, um zu sagen, wir haben eine Sprache, die ist einfach zu benutzen, unschnell.
Julia basiert auch auf LLVM.
Also, ich glaube, da der Einfluss von dieser Compiler-Infrastruktur ist einfach riesig.
Es gibt ein ähnliches Projekt, Mojo, was eine Python-ähnliche Syntax mit mehr Type ins und LLVM-basiert macht.
Aber das sind so im Moment die Entwicklungen, die weg von Fortran führen, weil Fortran es eigentlich immer noch notwendig macht, zwei Sprachen zu beherrschen.
Und ich glaube, da ist auch der Unterschied zu C<unk> nicht so groß.
Also es gibt schon auch den Trend, dass neue numerische Software in C<unk> geschrieben wird, nicht mehr in Fortran.
Die Gründe kann man vielleicht auch gleich ein bisschen drüber nachdenken, ist mir auch nicht so ganz klar, was da wirklich der Grund ist.
Aber auch wenn ich jetzt mein Computation-Kernel oder meine Hauptsimulation in C<unk> schreibe, gibt es immer noch niemanden, der die Datenvorbereitung und Nachbereitung in C<unk> macht.
Das heißt, da ist meiner Meinung nach C<unk> wirklich dann ein Ersatz für Fortran, wohingegen sowas wie Mojo oder Julia wirklich dahin abzielt, zu sagen, wir machen das ganze Ökosystem besser.
Jetzt hast du ein paar Mal LLVM erwähnt.
Kannst du das kurz erklären für alle, die jetzt nicht so in dem ganzen Sprachenkosmos drin sind?
Ja, LLVM ist eine Compiler-Infrastruktur, Compiler-Toolkit, ich weiß nicht, wie sie sich selbst bezeichnen.
Das gibt es, glaube ich, seit so ungefähr 25 Jahren, 2000, wurde es entwickelt.
Der Compiler auf Maps ist basiert auf LLVM.
Ich bin kein Compiler-Entwickler, aber es ist eben ein Toolkit, wo ich relativ einfach sagen kann, okay, du interpretierst den Quellcode so und dann hat es eben die Backends, um daraus schnellen Maschinencode für verschiedene Architekturen zu erzeugen.
Das heißt, Fortran ist dann irgendwann oder der Hauptcompiler ist dann irgendwann umgestiegen, einfach auf LLVM.
Bei Fortran ist es ein bisschen anders.
Fortran ist ja eine Sprache, die, wie ich eben gesagt habe, standardisiert wird.
Also das ist ein ISO-Standard.
C<unk> und C sind es auch.
Python zum Beispiel nicht, RustGo auch nicht.
Das sind mehr Sprachen, die entwickelt werden mit einer Referenzimplementierung.
Also bei Python weiß ich es ein bisschen besser.
Da gibt es auch noch zwei, drei alternative Implementierungen, aber die werden praktisch nicht benutzt.
Bei Rust gibt es den Rust-Compiler, der basiert auch auf LLVM oder LLVM, je nachdem, wie man es ausspricht.
Es gibt jetzt einen im GNU-Compiler, also in der GNU Compiler Collection gibt es auch einen Rust-Compiler, aber im Endeffekt ist es so, die Sprache stark mit dem Compiler verheiratet, würde ich mal sagen.
Bei Fortran ist es anders.
Es gibt eine Reihe verschiedener Compiler, unter anderem auch den meistgebrauchten im Open Source-Umfeld, GFOTran, der zur GNU Compiler Collection gehört.
Und dann gibt es eine Reihe von Compilern, die auch auf LLVM basieren.
Intel zum Beispiel, bei denen war das natürlich auch Teil des Geschäftsmodells.
Wenn ich High-Performance Computing-Hardware verkaufe, dann brauche ich auch einen guten Compiler, weil es nützt ja nichts, wenn ich den Leuten erzähle, ihr habt so und so viel Exaflops, aber der Compiler kann die nicht ansprechen.
Und Intel ist vor drei oder vier Jahren, haben die auch ihr Backend.
Vorher hatten sie irgendwas selbst geschriebenes auf LLVM umgestellt.
Ich frage mich gerade, weil du dieses zwei Sprachendilemma erwähnt hast und dass Julia anscheinend angetreten ist, um dieses Problem zu lösen, ob Fortran Teil des Problems oder Teil der Lösung hier ist.
Weil warum wird Fortran dennoch genutzt?
Also wenn es dieses Dilemma gibt, sind andere Sprachen so, schlecht, möchte ich nicht sagen.
Nicht so gut in der mathematischen Berechnung in Kombination mit der Geschwindigkeit.
Oder ist Julia noch nicht da, wo es verspricht zu sein, um Fortran abzulösen?
Oder ist Python, weil du nutzt es zur Vor- und Nachbereitung, vielleicht auf Basis seiner skriptähnlichen Ausführung noch zu langsam für wirklich parallele Execution of High Performance?
Also kannst du da vielleicht was zu sagen?
Ich würde sagen, Fortran könnte Teil der Lösung sein.
Dazu müsste es sich aus meiner Sicht aber schneller modernisieren.
Also, wenn sich jetzt die letzten Standards anguckt, persönlich ist es für mich eher eine Enttäuschung.
Da wurden viele Sachen eher an kosmetischer Natur geändert.
Da denke ich, wenn Fortran so weitermacht, ich meine, oft gesagt, Legacy verdientes Geld, vielleicht wird es noch zehn Jahre lang Geld verdienen oder 15 Jahre.
Aber auch hier in Löwen, ich unterrichte in einem Programm, in einem Master, der heißt Mathematical Engineering, da gibt es jetzt seit zwei oder drei Jahren kein Fortran mehr.
Also da sehe ich schon einfach auch für Fortran als Sprache die Bedrohung, dass es sich nicht schnell genug entwickelt.
Was unterrichtest du dann dort?
Also in dem Kurs unterrichte ich mit einem Kollegen zusammen Parallel Computing.
Also da geht es wirklich darum, wie kann ich Algorithmen entwickeln, die dann auf hauptsächlich Distributed Memory laufen, also Eigenwertberechnung, wie kann ich das auf High-Performance-Computing-Systemen ausführen.
Wie muss da die Kommunikationsstruktur sein, um effiziente Algorithmen zu haben?
Und ja, vielleicht ein bisschen ausholen.
Das Problem bei heutigen High Performance Computing ist eigentlich nicht die Geschwindigkeit der CPUs.
Heutige CPUs sind unglaublich schnell.
Ich meine, wir sprechen über Exascale Computing, das heißt, es sind irgendwie so etwas wie 10 hoch 18 Flops.
Das ist unglaublich krass.
Was heute das Problem ist, wie kriege ich die Daten an den Prozessor.
Und der Term dazu ist Memory Bound.
Das heißt, die Frage ist, wie schaffe ich es, dass die CPU einfach ausgelastet ist.
Und ehrlich gesagt schaffen wir es einfach nicht.
Das heißt, diese Peak Performance, die in der Top 500 Liste mit den schnellsten Rechnern steht, die wird einfach nicht erreicht, weil die Daten sind nicht da.
Also dieser ganze Fokus im traditionellen High Performance Computing auf Flops ist so ein bisschen Marketing.
Am Freitag war hier eine Vorlesung von einem neuen Kollegen von mir, der Zahlen genannt.
Normalerweise ist die Auslastung, wenn man das so betrachtet, im Bereich von 2%.
Das heißt, eigentlich wartet man nur auf die Daten.
Das ist absolut absurd.
Und das ist, glaube ich, dann ja im High Performance Computing so die große Herausforderung.
Und da tut sich Fortran dann noch ganz gut.
Zurück zur Frage, was ich unterrichte, also eben einmal Parallel Computing und dann ein Kurs, ein Projektkurs, wo es darum geht, dass Studenten in einer kleinen Gruppe ein kleines Problem lösen.
Und da war es eben vor ein paar Jahren eigentlich immer so: 30 Prozent, 40 Prozent haben vielleicht Fortran gewählt, die anderen Clos.
Und seitdem jetzt in den vorherigen Kursen eben kein Fortran mehr gelehrt wird, ist es eigentlich so, dass alle C<unk> verwenden.
Aber das heißt, ihr setzt dann auch auf C<unk>.
Also ihr unterrichtet C<unk> oder kommt dann auch sowas wie Julia und so weiter dazu?
Oder was ist mit Rust, Hippe-Technologie, die alles kannst in Richtung?
Also in dem Kurs sagen wir, es soll eine kompilierte Sprache sein, deshalb fällt Julia eben raus.
Das ist ja eine interpretierte Sprache wie Python.
Ich persönlich unterricht es nicht, aber es gibt sicherlich auch Doktoranden hier, die Julia verwenden.
Das ist auf jeden Fall eine gute Alternative.
Rust, ja, ich habe es mir mal angeschaut, dem merkt man aber eigentlich an, dass es keine Sprache ist, die gut sein will in Mathematik.
Das ist ein Ersatz für C, nicht für Fortran.
Natürlich kann man es auch machen.
Das hat ja auch irgendwelche Arten von Vektordatentypen und es gibt auch Bindings sicherlich zu anderen Libraries.
Aber Rust selbst, ja, ich sehe es einfach nicht als die Sprache, die besonders gut da drin ist, mathematische Ideen auszudrücken.
Jetzt hast du immer C<unk> erwähnt, wenn wir jetzt schon bei den Sprachen sind, C gibt es gar nicht oder wird C auch gemacht?
Eigentlich relativ wenig.
Ich bin neben dem eigentlichen, neben der eigentlichen Software, die ich sozusagen mit meinen Kollegen entwickle für ein Teil von Materialwissenschaften bin ich auch aktiv in der Entwicklung von einem relativ generellen Paket für numerische Berechnung.
Das ist Petsy, Portable, Extendable Toolkit for Scientific Computation oder sowas.
Und da wird in der Tat C benutzt.
Der Grund war, das ist auch ein bisschen ältere Software, das Sie damals gesagt haben, und von damals reden wir auch so über 30 Jahre, dass sie da mit der Qualität von C<unk>-Compilern noch nicht zufrieden waren.
Aber generell sehe ich im direkten Ersatz für Fortran, denke ich, ist es wirklich hauptsächlich C<unk>.
C mit dem ganzen Speichermanagement, mit der doch sehr systemorientierten Programmierung passt eigentlich nicht in diese Domain-Specific Language for Scientific Computing.
Man kann es natürlich machen, insbesondere wenn man ein guter C-Programmierer ist.
Aber der Punkt ist einfach so, ich habe meine Domäne ist ja hauptsächlich Materialwissenschaften.
Das heißt, ich habe Studenten, Doktoranden, die haben ein Einführungskurs in Programmierung gehabt.
Das sind aber keine Softwareentwickler.
Und denen will man eigentlich auch keine Sprache an die Hand geben, wo sie sich mit Pointern in die Füße schießen können.
Wir brauchen keine Pointer oder Low-Level-Memory-Zugriff, nur um ein paar Matrizen zu multiplizieren.
Das passt nicht so richtig zusammen.
Aber du hast ja jetzt gesagt, eher unterrichtet kein V dran mehr, sondern C<unk>.
Das ist ja eigentlich die komplexere Sprache.
Also ihr habt euch ja dann entschieden, den Leuten zu helfen, ins Knie zu schießen, oder?
Das würde ich so nicht sehen.
Also modernes C<unk> kann man ja auch ohne Pointer weitgehend machen.
C<unk> ist für mich auch so eine irgendwie merkwürdige Sprache.
Vielleicht ist es so ein bisschen, warum sie so populär ist wie bei der Hardware.
Also wir hatten ja eben, oder ich hatte ja eben gesagt, ursprünglich fortran auf Computern für numerische Berechnungen.
Das heißt, ich habe eine Hardware, ich will die Hardware verkaufen mit dem Ziel, darauf numerische Berechnungen durchzuführen.
Das gibt es heute nicht mehr.
Das hat sich dann in die Richtung entwickelt.
Seit 20, 30 Jahren, 1994, glaube ich, gab es den ersten Cluster bei der NASA, der berühmte Bio-World-Cluster, wo jemand gesagt hat, wir kaufen keine teure spezielle Hardware mehr für unser High-Performance Computing.
Wir kaufen uns einfach so viel wie möglich billige X86 und schließen die aneinander.
Das ist die Idee von einem Cluster.
Ich kaufe billige Hardware und einfach viel davon.
Und das hat sich so durchgesetzt, dass heute alle Rechner im Bereich High Performance Computing, alle Cluster basieren auf diesem Prinzip.
Und ich glaube, bei C<unk> ist, es ein bisschen ähnlich.
Einfach dadurch, dass die Sprache so allgemein ist, wird sie natürlich von vielen verschiedenen Gruppen weiterentwickelt und auch Compiler werden angeboten.
Es gibt ja einen Microsoft-Compiler für C<unk>, es gibt einen Intel-Compiler für C<unk>, es gibt natürlich einen GNU-Compiler für Clus.
Und ich glaube, da ist es wirklich so ein Economy of Scale.
Wenn ich C<unk> mache oder wenn ich irgendwas für C<unk> entwickle, dann habe ich einfach eine viel größere Kundschaft, einen größeren Markt als für Fortran.
Genauso wie es bei der Hardware ist.
Und deshalb ist es auch für Studenten natürlich sinnvoller zu sagen, ich lerne C, dann kann ich nachher überall arbeiten.
Wenn ich mich jetzt auf Fortran spezialisiere, dann gehe ich natürlich schon in die Nische.
Meine Frage ist eigentlich, wenn du sagst, die CPU-Geschwindigkeit ist nicht mehr der Bottleneck, sondern eigentlich der Datenfluss zur CPU.
Inwieweit springt die, oder inwieweit spielt die Programmiersprache, die Performance der Programmiersprache denn eigentlich noch eine Rolle, wenn wir sowieso von einer Auslassung von zwei Prozent reden.
Also sind zum Ist ist zum Beispiel Python so langsam, dass wir dann auf die CPU warten würden, anstatt auf die Daten.
Das ist, glaube ich, meine Frage.
Das kann ich so direkt nicht beantworten, hängt natürlich wahrscheinlich von vielen Dingen ab.
Aber eine Sache ist natürlich normalerweise, wenn ich sage, der Speicherzugriff, Details des Speicherzugriffs spielen eine große Rolle.
Das spricht ja eigentlich dafür, dass ich mein Code lieber in C schreibe, wo ich viel Kontrolle habe, oder sogar einen Assembler.
Und es gibt durchaus auch Kernel für numerische Libraries, die werden in Assembler geschrieben.
Das Problem ist dann natürlich, erstmal, ich muss Assembler können, wieder nicht unbedingt die Domäne von den Leuten, die ich einstelle.
Und zweitens, eigentlich muss ich das für jede Hardware neu schreiben.
Das heißt, ich muss wirklich hingehen und sagen, Cache Size L2 ist das, dann mache ich diese Block Size und so weiter.
Das heißt, ich habe einen riesen Aufwand, um dann eben für den Spezialfall, von dem ich vielleicht gar nicht weiß, wann er eintritt, genau dann die optimale Performance zu haben.
Und da ist fortan oder High-Level-Sprachen natürlich anders, weil da soll ich mehr Intention ausdrücken und dann hoffen, dass der Compiler das macht oder dass der Compiler das schnell macht.
Wieder LLVM, das ist offensichtlich sehr gut da drin.
Ein Beispiel, wo ich denke, dass das Fortran das richtig macht, auf einem hohen Abstraktionslevel, sind sogenannte Elemental Functions.
Das sind Funktionen, die schreibe ich einmal für einen Skalar und kann die dann aber auch für Vektoren oder Matrizen verwenden.
Also so etwas wie eine Addition.
Wenn ich in Fortran schreibe, 1 plus 1, dann kommt 2 raus.
Das ist zumindest meine Hoffnung.
Wenn ich jetzt aber einen Vektor habe, wo vorne drin steht 1,2 plus zweiter Vektor 2, 1, dann soll ein Vektor von der Länge 3,3 rauskommen.
Jetzt kann ich natürlich eine Schleife aufmachen und schreiben, okay, wir schreiben eine Schleife über den Vektor, dann machen wir das.
In Fortran kann ich einfach sagen, ich def, ich definiere eine Funktion für den Skalar und kann dann Vektorargumente reingeben.
Wenn der Compiler das richtig macht, kann er dafür den schnellsten Code raussuchen.
Und vielleicht ganz ganz zum Anfang von unserer Diskussion, wenn ich jetzt zwei Sprachen habe und eine davon ist Row Major und die andere Column Major, dann ist natürlich die Frage, in welcher Reihenfolge ich die Schleifen schreibe, ist Performance entscheidend, weil entweder habe ich guten Memory Access konsekutiv oder nicht.
Wenn ich das jetzt aber einfach so abstrakt hinschreibe und sage, okay, ist mir doch egal, mach's einfach schnell, dann habe ich genau diesen Weg, den ich eigentlich für die Art von Programmierung haben möchte, die wir machen.
Jetzt haben wir natürlich ein bisschen über Assembler gesprochen und Fortran und auch C<unk>.
Und da frage ich mich auch, wenn ich jetzt Student wäre oder ich wäre bei dir Doktorand oder ähnliches.
Bekommt man heutzutage überhaupt noch Leute auf die Sprache Fortran umgeboardet?
Ich meine, klar, sie entwickelt sich weiter und so.
Ich verstehe das.
Und du hast ja aber auch schon gesagt, bei anderen alternativen Sprachen wie Julia oder C und so weiter, hat man vielleicht eine höhere oder eine einfachere Zugänglichkeit.
Man kann sich mit Pointern in den Fuß schießen, alles richtig, ja, alles pro und konst.
Aber ich denke da auch so ein bisschen an die Zukunft der Leute, die das jetzt lernen, die da jetzt einsteigen.
Jetzt kann man sagen, okay, Fortran ist seit.
Was war das?
1967 am Start?
Wird ja wahrscheinlich.
Entschuldigung, ich bin immer noch in den 60ern, das tut mir leid.
Jetzt kann man sagen, okay, das ist seit 57 am Start.
Die nächsten 20 Jahre wird es auch noch da sein.
Aber da ist natürlich auch die Frage, Jobmarkttechnisch, wie sieht die Industrie aus?
Ihr seid jetzt in der Forschung, sieht die Industrie genauso aus?
Werden die gleichen Tools genommen in der Industrie wie in der Forschung?
Wie stehst du dazu?
Und ihr habt ja gerade auch gesagt, glaube ich, intern lehrt ihr auch weniger Vortrag.
Also in dem Masterprogramm kommt es eigentlich nicht mehr vor.
Wenn jemand bei mir in der Gruppe als Doktorand arbeitet, ist die Chance relativ hoch, dass er was mit Fortran macht.
Aber ich bin, also erstmal, ich mache Computational Material Science.
Ich bilde keine Programmierer aus.
Das heißt, was die Leute bei mir lernen sollen, sind Konzepte, Materialwissenschaft und das große Ganze.
Wenn die nachher ein Problem haben, C<unk> zu lernen oder Python zu lernen, weil das ihr Arbeitgeber verlangt, dann habe ich versagt.
Ich habe nicht versagt, wenn sie nicht das letzte Detail von Fortran verstehen.
Also, das ist überhaupt nicht der Anspruch in so einer Forschungsgruppe, dass da jemand rauskommt als Fortran-Nerd, der genau die eine Sache kann.
Nee, nee, ich glaube, das ist auch total fair.
Ich glaube, du sollst das richtige Tool nutzen, was euch weiterbringt, was zum Ziel der Forschung beiträgt.
Ich glaube, das ist total fair.
Und ich sag mal so, ich leh mich jetzt aus dem Fenster und sage, wenn man Fortran lernen kann, kann man auch andere Sprachen lernen.
Ich glaube, Leute, die bei heute hier im Feld da unterwegs sind, sind hochintelligent und smart genug, sich das drauf zu karren, besonders mit heutzutagen Tools wie AI und Co.
Aber würdest du dann, wenn ihr da reingrätschen darf, auch kein neues Projekt mal mit Fortran anfangen, mit irgendwelchen Studis?
Also, außer sie wollen jetzt natürlich, aber jetzt, wenn du irgendwie was Neues angehst und da jetzt keine Abhängigkeiten hast, dann klingt es ja eher danach, als würdest du auf was anderes setzen und nicht mehr auf Fortran.
Also ich glaube, die Idee, keine Abhängigkeit zu haben, gibt es nicht.
Die gibt es eben nicht.
Genau.
Also ja, wahrscheinlich ist es schon so, dass es nicht unbedingt Fortran wird.
Ich weiß aber auch nicht, ja, vielleicht bin ich auch einfach penibel.
Es gibt irgendwas, was mich bei jeder Sprache stört.
Da würde ich jetzt nicht irgendwie sagen, ah, okay, das ist mein Traum und wir machen einfach alles in dem.
Aber es gibt halt doch natürlich Abhängigkeiten.
Libraries müssen verfügbar sein.
Das ist eigentlich meistens so, wenn man jetzt wirklich die Wahl hat zwischen C<unk> und Fortran.
Alles, was es für Fortran gibt, gibt es auch für C<unk>.
Also, das wäre dann schon auch okay, C zu nehmen.
Andererseits finde ich, ist C<unk> halt einfach auch eine super komplexe Sprache.
Ich weiß nicht, wie viele Seiten der Standard von C<unk> hat, Fortran hat, 700 oder 600, finde ich auch schon relativ lang.
Das liest sich natürlich auch niemand durch.
Ich befürchte, bei C<unk> ist es nochmal deutlich mehr.
Es ist jetzt auch nicht so, dass ich einfach denke, ja, nimmst du kein Fortran, hast du kein Problem.
So ist es halt leider nicht.
Und Fortran hat sicherlich auch viele Nachteile.
Eins ist so ein bisschen das ganze Tooling, da ist C<unk> doch besser, wobei ich jetzt auch nicht so ganz überzeugt bin.
Python ist da schon relativ stark und dann auch sowas wie Julia oder Rust einfach vom Tooling her von Unit-Test als Teil des Package Managers oder sowas.
Das Ekosystem ist dann halt doch sehr, sehr wichtig.
Du hast das Ekosystem schon angesprochen.
Kennt man die Leute in der Community oder ist die Community noch so groß, also der Open Source Community und die Leute, die in Fortran-Foren unterwegs sind, dass man sagt: uh, ein neues Gesicht kommt hier gerade hoch.
Also es gibt durchaus immer mal natürlich Leute, die neu dazukommen.
Ich habe es eben erwähnt, es gibt diese Fortran-Discourse-Website.
Da tummeln sich natürlich auch viele Leute, mit denen man dann doch schon mal irgendeine Art von Interaktion hatte, meistens, weil sie auf irgendeinem Post von mir eine gute Antwort hatten.
In dem Forum sind auch einige Leute aus dem Standard-Komitee aktiv.
Also es gibt jemanden von Intel, von LLWM, Flang, die sind da aktiv, die erklären dann sagen, okay, wir haben das so verstanden, deshalb glauben wir, das ist ein Compiler-Bug oder wir glauben, der Code ist invalid.
Die Community da ist schon so, dass ich denke, die Hauptakteure hat man alle oder habe ich alle schon mal irgendwie nicht persönlich gesehen, aber schon mal was von ihnen gelesen oder so.
Was mich auf jeden Fall gefreut hat bei der Recherche zu sehen, dass auch beim Google Summer of Code 2026 wieder Fortran-Projekte zumindest nicht selektiert, aber beworben werden.
Also ich habe jetzt hier gerade zum Beispiel eine Seite vom GCC-Compiler auf und der GCC-Compiler kriegt immer ein relativ großen Stake im Google Summer of Code und auch der GCC-Compiler hat zwei Projekte zu der Unterstützung von Fortran im GCC-Compiler wieder drin.
Das freut mich natürlich schon sehr, weil das, da sieht man dann schon.
Okay, also GCC möchte jetzt die Features von Fortran 218 und von Fortran 220 Plus implementieren.
Das ist natürlich schon schön zu sehen, dass da immer noch nach einer solch langen Zeit eine aktive Entwicklung stattfindet und anscheinend dann auch sich Leute finden, Studenten in diesem Falle, das zu implementieren, weil das sind alles keine kleinen Projekte, die werden hier mit 175 Stunden oder 350 Stunden veranschlagt.
Das ist für Google Summer of Code-Projekt aber schon richtig groß.
Also ich glaube, Google Summer of Code gibt es zwei oder drei Kategorien.
Ich habe letztes Jahr auch jemanden hier in Löwen betreut.
Da haben wir die Fortran-Bindings für Petsy, also für diese numerische Bibliothek, modernisiert.
Das gibt es immer mal wieder.
Die Fortranlang.org ist da auch aktiv, die Projekte einzuwerben oder das zu organisieren.
Das muss ja auch irgendwie administrativ organisiert werden, mit den Auszahlungen und mit Ranking von Bewerbungen.
Also das gibt es auf jeden Fall.
Was ich ehrlich gesagt noch erstaunlicher finde, ist eben, dass es zwei neue Fortran-Compiler gibt.
Ich habe es eben erwähnt.
Einmal L Fortran, was auch dann in Jupyter-Notebooks, also interaktiv, so Scripting-mäßig funktionieren soll und auch schon kann.
Und eben Flaggen, wo ARM und Nvidia Geld in die Hand genommen haben und gesagt haben, wir brauchen einfach einen Fortran-Compiler.
Weil anderenfalls können wir unsere Chips nicht verkaufen.
Und das ist, die genauen Zahlen sind mir nicht so, also habe ich nicht ganz im Kopf.
Aber das sind Projekte, die ungefähr vor zehn Jahren gestartet sind und jetzt sind beide eigentlich so weit, dass man sie benutzen kann.
Würdest du aus deiner Beobachtung sagen, dass die Fortran-Community wächst?
Ich glaube, sie ist durch das Fortran-Discours und die Website und was auch relativ neu ist und dann gekommen ist, ist ein Fortran-Package Manager.
Also, dass ich sowas wie Pip mit Python oder Cargo mit Rust meine Pakete und Abhängigkeiten einfach installieren kann.
Ich glaube, sie ist sichtbarer geworden, gerade auch im Vergleich zu Mailinglisten.
Ich benutze eigentlich gerne Mailinglisten, aber ich glaube, für viele Leute, die jünger sind, ist es so ein bisschen abschreckend.
Ich glaube, sie ist sichtbarer geworden in den letzten zehn Jahren.
Und wahrscheinlich ist das auch der Grund für die gute oder den relativ gute Ranking auf Tube.
Was ich unglücklich finde, weil ich eine PHP-Background habe, ist, dass der Fortran-Package Manager FPM genannt wird.
Und wer schon mal PHP auf Nginx betrieben hat, kommt um PHP-FPM nicht drumherum.
Das kann man natürlich jetzt in deinen Topf werfen und dann hat man den PHP Fortran-Package Manager.
Naming is hard.
Ja, vor allem, wenn man nur drei Buchstaben verwenden.
Martin, wir könnten, glaube ich, noch ewig über die Sprache von 1957 sprechen.
Lass uns mal zu einem Tipp, den du unseren Hörerinnen und Hörern geben kannst, wechseln.
Und zwar ist die Frage, was sollte man über Fortran verstehen, bevor man es benutzt?
Was würdest du sagen, ist der Number One Tipp?
Also ich habe jetzt am Wochenende Zeit.
Ich habe keinen Supercomputer hier, aber ich habe ein paar Raspberry Pis.
Und die schließe ich in dem Cluster zusammen und da kompiliere ich Fortran drauf, ob das Sinn macht oder nicht, sei mal dahingestellt.
Was sagst du mir, Andi?
Liest dir erst das durch, versteh das erst, bevor du daran gehst, sonst kriegst du nämlich graue Haare.
Also ich glaube, meine Message wäre, fokussiert direkt auf Modern Fortran, also alles, was nach 1990.
Dieses Fixed Format mit den ersten sechs Spalten sind Kommentare.
Das ist wirklich nicht mehr State of the Art.
Versuch einfach Fortran so zu schreiben, dass es dem entspricht oder dass es die Möglichkeiten von den neuen Features nutzt.
Das wäre meine Nachricht.
Und verbunden damit ist es einfach so, es gibt viel mehr alten Code, den man von mir aus gerne verwenden soll, aber bitte nicht als Beispiel.
Also ja, ich habe eben LAPAC erwähnt, das Linear-Algebra-Package.
LAPAC hat unglaublich viele Routinen, Eigenwerte, Matrix-Multiplikation, Gleichungssysteme lösen, alles Mögliche.
Wurde in Fortran 77 geschrieben.
Und die Namenskonventionen sind super rigide.
Unter anderem wahrscheinlich, weil man damals nicht keine langen Namen verwenden konnte.
Das, wenn sich die erste Buchstabe sagt, ist es real, dann steht da ein S.
Ist es Double, dann steht da ein D, dann kommt der Matrix-Typ, was weiß ich, Diagonal Di, dann die Berechnung.
Man hat also immer sechs Buchstabenkombinationen, die irgendwie sich so aussprechen wie Drucks.
Das kann man natürlich machen.
Und 1980 war das vielleicht auch so, weil der Speicher klein war oder nur so und so viele Ziffern auf die Lochkarte gepasst haben.
Fragt mich nicht.
Aber wenn ich heute eine Eigenwertroutine schreibe, dann nenne ich die einfach Eigenvalues und dann versteht auch jeder, was es ist.
Also da, man kann ja auch mit Fortran mit der Zeit gehen.
Also ich sag mal so, für mich klingt das nach einer Opinionated Programmiersprache Framework.
Also alles super.
Also Ruby on Rails und wie sie alle heißen heutzutage sind ja auch Opinionated und heutzutage argumentiert man, Opinionated ist eine Stärke.
Aber ich musste gerade stark grinsen.
Du sagst es, konzentriere dich auf alles Neueres als 1990.
Ich hoffe, dass die Anzahl der oder die meisten Hörerinnen und Hörern hier überhaupt schon so alt sind.
Aber nutzt das überlassen wir den Hörerinnen und Hörern.
Martin, vielen lieben Dank.
Wo kann man deine Arbeit verfolgen?
Wo kann ich, wenn ich sagen möchte, Materialwissenschaften, das ist der Spot, da wo ich hin möchte.
Wo kann man an deine Tür anklopfen und bei dir mitforschen, wenn man da sich auf eine Doktorstelle bewerben kann und sollte.
Jetzt bin ich raus aus der Wirtschaft.
Ich weiß nicht, wie das ist.
Ich habe noch nie einen Doktor gemacht.
Laut Wolfgangs Professor oder Doktorvater habe ich einen Bachelor und bin deswegen Studienabbrecher.
Deswegen bin ich da raus.
Also die meisten Wissenschaftler haben ein Google Scholar-Profil.
Das ist natürlich mehr für Leute, die schon in der Thematik drin sind.
Einfach schauen, was ich gemacht habe.
Ich habe eine persönliche Website martin-spiel.net.
Am einfachsten ist es wahrscheinlich, eine E-Mail zu schreiben.
Martin Dial, Löwen googeln.
Funktioniert eigentlich auch ganz gut.
Und sonst findet man dich auf der Fortran-Mailing-Liste, oder?
Auf der Mailingliste habe ich ehrlich gesagt noch nie was geschrieben.
Aber im Fortran Diskurs, ich müsste die URL raussuchen.
Ich kann ja alles noch in den Shownotes packen.
Gar kein Problem.
Ich wollte schon sagen, haben wir alles in den Shownotes, gar kein Problem.
Da haben wir auch Links zu deiner Homepage, zu deinem LinkedIn-Profil, zu deinem Gitter-Profil, zu deinem Scholar-Profil.
Aber natürlich auch zu den ganzen Paketen, die wir genannt haben: SciPy, NumPy, Julia, LLVM, Pets, C, Pet, F-Lang, dem Fortran Package Manager und so weiter und so fort.
Martin, vielen lieben Dank.
Es ist unglaublich interessant, mal zu wissen, also Fortran habe ich immer mal wieder gehört, aber mich nie beschäftigt.
Ich habe auf jeden Fall das Gefühl, ich kam klüger aus dieser Podcast-Episode raus, als ich reingegangen bin.
Und das freut mich sehr.
Zu meinem oder deinem Leid, ich weiß es nicht, muss ich sagen, ich habe nicht so viele Matrizenkalkulationen, die ich machen muss.
Ich habe auch noch keinen 3D-Drucker, als dass ich Simulationen für Materialwissenschaften hier durchführen muss.
Aber wenn doch, dann schreibe ich das mal, glaube ich, in Vortrag.
Es hat mich auf jeden Fall gefreut, über eine Sprache zu sprechen, die älter ist als Andi und ich zusammen und aber trotzdem am Dioba-Index vor BHB und Go liegt.
Das ist immer schön zu sehen.
Moment mal, stopp.
Älter als wir beide zusammen 57, nie im Leben.
Das ist ja seit 53 entwickelt worden.
69.
Ich bin 38, Wolfgang.
Du bist älter als ich, da passt was nicht.
Ja, knapp.
Die Tails, die da ist.
Hat die LLM ausgerechnet, ne?
Genau.
Okay.
Martin, vielen lieben Dank für deine Zeit.
Vielen lieben Dank für all die ganzen Insights.
Ich sehe Fortran jetzt mit anderen Augen, mit positiveren Augen.
Allein auch wegen dem Tioba-Index.
Ich habe mir noch nie den Tobi-Index so detailliert angesehen, dass ich Fortran auf Platz 12 gesehen habe.
Aber nur gut.
Aber ich habe auch festgestellt, es ist der monatliche Platz 12.
Es ist nicht die Jahresliste.
Und die monatliche Liste wird anders zusammengesteckt als die Jahresliste.
Da muss man vielleicht mal differenzieren.
Naja.
Danke, Martin.
Ja, danke euch.
Und wenn ihr Feedback zu dieser Folge habt oder auch zu der Arbeit von Martin, kommt doch ruhig in unseren Discord.
Lasst uns ein bisschen Feedback da.
Wir leiten natürlich alles sehr gerne an Martin weiter.
Ansonsten lasst uns auch mal wissen, wie euch dieses Programmiersprachenformat gefallen hat.
Das war die erste Episode.
Ob wir, also wir versprechen immer, wir starten immer ein neues Format und dann machen wir zwei Episoden.
Und dann braucht das etwas bis zur dritten Episode.
Sagen wir es mal so.
Ansonsten würde ich sagen, vielen Dank, wir hören uns nächste Woche und tschüss.
Danke.
Tschüss.
Ciao.