PHPGangsta - Der praktische PHP Blog

Ein Gastbeitrag von Timo Puschkasch
Student aus Stuttgart, seit längerem als Webentwickler mit PHP und Ruby tätig. Seit kurzem auch in der UG Stuttgart anzutreffen.

PHP ist eine der ältesten serverseitigen Web-Sprachen und fast die einzige, die speziell zu diesem Zweck geschrieben wurde. Leider verleitet dies viele Entwickler dazu, den Gedanken, die PHP-Gemeinde könnte über den eigenen Tellerrand hinaus blicken und sich mit anderen austauschen, höchstens mit einem Lächeln abzutun. Dabei ist dieser Gedanke garnicht so abwegig. Es gibt viele Beispiele dafür, dass sich gerade Entwickler alt eingesessener Sprachen in alten Paradigmen verlieren und nicht dazu neigen, etwas Neues auszuprobieren. Deshalb möchte ich im Folgenden aufzuzeigen, an welchen Stellen die PHP-Entwicklergemeinde durchaus von anderen Gemeinden lernen kann. Dies betrachte ich am Beispiel der Ruby-Gemeinde, in der ich selbst seit einiger Zeit aktiv bin.

Ein sehr großer Unterschied, der einem sofort ins Auge fällt, ist die Wahl der Tools. Ich finde es zwar bemerkenswert und lobenswert, dass sich in PHP anders als in anderen Sprachen eine Vielzahl an Frameworks entwickelt hat, und dies ist eine Eigenschaft, die zu fördern durchaus lohnenswert ist. Doch diese Diversität bringt auch einen Mehraufwand mit, wenn es um das Einrichten und Betreuen von Anwendungen geht. Hier wäre es doch wünschenswert, einen Standard zu finden, der die Einrichtung von PHP-Anwendungen automatisiert. Diesen Standard gibt es bereits in Form von Pear, doch er hat sich nicht durchgesetzt. Symfony geht sogar so weit von einer Installation über Pear explizit abzuraten. Voller Neid schaut der PHP-Entwickler hier auf Rubys Gems und Bundle, mit deren Hilfe sich Anwendungen ganz einfach installieren lassen und auch mehrere parallel laufende Versionen kein Problem darstellen. Auch ein kompliziertes XML-Dokument zum Erstellen von Packeten ist überflüssig. Ich möchte nicht sagen, dass wir Pear als Standard erzwingen sollten. Vielmehr sollten wir uns fragen, weshalb die Community Pear bisher nicht angenommen hat und an den Schwächen arbeiten.

Ein weiterer Punkt sind Command Line Tools. Jedes Projekt bringt seine eigenen Tools inklusive eigener Implementierung mit. Wäre es nicht einfacher, wie Ruby einen de-facto Standard bei den Command Line Tools zu haben, der sehr leicht zu bedienen ist und dank einfacher Definition von Tasks auch von Entwicklern gerne benutzt wird? Es gibt mehrere Ansätze für solche Tools, doch bisher hat sich keines durchsetzen können. Deshalb müssen wir noch heute auswendig lernen, dass Befehle mal mit Unterstrich_Notation und mal mit Doppelpunkt:Trennung, mal groß mal klein und mit Sicherheit überall mit einer eigenen Parameterreihenfolge geschrieben werden, genauso wie viele Tools noch ohne Command Line Interface kommen, da es für den Entwickler zu komplex wäre, ein eigenes Tool zu implementieren. Und so müssen wir eben weiterhin im Quellcode rumpfuschen und ellenlange Logs lesen, um mit unseren Anwendungen zu arbeiten.

Bewegen wir uns von der handfesten Ebene der Tools weg zeigt sich ein anderes Bild: PHP hat eine Identität. Entwickler identifizieren sich mit dieser Sprache, jeder hat seine eigene Geschichte und seine Erfahrungen, und definitiv hat auch jeder seinen Stil und seine Vorlieben, über die gerne gestritten werden darf. PHP ist eine vergleichsweise alte Sprache und hat zwar keinen begrenzten, jedoch einen faktisch gut abgegrenzten Einsatzraum. Außerdem ist es eine feste Größe und aus dem Internet genauso wenig wegzudenken wie HTML und CSS. Was PHP jedoch fehlt ist ein Grundsatz, an dem sich alles orientiert. In Ruby gibt es derer zwei, nämlich alles ist ein Objekt und es gibt mehr als einen Lösungsweg. Hier liegt im Übrigen der ewige Zwist mit der Python-Community begründet, die die Auffassung vertritt, dass es nur einen offensichtlichen Weg zur Lösung geben sollte. PHP hingegen fehlt die klare Vorgabe und Struktur. Dies liegt unter anderem in der Geschichte begründet, PHP wurde nicht geplant, es hat sich einfach entwickelt. Und zu Zeiten der PHP-Entwicklung waren Grundsätze wie ausnahmslose Objektorientierung wohl auch noch nicht an der Tagesordnung. Doch diese fehlende Struktur zeigt sich noch heute vor allem in den PHP-eigenen Klassen und Funktionen.

Es ist an der Zeit eine Grundsatzdiskussion zu führen und sich darüber klar zu werden, was PHP ist und wie es sich von anderen unterscheidet. Wir müssen für uns herausfinden, warum uns etwas an dieser Sprache liegt, und wir müssen endgültig klären, ob es ($haystack, $needle) oder ($needle, $haystack) heißen soll. Es gibt kein und, nur ein oder in der Zukunft von PHP.

Alles in allem ist PHP eine tolle Sprache mit einer tollen und aktiven Community. Doch ich hoffe ich konnte aufzeigen, dass sich hin und wieder der Blick über den Tellerrand lohnt und dass es auch bei anderen Communitys durchaus etwas zu lernen gibt. Außerdem sollten wir uns in einen regen Austausch mit Mitgliedern der anderen Gemeinschaften begeben, denn nur so kann man effektiv voneinander lernen.