JavaScript auf dem James Webb Telescop, ist das schlimm?

Motivation

In meiner Timeline wird gerade dieser Artikel (link) herumgereicht. Darin wundert sich die Authorin darüber, dass die Programmiersprache JavaScript auf dem James Webb Space Telescope (JWST) eingesetzt wird. Es wird suggeriert, dass der Einsatz von JavaScript an sich ein Problem darstellt. Denn JavaScript stünde - so die suggestion des Artikels - für das Gegenteil von Qualität. Und das passe eben nicht mit dem JWST - dem Stolz der Astronomie - zusammen. Wie kann in so einem Projekt der Einsatzt von JavaScript gerechtfertigt sein?

Problem

Was genau ist das Problem daran, dass im JWST auch JavaScript läuft? Im Artikel erscheint es so, als sei es ein Problem an sich, JavaScript auf so etwas wie dem JWST auch nur auszuführen. Begründet wird das leider nicht wirklich, es gibt nur den knappen Satz: "Technologie die nicht wirklich für Robustheit bekannt ist". Aus dem Satz lässt sich lediglich erahnen, was die unterliegende Sorge wohl sein mag.

JavaScript ist die Programmiersprache im modernen Web. Das heißt, Websites, Webanwendungen, PWAs, etc. werden fast ausschließlich als JavaScript Anwendungen ausgeliefert. Diese Markt-Corner wird aber häufig von jenen StartUps bedient, die sich schnell weiterentwickeln- und dafür bereitwillig Fehler in Kauf nehmen wollen. Ganz nach dem facebook Motto "move fast and break things". Vermutlich ist aber vor allem dieses Denken der Grund für "Technologie die nicht wirklich für Robustheit bekannt ist". Und eben diese Philosophie passt nicht gut zu rock-solider Weltraumteleskop Technologie.

Verbindung

Wie passt es also zusammen, dass in einem Teleskop das vor allem solide sein sollte, Technologie aus einer philosophischen Ecke eingesetzt wird, für die Solidität eher zweitrangig ist?

Die Antwort darauf findet sich schon im verlinkten Quellpapier (link). Darin wird beschrieben, dass es im JWST ein intigriertes wissenschaftliches Instrumentenmodul (Integrated Science Instrument Module - ISIM) gibt. Dieses wurde im Ausgangsartikel als das Herz des JWST bezeichnet. Und genau dieses Modul ist aber selber garnicht in JavaScript sondern in C++ geschrieben. C und C++ stellen für Produkte wie einem Weltraumteleskop sicher soetwas wie den Industriestandard da. Allerdings ist die Tatsache, dass etwas in C++ geschrieben ist, noch kein Qualitätsmerkmal an sich.

Wo kommt jetzt aber die JavaScript Verbindung her? Tatsächlich gibt es im ISIM einen Interpreter, der sogenannte "on-board scripts" zur Steuerung des Teleskops ausführt. Und genau diese Steuerskripte werden auf dem JWST als Nur-Text-Blöcke (ASCII) in einem Javascript-Ähnlichen Format verfasst.

Letztendlich gibt es also im JWST ein Modul, das einen selbstgeschriebenen JavaScript-Interpreter enthält, der "on-board scripte" entegegennimmt die in einem Javascriptähnlichem Format verfasst sind. "Looks rock solid to me"

Diskussion

In der Vergangenheit wurden die oben genannten "on-board scripte" auch schon eingesetzt. Sie wurden allerdings in Form von Binärblöcke verfasst. Das JavaScript Format hat einen entscheidenden Vorteil, es ist nämlich ein nur-Text Format. Das bedeutet, dass es für einen Menschen direkt lesbar ist. Diese direkte lesbarkeit ist aber entscheidend, um einem Script mögliche Fehler anzusehen. In Binärblöcken ist das erstmal nicht möglich.

Ein spezielles Binärformat hat weiter das Problem, dass es eigens für eben diese eine Mission (oder aber für ein paar wenige Missionen) entwickelt wurde. Das hat im Gegensatz zu weit verbreiteten Standards immer die Gefahr, dass auch die Spezifikation des Binärformates fehler enthalten kann oder es aber unklare Randbereiche gibt. Solche Unklarheiten in der Spezifikation wirken sich dann in der Entwicklung eines entsprechenden Interpreters negativ aus.

Für ein JavaScript basiertes Format spricht daher auch, dass dieses Format eine weite Verbreitung genießt was sich positiv auf die Bugs der Spezifikation auswirkt.

Fazit

Natürlich kann man sich auf den Standpunkt stellen: "Ohje JavaScript, dass ist ja alles ganz furchtbar"! Allerdings ist das aus den oben genannten Gründen etwas zu kurz gedacht. Gut abgehangenen Menschen-Lesbaren Standardformate sind sicherlich Binärformatspezialentwicklungen überlegen.

Author: Dr. Matthias Brettschneider (matthias@brettschneiders.email)

Date: 2022-08-25 Thu 14:51

Emacs 29.1 (Org mode 9.6.10)

Validate