Writing things we can no longer read (3)

(Thema)

Mal ein paar Anmerkungen aus der Praxis.

Wenn man am Computer Algorithmen entwickelt, schraubt man ab einem gewissen Grad der Komplexität an etwas herum, was man als Programmierer selbst nicht mehr (komplett) versteht. Man verliert irgendwann den Überblick über das Zusammenspiel der Komponenten. Dann blickt man nur noch auf den Output. Wenn daran etwas nicht stimmt, probiert man letztlich nur noch: man hat einen Verdacht, was schief läuft, ändert ein paar Zeilen Code, und sieht nach, ob das etwas verbessert hat. Es gibt Grenzfälle: man blickt auf so absurde Ergebnisse, daß die nur an einem Bug liegen können; den kann man im Debugger durch Beobachten des Programmablaufs in Zeitlupe finden und beseitigen. Wenn das zu lösende Problem komplex genug ist, gibt es aber ständig Fälle, wo man gewissermaßen jenseits der Logik des Codes operiert. Ich „weiß“ beispielsweise, daß die Darstellung einer bestimmten rhythmischen Figur „falsch“ ist, ich kenne aber nicht die Ursache, warum das Programm hier versagt. Es gibt da auch gar keine eindeutige Antwort – das ist dann kein Bug, sondern meine Unfähigkeit, das zugrunde liegende Problem soweit zu abstrahieren, daß ich es codieren kann. Das weiß nicht der Computer, sondern allein „ich“.

Algorithmen bei der Steuerung des Autopiloten im Flugzeug befinden sich auf diesem Level von Komplexität – deshalb gibt es dort mehrere Programme, die von unterschiedlichen Teams entwickelt wurden, und die unterschiedlichen algorithmischen Ansätzen folgen. Wenn deren Output – aus welchen Gründen auch immer – nicht übereinstimmt, muß der Pilot übernehmen.

Algotrading findet noch auf einem ganz anderen Level statt – Gerald Braunbergers Hinweis beim Weissgarnix, daß man es hier oft mit ganz kleinen Teams zu tun hat, die sich vor jeder Öffentlichkeit scheuen, spricht hier Bände.

„Writing things we can no longer read“, heißt es im Vortrag von Kevin Slavin. Genau das ist hier das Problem.