[bacon]

nix gegen register_globals()

[Pixelpole]

[Pixelpole]

[choise]

[Pixelpole]

Aufwand und Ressourcen können bei jeder sprache bei schlechter Nutzung enorm steigen. Nur ist es bei PHP so das man auch mit gutem Code ohne Caching eine saumäßige Performance hat...und hinzu kommt das PHP noch nichtmal Thread-Safe ist

[dotSven]

Nur mal am Rande bemerkt: Mit symfony oder CakePHP gibt es zwei Frameworks für agile Webentwicklung und rapid Development die es der Masse der PHP Entwickler erlauben, auch wieder vorne mitzuschwimmen. Die Frage ist nicht goto oder register_globals sondern wie schnell und flexible Projekte umgesetzt werden. Wenn man die Entwicklunsgzeiten auf 20% runterschraubt dann ist das ganze auch wieder lukrativ.

Der große Nachfolger könnte für PHP da ja Ruby on Rails werden, wenn es mal einfach zu installieren wird

Mit Twitter und Co hat RoR ja schon den einen oder anderen Kuden aufmerksam gemacht.

Gruss aus Montevideo

Sven

[bacon]

Mag ja sein, das ganze ändert aber nichts an den Mängeln in der Architektur der Sprache selbst. Jedes RAD Framework bietet ähnliche Funktionalität und ist sicher auch ein Schritt in die richtige Richtung. Aber trotzdem - solange Fatals bleiben, kann es keine wirklich bombenfeste Anwendung geben. Und Fatals lassen sich nur durch vorheriges Komplilieren abschaffen. Man muss auch zugeben, dass die PHP Ausnahmebehandlung nicht wirklich durchdacht ist. Dazu kommt noch die weiter bleibende Unwissenheit der Gemeinde - da muss man bspw. nur mal einen Blick in die Symfony Usergroup oder ins Forum werfen. Es bleibt zu hoffen, dass die Community und die Macher solch gut durchdachter Quellpakete Einfluss auf die Kernentwicklung nehmen können. Aber wie gesagt - ich wüsste gern mal, ob SPL noch weiter entwickelt wird (ich glaube, das schläft) und vielversprechende Projekte wie Propel liegen auch brach. Gut, eins ersetzt das nächste - aber es kann nicht sein, dass eine Sprache eine solch sprunghafte Releasepolitik bei (defacto)Standardbibliotheken hat. Zend geht hier natürlich mit gutem Beispiel voran - aber ein schaler Beigeschmack bleibt immer. Kannst ja mal 'ne Umfrage machen, wer hier überhaupt mit solchen Frameworks rumwurschtelt.

Es gibt natürlich heuer Unmengen von RAD Frameworks und RAR clones auch im PHP bereich, aber naja. Die wenigsten erreichen das Niveau von RAR, Grails oder Python-Equivalenten (jetzt mal im klassischen Web/Scriptsprachenbereich), viele davon rühmen sich doch gar noch ihrer php4 backwardscompatibility (Cake!).

Es ist trotzdem ein positiver Seiteneffekt, dass solche Tools die losen Snippetsammlungen von Dazumal ersetzen (hier mein gästebuch von freephpscripts4you etc..., da mein Newsscript...), aber sie werden weiterhin nur von und für "echten" Entwicklern gebaut und interessant sein. 90% der PHP Gemeinde kann man nicht überzeugen, obwohl das Zeugs so viel einfacher und stabiler in der Handhabe ist (wie du richtig sagst). PHP bietet halt ab Werk einen zu leichten Einstieg, alles falsch zu machen, was man falsch machen kann

Ruby sehe ich btw nicht unbedingt als "Nachfolger" zu PHP, eher in direkter Konkurrenz zu Perl oder Python im Desktop-Bereich. Rails ist meines wissens nach das einzig brauchbare teil, um damit ins Web zu gehen - und auch hier musst du mod_ruby oder cgi ran lassen - eher was für Spezialisten, die sowieso Ruby scripten (Japaner ).

Ich glaub die Zukunft liegt in der vm, somit sehe ich groovy und vielleicht auch (j)ruby als ernsthafte Wahl für PHP-Umsteiger. Alle Macht der Javawelt, aber die "Einfachkeit" einer nicht streng typisierten Sprache. Die Herausforderung liegt halt dann darin, sich durch die myriaden an .jar-Files zu wurschteln, die es so gibt, und hier die richtigen Werkzeuge zu evaluieren.

[dotSven]