Will man beispielsweise länger dauernde Operationen in JavaScript realisieren, gerät man schnell an den Punkt, dass der Browser nicht reagiert, blockiert, träge wird. Eine Lösung dies zu umgehen gibt es: Die Algorithmen dahingehend ändern, nur kleine Teile des Problems auf einmal zu berechnen.

Beispiel: Alle Zahlen von 0 bis 100000 zusammenzählen.

var sum = 0;
for (var i = 0; i < 1000000; i++) {
    sum += i;
}

Diese Schleife blockiert und das Script reagiert träge bzw. gar nicht mehr. Damit man nun das Rad nicht neu erfinden muss, hat Thomas Peri eine sehr interessante JavaScript-Bibliothek geschrieben: Clumpy.

Clumpy versucht eine Pseudonebenläufigkeit in JavaScript zu realisieren, und das auf eine sehr elegante Art.

Beispiel: Die obere Schleife mit dem Clumpy-Way-Of-Life:

var sum = 0;
clumpy.for_loop(
    function () { i = 0; },
    function () { return i < 100000; },
    function () { i++; },
    function () {
        sum += i;
    }
);

Clumpy kann aber noch viel mehr: Verschachtelung von Schleifen, Verkettung, saubere Notification über den Status … etc … I am impressed my dear!

* Die asynchronen HTTP-Requests werden über, nun ja, esoterische Mittel realisiert, damit eine Anfrage nicht blockiert.

Jeder der ernsthaft in PHP programmiert, weiß, dass die eingebaute Fehlerbehandlung eher suboptimal umgesetzt sind. Der Errorhandler spuckt zwar artig Meldungen aus, jedoch greift nicht die beste Neuerung in PHP 5: Exceptions. Bei Builtin-Funktionen auf Rückgabewerte abzufragen funktioniert, jedoch setzt das eine ziemlich große Disziplin bei den Entwicklern voraus. Schön ist anders. Bei selbst geschriebenem Code kann man auf Exceptions setzen, doch dann muss man stets zwei Fehlerkonzepte in seiner Architektur vereinen.
Daher hier ein wenig Code, mit dem man die Fehlerbehandlung von Built-In-Funktionen durch Exceptions spiegeln kann. Dazu wird ein eigener Fehlerhandler installiert, der jede auftretende Fehlermeldung in eine Exception umwandelt. Zwar alles mehr eine Skizze, aber man versteht das Prinzip.

Beispiel:

FaultHandler::install();
try {
    // Wirft eine Exception
    eregi ();
} catch (Exception $e) {
    //  Insert additional magic:
    //  HTTP-Status-Code, JSON convert, Error-Logging ...
    print $e;
}
FaultHandler::uninstall ();

Hier die Implementierung:

class FaultException extends Exception {

     public function __construct($msg, $code, $file, $line) {
          parent::__construct($msg, $code);
          $this->file = $file;
          $this->line = $line;
          //     get a well rendered stack trace
          $this->trace = FaultException::getStackTrace ();
     }     //     end method __construct

     function __toString () {
          return ("".parent::__toString ()."\n\n".$this->trace."");
     }     //     end method __toString

     function getStackTrace () {
          $NL = "\n";
          $dbgTrace = debug_backtrace();
          $dbgMsg .= "Debug backtrace:".$NL;
          $dbgTrace = array_reverse ($dbgTrace);
          for ($i = 0; $i < count ($dbgTrace) - 3; $i++) {
              $dbgInfo = $dbgTrace[$i];
             $dbgMsg .= "#".($i).": "
                       .$dbgInfo['file']." (line ".$dbgInfo['line'].")"
                       ."-> "
                       .$dbgInfo['function']." "
                       ."(".join (", ",$dbgInfo['args']).")".$NL;
          }
          return $dbgMsg;
     }     //     end method getStackTrace

}     //     end class FaultException

abstract class FaultHandler {

     public static function install () {
          set_error_handler (array ("FaultHandler", "handleError"));
     }     //     end method install

     public static function uninstall () {
          restore_error_handler();
     }     //     end method uninstall

     public static function handleError ($no, $str, $file, $line) {
          throw new FaultException ($str, $no, $file, $line);
     }     //     end method handleError

}     //     end class FaultHandler

Ausbaumöglichkeiten gibt es viele: Innerhalb einer JSON-Schnittstelle könnte man sich seine Fehlermeldungen als schöne Exception-Nachrichten schicken lassen oder Logging einbauen oder oder oder.

Vielleicht finde ich ja mal Zeit, mehr als nur eine Skizze zu schreiben. Stay tuned.

Denn wenn selbst eine Hardwarebude wie Apple daher kommt und anfängt die Urgroßmutter C um neue Sprachfeatures zu erweitern, kann es ja nicht angehen, dass die Damen und Herren bei Google zurückstehen. Mit Versprechungen halten die Go-Macher nicht gerade hinter dem Berg: Einfaches Programmieren, schneller Code, einfach umzusetzende Nebenläufigkeit, Spaß soll es auch noch machen und dass es Open Source ist versteht sich ja von selbst. Dann muss es ja wohl gut sein, oder?

Oder? Oder!?

Nein, gut ist anders. Viel und ganz anders. So begrüßenswert der Versuch auch sein mag, eine fixe Sprache mit eingebautem Garbage Collector zu etablieren … die Konzepte wirken nicht eigenständig oder gar wie aus einem Guss. Mehr wie die Hochzeitsszene aus der Dreigroschenoper, mit einer Braut wie aus einem Tim-Burton-Film. Etwas Neues, etwas Gebrauchtes und etwas Blaues. Und mit Zombies.

Man glaubt es kaum: Google verzichtet auf LLVM und stampft stattdessen eine eigene Toolchain aus dem Boden. Der 6g-Compiler ist trotzdem ziemlich fix und mit den Fehlermeldungen kann man arbeiten. Effizienter Compilerbau ist keine Kleinigkeit, gerade wenn man die Sprachfeatures nicht mal halbwegs spezifiziert hat. Hut ab Google, Yeah!

Die Features und Konzepte sind dann aber schon weniger Yeah!: Keine Typehierachie, dafür aber Interfaces, das Modulkonzept ist eine wilde Mischung aus Java und Python, keine Exceptions, Unicode-Unterstützung nur über zusätzliche Module (wtf?!), kein sauberes Asserting (hey, by design *hust*) und  von dem Versprechen der einfachen Nebenläufigkeit ist man noch Lichtjahre entfernt.

Egal. Hey, jeder Hacker sollte wenigstens einmal in seinem Leben eine Programmiersprache entwickelt haben. Das geht schon in Ordnung, auch wenn das Ergebnis wirkt wie eine Chimäre aus C, C++, Erlang, Python und Scala.

Wirklich interessant ist aber wie die Community reagiert. Bis heute morgen sind etwa 600 Mails aufgeschlagen, Interesse ist also da. Neben der - nachvollziehbaren - Forderung nach Exceptions und sonstigem technischem Zuckerguss, fragen Leute (ernsthaft!), ob Go nicht die richtige Sprache für die Umsetzung ihrer Business-Transaktionen sei. Immerhin stamme sie ja von Google, da müsse das ja gut sein.Oder, ob nicht jemand Lust hätte, ein MVC-Framework zu schreiben, denn Go sei ganz toll und alles was man bräuchte wäre ein bisschen Code um in Gang zu kommen. Oder, ob jemand nicht einen MySQL-Treiber schreiben wollte, den bräuchte nämlich jemand. Dringend!

Kleine Projekte, kleine Sorgen – große Projekte, große Sorgen. Immerhin haben sie ein süßes Maskottchen.

Im Moment nutze ich Dropbox um genau dieses Problem zu beseitigen. Dropbox integriert sich nahtlos auf Dateisystemebene: Alle Dateien eines Verzeichnisses werden auf Änderungen überwacht und nur die Änderungen werden an einen zentralen Server übertragen. Wird in einer hundert MiB große Datei ein Byte geändert, geht genau dieses eine Byte über die Leitung (plus ein bisschen Overhead). Alle Clients synchronisieren sich selbstständig mit dem Server.

Der enorme Vorteil: Es funktioniert Out-of-the-box auf allen drei wichtigen Plattformen: Windows, Linux und Mac (und läuft sogar mit ein bisschen Bastelei unter *BSD, aber die sind Bastelei gewohnt).

Die Sache wäre so schön, gäbe es da nicht einen Haken: Dropbox ist Closed-Source.

Die Jungs von getdropbox.com machen einen netten Eindruck, keine Frage, sind bestimmt Kumpeltypen, ich würde mit denen Crossgolf spielen und so. Aber ich würde schon gerne einmal sehen, was da mit meinen Dateien genau passiert.

Da kam mir die Einladung zu Ubtuntu One gerade recht. Sache geritzt, dachte ich mir: Gleiches Funktionsprinzip wie Dropbox, Open-Source-Client, mit meinen Gebühren unterstütze ich ein tolles Projekt und brauche mich nicht mehr zu ärgern.

Aber Pustekuchen!

An dieser Stelle der Hinweis: Das hier ist kein Rant. Ich will den Ubuntu-Entwicklern gar nicht ihre Arbeit madig machen (Jungs, ihr macht einen tollen Job!). Aber welcher Teufel hat euch denn geritten in eine Public Beta zu gehen und nur Clients für Ubuntu anzubieten? Denkt ihr wirklich, es gäbe da draußen nur noch Ubuntu Boxen?

Diese Plattformbeschränkungen nerven (gewaltig!) und waren jahrelang einer der berechtigten Hauptkritikpunkte an Microsoft aus der Open-Source-Szene.

Ich brauche meine Daten überall wo ich bin. Und nicht nur dort, wo ein Ubuntu verfügbar ist.

Jetzt könnte ich hingehen und mir selbst einen Client schreiben. Oder den Source-Code nehmen und ihn porten (so wie ich es sehe ein bis zwei Tage Arbeit, Python rocks, nur ganz wenige Showstopper). Aber … will ich das wirklich? Das ist nicht Ubuntu-Style, echt nicht. Ubuntu-Style ist One-Click, Erdtöne und freundliche Icons.

Ehrlich: Alternative Systeme haben nur dann eine Chance, wenn sie selbst zum Ziel haben, sich überflüssig zu machen, unsichtbar zu sein. Erfolg wird durch Austauschbarkeit definiert. Insellösungen, gekappselt und isoliert von anderen Systemen mögen zu DOS-Zeiten funktioniert haben. Aber heute? Selbst Microsoft hat das mittlerweile erkannt. Jetzt war das doch ein Rant. Snark.