Und noch eine Ladung von Maias stetig anwachsendem Vokabular, bevor sie wieder ins fehlerfreie Hochdeutsche wechselt:
Kurze Übersicht der momentanen Lieblingsvokabeln Maiasprech – Hochdeutsch
Mitten in der Hektik des eiligen Pendelns zur Arbeit sorgt ein simpler Zeitungsartikel (ZEIT Nr. 43/2007, “Wo seid ihr?”) mal wieder dafür, dass ich mich frage, warum ich die Tage des Lebens so ungewürdigt vor sich hin rennen lasse. Der Autor Henning Sußebach redet von der verlangsamten Zeit des Alltags von geistig behinderten Menschen: Früher, als Zivi, hatte er mit den geistig behinderten Kindern zu tun, jetzt sind es Männer und Frauen geworden, deren Zeit aber im Kindesalter stehen geblieben ist. Beim Lesen wird mir nur zu deutlich, wie richtig es ist, sich mit unserer kleinen Maia über jeden neuen Schritt und jede neue Entdeckung (”Fluck-tschock” am Himmel) zu freuen. So zerbrechlich ist jeder Tag, so ein himmlisches Geschenk jede Freude, so ein Luxus ist das normale Leben.
Und um so mehr ist es eine Aufgabe der gesamten Gesellschaft, hier Barmherzigkeit und eben auch finanzielles Mittragen für jene zu leisten, die aus sich heraus nichts von dem leisten können, was der Zeitgeist als Erfolge ansieht. Also Behindertenheime auch weiterhin staatlich oder kirchlich oder wie auch immer dauerhaft zu finanzieren. Und es ist völlig klar, dass der Umgang mit den geistig Behinderten natürlich nur ein Beispiel unter vielen für eine gesunde Gesellschaft und ein gesundes Menschsein ausmacht. Der Artikel ist für mich ein Anstoß, ganz umfassend die Augen immer weiter dafür zu öffnen, an welchen Stellen denn kein Erfolgsdruck angesagt sein darf, sondern ich in Großzügigkeit aus meinem Reichtum abgeben kann, um als Mensch wirklich vollständig zu werden.
Ach ja, und für den erwähnten Artikel in der ZEIT wage ich mal die bescheidene Prognose, dass der noch irgendeinen Preis bekommen könnte…
Mein Schatz suchte nur einen Fahrradanhänger. Aber man bekommt viel mehr geboten: Einen unschlagbaren Witz am Abend! Siehe zweite Frage:
In ganz unregelmäßiger Tradition hier mal wieder ein Hinweis zu meiner Begeisterung für ZEIT-Lektüre: Ausgerechnet ein katholischer Priester im Feuilleton (ZEIT Nr. 33/2007, Aufmacher Feuilleton) darf die wegschauende Haltung der katholischen Kirche zur Aids-Seuche in Afrika geißeln. Wobei mir nicht nur der Artikel außergewöhnlich gut gefallen hat, sondern – viel schlimmer – die Aussage hat mich selber zum Nachdenken gebracht über meine eigene Haltung zu Aids-Kranken.
Denn wie leicht erwarte auch ich bei jemandem, der sich als HIV-positiv outet, dass derjenige direkt anschließend die Ansteckungsgelegenheit begründet. Was nichts anderes heißt als dass auch ich darauf lauere, ob derjenige nun ein moralisch verwerfliches Handeln bekennt – und ich mich wieder bequem in meine Selbstgerechtigkeit zurücklehnen kann: “Ich halte mich von sowas ja fern, also betrifft Aids mich nicht.” Damit liege ich falsch. Die Herausforderung Jesu ist stattdessen, den Erkrankten anzunehmen und nicht zu verurteilen. Denn was bedeutet es anderes als eine Verurteilung, wenn ich bei Infizierten zuallererst nach der Möglichkeit eines früheren Fehlverhaltens fahnden will? Es ist mir unklarer denn je, wie ich denn eine jesusmäßige Liebe hier weitergeben kann, aber es wird zumindest anders laufen als es die Lehrmeinung der katholischen Kirche vertritt, oder wie ich selber das bisher erwartet hätte.
Auf solchen Gedanken kann mich ein Katholik in der ZEIT bringen.
Bei den bereits zitierten Gedanken zu Programmiertechniken beschäftigte mich auch eine besonders folgenschwere Form von schlechter Programmstruktur, nämlich die Viel-Zu-Lange-Funktionen-Seuche.
In vielen Projekten gibt es Aufgabenstellungen, deren Lösung eine größere Anzahl Berechnungsschritte erfordert. Aus irgendwelchen Gründen ergibt es sich mancherorts, dass man diese größere Anzahl Berechnungsschritte kurzerhand sequentiell (einen nach dem anderen) in eine einzige Funktion mit einem Namen ähnlich BerechneJetztAlles() hineinschreibt.
Wo liegt das Problem? Diese Frage hört man vom ursprünglichen Autor, wenn man als neu Hinzukommender den Programmcode drei Tage lang angesehen hat und nun mit Augen voller Fragezeichen auf ihn zukommt. Da liegt das Problem: Kein Mensch kann solche Funktionen mehr verstehen, die bis zu 1000 Zeilen lang sind und in sich eigentlich mindestens 5 separate Aufgaben der Reihe nach erledigen. Funktionen sind dafür erfunden worden, dass man exakt spezifiziert, was reinkommt und was rauskommt. Im Gegenzug kann man sich dies leicht merken und – vor allem – auf einen Blick wieder anlesen. Innerhalb einer ellenlangen Funktion dagegen weiß man praktisch gar nichts mehr.
Man wundert sich ja geradezu, wie der ursprüngliche Autor in der Lage war, zu verstehen und zu kontrollieren, was in der viel zu langen Funktion denn vorging. Und hier kommt der Debugger ins Spiel.
Ein Debugger (von englisch bug, Fehler) ermöglicht das Zuschauen beim Ablauf eines Programms, auch genannt Ablaufverfolgung. Der Debugger führt das Programm schrittweise aus und kann bei jeder Programmzeile anhalten. Im Bild oben rechts ist diese Zeile durch das nette grüne Dreieck gekennzeichnet. Der Programmierer kann sich dann den Inhalt der Variablen in jenem Programmschritt anzeigen lassen, ähnlich der Variablenliste im klickbaren Bild unten links.
Eigentlich eine schöne Sache. Aber leider scheinen einige Debugger-Benutzer vergessen zu haben, dass ein Debugger ein Werkzeug zur Fehlersuche ist und nicht zum Verstehen eines Programmes. Wenn meine Frage zur Funktionsweise einer Funktion damit beantwortet wird, “geh mal mit dem Debugger schrittweise durch, dann siehst du, was passiert,” dann ist der Programmcode – wie mein deutlicher Kollege B. sagen würde – dann ist das totaler Mist.
Wenn man eine Funktion nicht durch Lesen verstehen kann, dann muss die Funktion eben aufgeteilt werden in kleinere Funktionen, die man verstehen kann. Dazu sind Funktionen da. Wenn die verwendete Datenstruktur dazu schlecht benutzbar ist, muss man sich eben neue passendere Datenstrukturen überlegen. Dazu sind Datenstrukturen da.
Wer sich dagegen durch den Debugger vorgaukeln lässt, dass eine ellenlange Funktion verstehbar sei, weil man “ja im Debugger durchsteppen” könne, ist bereits untrüglich der Viel-Zu-Lange-Funktionen-Seuche zum Opfer gefallen. Da hilft nur, den Debugger mal für 3 Monate im Schrank zu lassen und den Programmcode wieder durch den Programmcode verstehbar zu machen. Und meine negative Meinung über IDEs wird auch nicht besser durch die Tatsache, dass die IDEs das Anwerfen des Debuggers für den Programmierer möglichst einfach machen wollen.
Nochmal: Ein Debugger verführt durch die Ablaufverfolgung zu viel zu langen Funktionen.
Deshalb: Debugger are evil. Debugger sind ein Übel.
Debugger sind böse.
Neulich habe ich mir über so manche Programmiertechniken Gedanken gemacht und habe ich mich gewundert, woher eigentlich mehrere ziemlich destruktive Programmiertechniken kommen, die man gelegentlich antreffen kann. Da ist zum ersten die Alles-In-Einer-Datei-Krankheit: Man kann mancherorts bis zu 20.000 Zeilen pro Datei vorfinden. Und da ist auch die Viel-Zu-Lange-Funktionen-Seuche, aber die bespreche ich ein andermal.
Die Alles-In-Einer-Datei-Krankheit hat mehrere negative technische Folgen. Am wichtigsten ist dabei zu nennen, dass es praktisch unmöglich ist, den Inhalt der Datei im Nachhinein wieder in unterschiedliche Module aufzuteilen, also aus einer Programmbibliothek mehrere Bibliotheken zu machen. Denn Zeugs innerhalb der gleichen Datei tendiert ganz automatisch dazu, dass jeder jeden benötigt, so dass man eine einzelne Datei also sowieso nicht aufteilen kann. Für eine Aufteilung der Module muss man aber genau manche Dateien in das eine, manche Dateien in das andere Modul verschieben. Hat man keine Aufteilung in Dateien, ist auch eine Aufteilung in Module praktisch unmöglich geworden.
Wie also kommt es dazu, dass Programmierer sich von der Alles-In-Einer-Datei-Krankheit befallen lassen? Meine These: Die IDEs sind schuld. IDE bedeutet Integrated Development Environment, d.h. Integrierte Entwicklungsumgebung, d.h. ein großes Alle-Programmierwerkzeuge-In-Einem-Fenster Programm. KDevelop zum Beispiel (Screenshot oben links, Klick zum vergrößern). Microsoft Visual Studio zum Beispiel.
Denn die IDEs präsentieren dem Programmierer das jeweilige Projekt mit der Ansicht “Klassen-Browser” (Bild rechts, Klick zum vergrößern), in der die Klassen alle schön fein säuberlich aufgeteilt sind. Das ist zum Teil ja auch richtig – aber böse ist das an dieser Stelle, weil es den Programmierer zu dem Gedanken verleitet, dass mit der Aufteilung seines Codes in die Klassen alle Aufteilungsarbeit bereits erledigt ist. Dieser Gedanke ist falsch. Stattdessen ist es genauso wichtig, dass die Klassen als solche auch sinnvoll auf verschiedene Dateien aufgeteilt werden. Erst dadurch ist im letzten Schritt auch eine Aufteilung auf Module möglich – aber die IDEs gaukeln dem Programmierer vor, die Datei-Aufteilung sei total unwichtig. An dieser Stelle ist die Projektdarstellung in der IDE leider keine Hilfe, sondern im Gegenteil eine schleichende Verführung in schlechte Modularisierung des Codes.
Nochmal: IDEs verführen zu schlechter Modularisierung.
Deshalb: IDEs are evil. IDEs sind ein Übel.
IDEs sind böse.
(Nächste Woche: Warum Debugger böse sind.)
Hab ich schonmal gesagt, dass ich die ZEIT ganz toll finde? Ich finde sie ganz toll. Vielleicht denk ich ja doch daran, mal wieder regelmäßig darauf hinzuweisen, wenn es ganz extrem tolle Artikel dort drin gibt.
Denn regelmäßig bekommen Artikel dort auch noch diverse Preise. Witzigerweise zum Beispiel genau jener Artikel, den ich hier schon mal erwähnte. Also probier ich mal in den nächsten Wochen, noch weitere Preise vorherzusagen… In der aktuellen Ausgabe hab ich keine solchen Juwelen gefunden.