Die Turing-Award-Vorlesung ist normalerweise scheiße. Formal, banal, sicher. Außer wenn die CS-Giganten beschließen, das Drehbuch zu brechen. John Backus nutzte seine, um die funktionale Programmierung zu starten. Ken Thompson warnte uns, dass unsere Compiler uns möglicherweise anlügen. Edsger Dijkstra forderte uns auf, vor unserem eigenen Gehirn bescheiden zu sein.
Kenneth Iverson hat etwas anderes gemacht.
1979 gab er uns „Notation as a Tool Thought“. Er argumentierte, dass die Art und Weise, wie wir Code schreiben, unser Denken verändert. Eine gute Notation befreit das Gehirn von unnötiger Arbeit. Iverson hat dafür APL entwickelt. APL sieht gruselig aus, voller Symbole, die wie griechische Buchstaben auf Säure aussehen. Aber es ermöglichte Mathematikern, in Gleichungen und nicht in Schleifen zu denken. Keine Übersetzung von Kopfrechnen mehr in ungeschicktes Fortran. Es hat funktioniert. Es wurde nicht überall übernommen. Es spielte keine Rolle. Es hat gezeigt, dass aus zwei Sprachen eine werden kann.
Jetzt, sechzig Jahre später, haben wir das Zweisprachenproblem.
Python-Regeln. Jeder liebt es. Es ist der Freund auf der Party, der dir alles erzählt, aber furchtbar fährt. Python ist langsam. Brutal. Verteidiger winken mit den Händen. Es hilft nicht.
Forscher erstellen Prototypen in Python, weil es benutzerfreundlich ist. Wenn es dann auf die Leistung ankommt, schreiben sie kritische Abschnitte in C++ oder Rust neu. Das machen sie zweimal. KI-Programmierungsagenten können das Problem nicht beheben. Die Optimierung hat einen Boden. Ist der Boden langsam, steht das Gebäude langsam.
Denken Sie an den Bau. Holz ist leicht zu schneiden. Sie können einen Schuppen an einem Samstag zusammennageln. Stahl ist schwer zu bearbeiten. Aber Wolkenkratzer baut man nicht mit der Säge. Was wäre, wenn Sie Holz hätten, das so stark wäre wie Stahl? Oder eine ergonomische Sprache wie Python, aber schnell wie C?
Wir sind gierig.
Vier Informatiker haben diese Worte im Jahr 2012 geschrieben. Sie waren Matlab-Benutzer. Lisp-Hacker. Pythonisten. Rubyisten. Perl-Junkies. Sie hassten es, dass jedes Werkzeug, das sie liebten, für etwas perfekt und für etwas anderes schrecklich war. Sie wollten alles. Open Source. Einfach für Anfänger. Leistungsstark genug für die härtesten Hacker. Sie nannten es Julia.
Ich habe Julia 2017 kennengelernt. Es war ein Zufall. Ich habe Sebastian Seung zugehört, einem Neurowissenschaftler, der Gehirnkonnektome kartiert. Der Name selbst wirkte wie eine Entschuldigung für den Rest des Fachgebiets. Vergessen Sie C++ oder MUMPS. Oder sogar Haskell. Julia war gewinnend. Einfach.
Es wurde auch sorgfältig konstruiert.
Die Macher hatten mit ansehen müssen, wie andere Sprachen scheiterten. Sie nahmen die guten Ideen und ließen das Gepäck zurück. Bis 2026 ist die Julia-Community seltsam erwachsen. Kein Drama. Keine Flammenkriege um die Syntax. Es zieht Wissenschaftler an, nicht nur Programmierer. Sie sind nicht an intellektuellem Spielgeist interessiert. Sie wollen Ergebnisse. Auf der JuliaCon prahlen die Leute damit, MATLAB-Code neu zu schreiben und Benchmarks zur 60-fachen Beschleunigung zu sehen. Manche sagen, zehntausendmal schneller als Python.
Warum ist es also nicht überall?
Warum gefällt Stack Overflow nicht? Warum hat Python gewonnen?
Ökosystem. Python hat Bibliotheken für alles. Sie müssen etwas Unklares tun? Es gibt ein Python-Paket dafür. Julia hat nicht dieses Gewicht.
Firmenmäzenat. Objective-C war Apples Erfolg. Kotlin fuhr mit Google. Julia hat nichts von den Big-Tech-Giganten bekommen. Es ist von alleine gewachsen.
Oder vielleicht ist überhaupt nichts schief gelaufen.
Julia ist eine Nische. Klein. Geliebten. Es betreibt die großen Maschinen am CERN und der NASA. Es hilft bei der Entwicklung von Medikamenten. Es erledigt die Arbeit.
Glauben Sie, dass irgendeine Sprache das Zwei-Sprachen-Problem irgendwann lösen kann?
Ich bezweifle es. Die Spaltung ist softwarebedingt. Spiele verwenden C++-Engines und Lua-Skripte. Server-Backends kombinieren Python-Logik mit Rust-Leistung. Die Frontend-Entwicklung schlägt jedes Mal fehl, wenn versucht wird, Rust oder Go zu übernehmen.
Wir wollen immer wieder die Wunderwaffe. Holz, das nicht verrottet. Python, das nicht ins Stocken gerät.
Wir bauen mit dem, was funktioniert. Wir wechseln das Werkzeug, wenn dies nicht der Fall ist. Das ist kein Fehler.
Es ist der Job.
