Florian Mücke im Netz

An agile journey and beyond

Autor: Florian Mücke (Seite 1 von 3)

Real Programmers Do AI in FORTRAN

„Real Programmers Do AI in FORTRAN“ — Four Decades Later

Februar 21, 2026 /

Browsing old files last week, I found a quote from 1983 that stopped me for a moment:

“Real Programmers do Artificial Intelligence programs in FORTRAN.”

Forty-three years later, that joke hits differently.

At the time, it was satire. AI meant symbolic systems and Lisp machines. FORTRAN meant numerical computing. Claiming that “real programmers” would write AI in FORTRAN was deliberately absurd — a jab at macho developer culture and language tribalism.

But reading it today, in the age of GPT, Claude, and Gemini, it feels less like a joke about AI and more like a timeless observation about us.

The war never ends — it just rebrands

The original satire nailed something enduring:
developers will always form factions around tools.

Back then it was:

  • Lisp vs. Prolog
  • C vs. Pascal
  • “Structured programming” vs. “real programming”

Today it’s:

  • GPT vs. Claude vs. Gemini
  • Copilot vs. Claude Code
  • Rust vs. Go
  • VS Code vs. JetBrains

The pattern is unchanged:

  1. Pick a tool.
  2. Attach identity.
  3. Defend it with the passion of sports fandom.
  4. Declare everyone else unserious.

It’s comforting. It creates a clean story:
If we choose the right tool, we win.

But that’s rarely where the real advantage lies.

Tool choice is rarely the differentiator

Yes, tools matter. Bad tools slow you down. Good tools accelerate you.

But most performance gaps between teams are not explained by language or model choice. They’re explained by fundamentals:

  • Do you understand the problem?
  • Do you ship in small increments?
  • Do you measure outcomes?
  • Do you integrate feedback?
  • Do you use tools deliberately instead of ideologically?

Last month we evaluated different AI coding assistants for a team. The debate started as, “Which one is smarter?” Within an hour it became clear that the real question wasn’t intelligence — it was integration. Which one fits our compliance constraints? Which one works with our on-prem repositories? Which one aligns with our security model?

The model comparison was interesting.
The workflow implications were decisive.

That’s usually how these debates end — once you stop performing identity and start optimizing for outcomes.

The FORTRAN irony deserves more credit

Here’s the part that makes the original quote even better with hindsight.

The joke is that the author was accidentally right.

Modern AI does run on FORTRAN’s spiritual descendants. Those BLAS libraries and GPU kernels performing matrix multiplications are much closer to FORTRAN’s numerical computing DNA than to Lisp’s symbolic reasoning roots.

The AI revolution wasn’t won by symbolic purity.
It was won by scalable numerical computation.

The “real programmer” flex completely missed the direction history was about to take.

GPT vs. Claude vs. Gemini: the new FORTRAN vs. Lisp

Today’s debates follow the same pattern:

  • “Claude reasons better.”
  • “GPT writes cleaner code.”
  • “Gemini integrates better with our stack.”

Some of that is true in specific contexts. But the winning move isn’t picking a champion. It’s building a system of work.

High-performing teams don’t just “use AI.” They:

  • Define where it reduces cycle time
  • Establish review and validation loops
  • Understand its failure modes
  • Measure impact

Model choice matters.
Workflow design matters more.

Assembly taught me something about this

Here’s what changed my perspective on abstraction layers.

In my early twenties I decided life is too short to program in assembly and switched to Java, C++ and C#. That wasn’t lowering standards. It was choosing leverage. I could build more meaningful systems by operating at a higher level of abstraction.

Assembly still exists — in kernels, embedded systems, performance hotspots. But almost nobody builds complete products in it anymore. Not because we forgot how. Because we learned that leverage scales better than heroics.

Today it feels similar.

Life is too short not to use AI when building software.

Not as a crutch. Not as a substitute for thinking.
But as the next layer of abstraction.

We moved from assembly to high-level languages to gain leverage.
Using AI well is simply the next step in that progression.

So yes, “Real Programmers do AI in FORTRAN.”

And in Lisp.
And in Python.
And with GPT, Claude, Gemini — and whatever comes next.

Because real programmers don’t defend tools as identity.

They use leverage.

Larmans Gesetze zum Organisationsverhalten

April 25, 2021 /

(Übersetzung des Artikels von Craig Larman)

Nach jahrzehntelanger Beobachtung und Organisationsberatung, sind hier Larmans Gesetze zum Organisationsverhalten. Es sind allerdings eher Beobachtungen als Gesetze, die man befolgen sollte 😉

1. Organisationen sind implizit darauf optimiert, den Status Quo der mittleren und ersten Führungsebene sowie “ Spezialisten“-Positionen & Machtstrukturen nicht zu verändern.

2. Als logische Folge von (1) wird jede Veränderungsinitiative darauf reduziert, die neue Terminologie so umzudefinieren oder zu überladen, dass sie im Grunde dasselbe bedeutet wie der Status quo.

3. Als logische Folge von (1) wird jede Veränderungsinitiative als „puristisch“, „theoretisch“, „revolutionär“, „religiös“ oder „braucht eine pragmatische Anpassung an örtliche Gegebenheiten“ abgetan – was davon ablenkt, die Schwächen und den Status quo der Manager/Spezialisten anzugehen.

4. Als logische Folge von (1) werden, falls einige Manager oder Einzelspezialisten nach der Anpassung des Changes doch versetzt werden, diese zu „Coaches/Trainern“ für die Veränderung, was häufig (2) und (3) verstärkt.

5. (in großen etablierten Organisationen) folgt die Kultur der Struktur. Und in kleinen, jungen Organisationen folgt die Struktur der Kultur.

Ausführung:

Eine ausführlichere Beschreibung lautet: In großen, bereits etablierten Gruppen folgt die Kultur/das Verhalten/die Denkweise den Veränderungen im Organisationssystem und -design und wird von diesen beeinflusst. Das bedeutet, dass man in großen, etablierten Organisationen mit der Änderung des Organisationssystems (Gruppen, Teams, Rollen und Verantwortlichkeiten, Hierarchien, Karrierepfade, Richtlinien, Bewertungs- und Vergütungssysteme usw.) beginnen muss, wenn man die Kultur wirklich ändern will, weil sie sich sonst nicht wirklich ändert. Anders ausgedrückt: Das Organisationssystem hat einen starken Einfluss auf die Denkweise und das Verhalten.

Dies hat auch der Verfechter des systemischen Denkens John Seddon beobachtet: „Der Versuch, die Kultur einer Organisation zu ändern, ist Torheit, er misslingt immer. Das Verhalten der Menschen (die Kultur) ist ein Produkt des Systems; wenn man das System ändert, ändert sich das Verhalten der Menschen.„

Diese Beobachtung gilt für große etablierte Organisationen; in kleinen Start-ups ist es dagegen umgekehrt: Die Struktur folgt dort ihrer Kultur. Das heißt, das (wahrscheinlich einfache und informelle) Organisationsdesign spiegelt die Denkweise und Kultur der kleinen Anzahl von Mitgliedern im Startup wider. Wenn die Organisation wächst, kehrt sich das in der Regel irgendwann in Kultur folgt Struktur um.

Und „Kultur folgt Struktur“ (in großen Gruppen) ist der Grund, warum reine „Mindset“-Ansätze wie organisatorisches Lernen in großen Gruppen nicht wirklich haftend oder wirkungsvoll sind, und warum Frameworks wie Scrum (die zu Beginn einen starken Fokus auf strukturelle Veränderungen haben) dazu neigen, die Kultur schneller zu beeinflussen – wenn die Konsequenzen der strukturellen Veränderungen von Scrum tatsächlich umgesetzt werden.

Lernen ist nur was für Kinder!

Dezember 26, 2020 /

Von Erwachsenen wird in unserer Gesellschaft erwartet, dass sie Dinge auf anhieb verstehen und in der Lage sind, komplizierte, ja sogar komplexe Sachverhalte nach einer kurzen Erklärung zu verstehen.

Man wird auf Trainings geschickt, im Glauben, man könne Können einimpfen.

Dabei vergessen wir leider oft, dass auch Erwachsen nur Menschen sind und echtes Lernen mit Erfahrung verbunden ist. Diese Erfahrung kommt aber nicht durch stilles Reindenken und nacktes Wissen, sondern erst durch Kontakt mit anderen Individuen und praktisches Erproben in der Umwelt. Es wird erwartet, dass alles auf Anhieb verstanden wird und einmaliger Informationsinput ausreicht.

Weiterlesen

DIY: Lernturm fürs Kind bauen

Januar 5, 2015 / / Keine Kommentare

150103-Lernturm-01

Damit der oder die kleine endlich auch mal in der Küche helfen kann und deswegen nicht mehr quengelnd durch die Küche rennt, gibt es einen speziellen Hochstuhl auf dem das Kind sicher stehen kann. Einen solchen kann man sich ganz leicht selbst bauen – vorausgesetzt man ist nicht völlig ungeschickt.

Nach etwas Betteln seitens meiner Frau, habe ich mich dann doch bereit erklärt einen solchen Stuhl zu bauen – und Spaß hat es auch noch gemacht 🙂

Die sieben Arbeitsschritte habe ich hier zusammengeschrieben… Weiterlesen

Was spricht gegen Exceptions in C++?

September 24, 2011 / / Keine Kommentare

Obwohl es Exceptions im C++ Standard schon etliche Jahre gibt, werden diese in größeren Projekten oft nicht eingesetzt. Im folgenden Artikel möchte ich das Für und Wider erörtern und mit gängigen Vorurteilen aufräumen.

try {
    funktion();
   ...
} catch (const std::invalid_argument& e) {
    std::cerr << "Falsches Argument:"  << e.what() << std::endl;
} catch (const std::range_error& e) {
    std::cerr << "Ungültiger Bereich:" << e.what() << std::endl;
} catch (...) {
    std::cerr << "Sonstiger Fehler" << std::endl;
}

Gängige Vorurteile

  1. Die Behandlung von Ausnahmen ist codeintensiver (mehr Schreibarbeit)
    Falsch. Ein sinnvolles try/catch braucht ist sogar weniger Code als ein sinnvolles if/else if/elsefür alle möglichen Fehlercodes. Fehlercodes werden aber oft nicht vollständig überprüft oder gar ganz weggelassen, was der Qualität des Codes nicht gerade zuträglich ist. Exceptions dagegen zwingen zu einer durchdachten Fehlerbehandlung.
  2. Exceptions machen den Code langsam
    Falsch. Wenn Exceptions richtig eingesetzt werden, sollten sie für Ausnahmen im Programmablauf verwendet werden. Die Ausführungsgeschwindigkeit des "Gut"-Pfades (in dem keine Ausnahmen geworfen werden) leidet nicht darunter. Wenn also die Exception die Ausnahme und nicht die Regel ist, hat man nichts zu befürchten. Weiterlesen

Dateiversion auslesen

September 24, 2011 / / Keine Kommentare 
#pragma comment( lib, "version" )
struct FileVersion
{
	DWORD dwLeftMost;
	DWORD dwSecondLeft;
	DWORD dwSecondRight;
	DWORD dwRightMost;
	bool IsLower( const FileVersion& ver )
	{
		return dwLeftMost < ver.dwLeftMost ? true :
			dwSecondLeft < ver.dwSecondLeft ? true :
			dwSecondRight < ver.dwSecondRight ? true :
			dwRightMost < ver.dwRightMost ? true : false;
	}
};

static void GetFileVersion( const CString& fileNameWithPath, FileVersion& fileVersion )
{
	DWORD dwDummy;
	DWORD dwFVISize = GetFileVersionInfoSize( fileNameWithPath , &dwDummy );
	LPBYTE lpVersionInfo = new BYTE[dwFVISize];
	::GetFileVersionInfo( fileNameWithPath , 0 , dwFVISize , lpVersionInfo );
	UINT uLen;
	VS_FIXEDFILEINFO* lpFfi;
	::VerQueryValue( lpVersionInfo , _T("\\") , (LPVOID *)&lpFfi , &uLen );
	DWORD dwFileVersionMS = lpFfi->dwFileVersionMS;
	DWORD dwFileVersionLS = lpFfi->dwFileVersionLS;
	delete[] lpVersionInfo;
	fileVersion.dwLeftMost = HIWORD(dwFileVersionMS);
	fileVersion.dwSecondLeft = LOWORD(dwFileVersionMS);
	fileVersion.dwSecondRight = HIWORD(dwFileVersionLS);
	fileVersion.dwRightMost = LOWORD(dwFileVersionLS);
}

Stativtest: Bilora gegen Cullmann gegen Vanguard

August 21, 2011 / / Keine Kommentare

Da ich mein jetziges Stativ damals einfach für den Camcorder gekauft hatte und es jetzt meinen wachsenden Ansprüchen für die Fotographie nicht mehr genügt, habe ich mir (nach Lektüre diverser Tests) zwei potentielle Nachfolger mit Kugelköpfen zum Vergleich bestellt:

« Ältere Beiträge

© 2026 Florian Mücke im Netz

Theme von Anders Norén — Hoch ↑