1999 verglühte der Mars Climate Orbiter in der Marsatmosphäre, weil ein Team in Pound-force-Sekunden rechnete, während ein anderes Newton-Sekunden erwartete. Die Einheit ging bei der Übergabe verloren, und kein Compiler war da, um den Fehler abzufangen.

Maker erleben eine kleinere Version desselben Fehlers jedes Mal, wenn ein Mikrocontroller im Spiel ist. Einen Servo, einen Sensor oder einen Schrittmotor zu verdrahten bedeutet, in Millisekunden, Mikrosekunden, Grad, Radiant, Volt und Ampere zu denken — und wenn man sich bei einem davon vertut, wird keine Exception ausgelöst. Es reißt ein Riemen, blockiert ein Motor oder brennt ein Bauteil durch.

Lale ist eine Open-Source-Systemsprache, die physikalische Einheiten direkt in das Typsystem integriert, sodass solche Fehler zur Übersetzungszeit abgefangen werden statt auf der Werkbank: 

var distance as f64 in <m> = 0.5
var time    as f64 in <s> = 2.0

var speed as f64 = distance + time   // ❌ compile-time error

Der Compiler weigert sich, eine Länge zu einer Zeitdauer zu addieren. Radiant ist nicht Grad, und er wird nicht stillschweigend so tun, als wären sie es.

Das ist eine wirklich nützliche Eigenschaft für jemanden, der Dinge baut. Aber ich möchte ehrlich darüber sein, wann man sich darauf verlassen kann.

Was heute real ist

Die Einheitensicherheit ist keine Folie in einer Präsentation. Sie ist im aktuellen Compiler implementiert und funktionsfähig:

  • Dimensionsanalyse zur Übersetzungszeit. Einheiten werden aus Ausdrücken abgeleitet und gegen deklarierte Typen geprüft. Eine Abweichung ist ein Übersetzungsfehler.
  • Laufzeit-Prüfungen für Fälle, die der Compiler nicht entscheiden kann. Ist ein Exponent erst zur Laufzeit bekannt, erzeugt der Compiler eine Prüfung, statt die Einheit stillschweigend zu verwerfen. Diese Prüfungen sind in allen Builds aktiv, nicht nur im Debug-Build.
  • Explizite Sicherheit. Lale kennt keine impliziten Typumwandlungen und keine stillschweigende Verengung. Wenn eine Umwandlung überhaupt erlaubt ist, muss man sie ausschreiben.
  • Keine Exceptions. Der Kontrollfluss bleibt sichtbar und deterministisch — kein verstecktes Abwickeln des Stacks — was zählt, wenn man nachvollzieht, was ein kleines Gerät bei jedem Schritt tut.
  • Ein anpassbarer Ausgabe-Hook. Der Fehlerpfad des Compilers berücksichtigt bereits eingebettete Systeme: Der write-Hook kann auf eine UART-Schnittstelle umgeleitet werden statt auf stderr.

Die Disziplin, die ein Maker braucht — Einheitenfehler abfangen, explizite Umwandlungen erzwingen, den Kontrollfluss sichtbar halten — ist also bereits heute verfügbar.

Was noch nicht real ist

Lale befindet sich bei Version 0.1.0. Die Sprache ist noch nicht bei 1.0, und die Roadmap ist eindeutig darin, wo das Embedded-Thema landet:

  • Das Nebenläufigkeits- und Speichermodell ist Version 5.0.0.
  • Das erste Referenz-Mikrocontroller-Ziel ist Version 6.0.0.

Das bedeutet, dass man heute noch kein Lale-Programm auf ein Board der Arduino-Klasse flashen kann und man keine Firmware darauf portieren sollte. Der Weg von „kompiliert auf meinem Laptop“ zu „läuft auf der blanken Hardware“ liegt noch vor dem Projekt.

Das ehrliche Angebot

Das ist keine Behauptung, dass Lale bereit wäre, C auf dem nächsten Board zu ersetzen. Es ist eine Wette auf die Zukunft — und eine realistische, in die man früh einsteigen kann.

Der wertvolle Teil — die Gewohnheit, einheitenkorrekten, explizit sicheren Steuerungscode zu schreiben — lässt sich schon jetzt am Desktop aneignen, lange bevor das Embedded-Ziel erscheint. Schreibt man seine Motorberechnungen und seine Sensor-Timing-Logik in Lale und lässt den Compiler die Einheitenfehler abfangen, die man sonst auf die harte Tour finden würde, übertragen sich diese Gewohnheiten, sobald Version 6.0.0 kommt.

Wenn das nach einem langen Zeithorizont klingt: Das ist es auch. Aber der Fehler, auf den es abzielt — die Kategorie des Mars-Climate-Orbiter-Fehlers — verschwindet nicht, und kein noch so sorgfältiges Kommentieren fängt das ab, was ein Compiler kostenlos prüfen kann.

Wir wären lieber ehrlich über den Zeitplan, als ein Werkzeug zu überverkaufen, das noch nicht fertig ist. Die Einheitensicherheit ist heute real. Die Hardware ist unterwegs.