Das Jet Propulsion Laboratory (JPL) hat seit Jahrzehnten eine herausragende Stellung in der Raumfahrttechnologie und Robotik eingenommen. Eine weniger bekannte, dennoch faszinierende Facette seiner Geschichte ist die Rolle der Programmiersprache Lisp in der Entwicklung autonomer Systeme und Raumfahrtssoftware. Lisp, eine der ältesten noch verwendeten Programmiersprachen, die vor allem durch ihre Flexibilität und dynamische Natur besticht, fand am JPL anfangs eine engagierte Anhängerschaft, bevor sie durch politische und organisatorische Einflüsse an Bedeutung verlor. Lisp und die Ära der Robotik am JPL begannen in den späten 1980er Jahren. Zu dieser Zeit war die Künstliche Intelligenz (KI) gerade erst dabei, in den Fokus der Forschung zu rücken, obwohl der sogenannte AI-Winter am Horizont bereits sichtbar war.
JPL setzte damals auf autonome mobile Roboter als Schlüsseltechnologie für Marsmissionen, insbesondere für das Projekt Mars Rover Sample Return (MRSR). Während das damalige Paradigma schwergewichtige Tonnen schwere Rover vorsah, gab es Pioniere wie David Miller, die kleine, wendige Roboter favorisierten, welche mit weniger Ressourcen auskamen und dennoch wertvolle wissenschaftliche Leistungen erbrachten. Die Programmiersprache Lisp wurde zu dieser Zeit am JPL vor allem für die Softwareentwicklung auf den Robotern eingesetzt. Robby, ein Roboter mit zwei Motorola 68020 Prozessoren und immerhin 8 Megabyte RAM, konnte Lisp direkt auf seinem Betriebsystem vxWorks ausführen. Dieses Setup war beeindruckend für die damalige Zeit und ermöglichte eine agile Softwareentwicklung mit kurzer Iterationszeit.
Für kleinere Roboter wie Tooth jedoch, die über sehr begrenzte Hardware-Ressourcen verfügten – etwa 256 Bytes RAM und 2 Kilobytes EEPROM pro Mikrocontroller – war der direkte Betrieb von Lisp nicht möglich. Stattdessen wurde Lisp genutzt, um maßgeschneiderte Compiler zu entwickeln, die den für die Hardware optimierten Code generierten. Dies unterstreicht die Anpassungsfähigkeit und die Stärken von Lisp im Bereich der eingebetteten Systeme. Die technische Errungenschaft der Roboter Tooth, Robby und die nachfolgende Rocky-Serie war bahnbrechend. Robby war der erste Roboter, der mithilfe von Stereo-Vision autonom im Außenbereich navigierte.
Tooth konnte als einer der wenigen Roboter seiner Generation Objekte sammeln und bewegte sich zuverlässig in Innenräumen. Die Rocky-Rover bewiesen als Mikrorover, dass sie komplexe Aufgaben im unwegsamen Gelände bewältigen konnten, eine Fähigkeit, die bis heute nur selten erreicht wurde. Diese Erfolge wären ohne die Programmiersprache Lisp kaum möglich gewesen, da Lisp die Entwicklung hochangewichteter, dynamischer Software in kurzer Zeit erlaubte. Trotz der technischen Erfolge war das Umfeld am JPL damals politisch komplex und herausfordernd. Die Robotikforschung war institutionell zersplittert, und verschiedene Gruppen kämpften um Ressourcen und Einfluss.
Dies führte schließlich dazu, dass die Robotic Intelligence Gruppe aufgelöst wurde, und viele ihrer Forscher verließen die Institution. Ein für die Zukunft des Lisp-Einsatzes folgenreicher Einschnitt war die Entscheidung, den Mars Pathfinder Rover Sojourner nicht in Lisp, sondern in C zu programmieren. Sojourner wurde mit einem Intel 8085 Prozessor und 1 MB RAM ausgestattet und war ein Meilenstein der Raumfahrtgeschichte, doch die Softwareentwicklung reflektierte die damaligen politischen und organisatorischen Zwänge. Im Anschluss an die Robotics-Phase folgten Jahre mit wechselnden Projekten, in denen Lisp weiterhin eine Rolle spielte, jedoch nicht mehr im Rampenlicht stand. Ein bemerkenswertes Beispiel war das Engagement bei der Generierung einer Fehlerkorrektur für den Galileeo-Magnetometer, ein kleines, aber kritisches System mit sehr eingeschränkter Hardware.
Mithilfe von Lisp wurde nicht nur ein neuer Entwicklungszyklus entworfen, sondern auch ein Simulator erschaffen, der das Instrument bis ins Kleinste nachbildete. Diese Arbeit zeigte die einzigartige Leistungsfähigkeit von Lisp bei der schnellen und effizienten Lösung von komplexen Aufgaben unter schwierigen Rahmenbedingungen. Der Höhepunkt der Lisp-Anwendung am JPL war zweifelsohne das Projekt Remote Agent (RA) in den 1990er Jahren. Dieses autonome Raumschiffsteuerungssystem wurde komplett in Common Lisp entwickelt, trotz massiver Widerstände und politischem Druck, zu C++ zu wechseln. Die Überlegenheit von Lisp in ihrem speziellen Anwendungsfall zeigte sich deutlich, als der Versuch, den Planer des Systems auf C++ zu portieren, nach einem Jahr abgebrochen werden musste.
Das System wurde auf Deep Space 1 eingesetzt und konnte dort, dank Lisp und seinem lebhaften Entwicklungs- und Debugging-Ökosystem, einen kritischen Fehler in Echtzeit beheben. Diese Errungenschaft wurde mit der Auszeichnung „NASA Software of the Year“ gefeiert und belegte die Reife und Leistungsfähigkeit von Lisp in hochkomplexen Raumfahrtsystemen. Doch trotz dieser technologischen Erfolge war das Schicksal von Lisp am JPL besiegelt. Das Jahr 1999 markierte einen dramatischen Wendepunkt. Das New Millennium-Programm, dessen Leitmotiv „besser, schneller, billiger“ lautete, sah sich mit extrem knappen Budgets und Zeitplänen konfrontiert.
Als Probleme und Verzögerungen auftraten, suchte man nach Schuldigen. Bei einer wichtigen Managementkonferenz meldete sich ein Software-Integrationsingenieur zu Wort und verlangte, Lisp aus dem Projekt zu entfernen. Seine Begründung waren hauptsächlich Schwierigkeiten bei der Mehrsprachigkeitsintegration, insbesondere in der Kommunikation zwischen Lisp und C-Code, die durch einen instabilen C-basierten Server verursacht wurden. Diese mitunter berechtigten technischen Probleme wurden politisch instrumentalisiert und führten dazu, dass Lisp als Hemmschuh deklariert wurde. Die Folge dieser Entscheidung war der Niedergang von Lisp am JPL.
Projekte wie der Remote Agent wurden zu bloßen Experimenten degradiert und verloren ihren prominenten Status. Bemühungen, Lisp auf kleineren Embedded-Systemen mit angepassten Versionen wie Macintosh Common Lisp (MCL) erneut einzuführen, scheiterten angesichts der institutionalisierten Ablehnung. Schlüsselentwickler verließen die Einrichtung, darunter auch der Programmierer, der die MCL-Portierungen nach vxWorks, Linux und Solaris realisierte. Seine Arbeit fließt zwar weiterhin in Open-Source-Projekte wie OpenMCL ein, doch der Nutzen für das JPL selbst blieb gering. Diese Entwicklung steht im starken Kontrast zur weiterhin exzellenten Qualität der Lisp-Software, die durch Projekte wie SHARP (Spacecraft Health Automated Reasoning Prototype) und Plan-IT belegt wird.
Dass diese Initiativen heute kaum noch gewürdigt werden, verdeutlicht, wie politisch und kulturell Entscheidungen bei der Auswahl von Technologien oft getroffen werden, die wenig mit deren objektiver Eignung zu tun haben. Nach seiner Zeit beim JPL wechselte der Autor der Ursprungsdokumentation für ein Jahr zu Google, ein Unternehmen, das damals Lisp noch nicht als Standardprogrammiersprache einsetzte. Seine Versuche, Lisp bei Google einzuführen, stießen schnell auf Ablehnung, insbesondere durch das Management, das Lisp nicht als praktikabel für ein so großes und schnell wachsendes Unternehmen betrachtete. Diese Erfahrung spiegelte die damals vorherrschende Einstellung in der Softwareindustrie wider, die zunehmend auf standardisierte, strenge Sprachen wie Java setzte, die den Softwareentwicklungsprozess zwar strukturierten, aber auch Einschränkungen hinsichtlich Flexibilität und Ausdrucksstärke mit sich brachten. Als der Autor bald darauf zum JPL zurückkehrte, fand er sich in einer Umgebung wieder, in der qualifizierte Arbeit an Suchmaschinen eher administrativer Natur war als technischer Innovation.
Gleichzeitig beobachtete er mit Frustration, wie Millionen von Steuergeldern in Systeme investiert wurden, die mithilfe modernerer und geeigneterer Programmiersprachen wie Lisp hätten optimiert werden können. Die Ironie dieser Situation ist unübersehbar. Lisp bietet sich gerade für die hochspezialisierten, wenig standardisierten Anwendungen im Raumfahrtsektor an, die sich durch dynamische Anforderungen, knappe Budgets und eng getaktete Entwicklungszyklen auszeichnen. Stattdessen dominieren standardisierte imperativ orientierte Sprachen mit weniger klar definierten Semantiken und häufigen Fehlerquellen, was in der Folge zu einem erhöhten Wartungsaufwand und nicht selten zu signifikanten finanziellen Verlusten führt. Heute erinnert die Geschichte von Lisp am JPL an ein Stellvertreterdrama zwischen technologischem Fortschritt und bürokratischer Trägheit.
Die Sprache Lisp, einst Wegbereiter für autonome Steuerungssysteme und in Forschungsprojekten von Weltrang, wurde zunehmend marginalisiert. Diese Entwicklung zeigt, wie eng technische Innovationen mit organisatorischen und kulturellen Faktoren verwoben sind und dass selbst die beste Technologie nicht über siegen kann, wenn sie auf politischen Widerstand trifft. Dennoch besteht Hoffnung, dass sich der Kreis irgendwann schließt. Die Erfahrungen aus vergangenen Jahrzehnten lehren, dass technologische Wandelprozesse zyklisch verlaufen. Nach dem AI-Winter erlebte Lisp zu Beginn der 90er Jahre eine Renaissance, und nach dem Dotcom-Crash könnte eine weitere Phase folgen, in der funktionale und dynamische Sprachen ihren verdienten Platz zurückerobern.
Gerade im Bereich der Erforschung des Weltraums, wo Flexibilität, Zuverlässigkeit und innovative Lösungsansätze essenziell sind, bleibt Lisp ein inspirierendes Beispiel dafür, wie Programmierung ganzheitlich verstanden und angewendet werden kann. Abschließend bleibt festzuhalten, dass die Geschichte von Lisp am JPL nicht nur eine Erzählung über eine Programmiersprache ist, sondern auch eine Lektion über den Umgang mit Innovation, den Einfluss von Managemententscheidungen und die Bedeutung von technologischem Weitblick in einem der anspruchsvollsten Forschungsfelder der Menschheit.
