In dem Artikel [Snakes on the Web][1] macht sich Jacob Kaplan-Moss, einer der Entwickler von Django, Gedanken über die Zukunft der Web-Entwicklung in Python.
[1]: http://jacobian.org/writing/snakes-on-the-web/
Er bezeichnet PHP als die Eisenzeit der Web-Entwicklung (nach CGI, was die Bronzezeit, und statischem HTML, was die Steinzeit wäre). Dann kommt auch gleich schon die industrielle Revolution (wo sind denn bitte z.B. die Antike und die Aufklärung geblieben - den kulturellen Rückschritt ins europäische Mittelalter können wir ja gerne weglassen) in Form von Django und anderen Web-Rahmenwerken. Er klassifiziert Web-Rahmenwerk als Anwendungszentrisch und nicht mehr Seitenzentrisch wie PHP (ürsprunglich). Und man schraubt nicht mehr alles selbst zusammen und hat (industriell) vorgefertigte Komponenten.
Dann kommt er dem Punkt, was dennoch immer noch "suckt" und wie man's ändern kann. Sein Tenor, den ich nicht so absolut teile, ist, dass es an Interoperabilität mangelt und daher mehr Auswahl und Flexibilität statt Vorgaben nötig sind. Er erwähnt WSGI und Rubys Rack, welches ein besseres WSGI ist. Einen Punkt, den ich teile. Aber er wünscht sich noch weitergehende Interoperabilität: Programmiersprachenunabhängig soll sie sein. Er hat, so lese ich seine Aussagen, Angst, das Python (und Django) für die Web-Entwicklung weniger attraktiv wird. Auch da stimme ich ihm zu. Es ist schon armselig, dass trotz jahrelanger Vorbereitung von Python 3, auf einmal auffällt, dass der WSGI-Standard da gar nicht passt.
Er erwähnt GWT, SproutCore und Cappuccino als Beispiele für Systeme, die "herkömmliche" GUI-Anwendungen ins Web bringen wollen. Er findet die Tendenz, wie im Beispiel von Cappuccino, neue Sprachen zu erfinden, besorgniserregend. Ich finde sie gut und natürlich. Besorgniserregend ist eher, wenn Python als Programmiersprache nicht anpassungsfähig ist, dass sie mit den an sie gestellten Anforderungen mithalten kann.
Deployment ist zu kompliziert. Unbestritten. Hilft hier Googles App Engine? Sind einfach unsere Sprachen und Architekturen bedingt durch HTTP zu primitiv und erfordern zu schnell komplexe Skalierungsmaßnahmen, möchte ich hinzufügen. Ich meine, musste sich Microsoft bei Word oder Excel je Gedanken über Skalierung machen? Hatten sie das Problem von CSRF oder XSS? Caching? CDNs?
Web-Rahmenwerke, so ist glaube ich sein Argument, lösen nur die einfachen Probleme. Doch das muss sich ändern, so ist seine Forderung. Nur wie, frage ich dann.
Und dann ist da der GIL (global interpreter lock, immer nur ein Python-Thread kann gleichzeitig laufen, eine Sicherheitsmaßnahme, weil der Interpreter nicht thread-safe entwickelt ist). Python ist nicht bereit für die Welt der Mehrkernsysteme. Ich gehe davon aus, dass mein nächstes Notebook 4 Kerne hat, mein nächster Desktop-Computer (falls ich so einen überhaupt noch brauche) dann vielleicht 8. Server, so rechnet Kaplan-Moss vor, sind jetzt schon mit 32 Kernen erschwinglich. Und Pythons Lösung ist, dann eben 32 Interpreter mit dem Overhead von 32 Laufzeitsystemen einzusetzen. Vielleicht ist das egal, weil dann so ein Rechner auch 256 GB RAM mitbringt, sodass die 32 oder 64 MB pro Interpreter keine Rolle spielen, doch es stört (zumindest mich) schon. Da nützt es auch nichts, dass Ruby genau das selbe Problem hat. Ich sage: Vielleicht liegt die nähere Zukunft in JVM-basierten Sprachen - mit den richtigen Abstraktionen. Für JRuby könnte diese Strategie (wie für Scala und Clojure) aufgehen. Doch was wird mit Jython passieren? Hat es eine Zukunft bei Oracle?
Selbst wenn der GIL praktisch keine größeren Probleme macht, weil der zusätzliche Zeit- und Speicherbedarf einer Prozess-basierten Lösung nicht stört, so das letzte Argument, sorgt er für ein Desinteresse an Python und die "coolen Dinge" passieren in anderen Sprachen und in anderen Communities. Und das könnte viel schlimmer sein als nur technische Nachteile.
Jacob zweifelt daran, dass er in 10 Jahren noch Django einsetzen wird, auch wenn er es aus heutiger Sicht gerne machen würde (die Macht der Gewohnheit?). Dieser Zweifel soll sicherlich ein Signal sein, die Community aufzurütteln.
Aber ist, so möchte ich mit einer provokanten Frage eine Diskussion starten, lohnt das überhaupt? Vielleicht ist es einfach Zeit, weiter zu ziehen. Welches ist daher eure nächste Programmiersprache für Web-Entwicklung? Zurück zu PHP? Java EE 6? Smalltalk? Clojure? Ruby? Perl 6? (Ich argumentiere gerne für jede Sprache außer Perl, da ich die so gut wie gar nicht kenne, wenn jemand dagegen halten möchte ;)
Stefan
