(zu Hotaka)

Well, am WE hab ich mich mit Felix gerade über Versionskontrollsysteme und unsere Experimente mit HG unterhalten, als mich jemand 'von der Seite angemacht' hat, dass doch wohl im Moment alle Welt weg von HG und hin zu GIT wechseln würde.

Well, das konnte ich so nicht glauben, aber ich wollte mir die verschiedenen Tools dann doch mal anschauen - vor allem in Hinsicht auf SVN Kompatibilität - denn ich setze SVN sowohl für meine Arbeit, also auch für mich [browser:/ Privat] ein.

Na, denn ma auf zu dem Vergleich:

GIT

... hab ich mir als erstes dran genommen, und bin erst mal dran gescheitert, das das perl-script, dass den SVN-Modus macht via Fink natürlich nicht mit meiner Installation zusammenwollte, weil diese alten Perlhacker natürlich alle davon ausgehen, das Perl in /usr/bin/perl liegt. Well, tut es bei mir nicht, bzw, in /usr/bin liegt eine alte version von Perl, die eine bestimmte Library nicht enthält, die aber das Skript benötigt. ARGH! Also erst mal einen Patch zusammengebaut und an den Maintainer geschickt der das auf /usr/bin/env perl ändert. Oh well.

Danach war aber eigentlich alles dandy, bis auf die Tatsache, das ich trotz längerem nachlesen ums verrecken nicht verstanden habe, welchen Sinn diese komische Staging-Area "Index" haben soll, die man bei GIT immer zuerst mal auffüllen muss, bevor man sie Comitten kann.

Well, GIT is powerfull - aber für meinen Geschmack zu sehr an den Geschmack von Herrn Torvalds angepasst. Mag ja sein das er nur mit inkonsistenten und komplizierten Kommandozeilenoptionen effizient arbeiten kann. Ich jedenfalls hab was besseres verdient. Ausserdem erzeugt es bei mir Ablehnung wenn Herr Torvalds aus seiner Göttlichen Eingebung sämtliches anderes für Mist erklärt und dann etwas neues macht was deutlich komplizierter ist als die anderen - ohne das klar wird, wieso diese Komplexität der richtige Default ist und man nicht das Einfache zum Default machen kann, um das komplizierte als Option anzubieten.

Fazit: Funktioniert, push und pull zum SVN server waren kein Problem und das ist schon mal ein starkes Stück. Beindruckendes Tool, dass aber auch viel Ablehnung in mir erzeugt.

BZR

... war dann der zweite Kandidat, der nicht mehr viel Langsamer daherkommt als die anderen beiden (allerdings auch nicht zacko schnell). Allerdings, gibt es eine nette Extension die das Kommando shell hinzufügt. Das ist nett, denn dann hat man eine native Shell in bzr und hat superschnelle reaktionen, Tabvervollständigung überall, etc.

Der Checkout aus SVN hat auch prima geklappt (die Anfangsschwierigkeiten hatte ich vor einem halben Jahr, als ich mir die SVN-Python-Bindings selber bauen musste. ARGH war das ein Kampf.) Jetzt hatte ich sie aber schon und mir auch schon die notwendigen Wrapper-Skripte gebaut die die Library dann halt noch dazuladen.

Well, was soll ich sagen: pull vom SVN war hervorragend, lokales arbeiten auch, aber das Push.. das stirbt immer mit Fehler 175008 (ernsthaft!) und wirft mir dann noch an den Kopf das irgend eine property nicht angewendet werden konnte. Wenn er wenigstens sagen würde welche Property das Problem ist.. Aber naja.

Fazit: Sehr poliert. Gerade im Vergleich zu meinem letzten Test ist die Dokumentation viel besser geworden, das ganze Tool wirkt durchdacht. Vor allem der Output der Kommandos hat mir gefallen, schön aufgeräumt und übersichtlich. Dann ist da natürlich die Tatsache das dieses Tool doch immer noch das einzige ist, das tatsächlich Verzeichnisse auch Versionieren kann und mit renames vernünftig umgeht. Ahh.... Endlich ohne scheu refaktorn. :-)

HG

... will ich eigentlich schon länger mal benutzen, aber es hat mir bisher immer nur zu ein paar kleinen Experimenten gereicht. Allerdings: Felix hat sich schon anstecken lassen und verwendet das jetzt nahezu ausschließlich.

Well, mein Testcase hat leider gar nicht Funktioniert. Einigen Anmerkungen hatte ich entnommen das HG jetzt auch auf SVN zurückschreiben kann herausgefunden wie das geht, hab ich aber leider nicht. Oh well.

Fazit: Schnell, gute Bedienung und Python - aber ungeeignet um damit gegen SVN Repositories zu Arbeiten.

Fazit Fazit

So, dann bleibt mir also die Wahl: entweder GIT zu akzeptieren um damit gegen SVN zu arbeiten, oder aber den Bug in BZR zu finden um dann damit zu Arbeiten.

Vom Bauchgefühl her würde ich mich eigentlich lieber an BZR heranmachen. Mögen tue ich HG am liebsten, das hat einfach das einfachste Design und auch noch eine sehr gute Integration in das System - so öffnet es zum Beispiel standardmäßig gleich das System Merge-Tool (opendiff) anstatt CVS like Konflitkmarker in der Datei zu verstreuen.

So macht man dass.

BZR ist auf jeden fall mein zweiter Favorit - auch Python (kann ich also Hacken) und schön durchdacht - wenn auch manchmal etwas verbose zu bedienen (pull z.B. macht kein merge, aber er sagt einem dann das man statt pull merge machen müsste. ???)

GIT wirkt wie eine mächtige Kanone - ja man kann damit auch auf Spatzen schießen - ja danach wären sie tot - aber muss man sich das wirklich antun, das jeder normale Usecase ein wenig Komplizierter zu handhaben ist als mit den anderen Tools, nur damit man im zweifelsfall auch den Linux-Kernel mit dem gleichen Tool Maintainen kann?

Ich jedenfalls beantworte diese Frage für mich mit einem klaren nein. Und werde mich jetzt erstmal auf bzr und hg werfen.

Auf Archive.org. Goilomat.

Wie funktioniert eine Linotype Maschine 1 und 2.

Ich habe mich über die letzten zwei Tage erneut von Katrin inspirieren lassen.

Herausgekommen ist ein [attachment:blog:2008/04/12/22.16:AnimatedGrid.app.zip kleines Cocoa-Programm] ([browser:/open-source/animated-grid Source]) dass ein wenig mit solchen Grid-Animierten Ansätzen herumspielt und nebenbei noch ein wenig Sheets und Preferences verwendet.

Interessant ist dabei für mich der unterschiedliche Ansatz: Katrin war wichtig, das jeder Display Vorgang in konstanter Zeit abläuft und sie verwendet daher eine Liste der einzelnen Rechtecke. Ich hatte mir das auch überlegt, mich dann aber dagegen entschieden weil es komplexer zu Programmieren gewesen wäre.

Geschwindigkeit hat sich dann im Test überhaupt nicht als Problem herausgestellt - aber das grundsätzliche Problem bleibt. War es vernünftig den Code erst einmal einfach zu halten? Ich bin überzeugt das ja.

Ganz zufrieden bin ich aber noch nicht, weil das einzige Objekt ein View und gleichzeitig der Controller für die Preferences des Programms ist.

Aber - das Programm ist so auch kurz und Übersichtlich.

Hm.

Mal schauen was ich noch daraus mache. Vorschläge für interessante und auf dem modell ausdrückbare Algorithmen immer gerne an mich.

Hier noch ein paar Screenshots:

Endlich ist mir wieder so ein Punkt klargeworden, der mich schon lange an Python stört, den ich aber bisher noch nicht so richtig spezifizieren konnte.

Zusammenfassen lässt es sich als: Konvention ist besser als eine eigene Syntax / Regel.

Konkret geht es um folgendes: Python besitzt eine eigene Syntax für Konstruktoren. Nämlich diese:

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

point = Point(10, 15)

Der Konstruktor eines Objekts heißt immer __init__ (das mit den Unterstrichen finde ich sowieso hässlich, aber well, darüber ärgere ich mich wan anderes).

Das ist gut, weil man so den Konstruktor immer gleich findet.

ABER: Das ist total scheiße wenn man mehrere Wege braucht um ein Objekt zu initialisieren.

Denn genau wie in Java auch, kann man anhand den Argumenttypen ja keinen dispatch machen. Doh.

Also, wenn man das Beispiel erweitern will um auch Polarkoordinaten zu unterstützen, dann geht das nicht, denn bei

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __init__(self, theta, phi)
        self.x = ...
        self.y = ...

point = Point(10, 15)

kann die Runtime nicht mehr auflösen welchen Konstruktor mann denn jetzt genau gemeint hat.

Doh.

Jetzt hat man entweder die Wahl so etwas zu machen wie hier im Trac-Projekt

class WikiPage(object):
    """Represents a wiki page (new or existing)."""

    realm = 'wiki'

    def __init__(self, env, name=None, version=None, db=None):
        self.env = env
        if isinstance(name, Resource):
            self.resource = name
            name = self.resource.id
        else:
            self.resource = Resource('wiki', name, version)
        self.name = name
# ....

Was aber total ekelig ist, denn jetzt hat der Konstruktor auf einmal einen Parameter name der überhaupt nicht mehr dass ist, was er mit seinem Namen dokumentiert.

Klasse. Jetzt muss man tatsächlich den Code des Konstruktors lesen um zu verstehen was für Argumente man benötigt um so ein Objekt zu erzeugen. Habt ihr wirklich gut gemacht!!!!11!!

Oder aber man scheißt auf das Konzept eines Konstruktors und schreibt Factory-Methoden, also im Beispiel etwa so:

class WikiPage(object):
    """Represents a wiki page (new or existing)."""

    realm = 'wiki'

    @classmethod()
    def create_from_resource(klass, env, resource, db=None):
        page = WikiPage(env, resource.id, resource.version, db)
        page.resource = resource
        return page

    def __init__(self, env, name=None, version=None, db=None):
        self.env = env
        self.resource = Resource('wiki', name, version)
        self.name = name
# ....

Das ist jetzt immerhin klarer - hat aber den Nachteil das der Leser jetzt wissen muss dass man Factory Methoden einsetzt und welche (nichtstandardisierte) Konvention man für diese einsetzt. Na Klasse.

Ergo: Die Sprachdesigner haben sich gedacht, das es ja eine Tolle Sache wäre, wenn sie eine eigene Syntax einführen würden, damit Konstruktoren etwas besonderes sein können und haben damit erreicht, dass man sich beim tatsächlichen Programmieren jetzt auf einmal ein Bein Brechen muss, damit man ganz alltägliche Probleme auf eine saubere Art und Weise lösen kann.

Ganz groß.

Hätte man doch von vornherein anerkannt, das ein Konstruktor auch nur eine Methode ist - mit der Konvention dass der Name mit "init" anfängt - dann existierten auf einmal diese Probleme nicht mehr. Denn dann kann man über den namen der Methode dokumentieren was sie soll.

class Point:

    def init_cartesian(self, x, y):
        self.x = x
        self.y = y
        return self

    def init_polar(self, theta, phi):
        # ...
        return self

cartesian = Point().init_cartesian(10, 15)
polar = Point().init_polar(0.23, 0.23)

Yucheh!

Dazu kommt, dass man dann auf einmal sinnige Dinge tun kann, wie zum Beispiel, das ein "Konstruktor" nicht immer die gleiche Klasse zurückgeben muss. Man könnte also zum Beispiel eine öffentliche Superklasse haben, die aber tatsächlich in mehreren privaten Subklassen implementiert ist - zum Beispiel ein String, der je nachdem wie er erzeugt wird anders aussieht: Stringkonstanten vielleicht eine Klasse die nicht/anders an der Garbage-Collection teilnimmt und dafür Uniqued (also garantiert nur einmal) existieren (für einen schnelleren Interpreter interessant), Strings aus einer Datei entweder normal, oder falls die Datei eine gewisse Größe überschreitet als Memory-Mapped File, Strings die Pfade repräsentieren so, dass sie mit den Eigenheiten von Dateisystemen besser klarkommen, Strings die keine Unicode enthalten noch mal anders, damit sie effizienter sein können.... etc.

Und das alles, weil man auf Sprachebene auf ein zusätzliches Konzept verzichtet.

Aber dass, scheint ja für Sprachdesigner das Schwerste zu sein.

Ist ein Schwesterprojekt der Wikipedia.

Man sieht sich als eine Plattform zum gemeinschaftlichen Lernen, Lehren, Nachdenken und Forschen.

Könnte das der lang ersehnte nächste Evolutionsschritt der Universität sein? Das wie sie in 10 Jahren aussieht?

Mal genauer schauen. Morgen.

Will man sowas haben?

Wäre ja schließlich ein Hackerwerkzeug und damit verboten.

Nun, wer will da schon. Immerhin würde man damit ja schließlich normale WEP-Verschlüsselung in so etwa einer Minute entschlüsseln können.

Pah...

Aber Ankucken ist ja nicht verboten.

:-)

Ich will das die Partei transparent ist und bleibt. Jeder der dabei ist oder sich dafür interessiert soll komplett sehen können wie und an was wir arbeiten. Geheimniskrämerei ist nicht.

Ich will das die Partei Demokratie neu erfindet. Das Internet verspricht, dass man sich einfach und so tief man möchte, in die Themen einbringt die einen Interessieren und von denen man etwas versteht. Dieses Versprechen gilt es zu umzusetzen und gleichzeitig die Grundsätze der gleichen, freien und geheimen Wahl zu erhalten.

Hohe Ziele. Vor allem das letzte ist haarig. Denn: Wahlcomputer und mit ihnen alle Systeme die ich bisher kenne, haben einen gravierenden Nachteil: Bei einer normalen Wahl, kann man jeden x-beliebigen Erwachsenen bitten die Wahl zu beaufsichtigen. Wenn man ihm dann noch 3 Minuten lang erklärt wie alles funktioniert, kann er den ganzen Tag zusehen (er hatte vermutlich eh gerade nix zu tun) und am Abend dann mit voller Überzeugung verkünden dass dort alles korrekt abgelaufen ist (wenn dem denn so war).

Das geht mit technischen Systemen bisher nicht - und das ist ein Problem. Aber da sind wir garantiert die einzige Partei die das lösen kann.

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

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.

• Artikel
• Interview

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.