Vorweg: Ich habe in den letzten 12 Jahren mein Geld mit PHP verdient. Ich war immer der Meinung, es handle sich dabei um “echte Programmierung”. Oh Mann, ich war jung und brauchte das Geld.

Vor ein paar Jahren kam dann Python hinzu, die Versuche zuvor mit diversen anderen Sprachen wie Ruby lass ich jetzt mal weg. Python war für mich wie die Erlösung. Python war schneller, Python war strukturierter. Python hat eine Einrückvorgabe gegen lazy Entwickler, die der Meinung sind, dass man jede Zeile anders einrücken und damit Übersichtlichkeit verhindern kann. Es ist eine tolle Sprache. Für mich als Google-Fanboy war die Nutzung auf der Google-AppEngine anfangs auf Python (oder Java, aber mal ehrlich!) beschränkt.

Ich war in der Scriptsprachen-Welt. Man sagte immer, damit könne man am Schnellsten mal eben was hinzaubern. Das stimmte. Das war meine Welt. Ich hab immer Arbeit bekommen. Das war okay so.

Dann kam Go.

Es war keine Liebe auf den ersten Blick. Go sah komisch aus. Der Typ steht bei der Definition hinter dem Namen. Was für ’ne schräge Syntax. Dachte ich. Aber wie lernt man eine Sprache am Besten? Man liest anderen Quelltext danacht macht man es dann einfach mal selbst.

Was mir recht schnell auffiel: die Quelltexte verschiedener Entwickler sahen gleich aus. Alles war irgendwie schön strukturiert. Das Zauberwort heisst “gofmt”. Die Programmiersprache bringt seine Coding-Conventions mit. Wie geil ist das denn?

Bei PHP gibt es für jedes Framework seine eigene Coding-Convention.

Hä? Ach ja! Und es gibt auch  PSR (1 und 2 sind für Style da). PSR ist Scheisse! Bei Klassen und Funktionen werden die öffnenden geschweiften Klammern in die nächste Zeile gerückt. Bei ifs und Schleifen in die gleiche Zeile. Bei Funktionsaufrufen macht man die oeffnende Klammer ohne Leerzeichen hinter dem Funktionsnamen. Bei ifs und Schleifen (egal ob for, foreach, while) macht man ein Leerzeichen vor die öffnende Klammer. Was für ein inkonsistenter und unübersichtlicher Mist! Konfiguriert nur ein Kollege in der Firma seinen Editor falsch, hat man Chaos. Und dieses soziale Problem technisch zu lösen, ist sehr nervig.

Und dann ist da noch die Sprache PHP selbst. Ursprünglich entwickelt als Template-Sprache, wurde inzwischen so viel an der Sprache rumgefummelt um sie irgendwie professioneller zu machen.

Man konnte in dieser Template-Sprache plötzlich auch auf Datenbanken zugreifen.

Und dann kamen die Jungs von Zend.

Zeev und Andi dachten sich, dass es scheinbar eine total tolle Idee sei, den eh schon laxen Programmierern das Leben zu erleichtern. Sie dachten sich, dass man den alten Funktionsnamen, die alle klein und mit Unterstrichen geschrieben wurden, eine CamelCase-Syntax für die objektorientierten Sachen hinzufügen könnte. Die Funktionsparameter waren eh schon in einer zufälligen Reihenfolge, also hat man dann mit einer neuen Version diese Fehlentscheidungen gar nicht erst behoben, sondern einfach weitergemacht wie bisher.

Namespaces

Wer zur Hölle war da eigentlich besoffen als die Namespaces auf der Tagesordnung standen? Bei Java setzt man einfach noch einen weiteren Punkt vor den Namen (namespace.localname). Das ist eh deren Syntax. Bei C++ nimmt man ähnlich wie beim statischen Methodenaufruf noch einen weiteren doppelten Doppelpunkt (namespace::localname). Aber ein Backslash? Ein typisches Escaping-Zeichen? Echt mal!

Model, Controller und View in einem

Hier macht PHP meines Erachtens die meisten Fehler. Für so manchen Entwickler sind ja Design Patterns (nein, ich meine keine Photoshop-Vorlage!) ein Fremdwort. Andere halten es für veraltete Weisheiten. Aber MVC gehört zu den Dingen, bei denen mir oft die Nackenhaare hochstehen, wenn ich mir so manchen PHP-Code anschaue: Da werden in der einen Zeile Datenbank-Abfragen gemacht und in der nächsten Zeile nach der for-Schleife steht direkt HTML. Danach kommt dann wieder ein if mit Abfragen, ob im $_GET oder $_POST irgendwelche Werte stehen - man also Controlling-Mechanismen abbildet.

Die Pflege eines Projekts in solcher Form möchte niemand übernehmen, der bei klarem Verstand ist.

Die Datenbank-Konnektoren sind doof

Wenn ich mich in PHP mit einer Datenbank verbinden will, brauche ich viel Hoffnung. Nehmen wir mal MySQL als beliebteste PHP-Datenbank. Es gibt diverse Möglichkeiten, mich damit zu verbinden:

• mysql_* Methoden: sind seit PHP 5.5 als deprecated markiert und werden irgendwann ganz entfernt. Alte große Projekte, die darauf aufbauen, werden zukünftig also ihre PHP-Version nicht upgraden können
• mysqli_* Methoden: man hat irgendwie versucht, die mysql_* Methoden objektorientiert zu bekommen und pflegt dann diesen Baum weiter. Aber auch nicht ausschließlich objektorientiert. Wäre ja echt uncool, mal etwas richtig zu machen
• ODBC: Oh mein Gott, muss ich wirklich schreiben, warum das keine schnafte Idee ist?
• PDO: Nachdem ODBC ja so ein Windows-Ding war, musste man was plattformübergreifendes haben, mit dem man angeblich transparent die Datenbank wechseln kann. So es denn Konnektoren gibt. Mit MySQL ist es recht einfach. Das wurde alles implementiert, aber will ich mein PHP selbst kompilieren um eigene Konnektoren hinzuzufügen und es dann auf 100 Server verteilen?

Schauen wir uns doch mal an, wie es Go macht:

import (
  "database/sql"
  _ "github.com/go-sql-driver/mysql"
)

db, err := sql.Open("mysql", "user:password@/dbname")

Was machen wir hier? Wir importieren zuerst mal das SQL-Paket, welches Go grundsätzlich mitbringt. Danach importieren wir den Konnektor, eine in Go geschriebene Version des Konnektors - am Ende reden wir hier ja auch nur von ein paar Binärdaten, die da durch eine Connection geschoben werden. Wenn mir der Konnektor nicht zusagt, importiere ich einen anderen. Ich muss ja nichts weiter ändern als diese Import-Zeile. Der Rest wird durch das SQL-Package geregelt.

Wenn man die Datenbank ändert, hat man in jeder Sprache den Aufwand, dass die SQL-Statements anders sind. Das kann man nicht anders lösen, aber die Einbindung einer Datenbank geht einfacher.

Alles wird immer wieder wiederholt

Bei jedem Start, bei jedem Request - es wird immer alles von vorne gemacht. So ist das mit Scriptsprachen, die nicht kompiliert sind. Nicht nur bei PHP. Man stelle sich vor, man hat einen wirklich schlimmen Wulst aus XPath-Anweisungen. So um die 300+ Stück.

In Script-Sprachen wird der XPath-Ausdruck mit jedem Aufruf neu geparsed und kompiliert, um angewandt zu werden. Hat man nur Prozesse einer Software, die die Anfragen beantwortet (z.B. einen Server lokal, dem über FCGI die Anfragen weitergeleitet werden), wird das Parsen und die Kompilierung einmal gemacht und nur angewendet. Am Ende kann man damit ca. die 10- bis 10.000-fache Menge an Requests verarbeiten.

RAM-Management ist eine Seuche

Möchte man große Datenmengen verarbeiten und gerne auch mal was im RAM behalten, ist vor allem PHP wirklich schlimm. Da wird bei der DOMisierung eines 500 MB XML-Files auch mal 4 GB RAM verbraucht. Und man kann eben nicht alles mit Stream-Parsern erledigen.

Der schlechte Einfluss durch Java

Meist findet man ja in einer Firma Programmierer für Java und für PHP. Die Javaner werden besser bezahlt (weil man Java an der Uni lernt und nicht im Keller). Die PHPler wollen dann auch soviel Geld also schreiben sie wie Java, statt die Stärken ihrer Sprache zu nutzen.

Damit kombinieren Sie dann die Nachteile beider Sprachen. Also langsam UND kompliziert statt schnell und simpel.

Siehe dazu diverses Tooling, dass nochmal Annotations und Kommentare live nachverarbeitet: Das macht den langsamen Interpreter mittels Reflection gleich noch eine Ecke langsamer. Java braucht sowas, weil es nicht dynamisch typisiert ist. PHP eigentlich nicht.

Komplexe Anwendungen für Admin-Tätigkeiten

Wenn man in einem Verzeichnis und all seinen Unterverzeichnissen mal alle Dateien umbenennen möchte und keine Shell-Scripte bauen kann und schon ein PHP-CLI installiert ist, dann mag das alles noch okay sein. Mir begegnen aber immer häufiger Scripte, die dann unzählige Abhängigkeiten zu ganzen Frameworks haben. Da ist dann alleine schon das Deployment ein Schlag ins Gesicht. Diese Eigenschaft teilt sich PHP aber mit sehr vielen anderen Scriptsprachen.

Ein Single-Binary ist da schon ein Segen.

PHP muss und will mithalten

Anfangs von Entwicklern anderer Sprachen eher belächelt, hat PHP immer mehr User bekommen. Das ist natürlich auch der heutigen Kultur geschuldet, dass alles irgendwie schnell gehen muss und man mal eben kurz was hinkotzen muss. “Wir müssen da ein System auf die Beine stellen. Das muss nächste Woche fertig sein. Wie, in ProgrammierspracheX dauert das 14 Tage? Kannst du das nicht mal eben in PHP machen? Wir machen das dann irgendwann ordentlich.”

So oder ähnlich läuft es oft. Und aus irgendwann wird nie. Und aus hingeflanschten Systemen werden nach Jahren Projekte, bei denen es nur 2 von 25 Entwicklern gibt, die da komplett durchsteigen. Und wenn dann doch jemand mal den Hammer in die Hand nimmt, wird die nächste Version völlig over-engineered, da PHP ja inzwischen viel mehr Möglichkeiten bietet.

Das Problem der meisten PHP-Entwickler: Sie hören auf Userwünsche statt die Sprache schneller und stabiler zu machen. Da werden nämlich dann Wünsche nach anonymen Funktionen laut, die man von JavaScript kennt. Oder Traits, weil jemand mal gehört hat, dass man Mehrfachvererbung braucht.

One language to rule them all! Not.

Das alles in einer Templatesprache. Vor 15 Jahren, als die erste große Dotcom-Blase kam, nannten sich Leute, die HTML geschrieben haben “Programmierer”. Danach hat man Templates geschrieben, um HTML dynamisch auszugeben. Die nennen sich heute Programmierer. Jede Sprache hat seine Vorteile und seine Einsatzgebiete. Man versucht PHP zu einer Universalsprache zu machen und die Entwickler der Sprache leiden unter Featuritis.

Was ich versuche auszudrücken: PHP ist eine gute Sprache, wenn man HTML dynamisch ausgeben/generieren möchte. Aber diese Fähigkeiten gilt es zu optimieren und kein halbes Betriebssystem drumherum zu schrauben.