... ist vorbei.

Puah war das anstrengend.

Aber auch Produktiv.

Vor allem war überraschenderweise die Location der Kommunikation total zuträglich - ich hatte zuerst befürchtet das der Club mit seiner leicht verratzten und düsteren Atmosphäre das ganze eher unproduktiv gestalten könnte.

Es war aber genau das Gegenteil der Fall. Innen waren die Gespräche relativ strukturiert - obwohl sich 25 Leute gegenüber saßen. Und dadurch das es recht Eng und nicht soo schön und vor allem auch nicht soo gut belüftet war, wollten alle in schöner Regelmäßigkeit nach draußen auf die Straße zur Pause gehen.

Und diese Pausen waren gut! Die Gespräche wurden Befruchtet, neue andere Themen konnten zwanglos angeschnitten werden - oder man konnte auch einfach nur abschalten.

Alles in Allem: Gut. :-)

Schwieriges Thema. Die ganze Kommunikation findet ja schon fast ausschließlich online statt - da denkt man ja das Transparenz überhaupt kein Problem ist.

Tja... denkste.

Das Problem ist nämlich ein ganz anderes: Die Flut der Inhalte erschlägt jeden, der auch nur ansatzweise versucht das neben einem normalen Arbeitstag alles zu bewältigen.

Ugh.

Überraschung. Es braucht also doch noch mehr Energie um die Informationsflut übersichtlich zu machen.

Tja. Die müssen wir dann wohl erbringen. Aber Spaß machen tut es bisher noch nicht. :-(

Das Protokoll gibts immerhin.

Nur wie kriegt man das Zusammengefasst?

Ich nehm jedenfalls mit, dass der sehr viele Piraten aus verschiedenen Ländern anwesend waren. Super.

Und wir haben immerhin schöne Wünsche / Empfehlungen formuliert. Auch super.

Das Wichtigste war aber das sich die Leite aus den verschiedenen Landesverbänden wirklich Person zu Person unterhalten haben - und nicht immer nur Elektronisch kommunizieren.

Yay!

(zu Mother Earth von Within Temptation)

Diese Folien habe ich gestern gefunden.

Das Thema finde ich schon spannend - immerhin wird doch einiges angesprochen, das ich mal wieder auffrischen könnte. Monaden, und effiziente implementierungen von Sequenzen und Maps würden mich vor allem interessieren.

Aber leider kranken die Folien unter einem ganz spezifischen Problem: Sie strotzen nur so vor Begeisterung über die tollen typographischen Möglichkeiten von Tex.

:-(

Besonders bezeichnend finde ich Vorlesung 3.2. Ich meine, es ist ja schön, das man mit Tech Programme auf solch mathematische Art und Weise schreiben kann.

Aber wer bitte soll das Lesen? Und wieso wohl hat sich APL nicht durchgesetzt?

Im GCC gibt es auch eine Erweiterung die den tertiären Operator erweitert (test) ? ifTrueValue : ifFalseValue so dass man den mitleren Operanden weglassen kann um bei dieser Form zu landen aValue ?: ifValueEvaluatedToFalse. Das ist für sich gesehen nun jetzt erst einmal blöde - andersherum ergibt sich daraus die schöne Möglichkeit einen "Oder" Operator zu haben.

Das heißt: Muss man dieses Beispiel

void getImportantValue() {
    return somethingWhichGeneratesAStringOrNull();
}

erweitern, dass es nie null zurückgibt, sondern stattdessen immer mindestens einen leeren String, geht jetzt einfacher. Klassisch würde man das so machen müssen:

void getImportantValue() {
    char *value =  somethingWhichGeneratesAString();
    if (value) return value;
    else return "";
}

Oder eben kürzer mit der Erweiterung:

void getImportantValue() {
    return somethingWhichGeneratesAString() ?: "";
}

Ist diese Vereinfachung beim Schreiben die größere Komplexität beim Lesen wert? Immerhin wird fast kein C-Coder dieses Konstrukt kennen und daher zuerst einmal überrascht sein wird.

Vielleicht sollte man es dann also in ein Macro packen, das diese Funktion über den Namen dokumentiert, etwa

#define IF_NULL_USE ?:

Dann kann man aber eigentlich auch schon wieder ein Makro bauen das das explizit macht. So zum Beispiel:

#define IF_NULL_USE(testedValue, alternativeValue) (testedValue) ?: alternativeValue;

Oder man definiert sowas gleich als Funktion.

Und das ist genau das Problem dass diese Konstrukte, ob in Opal oder in C, immer haben. Es ist ja schön das man sowas machen kann - aber es dokumentiert sich selbst ganz beschissen. Und man schreibt den Code nun mal für andere Menschen - nicht für das Satzsystem. Also muss man doch eine Funktion oder ein Makro definieren, damit sich dieser Trick selbst dokumentiert - und dann kann man an der einen Stelle auch gleich ein if hinschreiben.

Schon lange hab ich mich gefragt, wieso eigentlich mich dieser eine Punkt an Python so sehr stört:

Jede Methode eines Objektes erhält als ersten Parameter eine Referenz auf das aufrufende Objekt.

Bisher konnte ich den Finger nie darauf legen konnte, wieso mir das eigentlich so auf den Keks geht. Bisher dachte ich immer das es mich stört, weil man schwieriger aus normalen Funktionen Methoden zu machen, beim Refactorn, aber so wirklich passt das nicht. Also dachte ich, vielleicht gewöhne ich mich ja irgendwann daran. Dem war aber nicht so.

Bei den Vorbereitungen zum Java-Kurs ist mir jetzt durch einen Hinweis von Robert der eigentliche Grund Aufgefallen.

Folgendes war der Auslöser: Wir haben uns gerade darüber unterhalten wie wir den Studenten im Java-Kurs erklären, wie sie this in Java verstehen sollen.

Naja, von der technischen Seite ist das klar - die Methoden sind im Klassenobjekt implementiert und die Methode braucht aber einen Weg um an die Daten zum gegenwärtigen Instanz-Objekt zu gelangen. Also wird dieses Instanz-Objekt als verstecktes erstes Argument übergeben, das immer den namen this trägt.

Soweit so klar.

Das Mentale Bild das man von diesem Systems hat, ist aber eigentlich anders: Darin gehören die Methoden zum Instanz-Objekt und "leben" auch darin - damit ist dann auch klar, wieso eine Instanz-Methode zugriff auf die Daten des Objekts hat und wieso zum Beispiel eine Klassen-Methode das nicht kann - sie lebt einfach im falschen Objekt.

Der Knackpunkt: this ist eigentlich ein Workaround (aber ein notwendiger) der zeigt wie diese Abstraktion implementiert wurde, der aber auch erlaubt eindeutig zu spezifizieren welchen Namensraum man jetzt meint. Jetzt möchte man aber die Implementierung möglichst von der Benutzung abstrahieren, damit man gut auf dieser Abstrakteren Ebene arbeiten kann und diese nicht ständig verlässt. Daher macht es viel Sinn diese Implementierung so transparent zu machen wie nur irgend möglich.

In Python dagegen ist das anders. Hier wird ganz Explizit immer self als erster Parameter geschrieben. Der Effekt? Ständig wird man daran erinnert das die Abstraktion eigentlich nicht so ist wie man sich das denkt und es tatsächlich alles anders implementiert ist in Python. Das Problem? Man erhält durch diesen Abstraktionsbruch keinen Vorteil - ja, alles ist expliziter, aber es bricht auch ständig mit der Abstraktionsschicht auf der man Arbeitet. Details der Implementierung "bluten" über dieses "Loch" in den ganzen Code den man schreibt.

Und saubere, klar getrennte Abstraktions-Ebenen sind einfach wichtiger als einfachste Implementierung - speziell für einen Sprachdesigner.

So, jetzt kurz ganz intensiv hinschauen - so sagen wir mal für 10 Sekunden.

Und, schon gesehen was es ist?

Ok, nochmal 10 Sekunden.

Jetzt?

Na, will ich es mal auflösen. Das ist ein Programm das in der von mir schon beschriebenen Veranstaltung Fortgeschrittene Techniken funktionaler Programmierung auf einer Folie erscheint.

Jep, als teil der Vorlesung für so sagen wir mal... 2 Minuten.

Aber jetzt zum Problem: Dieses Programm versteht man nicht! Schon gar nicht wenn man kein Opal kann - aber auch mit Opal-Kenntnissen hat man keine Chance.

Was für ein Schwachsinn diese ganzen Funktionssymbole sind. Als würden Programmiersprachen heute noch mit einer eigenen Tastatur kommen.) Vor allem aber haben sie ein Problem: Man muss den ganzen Kontext was sie Bedeuten komplett mitschleppen - was uns Menschen viel schwerer fällt als einfach ein Wort zu lesen das sagt worum es geht.

Jep.

Wer zweifelt, mag doch bitte das Programmfragment erklären.

q.e.d.

(Zu Rachel's Song von Vangelis)

Meine Bekannte Katrin hat sich eine Zeitschaltuhr zugelegt. Nun ja, da denkt man, diese Dinger gibts ja schon lange, kann ja alles nicht so schwer sein.

:-D

Nach längerer Zeit hat Sie herausgefunden wie der Funktioniert - zu zweit haben wir ihn dann mal im Detail angeschaut.

Schonmal vorweg: Meinen Respekt. Was die alles Falsch gemacht haben, muss man wirklich absichtlich machen, sonst geht das einfach nicht.

Hier erstmal ein Bild

Vielleicht das gute Vorne weg: Es ist klar eine Durchgangssteckdose, wo man was einsteckt ist schon mal einfach.

Nein, mehr positives fällt mir dazu nicht ein. Sorry.

Kommen wir mal zu den Details. Es ist eine Zeitschaltuhr. Völlig unbedarft erwartet man also erst einmal eine Uhr, die schaltet. Und wenn man das Bild betrachtet, dann ist das ja auch schon mal vertraut. Da sind Zahlen und die sind im Kreis angeordnet.

Ach ja, schalten... Das war schon die erste Schwierigkeit - wie schaltet man das gute Stück? Man muss die Schalter (der schwarze Kranz um das "Ziffernblatt" hoch oder herunterdrücken um den Strom zu schalten.

Interessanterweise gibt es auf dem guten Stück aber keinerlei Hinweis welche Stellung ein entspricht! Soweit ich das beurteilen kann scheint aber "herausgezogen" ein zu bedeuten. Sehr intuitiv.

Ach ja, und dann gibt es noch einen roten Schalter auf der Seite. Den haben wir auch nicht verstanden. Jetzt bei der Recherche hier zum Schreiben bin ich auf der Seite von Conrad-Elektronik fündig geworden. Offenbar ist das ein Master-Schalter der die Zeitschaltuhr völlig übergeht. Ist der UNBESCHRIFTETE Schalter also in der falschen Position, funktioniert sowieso gar nix.

Aber falls er zufällig richtig ist ist es trotzdem noch kompliziert - denn welcher der etwa 120 Schalter in dem Aussenring ist für welche Zeit zuständig? Beim Versuch das herauszufinden stößt man schnell darauf das man den äusseren Ring mit den Zahlen - das "Ziffernblatt" sozusagen - drehen kann.

Praktisch. So kann man zum Feststehenden Uhrzeiger die passende Uhrzeit einstellen.

Ich stelle mir das so vor: Damit man nicht völlig verzweifelt, wird man vermutlich die Uhr so einstellen, dass 0/24 Uhr oben ist, und dann stellt man sich einen Wecker, damit man die Uhr zum richtigen Zeitpunkt einsteckt, damit die Uhrzeit die er dann anzeigt zur Tageszeit passt. Und vielleicht betreibt man es vorher dann noch ein paar Stunden damit der Zeiger auf eine passende Stelle zeigt und man nicht um Mitternacht zum Zeitschaltuhr einstecken aufstehen muss.

Sehr komfortabel.

Ach ja, ausserdem stellt man ungefähr zu diesem Zeitpunkt fest, das die Beschriftung auf dem Ziffernblatt in die falsche Richtung ist. Nicht wie bei einer Uhr, nein, nein - natürlich anders herum. Auch wenn einem der Pfeil auf der "Zeiger"-Scheibe eine normale Richtung vorgaukeln möchte. Ach ja, natürlich macht der schon Sinn - denn den "Ziffernblatt"-Ring kann man nämlich ohne große Kraft nur in diese Richtung drehen. Oder soll - damit das einstellen der Uhrzeit noch "leichter" fällt vielleicht?

Der "Zeiger" jedenfalls bewegt sich genau in die andere Richtung.

Fassen wir also mal Zusammen:

• Schalten? An schwarzen Stiften, so etwa 10 min pro Stift, was ein und was aus bedeutet muss man aber durch trial und Error bestimmen
• Es gibt einen unbeschrifteten Schalter, der den ganzen Mechanismus ausser Kraft setzt - Was ein und was aus bedeutet muss man ausprobieren.
• Man dreht nicht die Scheibe mit dem Pfeil darauf, sondern den Ring aussen herum auf dem die Zahlen stehen.
• Damit stellt man die Uhrzeit zu dem feststehenden "Uhrzeiger" ein. Man stellt also nicht den "Uhrzeiger" sondern das "Ziffernblatt"
• Das "Ziffernblatt" ist in die falsche Richtung beschriftet

Eine tolle Uhr ist dass. Ich meine, man hat wirklich das Gefühl das der Konstruktör entweder noch nie eine Uhr in der Hand gehabt hat und daher etwas völlig neues erfinden musste, oder aber das er sich absichtlich überlegt hat, wie er seine Benutzer noch ein bisschen mehr quälen kann.

Wirklich faszinierend.

... war alles was ich noch sagen konnte, nachdem mir mein Vater ein (!!) Korn des Szechuanpfeffers gegeben hatte, die meine Verwandte Renate aus China mitgebracht hat.

Was die Wikipedia als "scharf-prickelnde Geschmack, der ein Gefühl der Taubheit auf Lippen und Zunge bewirkt" beschreibt ist in wirklichkeit ein intensives prickeln des ganzen Mundes, als stünde der ganze Rachen unter Strom!

Und das eine viertel-Stunde lang.

Dabei ist der Pfeffer eigentlich nicht scharf - man hat nur einen völlig betäubten Mund - der Geschmack ist wirklich nur als "volle Dröhnung" zu beschreiben.

Genau genommen, bin ich immer noch etwas high...

:) Cooles Zeug.

Nur wie man damit Würzen soll ist mir noch schleierhaft.

Da hab ich doch tatsächlich meinen ersten Kommentar zu einem Blog-Eintrag erhalten. Per mail von Felix!.

:)

Ja, ich muss noch an der Technik hier schrauben. Wird gemacht. Versprochen.

Hier zum Kommentar:

Richtig verstanden hat man erst wenn man es erklären kann. Das bedeutet aber auch, dass deine Erklärung nicht zu einem vollständigen Verständnis deiner Zuhörer_innen führen kann.

So hab ich diesen Satz noch gar nicht gesehen - aber das steckt da drinnen und ist absolut korrekt.

Allerdings...

Das bedeutet natürlich nicht, dass man sich weniger bemühen sollte auch schon bei der Erklärung eines Konzeptes so viel wie möglich erreichen zu wollen.

... muss man es trotzdem versuchen. Ein Kurs ist ja immer von ganz unterschiedlichen Menschen belegt, die jeder auf einem anderen Level sind.

Das Problem als Vortragender ist da natürlich das ich nicht individuell auf die einzelnen Zuhörer eingehen kann - um das Beispiel zu wählen das ihm am Meisten erklärt.

Das bedeutet aber natürlich auch, das damit jeder aus einem Vortrag etwas anderes mitnimmt. Ein perfekt strukturierter Vortrag gibt damit jedem der ihn hört genau das mit, was er benötigt um weiterzumachen und bietet bei erneutem hören weitere Inspiration.

Ok, das schafft man wohl nicht - aber das Ziel, das man das Material so präsentiert, das der Anfänger einen Einstieg hat, und der der etwas weiter ist, mehr mitnehmen kann - das hab ich schon.

Es heißt ja, das man etwas erst wirklich verstanden hat, wenn man es einem anderen Menschen beigebracht hat.

Nun, mir stellt sich mal wieder die Frage, im Rahmen des Javakurses der Freitagsrunde an der TU-Berlin:

Wie erklärt man Objektorientierung wirklich gut?

Verschiedene Kräfte zerren da an mir:

• Der Vortrag muss in eine Stunde passen
• Die Sprache anhand der es erklärt werden muss ist Java
• Die Studenten haben noch nie eine Programmiersprache gesehen
  • oder vorher eine Funktionale Sprache gelernt, die sie nicht verstanden haben

Was mir am meisten am Herzen liegt sagt Kent Beck in Smalltalk best Practice Patterns einfach wunderschön:

Objects model the world through behavior and state. Behavior is the dynamic, active, computational part of the model. State is what is left after behavior is done, how the model is represented before, after, and during a computation.

Of the two, behavior is the more important to get right. The primacy of behavior is one of the odd truths of objects, odd because it flies in the face of so much accumulated experience. Back in the bad old days you wanted to get the representation right as quickly as possible, because every change to the representation bred changes in many different computations.

Objects (done right) change all that. No longer is your system a slave of its representation. Because objects can hide their representation behind a wall of messages, you are free to change representation and only affect one object.

Nur leider können die Studenten mit dem Vergleich in die alten Tage nix anfangen, denn sie haben ja gerade keine Erfahrung warum die alten Tage schlecht waren.

Immerhin der erste Satz ist brauchbar - und ich werde ihn tunlichst einbringen. Damit ist das Problem doch schon mal zumindest kleiner geworden.

Denkfutter bis zum nächsten mal...

Weiß ich nicht, aber ich weiß, was für Folgen es hat.

Wenn man ohne Tests entwickelt, dann hat man beim Schreiben von z.B. einer Klasse immer den vollen Zugriff auf das gesamte System - und es ist ständig verlockend, nur eben dieses andere Subsystem aufzurufen oder es in die klasse als Instanzvariable einzubinden. Da man kein Korrektiv hat, sind die Folgen dieser Handlungen fast unsichtbar. Die Abhängigkeiten im System nehmen immer weiter zu - und die Architetkur immer weiter ab. :/

Als Testgetriebener Entwickler muss man sich, um den Code in einer Testsuite überhaupt laufen lassen zu können maximal vom Rest des Systems abkapseln. Das bedeutet das man sich bei jeder Abhängigkeit die man dazu nimmt genau überlegt, ob man sie wirklich braucht, ob man sie erreichen kann, indem man einen Parameter übergibt, oder indem man ein Protokoll einführt das die Kommunikation dieser zweier Systembestandteile klärt. Immer macht man sich über die Grenzen der Komponente Gedanken und wie die Kommunikation darüber hinaus abläuft.

Man macht eben nicht einfach nur einen Konstruktorparameter über den dann als globale Variable alles zugänglich ist - den man im Test aber niemals instanziiert bekommt.

Diese Tatsache macht für mich einen der größten Unterschiede zwischen Testgetrieben entwickeltem Code und sonstigem Code aus.

Es ist unglaublich schwierig (auf anhieb) Code zu schreiben der Wiederbenutzbar ist und wenig Abhängigkeiten besitzt - wenn man Code testgetrieben entwickelt bekommt man aber unheimlich viel davon umsonst.

Alleine deswegen darf es heute eigentlich keine Ausrede mehr Geben ohne Tests zu entwickeln.