kirjoittaessani

Eigentlich weiß ich das ja schon länger, aber heute ist es mir wieder schmerzhaft bewußt geworden: Interpretierte Sprachen[1] sind zur Entwicklung ernsthafter Programme ungeeignet. Für Prototypen, einen schnellen Hack, oder als Shell-Skript-Ersatz sind sie eine feine Sache, aber nicht für echte Programme.

Man hört oft, Computer sind heutzutage so schnell, daß das schlechtere Laufzeitverhalten nicht ins Gewicht fällt, und falls doch ein paar Stellen kritisch sind, so ist das auch kein Problem: die Sprache kann C-Routinen aufrufen. Aber darum geht es nicht. Die echten Nachteile liegen nicht in der Ausführungsgeschwindigkeit, sondern in der fehlenden statischen Prüfung des Codes. Wenn man in einer kompilierten Sprache Quatsch schreibt, dann kann man darauf hoffen, daß der Compiler das bemerkt. In manchen strengeren Sprachen[2] läßt der Compiler weniger Quatsch durchgehen als in nachgiebigeren[3], aber es gibt erstaunliche viele Sorten Quatsch, die jeder Compiler findet. Interpretierte Sprachen kennen keinen Compiler, deswegen finden sie den Quatsch erst zur Laufzeit. Wenn sie ihn finden: Es gibt viele Pfade durch ein Programm, und einige davon werden nur selten benutz; deshalb ist es einfach, völlig vergurkte Programme zu schreiben, zu installieren, und zu benutzen. Es heißt dann oft Deshalb brauchen wir Tests, aber so nützlich Tests auch sind, so haben sie doch gewichtige Nachteile (jedenfalls wenn sie die einzige Möglichkeit sind, Fehler zu finden: Zuerst müssen sie überhaupt geschrieben werden. Ein Compiler versteht die Sprache, aber der Entwickler muß alle nötigen Testcases von Hand schreiben. Dabei kann man leicht etwas übersehen, und noch leichter aus Bequemlichkeit zu wenige (oder gar keine) Tests schreiben. Zweitens braucht das Abarbeiten der Tests Rechenzeit — wahrscheinlich mehr, als man durch den fehlenden Compilerlauf gespart hat; und das Schreiben kosts Entwicklerzeit, und zwar eine Menge. Schließlich findet der Compiler oft einfach andere Fehler als Tests, und wenn man beides einsetzt, findet man mehr Fehler.

Ja, und dann gibt es noch das Problem mit externem Code. Bibliotheken, Module, oder wie man ihn auch nennen will. APIs sollten sich nicht ändern (jedenfalls nicht ohne guten Grund), aber manchmal tun sie es eben doch. Für gewöhnliche, binäre Programme gibt es wohldefinierte Mechanismen, um verschiedene Versionen einer Bibliothek gleichzeitig vorzuhalten, damit ältere Programme immer noch laufen. Einen entsprechenden Mechanismus für Python kenne ich nicht, und so ungewöhnlich ist es nicht, wenn ein sauber installiertes Modul mit ImportErrors um sich wirft. Wenn man eine solche Methode entwickeln wollte, hätte man auch mit einem zusätzlichen Problem zu kämpfen: Wenn ein Programmierer eine shared library verlinkt, dann nimmt der Linker automatisch die neueste installierte Version dieser Bibliothek. Die Versionsnummer wird dann in dem kompilierten Programm verewigt, und wenn man es irgendwann später startet, wird die richtige Bibliothek benutzt. Es liegt aber gerade im Wesen einer interpretierten Sprache, daß der Programmcode nur vom Programmierer verändert wird. Wenn dieser also nicht von Hand eine bestimmte Bibliotheksversion anfordert, dann tut das auch keine andere Instanz.

Im Ernst: man sollte Werkzeuge verwenden, die für die Aufgabe geeignet sind, anstatt sich verzweifelt an seinen Hammer zu klammern und überall Nägel zu sehen.

1. z.B. Python↩
2. z.B. Ada↩
3. z.B. C↩

Linux und die Speicherverwaltung — das ist gar kein einfaches Thema. Wenn man dann noch versucht, seine User mittels ulimit im Zaume zu halten, wird es nur schwieriger. Gerade habe ich etwas sehr erhellendes gefunden: die meisten Sachen funktionieren einfach nicht.

Ärgerlich, wenn der Rechner allnächtlich den mühsam zurechtgezimmerten Code löscht. Praktisch, wenn alle Änderungen in der Code-Datenbank gespeichert sind und man zu jedem beliebigen Zeitpunkt zurückgehen kann. Wunderlich, wenn zusammen mit dem Code auch alle seine Spuren in der Vergangenheit verschwunden sind.

Jetzt habe ich über Monate immer mal wieder ein, zwei Stündchen darauf verwendet, das Leck zu finden. Heute war ich endlich erfolgreich:

In the normal fast-forward case the behavior remains unchanged. However, now local modifications and commits will be erased, and upstream rewrites are handled smoothly.  This ensures that the upstream
branch is tested as expected.

Argh! Was soll das denn? Was ich teste, möchte ich bitteschön selbst entscheiden. Und wenn ich wirklich Upstream testen will, dann lege ich schon einen passenden Branch an. Aber es kann doch nicht sein, daß die Software das für mich entscheidet, und dann auch noch meinen Code aus der Datenbank löscht!

Gerade gefunden: Ein Link für alle, die wissen, was eine Turingmaschine ist.

Ja, da war ich wohl ein wenig voreilig, das Verständnis des Buildsystems anzunehmen. Das stellte sich heraus, als ich den erfolgreich kompilierten gcc unter einem Debugger[1] betreiben wollte. Wer schon einmal versucht hat, ein Kompilat mit eingeschalteter Optimierung zu debuggen, weiß, was ich meine: Variablen lassen sich nicht mehr auslesen, das Programm scheint im Code wirr vor und zurück zu springen — selbst ein sehr einfaches, selbst geschriebenes Programm ist kaum noch nachvollziehbar. Nicht so schlimm, dachte ich mir, und habe mit CFLAGS='-g -O0' configure gleich den nächsten Build angestoßen. Die Ernüchterung folgte allerdings auf dem Fuße:[2] die Flags waren irgendwo unterwegs verlorengegangen, und das Resultat kein bißchen brauchbarer als beim ersten Versuch.

Dabei bin ich eigentlich froh und dankbar, daß der gcc als Buildsystem die GNU Autotools verwendet. Sie werden zwar manchmal als veraltet und zu kompliziert abgetan, aber ich komme mit ihnen immer noch weit besser klar als mit CMake, Python Distutils und allem anderen, das ich bislang gesehen habe. Die Probleme beim gcc rühren allein daher, daß es mit dem bloßen Kompilieren nicht getan ist; stattdessen wird der dabei erzeugte Compiler dazu verwendet, aus dem Sourcecode noch einen Compiler (Stage2) zu erzeugen, und dieser wiederum erzeugt dann das fertige Kompilat (Stage3).[3] Of will man in verschiedenen Stadien verschiedene Optionen verwenden, und deshalb gibt es auch einen ganzen Zoo von Umgebungsvariablen, deren Zweck nicht immer ohne weiteres klar ist.

Ach so, die Lösung: nach dem Konfigurieren einfach make BOOT_CFLAGS='-g -O0' bootstrap eingeben, und schon klappt es.

1. Für den Fall, daß noch nicht alle des Programmierens nicht mächtigen Leser aufgegeben haben, sei gesagt: Ein Debugger ist ein Programm, mit dem man den Ablauf und den Zustand eines anderen — möglicherweise fehlerhaften — Programmen schrittweise verfolgen kann.↩
2. Jedenfalls halbwegs — so ein Notebook ist nicht gerade die schnellste aller Entwicklungsmaschinen↩
3. Dieser Bootstrap genannte Zauber dient dazu, den fertigen Compiler mit sich selbst zu kompilieren, was ein guter Test für seine Zuverlässigkeit ist. ↩

Eine kurze Statusmeldung: Inzwischen läuft der Build durch, und ein passendes Problemchen zur Analyse habe ich auch schon gefunden. Am Anfang ist es immer ratsam, sich einen weniger drängenden Bug zu suchen, weil es sonst leicht passiert, daß jemand mit mehr Erfahrung und Überblick schneller ist…

Es war vor ein paar Tagen, da saß ich in meinem Lieblingssessel, es war etwas früher als üblich, und es sollte ein schöner Abend werden. Endlich die Gelegenheit, etwas zu tun, zu dem mir sonst die Zeit fehlt — doch was nur? Lesen mochte ich aus irgendeinem Grund nicht, und der Vokabelkasten neben mir wirkte auch nicht gerade verlockend. Ein Computerspiel vielleicht, dachte ich mir, wenn die Monster zur Tür hereinkommen und du die Taschenlampen und Bumerangs strategisch ums Bett herum verteilst ist das sehr befriedigend, weil die Kiste dir mit jeder Monsterwelle eine neue Herausforderung vorwirft aber du löst sie jedesmal und die Lösung ist so einfach und so elegant wenn du nur die Taschenlampen hinten in die Kurven und die Shuriken vorne an die Geraden stellst, aber nein irgendwie ist das ja auch alles repetitiv und ein bißchen langeweilig, und dann wußte ich du brauchst Code code CODE und es ist völlig egal daß du jeden Tag acht Stunden am Rechner verbringst du mußt jetzt und gerade den Compiler anwerfen und ein programmieren und jedes Problem ist eine Herausforderung aber das Programm löst sie und der Code ist so elegant nur ist es gar nicht repetitiv wenn du nur das richtige Problem hast und hinterher können tatsächlich Leute dein Programm benutzen und…

Nun ja, ich habe dann ein bißchen nach einem passenden Projekt gesucht. Vielleicht ein schönes buntes Mac-Programm? Aber bald fiel mir wieder ein, daß ich vor fünf oder sechs Jahren schonmal ein bißchen im gcc herumgefuhrwerkt hatte, und das hat mir eigentlich von allen Projekten immer noch am meisten Spaß gemacht: einerseits ist der Compilerbau schon soetwas wie die Königsdisziplin der angewandten Informatik, und andererseits gibt es beim gcc unglaublich viele kleine Nischen und Unterprojekte, in denen man sich nicht gegenseitig auf die Füße tritt, man aber auch Chancen hat, daß der eigene Code hinterher im fertigen Produkt Verwendung findet. Naja, und dann hat der gcc natürlich eine sehr zentrale Rolle im GNU-Projekt und eine unglaublich breite Nutzerschaft, und das schmeichelt dem Ego dann auch irgendwie.

Für’s erste ist aber statt Blood, Sweat & Code noch der Kampf mit dem Buildsystem angesagt, damit ich den ersten Bootstrap hinbekomme.

Heute habe ich mal wieder eine Notiz, die für die meisten Leser wohl weniger interessant sein dürfte.

Wer Jim Rogers’ Pipe Commands für Ada verwendet und über den Linkerfehler
undefined reference to `c_constant_eof'
stolpert, der möge es einmal mit
pragma Import (C, c_constant_EOF, "__gnat_constant_eof");
anstelle von
pragma Import (C, c_constant_EOF);
probieren.

[via Usenet]

Wenn der Rechner plötzlich komische Sachen macht, dann könnten Cosmic Rays — also Höhenstrahlung — die Ursache sein; das findet jedenfalls Nelson Elhage vom Ksplice-Blog. Ich persönlich halte ja defektes RAM für wahrscheinlicher, aber Nelsons Fehlersuche ist erstklassig. Lesenwert!

Dumme Gedanken

Immer, wenn ich in den letzten Tagen auf unser Betriebsgelände gekommen bin, mußte ich an Eis denken[1]: die festgefahrene Schneedecke sieht mit dem dunklen Splitt wie Stracciatella aus, und die dünne Schicht leicht dreckigen Schnees darüber hat fast genau die Farbe von Nußeis.

Musikalisch

Aber eigentlich wollte ich ja etwas ganz anderes erzählen, etwas über iTunes nämlich. Ich benutze dieses Programm zum Musikhören und zum Verwalten meiner Sammlung, außerdem für den einen oder anderen Podcast. Den Store habe ich bislang noch gar nicht benutzt, und meinen iPod verwende ich auch nur noch sehr selten — im Grunde könnte ich also auch auf andere Software ausweichen. Allerdings funktioniert iTunes klaglos, ist gut ins System integriert (jedenfalls auf dem Mac), und eine echte Alternative kenne ich auch nicht[2]

Mißtöne

Trotzdem gibt es gelegentlich Punkte, die mich stören. Da ist zum einen einiges an Kleinkram, über den man aber ganz gut hinwegsehen kann. So läßt sich beispielsweise bei jedem futzeligen kleinen Tool die, äh, Toolbar[3] nach Lust und Laune den eigenen Vorstellungen anpassen; diese Funktion bringt das System mit, so daß der Anwendungsprogrammierer nur noch wenig Arbeit damit hat. Trotzdem geht es by iTunes nicht. Oder die Smart Playlists[4]: Mehrere Kriterien lassen sich logisch per und oder oder verknüpfen, aber nicht mit beiden[5]. Allerdings läßt sich dieses Problem (das ganz ähnlich auch bei Apple Mail besteht) durch Verschachteln von Smart Playlists ganz gut umgehen.

Bewertet

Zwei Sachen sind aber sozusagen etwas größer: der Umgang mit Alben, und das Bewertungssystem.
Letzteres ist sehr einfach — und genau deshalb macht es auf mich den Eindruck, etwas lieblos an das Programm angeklatscht zu sein: man kann jeden Titel mit einem bis fünf Sternen bewerten. Die Sterne erscheinen dann in den Titellisten, und man kann sie von Smart Playlists auswerten lassen[6]. Das war es auch schon. Halt, eine Kleinigkeit gibt es doch noch: wenn man komplette Alben bewertet, dann wird diese Bewertung auf alle enthaltenen (unbewerteten) Titel übertragen, aber bei diesen erscheinen die Sterne nur als Umrisse. Umgekehrt wird die Bewertung eines Albums aus den Bewertungen der Einzeltitel berechnet[7].

So weit, so gut (oder auch nicht). Solch eine simple Bewertungsfunktion ist irgendwie auf dem Stand der neunziger Jahre[8] stehengeblieben. Meine Durchschnittsbewertung liegt knapp über vier[9] — Noteninflation halt. Hier wäre Platz für ein grundlegend neues Konzept. Wie das genau aussehen soll, weiß ich auch nicht; aber die Grundidee ist, daß der Hörer keine absoluten Bewertungen mehr vergeben muß; stattdessen könnte man zum Beispiel verschiedene Titel gegeneinander bewerten, und das Programm berechnet daraus eine Gesamtbewertung. Oder die Titelbewertung baut sich langsam auf, und man gibt nach jedem Hören nur an, ob man den Titel gerade besser oder schlechter als seine Bewertung findet; diese wird dann in kleinen Schritten angepaßt[10]. Oder noch eine ganz andere Idee — irgendeinem Programmdesigner wird schon etwas Schlaues einfallen.[11]

Albus, -a, -um

Jetzt muß ich mich, glaube ich, mal wieder als furchtbar altmodisch outen. Mit dem Durchbruch von mp3 und ähnlichen Formaten hat sich der Musikkonsum[12] wohl ziemlich auf Einzeltitel konzentriert. Das Album hat sich einigermaßen überlebt.

Naja, bei mir halt nicht. Ich bevorzuge es immer noch, ganze Alben zu hören — für mich sind das Gesamtkunstwerke, da gibt es einen Spannungsbogen ganz ähnlich wie bei einem guten Buch, und manchmal wird sogar eine richtige Geschichte erzählt[13].

Nun ja, so ganz tot ist es auch wieder nicht: iTunes gruppiert Titel zusammen, die dem gleichen Album entstammen, und stellt das Coverbild neben der Titelliste dar. Außerdem kann man den Zufallsgenerator (“Shuffle“) so einstellen, daß statt einzelner Stücke ganze Alben abgespielt werden. Schließlich gibt es noch die Bewertungsübertragung, von der ich oben schon geschrieben habe.

Trotzdem finde ich, daß man da noch einiges tun könnte: so benutze ich gerne Smart Playlists, um gut bewertete Titel zu suchen, oder solche, die ich länger nicht gehört habe. Oft finden sich dann aber wirklich nur einzelne Titel statt ganzer Alben: vielleicht habe ich letzte Woche mitten in einem Album aufgehört, und die letzten Titel sind jetzt zwei Wochen älter als die ersten; oder ich habe nicht alle Titel gleich bewertet, so daß ich jetzt nur einen Teil in der Fünf-Sterne-Liste wiederfinde.

Schön wäre es, wenn Smart Playlists besser mit Alben umgehen könnten; ich fände es zum Beispiel praktisch, eine Liste länger nicht gehörter Alben zu haben statt immer nur einzelne Titel.

[Edit: English]

1. Will sagen, an Speiseeis; von der anderen Sorte gibt’s derzeit eh genug.↩
2. Wieder: auf dem Mac. Unter anderen Systemen mag das anders aussehen.↩
3. Also der obere Bereich des Fensters, in dem gerne diverse Icons erscheinen, um häufige Befehle schnell ausführen zu können.↩
4. Das sind automatische Zusammenstellungen von Musiktiteln anhand von Regeln.↩
5. Also: ich kann nicht alle Titel auswählen, die ich besonders gut bewertet habe und die entweder aus den 70ern stammen oder Folk sind.↩
6. Man könnte etwa eine Liste mit allen Titeln, die mindestens vier Sterne haben, erstellen.↩
7. Wieder vorausgesetzt, daß man das Album nicht explizit selbst bewertet hat.↩
8. Man könnte auch sagen: des vorigen Jahrhunderts.↩
9. Bei Lovelybooks liege ich sogar bei 4,3 …↩
10. Falls das unklar war: ein neuer Titel hat meinetwegen eine Bewertung von 3. Nach dem ersten Hören sage ich der ist aber besser, und das Programm erhöht die Bewertung meinetwegen auf 3,5. Beim zweiten Mal finde ich ihn immer noch besser, und er rutscht auf 3,8 — und so weiter in immer kleineren Schritten.↩
11. Ich habe mich gleich mal in die Wunschliste eingetragen:

    What I would like to see in a future iTunes version is a truly innovative rating system. Instead of assigning a fixed number of stars per title, something that evolves as I build up my library and listen to music would be great.

    For example, once I have assigned preliminary stars to a new title, iTunes might allow me to compare it to other titles with a similar rating (say, while listening to the track). iTunes could then adjust its rating accordingly. Globally adjusting ratings in order to use the full spectrum of one to five stars might also be useful. Currently, the average rating in my library is slightly above four stars, however it is hard to correct this manually.

    ↩

12. Von Konzerten mal abgesehen.↩
13. Und Vinyl finde ich toll. Nur das Laufwerk paßt nicht in meinen Rechner. Schnüff.↩