Gosling Didn’t Get The Memo - und wird dafür wunderbar abgewatscht. Kommentar- und Linksammlung zum neuesten "sind ja nur Scriptsprachen"-Kommentar von James Gosling.
programmierung
Waterfall 2006 - International Conference on Sequential Development - das Wasserfall-Entwicklungsmodell ist wieder da!
MP3 Python Module - einfache Lib zum Zugriff auf MP3 Informationen.
aspectes.tigris.org - Aspect Oriented Programming für JavaScript.
BranchBasedDevelopment - interessante Liste von Punkten wie man mit Branches in Subversion sinnvoll arbeiten kann.
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 Templates are not limited
shannon -jj behrens thinks that Django template language is limited - because it doesn't have functions with parameters to do html snippet reuse. Of course the official - and simplified - answer to this is, that Djangos template language is that simple by design, so that it can easily be learned by non-programmers (as often designers aren't necessarily programmers). This is a quite good reasoning, but I think it's a bit too simplified.
So here is the longer - more complete - answer to this accusition: the Django template language isn't limited at all. Yes, I know that the "include" and "block" tags aren't parameterizable and so aren't often that useful for more complex situations (at least if you don't want to end in namespace hell due to passing some template-globals in the context).
So what should you do if you notice that your templates would need more complex code? One way would be to precompute the data in the view function and pass it on via the context to the template - that way the template has the ready data and can directly present it.
But what to do if you can't precompute, because you are using generic views? You could wrap your generic view with your own code and call the original generic view in that function with the modified context. That way you have the same benefit as above - youre templates have the data readily available. If you have many view functions that all need the same context enrichment, you can write your wrapper as a decorator - and just decorate the generic views and use those decorated functions in your urlpatterns.
But what if even wrapping isn't the answer? Shouldn't there be some way to do more complex code without all that wrapping? Sure there is! The answer are custom template tags. This might sound like a bit of overkill, but believe me, writing some template tags isn't really that hard. There is documentation on using and extending the template system in python
An even easier way to write your own tags is to use the "simple_tag" or "inclusion_tag" helpers in django.template.Library. Those functions allow to build simple tags very easily - the inclusion tag will base it's output on some template snippet, so you can see it as a template function with paramerters. A lot of usage of custom templates is in the contrib/admin stuff.
The main problem with the newer stuff in the code is, there is documentation missing for it. Hopefully that will be solved over time. But please, if the next time someone tries to tell you that the Django Template Language is to primitive, don't believe him. The Django Template Language is easy to grasp for non-programmers - but it's very extensible for Python programmers. And you extend it in the language you like - in Python.
Hedgehog - Never underestimate the power of a small tactical Lisp interpreter.
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.