Wolfgang Jährling

(Keywords: Lists on a stack)

Nach unendlich langer Pause mal ein Update. :-) Ich bin gerade dabei, zu überlegen wie ich Lists on a stack mit brauchbarer Performance ausstatten kann. Das Profiling hat ergeben, dass ein riesiger Flaschenhals der Lookup von Variablen ist, was bei der momentanen Implementierung nicht verwundert. Aber ich frage mich, ob das bereits ausreicht, um auf brauchbare Performance zu kommen.

Aber im Rahmen meiner Überlegungen, wie ich Lists on a stack sinnvoll umbauen könnte, kam ich zu einer etwas traurigen Erkenntnis: Die meisten Ideen, die innovativ sind, sind nicht effizient implementierbar. :-(

last updated 7 months ago #

(Keywords: Kampfkunst)

In dem WingTjun, das ich unterrichte, werden die Bewegungen in den Formen als Wurf- und Hebeltechniken interpretiert. Es gibt vereinzelte Wing Chun-Richtungen, in denen wird das gänzlich anders gesehen. Hier mal eine kleine Sammlung mit Einwänden gegen unsere Sichtweise und meine Antworten darauf.

Einwand 1: "Das Einzige, was ich nachvollziehen kann, ist dass man sich mit den Formen Grundlagen schafft, um gewisse Bewegungen besser ausführen zu können und sich bestimmte Grundstrukturen anzueignen. Die so gerne reininterpretieren Anwendungen, kann man auch ohne den Umweg über die Form trainieren."

Zunächst mal denke ich nicht, dass das eine unbedingt das andere ausschließt. Nur weil man sich damit auch Grundstrukturen aneignet, heißt das ja nicht, dass es nicht auch Anwendungen geben kann.

Dass man die Anwendungen auch einfach so trainieren kann, stimmt zwar, aber: In der Distanz, in der man mit Griffen und Würfen arbeitet, sieht man als "Zuschauer" von außen nur die Hälfte, weshalb es gerade für Anfänger oft schwierig ist, dort stattfindende Techniken "nachzumachen", nachdem der Lehrer sie (als nächste Übung) gezeigt hat. Sich hier auf Bewegungen aus Formen beziehen zu können, macht es Schülern da oft ein gutes Stück einfacher. So können die Formen auch noch ein didaktisches Hilfsmittel für die Anwendungen sein. Unbedingt notwendig sind sie dafür natürlich nicht.

Ob die Anwendungen manchem Kritiker dabei "weit hergeholt" erscheinen oder nicht ist da im Grunde sogar unwichtig, denn wenn der Lehrer über die Formen das vermitteln kann, was er will, ist das doch gut.

Einwand 2: "Und in den geläufigen Wing Chun-Formen, seien sie auch en Detail recht unterschiedlich, erkenne ich doch eher ein schlagendes System."

Ich nicht. Also wohl alles eine Frage der Perspektive. Da ich die einzelnen Sätze aus den Formen im Kampf in der Wurf-Distanz benutze und weil die Sätze bzw. ihre Anwendungen sich dabei auch nahtlos zusammenfügen und ein konsistentes Ganzes ergeben, fällt es mir eher schwer, in den Formen etwas zu erkennen, was viel mit Faustkampf zu tun hätte.

Für den Faustkampf benötige ich nämlich im Wesentlichen vier Dinge: 1. Angriffe (Gerade, Schwinger, Haken, Uppercut), idealerweise auch als sinnvolle Kombinationen, 2. eine gute Deckung, da ich nach dem Kampf möglichst noch so aussehen will wie vorher, 3. flinke Schrittarbeit, sowohl offensiv als auch ausweichend, 4. Abwehrbewegungen gegen Schläge. Die Formen geben im Hinblick auf diese vier Aspekte IMO fast nichts her.

Einwand 3: "Der Nachteil dabei ist: Man arbeitet nicht mehr darauf hin, den Gegner im richtigen Moment durch gezielte Schläge auszuschalten, sondern zielt vielmehr auf's Hebeln und Werfen."

Das finde ich so nicht zutreffend. Es geht bei uns weder ums Werfen und Hebeln, noch ums Schlagen oder Stoßen mit Ellbogen bzw. Knie. Es geht im WingTjun um das Kombinieren der verschiedenen Dinge. Beispiel: Ich versuche das Bein des Gegners zu fegen, er zieht sein Bein weg und verhindert damit den Wurf, aber in dem Moment trifft ihn schon der Kniestoß, für den er mir durch seine Aktion den Raum gegeben hat und mit dem er nicht gerechnet hat. Beschränke ich mich auf das Werfen und Hebeln, fehlen mir wichtige Optionen, mit denen ich den Gegner ausschalten kann. Das gleiche gilt aber, wenn ich mich auf das Schlagen und Treten beschränke. Außerdem kann ein Wurf oder Hebel den Kampf ebenso beenden wie ein Schlag.

Einwand 4: "Ich bin nur der Auffassung, daß die Effektivität des Wing Chun in seiner Einfachheit und Direktheit (Spezialisierung, minimalistischer Ansatz) liegt."

Ich halte das WingTjun für ziemlich minimalistisch. Es gibt relativ wenige Techniken (schließlich sind die Formen nicht lang), und ein paar Theorien und Konzepte die einem sagen, wie man die Techniken benutzt und wie man sich verhält. Wobei ich gerne zugebe, dass ein reines Faustkampfsystem wohl noch ein Stück simpler sein dürfte, da der Faustkampf von Natur aus weniger komplex ist als das Arbeiten mit Griffen. Der Nachteil des reinen Faustkampfes ist aber, dass dabei der Faktor Glück relativ groß ist.

last updated 1 year ago #

(Keywords: Kampfkunst)

Hier ein Beitrag, den ich im Kampfkunst-Board geschrieben habe, der recht gut verdeutlicht, was unsere Idee vom Kämpfen ist.

Der Benutzer FCVT schrieb: "Ich behaupte mal einfach, dass man das bessere System anhand des Kämpfers erkennt. Nämlich an seiner Strategie, den Aktionen, Kampfverhalten und und und..."

Meine Antwort darauf:

Da ist auf jeden Fall etwas dran! Ich habe auch nicht bestritten, dass ein Kämpfer bzw. ein Kampf eine Aussage über ein System ermöglichen kann (Zitat: "nicht zwangsläufig über die Systeme der beiden"). Inwiefern das aber der Fall ist, hängt vom Einzelfal ab. Auch Aspekte wie Kondition haben z.B. einen Einfluss auf das, was jemand tut - Wenn ich erschöpft bin und eine eher unkluge Verzweiflungstat ausführe, weil mir nichts Besseres mehr einfällt, dann sagt das über mein System nichts aus, nur über mich. Andererseits: Wenn jemand die Strategien und die Aktionen seines Stils nur sehr schlecht umsetzen kann, muss auch die Frage erlaubt sein, ob die in seinem Stil verwendeten Trainingsmethoden geeignet sind, die Aktionen und Strategien umsetzen zu lernen.

Noch ein anderer Gedanke dazu: Nehmen wir an, ein Judoka (könnte auch ein Ringer sein, ist nur ein Beispiel) und ein VTler (könnte auch ein Kickboxer sein) kämpfen. Der Judoka kommt nicht an den VTler heran, und wird vom VTler zu Brei gehauen, er wirkt völlig wehrlos. Und jetzt nehmen wir an, es läuft umgekehrt: Der Judoka überwindet direkt die Distanz (der VTler reagiert einen Tick zu spät), wirft, setzt sich auf den VTler und schlägt ihn zu Brei (obwohl der nach dem Wurf eigentlich schon erledigt ist). Was würde das über die verschiedenen Kampfkünste aussagen?

Meiner Meinung nach sagt es vor allem eines aus: Solange spezialisierte Stile in dem Bereich bleiben, für den sie gedacht sind, ist alles in Ordnung. Sobald sie den Bereich, für den sie gedacht sind verlassen, wird es sehr problematisch. Warum waren die ersten UFCs viel blutiger als die heutigen? Nicht weil es heute ein paar weitere Regeln gibt, sondern weil Leute damals wehrlos waren, wenn sie in Situationen kamen, in denen ihnen jegliche Erfahrung fehlte, wie in meinen obigen Beispielen. Weil sie wehrlos waren, wurden sie regelrecht abgeschlachtet. Heute ist keiner mehr in einem Gebiet vollkommen wehrlos, wenn er bei UFC oder ähnlichen Veranstaltungen antritt. Selbst wer auf einen Bereich spezialisiert ist, kennt sich in den anderen einigermaßen aus.

Wenn also an deiner oben zitierten Behauptung etwas dran ist, dann konnte man aus den zahlreichen Kämpfen bei UFC&Co. eines mit Sicherheit folgern: Das "bessere" System ist das, bei dem man Schlagen und Treten, aber auch Werfen und Hebeln lernt.

last updated 1 year ago #

(Keywords: Status)

Nach langer Zeit mal wieder ein kleiner Eintrag. Natürlich hatte ich in der Zwischenzeit einige enorm kluge Gedanken ;) aber nichts was hier thematisch reinpassen würde. Leider habe ich immer noch ein paar nervige Arbeiten für die Uni zu erledigen, die ich erfolgreich vor mir her geschoben habe.

last updated 2 years ago #

(Keywords: Programmierung, enorm kluge Gedanken)

Man liest sehr häufig von objekt-orientierter Analyse (1.360.000 Google-Treffer) und objekt-orientiertem Design (2.670.000 Google-Treffer). Daraus kann man folgern, dass Objekt-Orientierung wohl bei der Analyse und bei dem Design hilfreich ist. Man liest eigentlich fast nie etwas von objekt-orientiertem Debugging (129 Google-Treffer), woraus man schließen darf, dass Objekt-Orientierung beim Debugging vermutlich keine Hilfe ist, oder sich vielleicht sogar eher noch störend auswirkt, sonst würde man sich ja trauen, darüber zu sprechen. (Eine alternative Interpretation wäre, dass bei Verwendung von Objekt-Orientierung das Debugging kein besonderes Problem darstellt, doch dagegen spricht beim besten Willen jegliche Erfahrung, daher bleiben wir mal erstmal bei der These, es handele sich hier um einen blinden Fleck.)

Ein wesentliches Prinzip der Objekt-Orientierung ist die Datenkapselung. Datenkapselung ist gut für die Modularität. Wozu ist Modularität gut? - Das ist eine einfache Frage, weil jeder die Antwort schon mal gehört hat. Modularität hilft dabei, bei der Konstruktion einer Software den Überblick zu behalten. Aber wo Licht ist, ist auch Schatten. Wozu ist also Modularität schlecht? Beim Auffinden von Fehlern, denn dann tritt die bislang verborgene Komplexität auf einen Schlag an die Oberfläche. Es gibt wohl kaum etwas Ekelhafteres als das Debuggen eines riesigen OO-Systems. Womit unsere Ausgangsthese soweit bestätigt wurde.

Gleichermaßen auf Design wie auf Debugging Rücksicht zu nehmen ist keine leichte Aufgabe. Aber es ist eine Aufgabe, der man sich stellen muss, denn manchen Problemen wohnt leider eine gewisse Konplexität inne, an der man einfach nicht vorbei kommt; aber wenn andererseits die Lösung des Problems verseucht ist mit Bugs, dann ist das auch nicht wirklich befriedigend. Heute sind wir jedenfalls noch weit davon entfernt, eine wirklich zufriedenstellende Infrastruktur an Modellen und Werkzeugen vorweisen zu können. Die schlechte Nachricht ist, dass wir uns davon immer weiter entfernen, weil wir irgendwelchen Dogmen hinterherlauen (etwa dem Glauben, Modularität sei ausschließlich positiv). Die gute Nachricht ist dagegen, dass je weiter wir uns vom Ziel entfernen, desto mehr Leute scheinen zu bemerken, dass wir eben dies tun.

last updated 2 years ago #

(Keywords: Programmieren, Web)

Nah längerer Pause mal etwas über Software-Entwicklung allgemein. In diesem Kommentar wird Bezug genommen auf einen lesenswerten Artikel von Alan Holub, der zwar nicht mehr unter der angegebenen Adresse online ist (typisch für das Web), aber immerhin findet man ihn noch an anderer Stelle in einem anderen Format (ebenfalls typisch für das Web), nämlich auf Seite 28 eines 2,3 MB kleinen PDF-Files.

Es geht darin um die Frage, ob der Begriff "Software Engineering" nicht ein Widerspruch in sich ist; schrieb nicht ein gewisser Alan Kay schonmal darüber? Neu ist hier aber, dass jemand in einer Mainstream-Zeitschrift diese ketzerische Ansicht geäußert hat. Und mehr noch, Alan Holub sagt im genannten Artikel sogar noch viel schlimmere Sachen:

"So if programming isn’t science or engineering, what is it? It’s a liberal art. Modern programming bears more similarity to creative writing than to engineering or physics. The design process that you go through (or at least should go through) to create a program is almost identical to the process that you use to write a book"

Und das von jemandem, der Kurse über Java und objekt-orientiertes Design gibt. Es besteht also noch Hoffnung für die Welt. Seine abschließende Forderung, dass die Ausbildung von Programmieren diese Tatsachen berücksichtigen sollte, wird zwar sowiso ignoriert werden, aber sicherlich erreicht Alan Holub einge Leute, die mal darüber nachdenken werden, während z.B. Paul Graham mit vergleichbaren Aussagen eher diejenigen erreicht, die ohnehin schon seiner Meinung sind (nämlich diejenigen, die regelmäßig seine Website besuchen). Dafür kann er es eindrucksvoller formulieren:

"If we (hackers) had a national holiday, it would be April 1st. It says a great deal about our work that we use the same word ("hack") for a brilliant or a horribly cheesy solution. When we cook one up we're not always 100% sure which kind it is. But as long as it has the right sort of wrongness, that's a promising sign. It's odd that people think of programming as precise and methodical. Computers are precise and methodical. Hacking is something you do with a gleeful laugh. In our world some of the most characteristic solutions are not far removed from practical jokes."

Mit diesem Schreibstil kann ich zwar nicht mithalten, aber dafür sage ich schon seit fast 10 Jahren, dass das Entwickeln von Software primär als Kunst zu betrachten ist und logisches Denken nur für einen Teil des Prozesses relevant ist. Wenn man dann bedenkt, was ich damals dafür alles NICHT wusste, dann ist es schon erstaunlich, dass es sich immer noch um eine Außenseiter-Meinung handelt.

last updated 2 years ago #

(Keywords: Zitate, Programmierung)

In meinen Notizen findet sich eine große Liste an Zitaten. Ich habe jetzt mal einige zusammengestellt, die konkrete Tipps zur Erstellung von Software (und Dokumentation) geben).

---

"Documentation should be organized around tasks the user needs to do, not around what your program happens to provide." -- Peter Norvig

"Schreibe kurz, uns sie werden es lesen.
Schreibe klar, und sie werden es verstehen.
Schreibe anschaulich, und sie werden es behalten."
-- Unbekannt

"Nützlich übertrifft standardisiert übertrifft effizient." -- Unbekannt

"A well-designed object is one that helps the user find its intended use." -- Donald A. Norman

"Wichtiger als ein geniales Design zu haben ist, ein furchtbares Design zu vermeiden. Wer ein Geniales erzwingen will, kann leicht ein Furchtbares bekommen." -- Unbekannt (Paul Graham?)

"The purpose of abstractions is to conceal undesirable properties; desirable ones should not be hidden." -- Butler W. Lampson

"Capturing a process at the appropriate level (of abstraction) ensures minimal maintainance." -- Unknown

"The key to performance is elegance, not battalions of special cases." -- Jon Bentley and Doug McIlroy

"Programs must be written for people to read, and only incidentally for machines to execute" -- Harold Abelson and Gerald Sussman in SICP

"Sei optimistisch bezüglich der Möglichkeit, das Problem zu lösen und skeptisch im Hinblick auf das, was du bereits erreicht hast." -- Paul Graham (paraphrasiert)

last updated 2 years ago #

(Keywords: Taoismus, Zitate)

Noch ein Text von Tschuang-Tze, der zu meinen Lieblingstexten zählt:

---

Die Mitglieder einer Räuberbande traten einmal an ihren Anführer heran und fragten: "Braucht ein Räuber denn auch Moral?"

Der Anführer sprach: "Natürlich braucht er Moral bei allem, was er tut:

Seine Größe ist, ohne Überlegung zu wissen, wo die Schätze in den Häusern zu finden sind.
Sein Mut besteht darin, als Erster einzubrechen.
Sein Pflichtgefühl bringt ihn dazu, als Letzter wieder zu gehen.
Seine Weisheit liegt darin, zu wissen ob ein Raub gelingen wird.
Seine Güte liegt in der gerechten Teilung der Beute.

Wer diese fünf Tugenden nicht alle besitzt, der wird niemals ein großer Räuber werden!"

Führt man sich dies vor Augen, dann erkennt man: Auch wenn Gutes nur durch die Moralvorstellung der Heiligen möglich ist, so kann auch das Werk der Räuber nicht ohne jene Moral vollzogen werden. Nun gibt es auf der Welt wenige Gute und viele Schlechte, darum ist der Nutzen der Heiligen für die Welt klein und der durch sie entstandene Schaden groß.

last updated 2 years ago #

(Keywords: Programmierung, Lists on a stack)

Ich habe mir ein paar Gedanken dazu gemacht, wie das Zeug aus dem vorherigen Blog-Eintrag implementiert werden kann. Wir benötigen eine globale Mutex (pthread_mutex_t) m, sowie für jede Co-Routine r1, r2, ..., rN eine passende Condition-Variable (pthread_cond_t) c1, c2, ..., cN und natürlich auch je einen Thread (pthread_t). Wenn wir in Co-Routine rX sind, dann funktioniert der Wechsel zu Co-Routine rY (und das anschließende Warten auf die Erlaubnis, selbst weiterzulaufen) so:

pthread_cond_signal (cY);
pthread_cond_wait (cX, m);

Wenn ich keinen Denkfehler gemacht habe, dann ist das ganze also recht simpel. Natürlich müssen noch an diversen anderen Stellen pthread-spezifische Funktionen benutzt werden, etwa gibt es Dinge, die lokal für jeden Thread existieren, wie der Daten-Stack.

Der Vollständigkeit halber: Um diese Funktionalität zu implementieren, werde ich am besten in mehreren Schritten vorgehen:

• Den Evaluator-Code so modifizieren, dass er darauf vorbereitet ist, dass es mehrere Co-Routinen geben kann
• pthreads schon benutzen (etwa für den nun lokalen Daten-Stack, und für Cleanup-Aufgaben), aber es existiert immer noch nur eine Co-Routine
• Mehrere Co-Routinen ermöglichen

Nach den ersten beiden Schritten wird natürlich geprüft, ob alles noch so funktioniert wie bisher. Wenn nicht, dann ist relativ klar wo das Problem liegen muss.

last updated 2 years ago #

(Keywords: Lists on a stack, Programmierung)

Ich habe ja schon einige Zeit überlegt, wie ich ein Feature, das Threads, Co-Routinen oder Continuations entspricht, sinnvoll in Lists on a stack integrieren kann. Ich glaube, eben habe ich die Lösung gefunden.

Ein solches Feature zu haben ist nicht unwichtig, denn es handelt sich dabei um ein Programmiersprachen-Konzept, ohne das viele Probleme nur sehr unelegant ausgedrückt werden können. Wenn es nur einen Stack gibt, und man entsprechend nicht an passender Stelle zu einem anderen wechseln kann und zurück, dann muss man seien Code völlig anders (und zwar erheblich komplizierter) organisieren, um bestimmte Ergebnisse zu erzielen.

Als einfaches Beispiel sei das Problem eines modalen Dialoges in einer GUI genannt. Den Code dafür zu schreiben ist simpel (im Prinzip nur eine Zeile zum Aufruf des Dialoges), aber für den Benutzer ist es sehr unangenehm, wenn er nicht das Hauptfenster der Anwendung benutzen kann, bis er den Dialog geschlossen hat. Soll nun der Dialog nicht modal sein, wird der Code entsprechend komplizierter - Es sei denn man verwendet Continuations, denn damit kann man den Code so schreiben, als sei der Dialog modal, aber für den Benutzer ist er nicht-modal! (Es gibt ein Guile-Gtk Beispiel, das genau dies demonstriert - hat mich damals sehr beeindruckt).

Im Grunde sind Threads, Continuations und Co-Routinen äquivalent. Ich habe in Scheme schon mal Co-Routinen mit Hilfe von Continuations implementiert, das war geradezu trivial. Threads haben lediglich die zusätzliche Eigenschaft, dass man nicht explizit zu einem anderen Stack wechselt, sondern dies automatisch nach einer gewissen Zeit passiert. Das hat gewisse Vorteile, aber zumindest bei Verwendung von Shared State handelt man sich auch viele Schwierigkeiten damit ein, weil die Threads synchronisiert werden müssen. Im Interpreter von Lists on a stack komme ich letztendlich nicht ohne Shared State aus.

Die Anforderungen im Hinblick auf Lists on a stack waren nun (natürlich) Folgende:

• Es darf den Interpreter nicht deutlich komplizierter machen
• Es muss auch im Compiler funktionieren
• Auch der Compiler darf dadurch nicht deutlich komplizierter werden
• Es sollte möglichst portabel sein
• Es sollte optional sein (vor allem wenn es nicht zu 100% portabel ist)

Gemessen daran, dass es sich doch um ein sehr fundamentales Feature handelt, sind das recht hohe Ansprüche. Ich schrieb mir allerdings gerade auf ein Blatt Papier das Problem und schaute es mir an. Dann schrieb ich darunter: "Es muss eine einfache Lösung dafür geben." Und schon wusste ich sie: Ich verwende POSIX Threads, um Co-Routinen zu implementieren.

POSIX Threads sind eine ziemlich portable Möglichkeit, mehrere Stacks in C verwenden zu können. Das ist notwendig, weil ein Stack-Frame in Lists on a stack einem Stack-Frame in C entspricht (in einem Interpreter könnte man das noch vermeiden, doch spätestens in einem Compiler kommt man daran kaum vorbei, weil sonst die Effizienz erheblich schwindet).

Wenn ich Co-Routinen implementiere, bleibt mir der ganze Aufwand der Synchronisierung von Threads erspart, und lediglich der Code des Evaluators muss geändert werden, um das Feature zu integrieren. Ich verwende dann praktisch einen "Global Lock", damit immer nur ein POSIX-Thread zugleich läuft. Dabei ist auch naheliegend, dass der ganze Zauber optional ist.

Dann bleibt nur zu hoffen, dass die praktische Umsetzung so gut klappt wie erhofft.

last updated 2 years ago #

(Keywords: Programmiersprachen, Web)

Ich benutze ja kein Ruby, und weiß dass es einige Macken hat. Aber gegen Kritik aus der Java-Ecke verteidige ich Ruby natürlich gerne. ;-)

Dieser Text von Bruce Eckel enthält sicher auch den ein oder anderen guten Punkt, aber an einigen Stellen musste ich fast lachen. Okay, immerhin gibt er zu, dass er mal Monate brauchte, um etwas Banales zu verstehen: "one error in particular was dismissing Python's scoping-by-indentation when I first saw it (months later realizing that we always indicate scoping by indentation anyway, even when we have curly braces available)." Witzig, dass ich exakt dazu schon mal etwas schrieb... Aber hören wir weiter: "Now I try to investigate and support my ideas about these things more thoroughly."

Aus diesem guten Vorsatz ist dann leider nicht so viel geworden, denn die Aussage "Ruby is to Perl what C++ was to C." wirkt nicht nur aus dem Kontext gerissen seltsam, sondern vor dem Hintergrund seiner näheren Ausführungen dazu umso mehr: "Ruby improves and simplifies the Perl language" - Der will doch hoffentlich nicht andeuten, dass C++ eine Vereinfachung(!) von C sei; über "Verbesserung" kann man lange streiten, aber Vereinfachung? Das würde wohl selbst ein C++-Liebhaber nicht behaupten. (Die alternative Interpretation seiner Aussage, dass Ruby durch seine Existenz einen entsprechenden Einfluss auf Perl ausübt, wäre im Fall von C und C++ ebenso unpassend.)

Bruce verweist auch auf einen Text von Elliotte Rusty Harold und kommentiert diesen mit: "Look at what he writes; I think he makes a good case." Das zeigt, dass keiner der beiden auch nur die Grundideen von Ruby verstanden hat, denn von den Ruby-Methoden, die dort als überflüssig kritisiert werden, ist der größte Teil ganz eindeutig nützlich (z.B. new, each_index, reverse) oder schlichtweg notwenig innerhalb der Gesamtkonzeption der (IMO sehr ordentlich designten) Ruby-Library (z.B. <=>, to_a).

Um ein Beispiel näher auszuführen: Es wird behauptet, each_index sei überflüssig, "weil man ebensogut eine for-Schleife (oder das entsprechende Äquivalent in Ruby) verwenden könne". Der Witz ist, dass in Ruby anstelle von for-Schleifen entsprechende Iteratoren wie each_index benutzt werden. Es ist also bereits das Äquivalent!

last updated 2 years ago #

(Keywords: Programmierung, Web)

Es ist passiert! Selbst Leute, die den Begriff "Software Engineering" benutzen, haben nun verstanden, dass der Erfolg eines Projektes weniger von der eingesetzten "Methodology", sondern vielmehr von den Mitarbeitern des Projektes abhängt. Aber um fair zu sein ist das Paper Characterizing People as Non-Linear, First-Order Components in Software Development lesenswert, auch wenn (zumindest aus meiner Sicht) nichts Überraschendes drinsteht.

last updated 2 years ago #

(Keywords: Programmierung, Programmiersprachen, Zitate)

Sich selbst zu zitieren ist toll, also los! ;-)

"Learning from failures is nice in theory... but in practice, it sucks." -- Wolfgang Jährling, 2002

"Wir entwickeln mit hohem Aufwand komplexe Systeme, deren zahlreiche Features am von Anwendern erzielten Resultat wenig ändern, die Produktivität aber senken." -- Wolfgang Jährling, 2002

"Programmieren in C ist einfach: Man schreibt "for (i = 0; i <", dann fängt man an zu überlegen." -- Wolfgang Jährling, 2004

"I like the so-called Very High Level Languages, because they try to come close to LISP." -- Wolfgang Jährling, 2002

"When we were five people in a CAR, and I was asked whether I have enough space, I replied "I don't need much space, I'm an empty list". -- Wolfgang Jährling, 2003

"The problem with statically typed languages is that you have to emulate dynamic typing all the time." -- Wolfgang Jährling, February 2004

"But the problem with dynamically typed languages is that you have to emulate static typing all the time." -- Wolfgang Jährling, September 2004

"Die Lieder der Beatles waren kurz, die Texte einfach und die Melodien einprägsam. Wir Programmierer können noch viel von den Beatles lernen!" -- Wolfgang Jährling, 2004

"Erfahrungen sind ein Produkt von Überzeugungen - Nicht umgekehrt!" -- Wolfgang Jährling

last updated 2 years ago #

(Keywords: Programmierung, Taoismus)

KAPITEL 3

Würdigt man die Programmierer zu sehr,
werden die Benutzer zu schüchtern.
Wird Ansehen zu sehr angestrebt,
versuchen die Leute, ihre Fehler zu verheimlichen.
Hat man zu große Pläne,
verliert man den Überblick.

last updated 2 years ago #

(Keywords: Lists on a stack)

Soeben habe ich das implementiert, was man in LISP als gensym kennt: Neue Symbole generieren. Das ist zwar vor allem für LISP-Makros interessant (die ich vielleicht nie haben werde, wenn auch vermutlich etwas ähnliches), aber es gibt auch gelegentlich andere Situationen, in denen man neue Symbole braucht, die eben noch nicht für etwas anderes benutzt werden. Die Implementierung ist sehr kurz, das ist das komplette Modul:

Gen-Counter: 0

sym-gen: | Prefix
(Gen-Counter: ++ Gen-Counter
 str->sym str-append Prefix obj->str Gen-Counter)

Allerdings musste ich erst noch obj->str implementieren, was aber einfach war, da ich bereits Streams habe, die in einen str schreiben ("String Destination", kurz str-dst):

obj->str: | Obj
(str-dst->str stream-out .. Obj str-dst-new)

Damit bin ich auch meinem Versprechen nachgekommen, hier mal etwas I/O-Code zu posten. ;-) Was allerdings auffällt ist, dass ich erheblich weniger Klammern brauche als in LISP (was auch naheliegend ist), woraus sich zwei Dinge ergeben: Erstens braucht man nicht zwangsweise einen dafür besonders geeigneten Editor wie GNU Emacs, und zweitens muss man weniger tippen. :-)

last updated 2 years ago #

(Keywords: Web, Programmierung, Programmiersprachen)

Ein sehr, sehr, sehr gelungenes LISP-Tutorial speziell für Leute, die bisher nur minderwertige^Wverbreitete Programmiersprachen benutzt haben.

"One moment I understood nothing, and the next moment everything clicked into place. I've achieved nirvana. Dozens of times I heard Eric Raymond's statement quoted by different people: "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." I never understood this statement. I never believed it could be true. And finally, after all the pain, it made sense! There was more truth to it than I ever could have imagined. I've achieved an almost divine state of mind, an instantaneous enlightenment experience that turned my view of computer science on its head in less than a single second."

last updated 2 years ago #

(Keywords: TUD, enorm kluge Gedanken)

Heute hat der Dozent in einem Pädagogik-Seminar an der Uni einige Bemerkungen gemacht zum (lesenden wie schreibenden) Umgang mit (wissenschaftlichen) Texten.

Zunächst erklärte er etwas Banales: Texte sind üblicherweise in einer Hierarchie strukturiert, haben also zu einem Punkt "1" auch Unterpunkte wie "1.1". Dabei beschreibt "1.1" einen Aspekt von "1", während "1" dagegen nicht unmittelbar mit "2" zu tun haben muss. Natürlich muss sich diese Struktur nicht zwingend in Überschriften niederschlagen, auch ein Text ohne Zwischenüberschriften kann eine solche Struktur haben.

Dann erklärte er etwas Nachvollziehbares: Es ist schwer, solche Texte - wenn sie länger sind und die Hierarchie tiefer ist - zu erfassen, weil bei all den ausgebreiteten Details der Überblick schnell verloren geht. Man versucht, den Erläuterungen des Textes zu folgen, versteht aber gar nicht mehr, worauf es hinausläuft. Man ist dann auch ganz sicher nicht mehr in der Lage, mit wenigen Sätzen zusammenzufassen, worum es in dem Text geht.

(Ich behaupte, das liegt vor allem daran, dass in hierarchisch strukturierten Texten Endergebnisse ausgebreitet werden, auf die der Autor erst nach längerer Zeit gekommen ist, ohne dass man sehen könnte, wie die Ergebnisse entstanden sind. Leichter verständlich sind typischerweise Texte, in denen man dem Autor quasi "beim Denken zuschauen" kann, weil es dann viel leichter nachzuvollziehen ist, wie er schrittweise zu seinen Ergebnissen kam.).

Dann erklärte er etwas Fragwürdiges: Wenn man beim Lesen eines Textes keine hierachische Struktur erkennen kann, dann hat man entweder den Text nicht verstanden oder der Text ist schlecht. Wenn man einen Text schreibt, gilt entsprechend: Wenn man etwas nicht in eine hierarchische Struktur einordnen kann, "hat man ein Problem mit der Logik".

Warum aber muss man ausnahmslos alles in eine Hierarchie packen können? Was ist, wenn die Zusammenhänge und Wechselwirkungen zwischen einzelnen Aspekten untereinander so beschaffen sind, dass eine Hierarchie ihnen nicht gerecht wird? Ist es "unwissenschaftlich", die Inhalte dann anders aufzubereiten? Wohl kaum. (Und wenn es "unwissenschaftlich" wäre, wäre das schlimm?)

Die Haltung des betreffenden Dozenten ist mir zu dogmatisch, und insbesondere halte ich den Ansatz des "beim Denken zuschauens" in einigen Fällen für erheblich besser als eine Hierarchie. (In wie vielen Fällen diese Struktur tatsächlich besser ist, müsste man natürlich erst testen; vielleicht fand ich Texte dieser Art ja nur deshalb so verständlich, weil sich das jeweilige Thema für diesen Ansatz geeignet hat, auch wenn ich das nicht glaube.)

Aber wo wir gerade bei "dogmatisch" waren: Ein anderer Dozent sagte heute: "Ich bin ein Dogmatiker. Ich trete dogmatisch für die Menschenrechte ein." Das ist doch mal ein erfrischend anderer Blickwinkel auf den Begriff "dogmatisch", den man sonst (wenn auch meist berechtigterweise) mit "verbohrt" gleichsetzt. Einen Kompromiss zwischen wirtschaftlichen Interessen und den Menschenrechten zu suchen lehne er ab, fügte er noch hinzu.

last updated 2 years ago #

(Keywords: Freie Software, Lists on a stack)

War heute auf dem GNU/LinuxTag 2006 in Wiesbaden. Das war wundervoll. Ich bin zahlreichen netten Leuten begegnet - zu viele um sie alle aufzuzählen - und bin auch einige Fragen an den Projekt-Ständen losgeworden. Um die Firmenstände habe ich mich bislang gar nicht gekümmert (außer die mit den Büchern, daran komme ich einfach nicht vorbei).

Heute bin ich auch noch der Justizministerin Zypris über den Weg gelaufen, die auf dem GNU/LinuxTag zu Besuch war. Da sie ohnehin nicht bereit war, über Softwarepatente zu reden, hätte sie auch wegbleiben können, finde ich.

Ich hatte auch Gelegenheit, jemandem (nein, nicht der Zypris ;-)) ein paar Features von Lists on a stack zu zeigen und erntete dabei die überraschte Reaktion: "Oh, nice." Sowas ermutigt, vor allem wenn es von jemandem kommt, der von Programmiersprachen sehr viel versteht (LISP-Kenner und C++-Guru). :-)

Wenn mir noch gute Fragen einfallen, gehe ich morgen mal zum Forth-Stand, denn die Leute dort haben sicherlich mehr Erfahrung mit stackbasierten Sprachen als ich, was ganz hilfreich werden könnte.

Da ich morgens erst an der Uni war und abends noch Training gegeben habe, musste ich heute ganz schön umdenken. Erst Pädagogik-Seminar und eine kleine Meta-Diskussion im Zug, dann GNU/LinuxTag (mit einem kleinen Abstecher nach Juraland am Stand der FSFE) und am Ende Kampfkunst. An Abwechselung mangelt es mir jedenfalls nicht.

Morgen um fünf Uhr aufstehen. Schrecklich... aber es lohnt sich immerhin. Hoffentlich schaffe ich es auch. ;-)

last updated 2 years ago #

(Keywords: Programmierung, enorm kluge Gedanken)

Früher dachte ich immer, dass ein guter Programmierer in der Lage ist, unglaublich komplexe Dinge hinzukriegen, an denen ein Anfänger scheitern würde. Von einem gewissen Blickwinkel aus ist das ein ziemlicher Irrtum. Zwar entwickelt sich im Laufe der Zeit auch die Fähigkeit, komplexere Arbeitsschritte ausführen zu können, aber diese Fähigkeit lässt sich insgesamt doch nur sehr begrenzt entwickeln.

Viel wichtiger ist eine andere Fähigkeit. Nämlich die, sofort zu erkennen wenn eine Aufgabe zu komplex ist um sie direkt zu bewältigen. Der fähige Programmierer wird diese dann in mehrere kleine Schritte aufteilen und Stück für Stück bearbeiten und spart dadurch eine riesige Menge an Zeit gegenüber dem Unwissenden, der sich überschätzt und an den Aufgaben scheitert, die er sich vorgenommen hat. Der gute Programmierer weiß also, wie unfähig er eigentlich ist, während der unfähige Programmierer sich für sehr kompetent hält. ("Die Dummen sind so sicher, und die Gescheiten so voller Zweifel" sagte mal Bertrand Russell.)

Dazu ein Beispiel: Wenn man ein Stück Code schreiben möchte und einem sofort klar ist, dass der Code am Ende kürzer und verständlicher wäre, wenn man eine entsprechende Abstraktion verwendet, die dann auch für ähnliche Probleme genutzt werden kann, wird der schlechte Programmierer sofort die Abstraktion bauen und verwenden. Das wird natürlich im Regelfall nicht funktionieren (weil fast nichts sofort funktioniert). Den Fehler zu finden ist dann relativ aufwendig, weil man nicht weiß in welchem Layer das Problem liegt: In der Abstraktion oder in dem Code, der sie verwendet. Der gute Programmierer hingegen wird zunächst Code schreiben, der keine Abstraktion verwendet und sobald dieser funktioniert, ihn entsprechend abstrahieren. Statt einer komplexen Sache macht er zwei einfache.

Vielleicht meinte Alan Perlis vor allem das, als er schrieb: "In programming, everything we do is a special case of something more general -- and often we know it too quickly."

last updated 2 years ago #

(Keywords: TUD, Lists on a stack)

So, heute habe ich die Bibliothek von Lists on a stack etwas erweitert, indem ich Queues hinzugefügt habe. Außerdem ein paar Bugs entfernt und die REPL verschönert (es wird nun kein Stack ausgegeben, wenn er ohnehin leer ist).

Nachher muss ich noch für die Uni eine halbe Seite darüber schreiben, warum es für einen Pädagogen wichtig sei, sich mit Immanual Kant zu befassen. Das ist notwendig, um an einem Seminar über Kant teilnehmen zu dürfen. Würde meine Zeit lieber damit verbringen, auszuarbeiten wie ich Threads in Lists on a stack integrieren kann. Ich möchte nämlich, dass der Interpreter nicht voller mutex_lock und mutex_unlock aufrufe ist, sondern eher einen SOA-Ansatz verwendet. Allerdings will ich die Verfügbarkeit von Threads auch nicht voraussetzen. Mal sehen, ob ich das irgendwie zusammenbringen kann.

last updated 2 years ago #

(Keywords: Lists on a stack)

Um mal öffentlich zu zeigen, wie Lists on a stack aussieht, hier etwas Code aus dem Modul core. Zunächst die fundamentale Operation both, die zwei Unterprogramme aufruft, nachdem sie jeweils einen bestimmten Wert auf den Stack gelegt hat. Man kann damit also sozusagen zwei Unterprogramme mit dem gleichen Wert als Parameter aufrufen:

both:             # Was definiert wird
| sub1 sub2 X     # Parameter
(sub1 X sub2 X)   # Code

Damit können wir leicht uncons definieren, was das CAR und das CDR eines CONS auf den Stack legt:

uncons: (both car^ cdr^)

Außerdem lässt sich damit auch recons definieren, was jeweils ein Unterprogramm auf das CAR und auf das CDR eines CONS anwendet und aus den Resultaten ein neues CONS erstellt:

recons: | car-sub cdr-sub
(cons both (car-sub car)
           (cdr-sub cdr))

Damit lässt sich nun auch map leicht definieren:

map: | sub
@(unless (nil? .)
  (recons sub^ recurse^))

Demnächst poste ich etwas I/O-Code.

last updated 2 years ago #

(Keywords: Programmierung, Taoismus)

KAPITEL 2

Wenn manche Dinge als benutzerfreundlich gelten,
werden andere Dinge schwer zu bedienen.
Wenn manche Dinge als korrekt gelten,
werden andere Dinge fehlerhaft.

Design und Implementierung erzeugen einander.
Ausdruck und Funktion stützen einander.
High-Level und Low-Level bestimmen einander.
Entwicklung und Release folgen einander.

Daher programmiert der Hacker,
ohne etwas zu tun,
und dokumentiert,
ohne etwas zu schreiben.

Die Bugs tauchen auf,
und er nimmt sie zur Kenntnis.
Die Bugs werden entfernt,
und er vergisst sie wieder.
Er programmiert, erwartet aber dabei nichts.
Wenn sein Code geschrieben ist, vergisst er ihn.
Eben darum währt er ewig.

last updated 2 years ago #

(Keywords: Programmierung, Taoismus)

Weil das Tao Te King so schwer zu verstehen ist, hier mal die Version, die wenigstens für Programmierer nachvollziehbar ist. Das ist jetzt nur der erste Teil, demnächst poste ich hier einige weitere.

---

KAPITEL 1

Das Tao, dass sich dokumentieren lässt,
ist nicht das ewige Tao.
Die Software, die wir implementieren können,
ist nicht die ewige Software.

"Design" ist der Ursprung aller Abstraktionen.
"Implementierung" ist der Ursprung allen Quelltextes.

Darum führt das Studium des Designs
zum Erkennen des Wesentlichen.
Und das Studium der Implementierung
nur zum Verständnis von Einzelheiten.

Aber beide sind nur verschiedene Blickwinkel
auf die gleiche Sache.
In ihrer Einheit sind sie ein Geheimnis.
Das Geheimnis aller Geheimnisse,
das Tor zu erfolgreicher Wartung.

last updated 2 years ago #

(Keywords: Programmierung, Programmiersprachen, Lists on a stack)

Von diversen Ausnahmen abgesehen gibt es in Programmen nur einige geschwindigkeitskritische Stellen. Die Idee, diese in einer performanten und gut optimierbaren Sprache wie C zu schreiben, während man den großen Rest in einer High-Level-Sprache schreibt, die sehr ausdrucksstark ist - Diese Idee hat mich schon im Jahr 2001 überzeugt.

Welche Sprachen ich dafür einsetzen will, da konnte ich mich allerdings nicht sofort entscheiden. Als Low-Level-Sprache war C noch relativ naheliegend, auch wenn ich zwischenzeitlich sogar mal Pascal in Erwägung gezogen hatte. Als High-Level-Sprache begann ich mit Ruby, doch die Ausdruckskraft von LISP hat mich 2002 dazu gebracht, die Scheme-Implementierung Guile zu nutzen ("LISP is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud." -- Joel Moses).

Guile ist sicher ein nützliches Stück Software; es besteht aber aus rund 68.000 Zeilen C-Code. Der Quellcode des Evaluators beginnt mit dem Kommentar: "This is the evaluator. Like any real monster, it has three heads." Das ist nur solange lustig, bis man bemerkt dass es auch wahr ist. Die Kernfunktion des Evaluators besteht aus über 1400 Zeilen überwiegend nicht-trivialem Code. Ein Monster, tatsächlich. Aber nicht das schlimmste Monster.

2003 wollte ich Guile als High-Level-Sprache für ein Computerspiel nutzen, dessen Kern in C geschrieben war. Dazu musste ich ein Stück Code schreiben, dass mit dem Garbage-Collector (GC) von Guile interagiert. Dieser Code enthielt einen Fehler, der dazu führte, dass irgendwann der GC irgendwo abstürzte. Diesen Fehler konnte man natürlich nicht systematisch mit Hilfe eines Debuggers finden. Das fand ich sehr unangenehm. Was ich an Microsoft Windows immer am wenigsten mochte war, dass es oftmals praktisch unmöglich war, die Ursache von Fehlern zu finden, weil das System nicht durchschaubar war. Dabei spielt es auch keine große Rolle, ob das nun an proprietärer oder komplizierter Technologie liegt, der Effekt ist (leider) der gleiche: Man ist hilflos.

2004 habe ich eine Unmenge an Material gelesen, sowohl alte Dokumente von berühmten Informatikern wie Edsger Dijkstra, als auch aktuelle Papers über moderne Entwicklungen wie AOP. Ich bin dabei zu der Ansicht gelangt, dass insgesamt die Informatik bzw. die Software-Entwicklung eher eine falsche Richtung eingeschlagen hat (auch wenn natürlich viele neuere Entwicklungen auch gut sind). Ich habe dann die Hoffnung aufgegeben, dass jemand anderes die Software schreiben wird die ich haben will, und habe beschlossen es selbst zu tun.

Natürlich benutze ich eine Menge komplexer Software. So wie RMS nicht-freie Software benutzen musste, um die ersten GNU-tools zu schreiben, muss ich eben auch komplexe Software benutzen, bis ich einen Ersatz dafür habe. ;-)

Anfangs dachte ich, die Lösung die ich haben will sei einfach ein simples LISP ohne GC. Ich nannte das dann Polliwog, für "POlliwog is Like LIsp WithOut Garbage-collection". Im Jahr 2005 habe ich das eigentliche Problem erkannt, nämlich dass ich eine ausdrucksstarke Sprache ohne komplizierte Komponenten will. Die Stärken von LISP habe ich soweit möglich beibehalten (insbesondere das intensive Arbeiten mit Listen), und einige Stärken von Forth/PostScript kamen dazu, weil die Sprache nun stackbasiert ist. Entsprechend wurde das Projekt umbenannt in "Lists on a stack".

Nun habe ich es 2006 geschafft, eine erste benutzbare Version fertigzustellen, die aus ca. 3.500 Zeilen C-Code besteht. Die ein oder andere Baustelle gibt es zwar noch (und der Umfanng dürfte zumindest auf 4.000 Zeilen wachsen), aber ich kann nun anfangen damit ernsthaften Code zu schreiben. Was die Ausdrucksstärke angeht, hat die Sprache bislang meine Erwartungen sogar übertroffen. Ich habe noch nicht genügend Erfahrung damit, um endgültig beurteilen zu können, ob mein Ansatz praktikabel ist, aber eben diese Erfahrung werde ich nun sammeln.

last updated 2 years ago #

(Keywords: Programmierung, Web)

Ein Blog-Eintrag über das Wasserfall-Modell, der sehr lustig und äußerst traurig zugleich ist.

Update: Und die passende Konferenz dazu gibt es auch. Sehr amüsant.

last updated 2 years ago #