Abbildung 1: Programme lassen sich unter höchst unterschiedlichen Kriterien entwickeln. Übersichtlichkeit und Laufzeit waren bei dieser Ruby-Lösung von Leser Knut Franke nur zweitrangig: Dafür ist es die bislang kürzeste Einsendung.

Programmier-Promis hatte das Linux-Magazin in der letzten Ausgabe nach Lösungen für eine gestellte Aufgabe gefragt – nicht alle Einsendungen konnten vollends überzeugen. Seit Erscheinen des Hefts programmieren die Fanclubs der Sprachen zur Ehrenrettung um die Wette. Ein Zwischenbericht.

Mit negativer Logik lassen sich kleine Kinder manchmal zu Dingen überreden, die anderweitig hohe Motivationskünste erfordern. Sollten Software-Entwickler etwa ähnlich gestrickt sein?

Im Wettstreit populärer Programmiersprachen [1] kämpfte die eingesandte Python-Lösung mit einem Problem: Sie verwaltet die zu durchsuchenden Fußnoten der Aufgabenstellung in einer kontinuierlich wachsenden Liste und durchforscht sie bei jeder neuen Fußnote linear. Experten und geplagte Informatikstudenten nennen das O(n2) oder auch “quadratischen Aufwand”.

Komplexe Materie

Das bedeutet vereinfacht gesagt, dass die Ausführungszeit quadratisch mit der Anzahl der Fußnoten steigt. Der vorgegebene Beispieltext hatte zehn Fußnoten. Das war für alle Skripte einfach. Ein zweiter Testfall hatte jedoch eine Million Einträge, also 100000-mal mehr. Bei einem Programm der Komplexität von O(n2) bedeutet dies, dass es nun 10 Milliarden (1000002) mal so lange braucht als vorher. 10 Milliarden mal eine kurze Zeit ist immer noch ein erkleckliches Weilchen. Daher enthielt der Beitrag in der letzten Ausgabe keinen Messwert für die Python-Lösung.

Aber zurück zur negativen Logik: Diese Schmach mochten die zahlreichen Python-Liebhaber unter den Lesern des Linux-Magazins natürlich nicht auf sich sitzen lassen. Folglich führen die Python-Einsendungen zahlenmäßig die Hitliste der Leserzuschriften an, um die die Redaktion bis Ende September gebeten hatte. Da dieses Heft seinen Redaktionsschluss noch vor diesem Termin hatte, folgt erst in der kommenden Ausgabe eine komplette Auswertung der Leserzuschriften.

Motivation zur Verbesserung

Software-Ingenieure oder Programmier-Philosophen mögen in diesem Umstand vielleicht eine Bestätigung des Postulats von Vordenker und Waffennarr Eric S. Raymond sehen, der 1997 auf dem Linux-Kongress [2] in seinem denkwürdigen Essay [3] forderte: “Release early, release often”. Ein zentraler Gedanke in seinem Beitrag war die Motivation von Entwicklern für das Entwickeln: Oft geht es um das Vergleichen und Verbessern von fremdem Code mit den eigenen Lösungen und Fertigkeiten. Manch einer mag das unter dem Geiste olympischen Wettstreitens sehen, andere als maskulines Kräftemessen auf dem Weg zum Denkergeschlecht [4]. Egal: Es produziert schnelleren, kürzeren oder schöneren Code (siehe Abbildung 1).

Abbildung 1: Programme lassen sich unter höchst unterschiedlichen Kriterien entwickeln. Übersichtlichkeit und Laufzeit waren bei dieser Ruby-Lösung von Leser Knut Franke nur zweitrangig: Dafür ist es die bislang kürzeste Einsendung.

Bearbeitet ein neuer Programmierer ein Stück Code und legt er einigermaßen objektive Kriterien zum Benchmarking wie Laufzeit oder Speicherbedarf zugrunde, veredelt sich fast immer dessen Qualität. Diese Eigenschaft hat freie Software mit ihrer fast unbeschränkten Zahl von möglichen Veredlern jeder proprietären Variante voraus. Allerdings setzt dies voraus, dass das zu veredelnde Programm, sein Code und seine Umgebung auch so attraktiv sind, dass sie genügend viele Enthusiasten anziehen. Freie Software skaliert besonders mit großen Zahlen: Jeder darf mit beliebig kleinen Quäntchen zu einem Projekt beitragen, aber viele kleine Schritte ergeben oft beeindruckend Großes. Wie bei der Laufzeit von einigen Python-Programmen.