programmierung - 7.1.2006 - 28.2.2006

Divmod - eine ganze Reihe von sehr interessanten Python Projekten. Natürlich auch eigenes Webframework und eigener ORM, aber auch ein paar kleinere, interessante Sachen wie z.B. ein Bayesian Classifier.

Screencast über Web-Anwendungen

Steve vom JPL hat einen Vergleich über verschiedene Webframeworks als Film bereitgestellt. Ganz nett, auch wenn er natürlich manche Sachen stark vereinfacht. Warnung: das Video ist sehr gross (300 MB) und J2EE kommt schlecht weg

Zu den Django-Kommentaren (schliesslich bin ich ja Django Contributor): I18N ist seit längerem schon im Standard drin, aber da Django sich sehr fix bewegt, kann man da nicht erwarten das er alles berücksichtigt. Und bei den Templates ist er nicht auf die Django-Template-Sprache angewiesen, er kann auch ZPT (die gleichen wie bei Plone) benutzen.

Der Zentrale Punkt kommt aber gut rüber: vergesst J2EE, lernt was anderes. Und dabei ist die Entscheidung zwischen Plone, Rails, TurboGears oder Django warscheinlich völlig egal - hauptsache ihr lernt was, das dann auch Spaß macht bei der Programmierung.

Tail Call Optimization in Python

Anfang des Monats hab ich mich noch darüber geärgert, das GvR keine Tail-Call Optimierung in Python will - weil er meint, das wäre ein Feature das kein einfaches Interface haben kann. Auf [Lambda the Ultimate] gibts dazu auch einen Kommentar - denn logischerweise hat dieses Statement von GvR zu einiger Erheiterung in der Lisp-Community geführt. Ganz besonders putzig daran: es gibt eine Lösung Tail-Calls per Dekorator optimieren zu lassen - in dem Python einfach im Stack rumfummelt (dank Stack-Introspection geht das ganz gut). Soviel zum Thema Rube Goldberg Device - der Dekorator ist extrem kompakt, da ist wirklich nicht viel Komplexität enthalten. Natürlich ist die Optimierung nicht wirklich optimal - sie vermeidet zwar den Stacküberlauf, aber benutzt Exception-Handling um die Funktionsaufrufe zu vermeiden, was dann doch etwas auf die Performance schlägt. Aber für die einfache Übertragung rekursiver Algorithmen kann das trotzdem durchaus nützlich sein.

Und warum wird sowas jetzt nicht als bessere, effizientere Lösung direkt in Python eingebaut? Python 2.5 kriegt von Perl geerbte bedingte Ausdrücke ( value if condition else othervalue ), aber sowas wie ein einfacher Dekorator zur Optimierung von bestimmten Funktionsaufrufen nicht?

Live Thumbnails: Watch 'em Grow - interessante Art aus Thumbnails direkt Grossbilder zu machen, ohne einen Seitenwechsel einzulegen. Allerdings aufgrund der erfundenen Attribute kein valides HTML4.

The Little Calculist: JavaScript language level - JavaScript als Sprache direkt in DrScheme unterstützt. Damit gibts die genialen Werkzeuge von DrScheme auch zur Bearbeitung von JavaScript.

RubyForge: Ruby Port to Nokia 770 Internet Tablet: Projektinfo - Ruby ist jetzt auch auf dem Nokia 770 verfügbar. Mit Python und TCL ist das schon eine stattliche Zahl von Onboard-Programmiersprachen.

Scsh PhotoBase - ist eine Foto-Verwaltungs-Software ala iPhoto, aber in Scheme geschrieben und für Benutzung über das Web. Bisher nur eine Ankündigung, aber der Source soll definitiv released werden.

Clim-Desktop project - erste Ansätze für eine integrierte Common Lisp Entwicklungsumgebung auf Basis der freien CLIM Implementierung.

Migrate apps from Internet Explorer to Mozilla - interessanter Artikel der eine Reihe von Fallstricken beim Wechsel zwischen IE und Mozilla.

Snowball - findet Wortstämme in verschiedenen Sprachen. Algorithmen in einer speziell dafür entwickelten Sprache. Praktisch für klassische Wortlisten.

Stéphane Ducasse :: Free Online Books - eine ganze Reihe von freien Büchern über Smalltalk. Zum Teil nur gescanned, zum Teil als echte Text-PDFs. Eine ganze Reihe von Klassikern sind dabei.

Cocoa für Klammerfetischisten

Es gibt doch tatsächlich eine Objective-C Bridge für das zweitbeste Scheme der Welt. Und ich hab das noch nicht vorher gesehen. Sieht sehr interessant aus, der Autor hat ein nettes Tutorial online, in dem er mit Scheme sein iTunes steuert. Und noch jede Menge anderer Source-Samples für Chicken-Scheme, unter anderem den obligatorischen Currency-Converter. Allerdings braucht man da eine neuere Chicken-Scheme-Version (also einen aktuellen Snapshot), sonst ist der -objc Schalter nicht unterstützt.

Wenn die noch weiter so produktiv sind, wird Chicken bald das beste Scheme von seinem Platz verdrängen

Die Installation ist allerdings ziemlich haarig, daher hier ein paar Notizen wie ich es gemacht habe:

Chicken Scheme 2.3 ist Minimum

libffi aus den Darwinports installieren: sudo port install libffi

objc Egg installieren:

sudo chicken-setup -c "-I/opt/local/include -L/opt/local/lib" objc

Gauche:ObjectiveCBridge - auch für Gauche Scheme gibt es eine Objective-C Bridge. Allerdings weniger ausgefeilte Beispiele.

HOC: A Haskell to Objective-C Binding - sogar für Haskell gibt es eine Objective-C Bridge, die ich noch nicht kannte.

Management by Stupidity or by Corruption?

Wie stehts eigentlich um die ALGII Software?

Die Tochter der Deutschen Telekom habe aber mittlerweile eingesehen, dass die bestehende Lösung «nicht mehr reparabel» sei. Es gebe einfach zu viele grundlegende Fehler bei der Architektur der Software.

Ok, soweit, so schlecht. Und was macht die BA? Ganz einfach:

Die Pannen-Serie mit der Arbeitslosensoftware A2LL hat die Bundesagentur für Arbeit (BA) nach Informationen der Netzeitung dazu bewogen, T-Systems mit der Programmierung einer komplett neuen Software zu beauftragen. «T-Systems ist dabei, an einer grundsätzlichen Lösung zu arbeiten», hieß es in mit der Situation vertrauten Kreisen. Die Erstellung eines neuen Programms erfolge «im Rahmen des bestehenden Vertrages». Die BA wollte sich auf Anfrage der Netzeitung dazu nicht äußern.

Übersetzt: da hat jemand eine Software massiv vergeigt, gibt selber zu das sie nichts taugt und kriegt im Rahmen bestehender Verträge (also ohne Ausschreibung!) den Auftrag für eine neue Software. So werden unsere Steuergelder und Arbeitslosenversicherungsbeiträge verschwendet. Und der Grund?

Knackpunkt für die BA ist die Kompatibilität mit A2LL. «Es muss möglich sein, alle acht Millionen Datensätze einfach zu übernehmen», hieß es. Darum habe sich die Behörde auch dafür entschieden, erneut T-Systems mit der Programmierung zu beauftragen. Es sei wichtig, T-Systems «mit im Boot zu haben», auch wenn das Unternehmen für die Misere um A2LL mitverantwortlich sei. Die BA hat sich dabei ausdrücklich gegen die dezentrale Lösung der Firma Prosoz entschieden.

Bitte was? Es hat eine alternative Lösung als Angebot gegeben. Aber es wurde wieder der Versager vom letzten Mal eingesetzt, damit die Datensätze übernehmbar sind? Wer garantiert das? T-Systems hat ihre Unfähigkeit doch schon bewiesen - warum glaubt jemand, das die ihre Daten korrekt übernehmen können, wenn sie diese nicht korrekt verarbeiten können?

Datenübernahmen sind nun wirklich nicht an Personen oder Firmen gebunden - statt den Bock erneut zum Gärtner zu machen, hätte man T-Systems dazu verpflichten müssen alle Schnittstellen, Datenformate und Strukturen zu dokumentieren und offen zu legen. Und dann eine Ausschreibung auf der Basis zu machen - und schlicht die Kompatibilität zur alten Datenbasis als Bedingung zu definieren. Das ganze diesmal bitte mit heftigen Konventionalstrafen bei Nichterfüllung.

Entweder ist bei der BA jemand in der Projektleitung völlig unfähig, oder völlig korrupt. Eine andere Erklärung fällt mir da nicht ein. Wenn man dann noch das Debakel beim Online-System bedenkt, verdichtet sich das ganze - mit den Geldern, die da verballert wurden, hätte man einigen Arbeitslosen gut über den Winter helfen können.

pyOpenSSL - Python interface to the OpenSSL library - relativ vollständige Bindings. Sieht deutlich besser aus als die bisherigen Libs die ich mir angeguckt habe.

Statistical programming with R

Den ersten Teil (Umgebung und grundsätzliche Struktur) von "Statistical programming with R" hatte ich ja schon früher mal. Mitlerweile sind auch die Teile 2 (funktionale Programmierung und Datenanalyse) und 3 (Objektorientierte Programmierung) online. Spannend für Zahlenfresser.

Yahoo! Design Pattern Library - Sammlung von Standardmustern in Web-GUI-Anwendungen und wie man sie mit der Yahoo JS-Lib löst. Sehr interessant als Cookbook.

Yahoo! UI Library - die JS/Ajax-Lib, die von Yahoo für die eigenen Anwendungen benutzt wird. BSD-Lizenz!

Language Design Is Not Just Solving Puzzles

Language Design Is Not Just Solving Puzzles ist ein recht interessanter Artikel von Guido van Rossum über die Unmöglichkeit einer eleganten Syntax für mehrzeilige Lambdas in Python. Lesenswert und in weiten Teilen stimme ich ihm zu. Allerdings stolpere ich dann über so einen letzten Absatz:

And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.

Ich bin durchaus bereit zu akzeptieren das Continuations komplex sind - aber nicht wegen des Interfaces. Denn im Interface für Continuations braucht man nur den callcc Aufruf zum Binden der Continuation und eine einfache Funktionssyntax zum Auslösen der Continuation. Das Hauptproblem bei Continuations liegt in der Kooperation mit Generatoren und Exceptions - was passiert, wenn eine Continuation innerhalb eines Generators ausgelöst wird? Was passiert, wenn innerhalb einer Continuation eine Exception ausgelöst wird? Das sind die schwierigen Aspekte - die übrigens auch Scheme-Implementatoren zum Schwitzen bringen, weshalb bei denen in der Regel Exceptions nicht so gerne gesehen werden (gleiches Problem, einfach nur aus der anderen Richtung betrachtet).

Also ok, keine Continuations in Python - auch wenn wir schon längst poor-mans-continuations mit pickable generators bekommen (oder mit Greenlets, oder mit cloneable Coroutines, oder einer der anderen vielen Ansätze um Subsets von Continuation-Features zu erhalten).

Aber was bitte schön ist komplex an Tail-Call-Optimization (denn es geht nicht nur um Tail-Recursion)? Die ist so primitiv, das sie transparent für den Programmierer implementiert werden kann - wenn ein Tailcall vorliegt, keine Rücksprungadresse auf dem Stack notieren, sondern die Parameter im Stackframe umladen und einen einfachen Jump notieren. Wenn man nett sein will, kann man noch eine Pseudofunktion "tailcall" einführen, welche eine Exception auslöst wenn sie nicht in einer Tailcall-Position ausgeführt werden soll. Es mag weitere Bedingungen geben, unter denen Tailcalls nicht optimiert werden können - aber diese können genauso in eine entsprechende Prüfung einfließen.

Gerade der Funktions-Overhead ist es ja, der manche Algorithmen in Scriptsprachen nur unschön implementierbar macht. Und Tail-Call-Optimization würde da definitiv helfen. Ganz besonders in Situationen, in denen man eine Kette von kleinen Funktionsaufrufen hat. Wegen meiner kann es auch gerne eine Optimierung sein, die nur bei -O (oder einem -O2 oder sonstwas) aktiviert wird.

Django-Vorlagen sind nicht begrenzt

shannon -jj behrens hält die Django-Vorlagensprache für begrenzt - weil sie keine Funktionen mit Parametern hat, um HTML-Snippets wiederzuverwenden. Natürlich ist die offizielle - und vereinfachte - Antwort darauf, dass die Django-Vorlagensprache absichtlich so einfach ist, damit sie leicht von Nicht-Programmierern gelernt werden kann (da Designer nicht unbedingt Programmierer sind). Das ist eine ziemlich gute Begründung, aber ich denke, das ist ein bisschen zu vereinfacht.

Hier ist die längere - vollständigere - Antwort auf diesen Vorwurf: Die Django-Vorlagensprache ist überhaupt nicht begrenzt. Ja, ich weiß, dass die "include" und "block" Tags nicht parametrisierbar sind und daher nicht oft für komplexere Situationen nützlich sind (zumindest, wenn Sie nicht in der Namensraum-Hölle enden wollen, weil Sie einige Template-Globals im Kontext weitergeben).

Was sollten Sie also tun, wenn Sie feststellen, dass Ihre Vorlagen komplexeren Code benötigen? Eine Möglichkeit wäre, die Daten in der View-Funktion vorzuberechnen und sie über den Kontext an die Vorlage weiterzugeben - auf diese Weise hat die Vorlage die fertigen Daten und kann sie direkt präsentieren.

Aber was tun, wenn Sie nicht vorberechnen können, weil Sie generische Ansichten verwenden? Sie könnten Ihre generische Ansicht mit Ihrem eigenen Code umhüllen und die ursprüngliche generische Ansicht in dieser Funktion mit dem modifizierten Kontext aufrufen. Auf diese Weise haben Sie denselben Vorteil wie oben - Ihre Vorlagen haben die Daten sofort zur Verfügung. Wenn Sie viele View-Funktionen haben, die alle die gleiche Kontextanreicherung benötigen, können Sie Ihren Wrapper als Dekorator schreiben - und einfach die generischen Ansichten dekorieren und diese dekorierten Funktionen in Ihren urlpatterns verwenden.

Aber was, wenn auch das Umhüllen keine Lösung ist? Gibt es nicht eine Möglichkeit, komplexeren Code zu schreiben, ohne all dieses Umhüllen? Natürlich gibt es das! Die Antwort sind benutzerdefinierte Vorlagentags. Das mag zwar ein bisschen übertrieben klingen, aber glauben Sie mir, das Schreiben einiger Vorlagentags ist wirklich nicht so schwer. Es gibt Dokumentation zur Verwendung und Erweiterung des Vorlagensystems in Python

Ein noch einfacherer Weg, Ihre eigenen Tags zu schreiben, ist die Verwendung der "simple_tag" oder "inclusion_tag" Hilfsprogramme in django.template.Library. Diese Funktionen ermöglichen es, einfache Tags sehr einfach zu erstellen - das inclusion tag basiert auf einem Vorlagensnippet, sodass Sie es als eine Vorlagenfunktion mit Parametern betrachten können. Eine Menge von benutzerdefinierten Vorlagen wird in den contrib/admin Sachen verwendet.

Das Hauptproblem mit den neueren Dingen im Code ist, dass die Dokumentation fehlt. Hoffentlich wird das mit der Zeit gelöst. Aber bitte, wenn das nächste Mal jemand versucht, Ihnen zu sagen, dass die Django-Vorlagensprache zu primitiv ist, glauben Sie ihm nicht. Die Django-Vorlagensprache ist leicht für Nicht-Programmierer zu verstehen - aber sie ist sehr erweiterbar für Python-Programmierer. Und Sie erweitern sie in der Sprache, die Sie mögen - in Python.

Igel - Unterschätze nie die Macht eines kleinen taktischen Lisp-Interpreters.

GREYCSTORATION - denoizing Algorithmus als Open Source CLI tool.

Lightbox JS - Fotos mit JS in der Seite einblenden. Netter Effekt.

lambda bleibt in Python

Let's just keep lambda - GvR gibt auf

Mandelbrot Set - Labix - Beispielsource der mit PyGame Apfelmännchen auf dem Nokia Tablet malt.

Eiffel For OS X - das was draufsteht ist auch drin. Nur diese grauenhafte Hintergrundgrafik auf der Site ...

Just-In-Time-Scheme

plt-scheme bekommt einen JIT Compiler - was dann nochmal einen deutlichen Schub für DrScheme, das beste Scheme der Welt, bieten sollte. Bisher war es ja ein rein interpretiertes System, mit einer eigenen virtuellen Maschine - und die war schon verdammt flott. Aber ein JIT Compiler kann gerade bei grösseren Stringbergen oder Listenfressereien und Zahlenverwurstelungen einiges bringen. Es wird spannend, wie das sich dann gegen z.B. Gambit-C und Chicken darstellt.

Guido van Rossum und Web-Frameworks

Guido van Rossum fragt nach Webframeworks - an sich nix spannendes. Er hat halt bisher damit nix gemacht und will sich mal informieren. Stellt einige Behauptungen auf, die nicht ganz stimmen (z.B. das Djangos Templatesprache ähnlich zu PHP wäre), ist aber bei der wohl vorliegenden Kürze des "anguckens" verzeihlich.

Lustig wird es in den Kommentaren zu seinem Beitrag. Berge von Frameworks, die alle nicht fertig sind. Haufenweise Kommentare der Art "nimm XYZ, das ist toll und in den nächsten Monaten wird es bestimmt brauchbar" - ganz besonders häufig kommt das bei TurboGears als Vorschlag.

Sorry, was? Wenn ich ein Web-Framework suche, dann suche ich keines, das in ein paar Monaten benutzbar wird. Dann will ich eines, das jetzt und heute benutzbar ist und für das es jetzt und heute klare Aussagen zur Fitness gibt. Wir brauchen wirklich nicht noch mehr Webframeworks die nicht fertig werden.

Ich hab ja nix gegen Vielfalt an Frameworks - das macht das Leben spannend und interessant, weil man nie weiss, ob man auf das richtige Framework gesetzt hat - aber unfertige Frameworks die von ihren Benutzern gepitched werden als wären sie das beste seit geschnittenem Weissbrot gibts wahrlich mehr als genug.

Übrigens benutze ich genau aus diesen Gründen auch Django: das Zeug ist schon geraume Zeit im Einsatz und hat bewiesen, das es für grosse Sites und hohe Last geeignet ist. Es wurde aus echten Anwendungen rausgearbeitet und ist nicht das Nebenprodukt eines unwichtigen Web2.0-Dingens von dem ich außerhalb der TurboGears-Clique noch nie gehört hab. Es wurde auch nicht von einem Kid alleine zusammengedengelt, der sich für den neuen Einstein hält und meint das nur er weiss wie Frameworks zu sein haben. Und es ist auch kein Projekt, das im Prinzip schon seit über einem Jahr tot ist, weil der Autor selber schon längst was anderes macht. Und es wird nur deshalb als 0.9 derzeit bezeichnet, weil API-Änderungen und Aufräumarbeiten in den Innereien anstehen (was bei jedem Projekt das zwei Jahre lang im Lifebetrieb entwickelt wurde angebracht wäre) - nicht weil es nur zu 90% fertig wäre.

Natürlich wird jetzt nach diesem Artima-Beitrag alles auf GvR gucken und warten was er nimmt. Und natürlich springen alle Webframework-Autoren auf und ab und wollen sich bemerkbar machen. Und natürlich wird jedes Wort analysiert und dem anderen unter die Nase gerieben. Und eine ganze Reihe von Projekten werden kurzfristige Schnellschussänderungen machen, weil sie hoffen das GvR ihr Framework wählt. Was alles eine wirklich wahnsinnig sinnvolle Zeitverschwendung ist. Manchmal gehen mir diese Kinder in den OSS Projekten tierisch auf den Senkel.

PythonForMaemo - Python for Maemo - Python auf dem Nokia 770 Tablet (die Versandbestätigung ist heute eingetroffen, hoffentlich trifft auch das Gerät bald ein) benutzen.

twill: a simple scripting language for Web browsing - in Python scriptfähiger Web-Client. Interessant für automatisierte Seitenabrufe und für spezialisierte Robots. Möglicherweise auch für das Testen von Webanwendungen.

pyvm home - eine weitere Python-Implementierung. Ein eigener Bytecode-Interpreter und ein Python-Compiler, der in Python geschrieben ist. Klingt fast wie PyPy meets Parrot - allerdings unter Beibehalt des Python Bytecodes.

A P R E S S . C O M : Practical Common Lisp - gibts jetzt auch als freien PDF Download (auf die Free Download Seite gehen und dort runterladen).

Bill Clementson's Blog: Update on Termite (A Lisp for Concurrent/Parallel Programming) - Infos zu Termite, einem auf Gambit-C aufbauenden Scheme mit den Concurrency-Features von Erlang. Klingt sehr interessant das ganze, mal anschauen, wenn der Code released ist.

Thinking Forth - gibts jetzt auch als PDF Download. Für alte Forther wie mich natürlich Pflichtdownload.

A list of open-source HTTP proxies written in python - eine ganze Reihe davon sind immer noch aktiv, und eventuell durchaus für den mobilen Einsatz interessant (speziell die auf asyncore aufbauenden, wegen der geringen Resourcen)

WebCleaner - a filtering HTTP proxy - absolut High-Tech, das Teil. Asyncore, also niedrige Resourcen, integrierter JavaScript-Interpreter gegen Obfuscation und noch einen Haufen anderer Features. Klingt von der Papierform sehr gut.

Hurring.com: Code: Python: PHP Serialize implemented in Python - PHP-Daten von Python deserialisieren. Könnte interessant sein, wenn ich weitere Sites von PHP auf Django umbauen will und z.B. an Wordpress-Settings dran will.

ScriptAculoUs - MochiKit - Trac - eine Portierung der script.aculo.us Effekte auf MochiKit. Endlich Drag and Drop und andere Effekte mit der deutlich besseren technischen MochiKit Basis.

An alle Oberonistas

Los ihr Wirthianer und Oberonistas. Lauft, nein rennt und holt euch die PDF-Ausgabe von Project Oberon. Hey, ich weiss, das ist alles nicht mehr so ganz state-of-the-art und einige Aspekte des Oberon-Systems waren schlichtweg albern (vor allem seine Begründung für nicht überlappende Fenster im Windowing-System ), aber trotzdem ist das Buch absolut lesenswert. Und das vorgestellte System hat immer noch eine Menge Charme, auch wenn es weitestgehend in der Versenkung verschwunden ist.

Ancient Languages: Perl - schon älter, aber einfach klasse. Eine bitterböse Abrechnung mit Larry Wall und Perl.

Django Paste - Ian ist starting to integrate Django with paste (and paste deploy). I for one will most definitely try to support that, so his list of related tickets is already down by one. Paste deploy might even be taken as the future default FCGI/SCGI solution - because it uses the same FLUP lib, it is as capable as my scripts, but due to the structure of Paste, installation should be much easier (and might even be standard in the future with Python hosters).

Apples Photocast Format

Apple unterstützt ja jetzt PhotoCasting - und Dave Winer kommentiert das Format. In diesem Fall bin ich absolut seiner Meinung: das Format ist ganz grosse Scheisse. Zum Einen haben sie schon wieder was neues erfunden, anstelle einfach Enclosures zu benutzen (die in RSS ja genau für solche Zwecke da sind), zum Anderen ist der Feed auch noch von vorne bis hinten defekt. Was soll so ein Quatsch?

MoinMoin Release 1.5 - hui, das neue MoinMoin sieht ja richtig slick aus.

Microsoft behält FAT-Patente

Na klasse, das US-Patentamt bestätigt das Microsoft-Patent auf das FAT Dateisystem:

Im Rahmen seiner Überprüfung (Re-Examination) hatte das Patentamt die Patente wegen "Prior Art" tatsächlich zunächst für vorläufig ungültig erklärt (Non-Final-Ruling). Die jetzt erfolgte Entscheidung ist hingegen endgültig und Microsoft erhält vom USPTO für beide Patente ein so genanntes "Patent Re-Examination Certificate". Das Patentamt habe abschließend festgestellt, dass das FAT-Dateisystem eine Neuentwicklung gewesen und deshalb patentierbar sei, teilte Microsoft weiter mit.

Wir können also abwarten, wann Microsoft das Patent einsetzen wird, um gegen Open Source Software anzugehen, die FAT-Dateisysteme verwendet oder unterstützt.

ProGraph für OS X

Erinnert sich noch jemand an die Dataflow-Language ProGraph? Die, bei der man einfach nur Kästchen verdrahtet hat, aber keinen normalen Code gechrieben hat? Die, bei der Spaghetti-Code noch aus echten verdrehten Bändern besteht? Gabs mal für das alte, klassische Mac OS.

Jetzt gibt es eine Version von Andescotia Software für Mac OS X. Mit 60 Dollar vielleicht nicht gerade ein Schnäppchen für ein obskures Teil Programmiersprachengeschichte, aber irgendwie gefällts mir trotzdem. Mal gucken ob ich da mal Geld für über habe.

Wer mal ProGraph in Aktion sehen will, es gibt ein recht brauchbares Tutorial online. Und natürlich gibt es bei der Wikipedia ein bischen zur Geschichte und Entwicklung.

Nachtrag: natürlich hab ich das Geld über. War ja klar. Bischen zäh, der Download, aber er läuft.

Die Open-Source-Ansätze sind übrigens ausgesprochen verhärmt bisher - und bestehen auf den Webseiten zu einem grösseren Teil aus Geschimpfe, Gejammer und Konfusion.

Efficient Editing With vim - Jonathan McPherson - nette Referenz von mehr advanced Tastenbefehlen in vi. Ich benutz auch nicht mal alle davon - sollte mir da auch mal den einen oder anderen angewöhnen.

Freie Alternative zu Flash?

Gnash ist ein GNU-Projekt zur Implementierung eines Flash-Clients unter GPL. Sehr interessante Sache - besonders interessant wird, wie die Reaktion von Adobe darauf aussehen wird. Ich hätte ja nix gegen ein bischen Vielfalt in dem Bereich einzuwenden, auch wenn ich normalerweise nicht so der Flash-Fan bin.

nadamac CamiScript - Script Repository - nützliche Scripts für Camino, zur Benutzung in CamiScript

Gambit Scheme - eine neue Beta

Vom drittbesten Scheme der Welt - Gambit Scheme System - gibt es eine neue Beta für die Version 4.0. Besonders interessant an Gambit-C ist - neben der hohen Performance des Codes - die wirklich geniale Threading-Implementation. Es werden normale Scheme Continuations benutzt und darauf dann ein Dispatcher aufgesetzt. Als Ergebnis brauchen Threads unter Gambit-C fast keinen Speicher (in einer 2G Maschine kann man ohne Probleme über eine Million Threads laufen haben) und Resourcen (und ja, das Switchen bei der Million von Threads ist ebenfalls recht ordentlich). Als Ergebnis ist Gambit-C für massives Multithreading auf Single-Prozessor-Systemen die absolute Nummer 1 - und Webserver lieben viele Threads.

Und bevor jemand fragt: das beste Scheme ist natürlich PLT Scheme (Dr. Scheme) und das Zweitbeste ist Chicken Scheme - denn Chicken Scheme hat immer noch nach PLT Scheme die beeindruckendste Library an mitgelieferten Code. Gambit-C könnte sich da gut einiges abgucken und mehr Libraries mitliefern, denn Libraries sind erst das, was die Sprache wirklich benutzbar macht. Im Moment ist es da bei Gambit-C doch noch arg duster.

Übrigens ist auch die Lizenz endlich gelöst: man kann jetzt bei Gambit-C zwischen LGPL und Apache Lizenz wählen, was wirklich alle Lizenzdiskussionen erübrigen sollte.