Haskell will die beste Sprache für „Human in the Loop“ werden

Es gibt dieses Memo-Video von S. P. Jones, das berühmt dafür ist, zu sagen: „Haskell is Useless“. Ich liebe Haskell, aber ich wünschte, es wäre universell wie C, C++, JavaScript, Rust und C#. Damit meine ich: Man könnte damit Apps für Desktop, Mobile und Web erstellen. JavaScript kann für so viele Dinge verwendet werden, wie das gesamte Web antreiben, auf Node laufen und jedem ermöglichen, CLI-Tools zu erstellen und den Code mit Web zu teilen, und Mobile über React Native, auf Desktop mit Electron und ähnlichen Dingen; es ermöglicht Plugins für weiß Gott wie viele Dinge, man kann Dinge für die GNOME Shell schreiben ... C und C++ stehen vielleicht hinter allem in der Welt, und wenn die Stringtheorie endlich gesehen wird, wird man sehen, dass sie in C geschrieben ist. Und sie können ins Web und fast alles in der Welt kompiliert werden. Rust ist ein Platzhalter für die beiden, und C# hat sich neu erfunden, als es Mono sah, und funktioniert jetzt sogar im Browser. Jedes Mal, wenn ich Haskell sehe, frage ich mich, was ich sonst noch tun kann, außer CLI-Apps zu erstellen, und es lässt mich etwas anderes wählen, das mir mehr Code-Wiederverwendung und interessante Anwendungen ermöglicht.

Wenn ich eine Vision für Haskell haben könnte, dann wäre es, dass es nützlich ist. Akademische Forschung und Compiler zu bauen ist cool, ein paar CLI-Sachen hier und da sind auch cool, aber warum können wir damit keine Musikplayer und Game-Engines und Flutters und Webseiten bauen? Die Sprache ist viel eleganter und schöner als all die JS/C-ähnlichen Sprachen da draußen, und ich wünschte wirklich, ich könnte sie für die Dinge nutzen, die ich tue. Ich kenne Servant/Yesod/IHP/Miso/Reflex für Web, GTK/M […]

hasufell war eine wunderbare Person im Haskell-Land. Er hat sehr klare Vorstellungen von Dingen und so weiter.

Außerdem ist das, was ich jetzt in Haskell mit Computerhilfe bauen kann, episch. Anfang dieser Woche habe ich das, was ich für einen der – wenn nicht den – besten STEP-Dateiformat-Leser/Schreiber in praktisch jeder Hinsicht halte, auf die Beine gestellt. Einige C-Varianten sind bei den größten CAD-Baugruppen, die ich ausprobieren konnte, 20–30 Prozent schneller.

Eine wichtige Achse, die Leute zu vernachlässigen neigen: Die Hauptmethode, wie LLMs für besseres Programmieren skaliert werden, sind metrische Megatonnen von Reinforcement-Learning-Traces, und Typchecking, das schick ist, gibt eine billigere und schnellere Trainings-Feedback-Schleife.

Mit einem LLM als eine Art wahnsinnigem, manischem Praktikanten, über dessen Schulter ich sozusagen schaue, bin ich in der Lage, die APIs und Designs zu bauen, die ich sehen kann, aber nicht im entferntesten im selben Maßstab tippen kann. Aber ich kann die Eckpfeiler für die genauen Designs recht kompakt spezifizieren, und dann fungiert der Agent irgendwie als Compiler, den ich korrigieren und iterativ laufen lassen muss.

Es hat nicht genug zusätzlichen Mehrwert gegenüber Konkurrenten wie Rust. Es gibt andere bedeutendere Synergien mit Coding-Agenten, die stattdessen Aufmerksamkeit bekommen, wie autonome formale Verifikation. Sprachen wie Lean ermöglichen eine völlig neue Kategorie des Engineerings, und Haskell tut das einfach nicht. Also steckt es in einem schwierigen Mittelfeld fest, wo es zu anders ist, um sich relativ zu seinen Gewinnen zu rechtfertigen, aber nicht anders genug, um die neuen Möglichkeiten einzufangen, die entstehen.

Obwohl ich zustimme, dass die Kompilierzeit ein großes Problem ist, denke ich, dass der Fokus wirklich auf inkrementellem Build liegen sollte, denn wenn man bedenkt, wie viel Arbeit der Haskell-Compiler zu erledigen hat, ist es zu erwarten, dass er bei einem vollständigen Build ziemlich langsam ist.

Aber inkrementeller Build hat keinen Grund, langsam zu sein, wenn der Scope so feinkörnig ist wie auf Funktions- und Typebene.