Swap-Funktion für Bubble Sort: Stilfrage

[paedubucher]

Ich absolviere gerade einige Kurse auf Coursera, u.a. einen Kurs über die Programmiersprache Go, die ich eigentlich schon recht gut kenne. Vorweg: Einige Kurse auf Coursera sind anspruchsvoll und sehr hochwertig (z.B. die Machine-Learning-Kurse von Andrew Ng), dieser hier ist eher etwas mehr auf Anfänger-Niveau. Wie auch immer: ich will ihn mal durchziehen.

Nun muss man in der ersten Woche in einer Übung einen Bubble Sort entwickeln. Eine Anforderung ist es, dass man eine Swap-Funktion implementiert, die das Element an Stelle i mit dem Element an Stellt i+1 vertauscht:

Code: Alles auswählen

func Swap(elements []int, i, int) {
    temp := elements[i]
    elements[i] = elements[i+1]
    elements[i+1] = temp
}

Nun habe ich es stattdessen so implementiert, dass man Swap zwei Indizes übergibt: i und j, an deren Stellen dann die Elemente vertauscht werden:

Code: Alles auswählen

func Swap(elements []int, i, j int) {
    temp := elements[i]
    elements[i] = elements[j]
    elements[j] = temp
}

Für meine Implementierung habe ich Punktabzüge bekommen, weil ich ein anderes Interface anbiete als verlangt. Der Punktabzug hat keine negativen Konsequenzen, ich finde es aber dennoch eigenartig.

Nun die Argumente für die Implementierung mit nur einem Index:

1) Es entspricht exakt der Aufgabenstellung.
2) Für Bubble Sort genügt eine Implementierung, die zwei benachbarte Elemente vertauscht.

Meine Gegenargumente lauten:

1) Die Umsetzung mit nur einem Index ist nicht wiederverwendbar für andere Sortieralgorithmen (Quick Sort, Insertion Sort), welche Elemente vertauschen müssen, die nicht benachbart sind.
2) Die Umsetzung mit nur einem Index ist eine schlechte Abstraktion, da ich im Code nachschauen muss, ob Element i mit Element i+1 oder i-1 vertauscht wird. Ich kann die Funktion dadurch nicht als Blackbox betrachten. Wenn ich hingegen zwei Indizes übergeben muss, weiss ich schon vom Interface her, was da passieren muss.

Meinem Gegenargument 1) könnte man entgegnen, dass die generalisierte Implementierung mit zwei Indizes "auf Vorrat" programmiert wird, da man für Bubble Sort ja nur benachbarte Elemente tauschen muss. Dagegen könnte man wieder sagen, dass dieses "auf Vorrat" programmieren ja gratis sei, zumal ein Tauschen von i mit i+1 oder i mit j keine Komplexitätssteigerung, jedoch eine Verallgemeinerung ist.

Was meint ihr zu diesen Argumenten?

Einige von euch mögen vielleicht Nase rümpfen über die Diskussion rümpfen, da es ja scheinbar nur um wenig geht, ich diskutiere aber recht gerne über Stilfragen

[Meillo]

Diese Art von Lehre scheint auf eine sehr mechanische Weise zu funktionieren. Du hast nicht genau das gemacht, was gefordert war, darum hast du Punktabzuege bekommen. Dass dir eine andere Art von Lehre lieber waere, ist gut und schoen, aendert aber wohl nichts daran, dass dort nicht Sinnhaftigkeit, Selberdenken und Stimmmigkeit eigener Umsetzungen gewuenscht sind (und in diesem Lehrformat vielleicht auch grundsaetzlich nicht realisierbar sind). Jedenfalls macht es diesen Eindruck.

Was genau ist nun deine Zielrichtung:
- Willst du eine Reaktion auf die Bewertung vorbereiten und dafuer deine Argumente pruefen?
- Oder geht es dir (unabhaengig von Coursera) um eine grundsaetzliche Diskussion von Designentscheidungen anhand dieses Beispiels?

[Meillo]

Btw:

Eine kleine Online-Recherche sagt mir, dass Go Double-Assignments hat, somit wuerde man das doch eher direkt an der Stelle so realisieren (und den Funktionsaufruf ganz weglassen):

Code: Alles auswählen

elements[i], elements[i+1] := elements[i+1], elements[i]

(bzw. ggf. mit mehr Listensyntax Sugar, den ich nicht kenne)

[paedubucher]

Diese Art von Lehre scheint auf eine sehr mechanische Weise zu funktionieren. Du hast nicht genau das gemacht, was gefordert war, darum hast du Punktabzuege bekommen. Dass dir eine andere Art von Lehre lieber waere, ist gut und schoen, aendert aber wohl nichts daran, dass dort nicht Sinnhaftigkeit, Selberdenken und Stimmmigkeit eigener Umsetzungen gewuenscht sind (und in diesem Lehrformat vielleicht auch grundsaetzlich nicht realisierbar sind). Jedenfalls macht es diesen Eindruck.

Die Bewertungsfunktionen bei den meisten Kursen sind durchaus mechanisch. Beim Kurs "Machine Learning" lässt man z.B. seinen Code gegen eine (nicht sichtbare) Testsuite validieren. Und diese harte Korrektheit (teils mit möglichen Abweichungen) bekommt man aber auch nur hin, wenn man die Konzepte verstanden hat. Von daher würde ich das Konzept nicht pauschal aburteilen.

Ich bin im Gegenteil positiv davon überrascht, wie gut die das hinkriegen. Neuere Kurse verwenden Jupyter Notebooks, die dann im Hintergrund validiert werden. Der Kurs in der funktionalen Programmierung mit Scala hat ein ähnliches Konzept die der erstgenannte Kurs "Machine Learning" (quasi der Vater aller Coursera-Kurse). An der Fachhochschule habe ich praktisch nur negative Erfahrungen mit mechanischer Bewertung gemacht. Bei Coursera habe ich gesehen, dass man durchaus sinnvolle mechanische Validierungen umsetzen kann, wenn auch nur in einigen Teilbereichen.

Lustigerweise war bei dieser Validierung (Swap-Funktion) ein menschlicher Korrektor am Werk, der jedoch 1:1 gemäss Anweisungen bewertet hat. Ich kann zwar die Bewertung kommentieren, eine Antwort werde ich aber wohl nicht erhalten.

Was genau ist nun deine Zielrichtung:
- Willst du eine Reaktion auf die Bewertung vorbereiten und dafuer deine Argumente pruefen?
- Oder geht es dir (unabhaengig von Coursera) um eine grundsaetzliche Diskussion von Designentscheidungen anhand dieses Beispiels?

Eine Reaktion habe ich bereits abgegeben, siehe meine Argumente oben. Ich bezweifle, dass sich der Autor des Kurses persönlich bei mir melden wird. (Ausschliesen kann ich es aber nicht.) Es geht mir also nicht darum, mich für eine Debatte zu rüsten, auch wenn ich dieser nicht ausweichen würde.

Ich möchte lieber zweierlei beantworten: 1) Ist meine Argumentation stichhaltig? 2) Gibt es Kriterien, anhand derer man zwischen "Programmieren auf Vorrat" und angemessener Generalisierung unterscheiden kann?

Gerade die zweite Frage ist für meine Programmierpraxis und mein Verständnis derselben auch sehr relevant.

[paedubucher]

Btw:

Eine kleine Online-Recherche sagt mir, dass Go Double-Assignments hat, somit wuerde man das doch eher direkt an der Stelle so realisieren (und den Funktionsaufruf ganz weglassen):

Code: Alles auswählen

elements[i], elements[i+1] := elements[i+1], elements[i]

(bzw. ggf. mit mehr Listensyntax Sugar, den ich nicht kenne)

Von Python herkommend auf Go zurückwechselnd bin ich wohl zu weit in Richtung C gegangen: Ja, diese Syntax wird in Go auch unterstützt; das habe ich ganz vergessen. Jedoch funktioniert := nur im Zusammenhang mit der Initialisierung. In diesem Kontext muss es = sein. Sonst meint der Compiler: non-name elements on left side of :=.

[Meillo]

Ich möchte lieber zweierlei beantworten: 1) Ist meine Argumentation stichhaltig? 2) Gibt es Kriterien, anhand derer man zwischen "Programmieren auf Vorrat" und angemessener Generalisierung unterscheiden kann?

Gerade die zweite Frage ist für meine Programmierpraxis und mein Verständnis derselben auch sehr relevant.

Generalisierung macht den Code meist kuerzer und klarer. Wenn er stattdessen komplexer wird, in einer Weise die derzeit nicht noetig ist oder direkt absehbar ist, dann ist es auf Vorrat.

In den zwei Implementierungen sehe ich keinen Unterschied in der Komplexitaet. Ich finde die Variante mit den separaten Indices auch klarer, weil eindeutig ist, welche Elemente getauscht werden. Die Frage, ob mit dem davor oder mit dem danach -- die in beiderlei Weise gleich viel Sinn macht -- entfaellt. (Falls man nur einen Index verwendet, dann sollte man die Frage mittels des Funktionsnamens beantworten: swapWithNext() oder so.)


Ein bisschen finde ich deine zweite Frage zu akademisch, zu theoretisch, zu abstrakt. Wenn ich mich beim Programmieren an die Ziele vom Cover von Kernighan und Pikes ``The Practice of Programming'' -- Simplicity, Clarity, Generality -- halte, dann komme ich selten an den Punkt, wo ich mich fragen wuerde, ob etwas eine angemessene Generalisierung oder auf Vorrat ist. Dieses ``auf Vorrat'' scheint mir typisch fuer Projekte in denen man Pflichtenhefte mit Anforderungslisten umsetzt. Wenn man dagegen konkrete Probleme loest indem man Software inkrementell schreibt, die man selber einsetzt und ganz eng mit den Nutzern verzahnt ist, dann besteht wohl wenig Gefahr ueberhaupt in diese Richtung abzurutschen. (Okay, wenn man natuerlich in Studium oder Ausbildung jahrelang auf Software-Engineering getrimmt worden ist, dann wird es womoeglich schon eine Schwierigkeit sein, das und die damit direkt verbundene Gefahr des Overengineerings und des Auf-Vorrat-Programmierens abzuwehren.)

Wahrscheinlich ist das wie wenn man Picasso fragen wuerde, wie er weiss, wie viele oder wie wenige Striche noetig sind um die Essenz des Stieres darzustellen. Er hat sich halt jahrelang damit beschaeftigt, genau das rauszufinden. Und dann konnte er es umsetzen, aber eine konkrete Antwort koennte nur erklaeren wie er seinen Stier nun malt. Sie kann nicht erklaeren wie man es in irgend einem anderen Fall macht. Die einzige Antwort dafuer ist wohl: Man muss es genau so machen wie Picasso: viele, viele Versuche um selber die Essenz zu finden. Man muss es lernen zu spueren. Man muss den passenden Blick entwickeln. Man braucht die Erfahrung der vielen, vielen Fehlschlaege. Die zeigen einem den Weg.

Wenn ich wuesste wie es mit dem Stil beim Programmieren so genau waere, dann wuerde ich ein Buch darueber schreiben. Ich habe wenig Hoffnung, dass das passieren wird. Ich kenne aber Buecher, die gute Hilfen sind, um es selber fuer sich rauszufinden. Das oben erwaehnte ist eines davon.


Wie du das hier machst, finde ich schon ganz gut. Du analysierst deine eigene Umsetzung im Vergleich zu alternativen. (Danke bei Gelegenheit dem Korrektor, dass er dir Punkte abgezogen hat, weil er damit deine Motivation dazu angestachelt hat!) Nun solltest du die beiden Implementierungsvarianten im naechsten Projekt umsetzen und schauen was passiert, wenn du es auf die eine oder andere Weise machst. Was hat es fuer Auswirkungen und wie fuehlt es sich an? (Dafuer ist das konkrete Beispiel hier etwas zu trivial.) Ich glaube, dass es immer beides braucht: die theoretische Analyse (inkl. Argumentation und Verteidigung) und die praktische Umsetzung. In Kombination kommst du zu den Erkenntnissen und entwickelst einen Blick und ein Gefuehl fuer die Dinge.

Ich stelle fest, dass es kaum moeglich ist, pauschale Aussagen zum Stil zu machen. Das ist alles hochgradig abhaengig vom Kontext. Das ist ganz grundsaetzlich ein Abwaegen in einem komplexen System. Was ich im einen Projekt sehr hilfreich finde, kann ich im anderen Projekt auch katastrophal finden. Nur die anzustebenden Ziele (sowas wie Simplicity, Clarity und Generality) bleiben gleich.


Ich hoffe, diese Gedanken -- einfach mal wild in den Raum -- bringen dir etwas. Wir koennen uns gerne thematisch auch wieder auf Teilaspekte fokussieren, nachdem ich hier eher gross ausgeholt habe.

[paedubucher]

Ich möchte lieber zweierlei beantworten: 1) Ist meine Argumentation stichhaltig? 2) Gibt es Kriterien, anhand derer man zwischen "Programmieren auf Vorrat" und angemessener Generalisierung unterscheiden kann?

Gerade die zweite Frage ist für meine Programmierpraxis und mein Verständnis derselben auch sehr relevant.

Generalisierung macht den Code meist kuerzer und klarer. Wenn er stattdessen komplexer wird, in einer Weise die derzeit nicht noetig ist oder direkt absehbar ist, dann ist es auf Vorrat.

Kurz und klar können aber auch gegensätzlich sein, wie z.B. in meinem Beispiel: Ein weiterer Parameter macht die Parameterliste länger, schafft aber mehr Klarheit.

In den zwei Implementierungen sehe ich keinen Unterschied in der Komplexitaet. Ich finde die Variante mit den separaten Indices auch klarer, weil eindeutig ist, welche Elemente getauscht werden. Die Frage, ob mit dem davor oder mit dem danach -- die in beiderlei Weise gleich viel Sinn macht -- entfaellt. (Falls man nur einen Index verwendet, dann sollte man die Frage mittels des Funktionsnamens beantworten: swapWithNext() oder so.)

Mit dem Funktionsnamen kann man auch vieles Ausdrücken. Aber bloss Swap() drückt halt die Nachbarschaft nicht aus.

Ein bisschen finde ich deine zweite Frage zu akademisch, zu theoretisch, zu abstrakt. Wenn ich mich beim Programmieren an die Ziele vom Cover von Kernighan und Pikes ``The Practice of Programming'' -- Simplicity, Clarity, Generality -- halte, dann komme ich selten an den Punkt, wo ich mich fragen wuerde, ob etwas eine angemessene Generalisierung oder auf Vorrat ist. Dieses ``auf Vorrat'' scheint mir typisch fuer Projekte in denen man Pflichtenhefte mit Anforderungslisten umsetzt. Wenn man dagegen konkrete Probleme loest indem man Software inkrementell schreibt, die man selber einsetzt und ganz eng mit den Nutzern verzahnt ist, dann besteht wohl wenig Gefahr ueberhaupt in diese Richtung abzurutschen. (Okay, wenn man natuerlich in Studium oder Ausbildung jahrelang auf Software-Engineering getrimmt worden ist, dann wird es womoeglich schon eine Schwierigkeit sein, das und die damit direkt verbundene Gefahr des Overengineerings und des Auf-Vorrat-Programmierens abzuwehren.)

Das "auf Vorrat" ist sicherlich in Projekten eher ein Kriterium als bei Programmieraufgaben. Wenn ich in einem Kontext einen Bubble Sort implementiere, weil der für den Moment gut genug ist, kann dieser doch später der Flaschenhals sein. Bubble Sort schreit als Algorithmus ja gerade nach seiner Ersetzung

In der Domäne (Sortierung) ist nun der Gedanke an andere Sortieralgorithmen nicht weit. Mit meiner Swap()-Funktion erhalte ich in diesem Kontext einen generellen Baustein, der für Bubble Sort kein Overkill ist, aber auch wiederverwendet werden kann.

Wahrscheinlich ist das wie wenn man Picasso fragen wuerde, wie er weiss, wie viele oder wie wenige Striche noetig sind um die Essenz des Stieres darzustellen. Er hat sich halt jahrelang damit beschaeftigt, genau das rauszufinden. Und dann konnte er es umsetzen, aber eine konkrete Antwort koennte nur erklaeren wie er seinen Stier nun malt. Sie kann nicht erklaeren wie man es in irgend einem anderen Fall macht. Die einzige Antwort dafuer ist wohl: Man muss es genau so machen wie Picasso: viele, viele Versuche um selber die Essenz zu finden. Man muss es lernen zu spueren. Man muss den passenden Blick entwickeln. Man braucht die Erfahrung der vielen, vielen Fehlschlaege. Die zeigen einem den Weg.

Hier habe ich in der Praxis auch schon bemerkt, dass junge Programmierer es oft mit Prinzipientreue übertreiben (z.B. das Aufschieben von konkreten Entscheidungen in Java-Projekten, wo man manches auf Vorrat mal dynamisch hält). Erfahrene Programmierer haben hier öfters mehr Feingefühlt. Oder vielleicht werden sie auch nur bequemer, und gehen ein kleines Risiko für ein kleines Refactoring ein?

Wenn ich wuesste wie es mit dem Stil beim Programmieren so genau waere, dann wuerde ich ein Buch darueber schreiben. Ich habe wenig Hoffnung, dass das passieren wird. Ich kenne aber Buecher, die gute Hilfen sind, um es selber fuer sich rauszufinden. Das oben erwaehnte ist eines davon.


Wie du das hier machst, finde ich schon ganz gut. Du analysierst deine eigene Umsetzung im Vergleich zu alternativen. (Danke bei Gelegenheit dem Korrektor, dass er dir Punkte abgezogen hat, weil er damit deine Motivation dazu angestachelt hat!) Nun solltest du die beiden Implementierungsvarianten im naechsten Projekt umsetzen und schauen was passiert, wenn du es auf die eine oder andere Weise machst. Was hat es fuer Auswirkungen und wie fuehlt es sich an? (Dafuer ist das konkrete Beispiel hier etwas zu trivial.) Ich glaube, dass es immer beides braucht: die theoretische Analyse (inkl. Argumentation und Verteidigung) und die praktische Umsetzung. In Kombination kommst du zu den Erkenntnissen und entwickelst einen Blick und ein Gefuehl fuer die Dinge.

Vielleicht ist das Problem an diesem Kurs auch, dass die einzelnen Programmieraufgaben nicht zusammenhängen. Hier möchte ich erneut den "Machine Learning"-Kurs hervorheben. Man entwickelt da z.B. eine Funktion zur Initialisierung von Gewichtsmatritzen und erhält die Dimensionsparameter dazu. Wenn man da nicht aufpasst, und konkrete Werte statt eines zur Verfügung stehenden Parameters verwendet, funktioniert zwar der nächste Schritt; bei einer späteren Wiederverwendung mit einem grösseren neuronalen Netzwerk funktioniert dann aber plötzlich gar nichts mehr, und man startet wieder auf Feld 1. In diesem Sinne macht es der isolierte und triviale Kontext schon schwierig, hier Lösungsprinzipien zu finden.

Ich stelle fest, dass es kaum moeglich ist, pauschale Aussagen zum Stil zu machen. Das ist alles hochgradig abhaengig vom Kontext. Das ist ganz grundsaetzlich ein Abwaegen in einem komplexen System. Was ich im einen Projekt sehr hilfreich finde, kann ich im anderen Projekt auch katastrophal finden. Nur die anzustebenden Ziele (sowas wie Simplicity, Clarity und Generality) bleiben gleich.


Ich hoffe, diese Gedanken -- einfach mal wild in den Raum -- bringen dir etwas. Wir koennen uns gerne thematisch auch wieder auf Teilaspekte fokussieren, nachdem ich hier eher gross ausgeholt habe.

Ich sollte vielleicht besser mal "The Practice of Programming" fertig durcharbeiten statt auf Coursera Videokurse zu machen.

Aber ich schlafe noch einmal über dieses Thema.

[eggy]

Ich hab zuwenig Ahnung von Go, als dass ich das jetzt fundiert begründen könnte, aber ne Funktion mit drei Parametern ist vom Aufbau (Callstack) immer aufwändiger als eine mit 2.
Man könnte das mal Benchmarken, ob bzw ab welcher Wiederholungsanzahl das merkliche Auswirkungen hat.

Wichtiger ist aber, dass man sich als "Anfänger" erstmal dran gewöhnt, dass man den "Specs" haarklein flogt. Abweichen ist nur _nach_ Freigabe drin. Stell Dir mal vor, Du arbeitest in nem großen Team, beim Design werden die Übergabepunkte der Funktionen festgelegt und einer springt dann mal aus der Reihe und macht "was er für besser hält". Die "API" die die Externen erwarten, tut nicht, die Schnittstellen, die die anderen Teams erwarten, gibt's nicht, und das Team, was die 2-Parameterversion fürs Osterei geschrieben hat, wundert sich, warum ihr Code überschrieben wurde.

Ich finde "ein Parameter" in dem Fall übrigens besser, aus folgenden Gründen:
a) Du verhinderst Fehler, die sich sonst außerhalb Deines Einflussgebiets befinden. Dinge wie "vertausche i mit i" können nicht passieren. Dass das hier kein Problem ist, ist klar, aber in anderen Fällen hätte man so einen Fehlercase by Design ausgeschlossen.
b) Die API ist eindeutig, man braucht sich als Nutzer nicht fragen, muss ich erst a oder erst b angeben.
c) Der Test, ob die Werte innerhalb Deines Arrays liegen, ist weniger aufwändig. i=>0 und i+1<len(array), wohingegen Du bei unabhängigem i und j vier Tests brauchst. (Wo sind die Gültigkeitstests eigentlich? Oder ist das ne Eigenheit von Go?)

Edit: Typo

[Meillo]

Ich finde, dass eggys Beitrag im Vergleich zu meinem gut zeigt, wie unterschiedlich die Betrachtungswinkel sein koennen. Jede dieser Perspektiven und Priorisierungen kann Sinn machen. Es kommt eben darauf an. Das haengt sicher von den Philosophien ab, denen man anhaengt, aber ebenso vom konkreten Projekt, mit all seinem Kontext.

Erfahrene Programmierer haben hier öfters mehr Feingefühlt. Oder vielleicht werden sie auch nur bequemer, und gehen ein kleines Risiko für ein kleines Refactoring ein?

Mir gefaellt es am besten, wenn man das Refactoring als normalen Prozess der Programmierung ansieht, also mehr als ein konstantes Ueberarbeiten des Codes, an dem man schreibt und den man bisher geschrieben hat. Das sieht die Codebasis als sich staendig verwaendernde und sich wandelnde Masse an. So ein inherent inkrementeller und fliessender Ansatz funktioniert natuerlich nur wenn die Umgebung wie die Mitprogrammierer und der Nutzer/Kunde auch in der Weise arbeiten kann. Das ist dann ein doch sehr anderes Vorgehen, als mit einem fixeren Plan und fixeren Interfaces.

Beides kann gut funktionieren. Jede Person hat wohl persoenliche Praeferenzen und es gibt gute Gruende fuer jede Weise. Letztlich entscheidet, was in der konkreten Situation und dessen Kontext am besten funktioniert und Sinn macht.

Gute Programmierer koennen wohl eher in verschiedener, der jeweiligen Situation angepasster Weise, arbeiten. Sie bleiben nicht in einer einzigen Sicht- und Arbeitsweise verhaftet. (Aber das ist auch schon wieder eine subjektive Bewertung.)

[paedubucher]

@eggy: Performance ist natürlich ein gutes Stichwort im Kontext von Sortierfunktionen. Soweit habe ich gar nicht gedacht. Sollte es aber wirklich performant werden, sollte man a) nicht auf Bubble Sort setzen und b) Swap besser inline hinschreiben denn als Funktion implementieren.

[Meillo]

b) Swap besser inline hinschreiben denn als Funktion implementieren.

... oder den Compiler das wegoptimieren lassen. Ausgereifte Compiler koennen das heutzutage besser als der Programmierer. Die Herausforderung verlagert sich dann mehr dazu, den Code so zu schreiben, dass der Compiler die Moeglichkeit hat, ihn zu optimieren.


Aber was Optimierungen fuer den Computer im Gegensatz zu Optimierungen fuer den Menschen angeht, habe ich ja eh eine Aussenseitermeinung.
http://marmaro.de/docs/chaosseminar/on-performance/

War es nicht Ken Thompson, der mal gesagt hat, dass die meisten Sortierungen, die man in der Praxis durchfuehrt eh nur ein Dutzend oder so Elemente umfassen und dort das Sortierverfahren egal ist. Und fuer den Rest ist Quicksort gut genug (von Problemen in Spezialdomaenen abgesehen). Jedenfalls ging seine Aussage sinngemaess in diese Richtung.


Manchmal finde ich es schwierig anhand von so akadmischem Code wie Sortieralgorithmenimplementierungen reale Probleme zu diskutieren, weil dieser Code so fern aller Praxis ist. Diskutiert man dann die Theorie oder die Praxis? In so einem Code gibt es keine Praxis und projeziert man ihn in ein Praxissetting, dann ist das Setting viel ausschlaggebener als der Code selbst.

Natuerlich sind die meisten realen Probleme viel zu komplex und die Codebasen zu gross und zu verwoben, um gut darueber diskutieren zu koennen. Das ist es, was ich an Kernighans Buechern (The Practice of Programming, The Elements of Programming Style) so schaetze: Alles darin ist realer Code. Keine akadmischen Problemstellungen sondern Code aus der Praxis, und doch ueberschaubar und verstaendlich. Diomidis Spinellis hat diesen Ansatz in ``Code Reading'' auch gut umgesetzt. (Sein Folgewerk ``Code Quality'' ist leider zu theoretisch geworden und leidet unter dem Second-System-Effekt, IMO.)