Programmieren Lernen - mit Scheme?

written by Martin Häcker on

Meine Freunden hat sich mal damit beschäftigt. Und da dachte ich, schauste doch mal was es da so gibt.

Klaro das große alte SICP, der Großvater aller großartigen Programmierbücher mit Tiefgang. Gleichzeitig aber natürlich auch ziemlich Tief und für jemanden der sonst von Informatik nicht so viel Ahnung hat vielleicht zu viel.

Das sehen andere Leute auch so und daher gibt es inzwischen einen Nachfolger: Das HTDP.

Well, die Haupt Kritik war eigentlich das das Buch zu viele Grundlagen in der Elektrotechnik verlange und zu tief in die Konstruktion von Computern hineingeht, dabei aber gleichzeitig zu wenig darüber erklärt wie man eigentlich ein größeres Programm aufzieht.

Und genau das wollten sie anders machen.

Gut fand ich dass Sie sich mühe geben jede ihrer Kapitel mit einem Rezept abzuschließen, in dem dann Dinge stehen wie "Mach dir erst Gedanken darüber was aus deinen Funktionen herauskommen muss bevor Du sie implementierst, damit Du Logikfehler besser finden kannst. - Schon mal ein guter Ansatz.

Dazu kommt durchweg eigentlich ein recht sauberer Programmierstil mit dem ich durchaus leben kann.

Was mir eher auf den Geist ging: Die ganze Zeit über predigen sie es, dass man zu jeder Funktion einen "Kontrakt" schreibt, der erklärt welche Typen man erhält und welche man zurückgibt.

Well, das ist ja ganz schön, aber entweder, soll man eine Sprache mit Typechecking nehmen, oder es lassen. Die Dokumentation ist zwar ganz nett - aber dann doch bitte so, dass man die Variablen so eindeutig benennt, das keine Typ-Unsicherheiten auftreten.

So sind die Kommentare (von denen sie pro Funktion mindestens drei bis fünf Zeilen haben wollen) nach der ersten Änderung einer Funktion nicht mehr aktuell.

:-(

Dazu kommt, dass der Klammernwald von Scheme, natürlich gerade für Anfänger schnell mal verwirrend wird und ohne Editor-Unterstützung gar nicht handhabbar ist. Andererseits: da gewöhnt man sich gleich daran kleine Funktionen zu schreiben...

Was ich auch merkwürdig finde ist, dass den studenten die wirkliche Freude eines metazirkulären Interpreters vorenthalten wird. Da hat man sowas mit Scheme schon unter der Haube, und dann geht es irgendwann um den Interpreter und es werden lauter neue Datentypen eingeführt um etwas Scheme-Ähnliches darzustellen, dass dann nicht mal richtig interpretiert werden kann.

Habt ihr wirklich toll gemacht.

Generell hat das Buch weniger Tiefgang als das [- vor allem weil es dazu natürlich die ganz hervorragenden http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/ Video-Lectures gibt, die einfach nur begeisternd sind.

Fazit: Irgendwie hat das Buch schon Sinn - aber Begeistern kann es mich nicht. Mal schauen wie es meiner Freundin geht. :)

p.s.: Zum SICP gibt es noch einen Nachfolger, SICM - Structure and Interpretion of Classical Mechanics. Das werd ich mir mal demnächst ansehen müssen. :)

Computational Thinking

written by Martin Häcker on

Was ist Informatik? Jeannette Wing bringt es ganz hervorragend auf den Punkt:

Computational thinking is thinking recursively. It is parallel processing. It is interpreting code as data and data as code. It is type checking as the generalization of dimensional analysis. It is recognizing both the virtues and the dangers of aliasing, or giving someone or something more than one name. It is recognizing both the cost and power of indirect addressing and procedure call. It is judging a program not just for correctness and efficiency but for aesthetics, and a system’s design for simplicity and elegance.

Dem ist eigentlich nichts mehr hinzuzufügen - ausser vielleicht einem deutschen Begriff. Einen Perfekten Begriff habe ich noch nicht gefunden, aber einen Vorschlag: Informatisches Denken.

Wikipedia braucht einen neuen Namen

written by Martin Häcker on

Soeben habe ich volgende fiktive Pressemitteilung zur Veröffentlichung erhalten:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Aufwendige Untersuchungen haben ergeben, dass der gegenwärtige Name des liebevoll auch "allwissenden Müllhalde" genannten Nachschlagewerks geändert werden muss.

"Wir waren selbst von den Ergebnissen überrascht!" sagt ein Sprecher für das Projekt, "Wir hätten erwartet das wir den Namen erst wegen einer Copyright-Verletzung verlieren würden - und jetzt dass".

Aber die Ergebnisse sind eindeutig - der Name lässt sich einfach nicht in einen kurzen Satz pressen, so wie "Google es einfach". "Wikipedia es doch" funktioniert einfach nicht. Das ist das Grundproblem.

Die nun beginnende Diskussion um einen würdigen Nachfolger wird von allen Community-Mitgliedern mit Spannung verfolgt. Immerhin muss solch ein Satz in über 20 Sprachen funktionieren können - ein nicht triviales Problem bis zu dessen Lösung das Projekt aber in seinem gegenwärtigen Zustand eingefroren wird.

"Das ist ein notwendiger Schritt um die Kräfte Freizumachen die wir benötigen um diese Namensdiskussion voranzutreiben." Sagt der Sprecher der Wikipedia erneut auf unsere Nachfrage.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Oder habe ich etwas übersehen und es gibt so einen Satz mit dem man effizient antworten kann?

Vorschläge willkommen.

Unser Feind - **das Bundesverfassungsgericht**

written by Martin Häcker on

Durch Denkanstoß von CHRISTIAN RATH

Wer hätte das Gedacht. Die letzte Bastion der Gerechten in einem Staat voller kranker, überwachungsgeiler Politiker. Ein Kleines Dorf umgeben von vier Garnisonen....

Aber wenn man drüber nachdenkt: Das Bundesverfassungsgericht ist seit geraumer Zeit schon die letzte Hoffnung für alle Menschen die vernünftige Gesetze fordern. Jedes Sicherheitsgesetz macht eine Zwischenrunde durch Karlsruhe - und wird dort Beschnitten.

Und genau das ist das Problem. In Karlsruhe wird ein Kompromiss gefunden zwischen dem was das Grundgesezt / die Vernunft sagt und dem was die Politiker wollen.

Und das bedeutet letztlich auch nichts anderes als die Gesetze kommen - zwar gebremst, aber sie kommen.

Aber weil Karlsruhe gesagt hat jetzt ist alles ok, ist es dann natürlich in Ordnung.

Ha ha, selten so gelacht.

Vom Teilen

written by Martin Häcker on

(Geschrieben für das Sternbuch meiner Familie)

Wenn man über das Teilen sprechen will, dann muss man diesen Begriff zuerst festklopfen.

Teilen kann man verschiedene Dinge. Dinge, die man anfassen kann und solche, die man nicht anfassen kann. Brot zum Beispiel kann man anfassen - und wenn man es unter mehreren aufteilt, dann hat man selbst weniger. Wenig überraschend ist es eines der drängendsten Probleme unserer Zeit, wie wir mit unserem knappen Trinkwasser umgehen. Pah, Öl. Trinkwasser!

Dann gibt es Dinge, die man anfassen kann - aber die man sowieso nur so kaufen kann, dass man sie alleine - außer in Extremfällen - gar nicht verbrauchen kann. Ein Auto zum Beispiel steht bei den meisten Menschen die meiste Zeit herum. Ab und zu jemanden mitzunehmen bringt da eine Menge - in manchen Gegenden sogar das Recht überhaupt fahren zu dürfen, damit weniger Verkehr ist.

Und dann gibt es jede Menge Dinge die man nicht anfassen kann - Liebe, Zuwendung, Musik, Freude, Theater, Humor...

Für einige davon wird in unserer Kultur eher nicht bezahlt. Liebe und Zuwendung zum Beispiel.

Für andere Dinge aber schon. Musik und Theater zum Beispiel. Die werden in unserer Gesellschaft meist industriell hergestellt, als CDs, Kino oder DVDs.

Lebt man, wie ich, schon größtenteils in einer Welt, in der solche geistigen Dinge vermehrt kopiert und geteilt werden, ohne dass sich etwas Greifbares bewegt, dann muss man sich früher oder später die Frage stellen: Was geht mir verloren, wenn ich zum Beispiel ein Lied singe, und meine Freundin das hört, dann mitsingt und es schließlich auch alleine singen kann? Habe ich wirklich weniger? Ist ein Lied teilen nicht Verbundenheit und habe ich damit sogar mehr als vorher? Oder abstrakter: Was verliere ich, wenn ich mit jemandem etwas teile, ohne dass ich danach weniger habe?

Diese schöne neue Welt hat natürlich einen Haken - denn wie für fast alles gibt es auch hier eine Industrie und Lobby - und die wollen von dem, was sie "schon immer" gemacht haben, weiterhin leben.

Dabei darf man aber den Blick für die Realität nicht verlieren - wer tatsächlich Kunst schafft, zum Beispiel als Musiker, verdient und verdiente - bis auf wenige Ausnahmen - immer schlecht. Es gibt viel mehr Künstler als Plattenfirmen produzieren wollen - und das drückt den Preis. Denn die Plattenfirmen leben davon, Hits zu produzieren - aber nicht zu viele, damit sich jeder einzelne auch lohnt.

Und diese verhältnismäßig kleine Industrie fordert jetzt, dass wir als Gesellschaft die beschriebenen Nuancen des Teilens vergessen sollen - und alle Dinge, auch die geistigen, betrachten sollen wie Brot. Als hätte man, wenn man sie teilt, selbst weniger. Vielleicht nimmt man dort an, dass wir auch nur die Intelligenz von selbigem besitzen.

Was würden wir wohl heute machen, wenn die Ochsenkarren-Industrie fordern würde, dass ab heute alle Straßen nur noch auf dem Standstreifen mit Autos befahren werden dürfen, damit der Rest endlich für ungehindertes Durchkommen mit Ochsenkarren frei wird?

Provokant gesagt: Das Geld wird eben heute anders verdient. Na und?

Mancher mag das für ein wenig wichtiges Thema halten - dabei bedeuten die hier besprochenen feinen Nuancen des Teilens eine Revolution. Wikipedia legt einen Grundstock an geteiltem Wissen an, der zeigt, wo es hingehen kann, wenn man zulässt, dass Teilen zum Grundprinzip wird. Open Source-Software verändert komplett die Weltwirtschaft, weil ärmere Länder plötzlich keinen Grund mehr haben, viel Geld an den ohnehin schon reichsten Mann der Welt zu bezahlen. Regierungen wie Deutschland setzen Open Source-Software ein, um sicher zu sein, dass kein ausländischer Geheimdienst Hintertüren in ihre technischen Systeme einbaut, und auf der anderen Seite nutzen Privatpersonen die selbe Software, um kontrollwütigen Regimen wie in China entgehen zu können. Auch Künstler entdecken immer mehr, dass sie ihr dringendstes Problem - wahrgenommen zu werden - durch die Freigabe ihrer Kunst viel besser erreichen können, als wenn sie darauf warten, von einer (Platten-)Firma entdeckt zu werden.

Diese Revolution, die uns erlaubt, mit geistigen Gütern so umzugehen wie es ihnen gebührt, hat gerade erst als technische Revolution begonnen - und wird noch lange Zeit weitergehen, bis der soziale Teil dieser Revolution abgeschlossen ist.

Jetzt durch kurzfristige und eilig durchgeführte Regulierungen das Kind mit dem Bade auszuschütten, bedeutet, dass diese Entwicklungen um Jahrzehnte verzögert, vielleicht sogar vollständig verhindert werden könnten. Vernünftige Politik ist hier abwartend - und lässt neues mutig zu, ohne es zu verteufeln.

Der Kongress...

written by Martin Häcker on

... 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. :-)

Piratenpartei und Transparenz

written by Martin Häcker on

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!

Fortgeschrittene Techniken Funktionaler Programmierung

written by Martin Häcker on

(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.

Python saugt

written by Martin Häcker on

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.

Was ist an diesem Programm falsch?

written by Martin Häcker on

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

Image

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.