Über PHP

Ein tiefenbeleidigter PHP-Entwickler hat mir geschrieben.

Ich hatte doch gerade über diese ausgefallene PHP-Konferenz geschrieben und dabei eine geringschätzige Bemerkung über die Sprache PHP fallen gelassen.

Einige schrieben mir, dass das nicht nur dort so sei, sondern dass dieser Krampf sich inzwischen quer durch die technischen Konferenzen zieht. Da gab’s wohl angeblich eine andere Konferenz aus dem Linux-Umfeld, zu der wieder nur weiße Männer Beiträge eingereicht haben. Also habe man in der Not einfach eine zweite Phantasiekonferenz zur selben Zeit am selben Ort abgehalten, bei der „Diversity” und „Empowerment” im Namen vorkommt, auf der dann „Unterdrückte” in 14 Sessions erzählen durften, wie sie die Open-Source-Welt umwälzen wollen ohne dabei jemals mit Technik in Berührung zu kommen.

Man merke inzwischen richtig, wie durch diesen Gender-Druck die Konferenzen kaputtgehen und es immer weniger Leute dahinzieht – die einen, weil sie den Quatsch nicht mehr hören können – die anderen, weil sie durch diese Ideologie die Erwartung quotenmäßiger Durchmischung haben, die einfach nicht erfüllt werden kann und dann wegbleiben, weil die haluzinierte Frauen- oder Herkunftsquote nicht erfüllt wird. Egal, ob nun aus dem einen oder anderen, dem kritischen oder dem gläubigen Grund, das Ergebnis ist: Konferenz kaputt. So, wie durch diese Gender-Politik empirisch betrachtet alles kaputt geht. Ich schaue mir das ja an und bekomme unzählige Zuschriften, und mir ist bis heute kein Fall bekannt, in dem durch diesen Gender- und Diversitätsdruck irgendetwas besser wurde (obwohl das ja das große Versprechen und der angegebene Grund war), und mir fällt spontan auch kein Fall ein, in dem etwas wenigstens gleich gut belieben ist, weil allein schon der politische Druck und die verschobenen Anforderungen und Maßstäbe immer zu Konflikten, Konfrontionen, Streit führt. Viele Open-Source-Projekte wurden dadurch kaputtgefahren, und ich habe als Informatiker den Eindruck, dass Linux und das zugehörige Open-Source-Umfeld deutlich schlechter, leistungsärmer, innovationsärmer, qualitätsärmer ist als vor 10-15 Jahren, weil der Streit einfach zuviel Energie kostet und man zuviele hochproduktive aktive Developer in die Flucht geschlagen und durch Leute ersetzt hat, deren „Stärken” es sind, Kommentare und Variablennamen politisch korrekt umzuformulieren. Kommen dann noch solche Code-of-Conduct-Erklärungen dazu, die die Leute sogar außerhalb dieser Projekte in politische Diktate zwingen, wird das vielen Leuten zu dumm und sie gehen einfach. Übrig bleiben solche Leute, die bei den technischen Konferenzen nichts einreichen und dann zu „Diversity” und „Empowerment” sprechen. Ich kann mich nicht erinnern, jemals eine technische Leistung von „empowerten” Leuten gesehen zu haben.

Nun schreibt mir aber auch einer, der zutiefst beleidigt ist, weil ich PHP kritisiert habe:

Laut Ihrer Website sind Sie studierter Informatiker.

Hat es dann aber im Studium und der Arbeit danach, nicht für das Mindestmaß an Intelligenz und/oder Erfahrung gereicht eine Sache, wie eine Programmiersprache, objektiv und leidenschaftslos anhand ihrer Eigenschaften für den jeweiligen Anwendungsfall, als geeignet oder ungeeinet einzustufen?

Als PHP-Entwickler bin ich Menschen wie Sie einfach so dermaßen leid, dass ausgerechnet Sie als Informatiker, jetzt auf dem Rücken der abgesagten Konferenz noch PHP am liebsten untergehen sehen wollen ist so etwas von armselig und dumm.
Sie stehen mit Ihrer “Ansicht” dem nächstbesten Internettroll in nichts nach.

Sie halten das “Konzept” für “verfehlt und systematisch unsicher”.
Abgesehen von dem “auf die Nüsse gehen” ist dies meinem Verständnis nach eine fachliche Einschätzung.
Nur leider finde ich nichts fachliches in ihrem Beitrag.

Was wäre denn ihrer Meinung nach die bessere Alternative zu PHP?
Welche Sprache nebst Ökosystem ist denn besser geeignet und hätte so vielen Menschen gleichgut den Zugang zur eigenen Website ermöglicht?
Verfolgen Sie zudem überhaupt die Entwicklung an PHP selbst?
Kennen Sie überhaupt den derzeitigen Stand der Sprache?

Ich weiß nicht ob oder womit Sie ihr Geld verdienen aber ich hoffe in Ihrer Arbeit gehen Sie professioneller vor als in diesem Beitrag.

Das einzige, was an dieser Zuschrift stimmt, ist, dass ich „studierter Informatiker” bin (der Zuschreiberling anscheinend nicht).

Und ich bin durchaus in der Lage (und das gehört übrigens auch zu meinem Beruf), Programmiersprachen objektiv und leidenschaftslos anhand ihrer Eigenschaften zu beurteilen.

Übrigens halte ich es für völlig dämlich, die Frage nach der Qualität von PHP mit der Frage „was ist die bessere Alternative” zu verbinden. Noch nie wurde etwas dadurch besser, dass es keine „Alternative” dazu gegeben hätte.

Ich habe im Laufe meines Lebens bestimmt 30, 40 Programmiersprachen mehr oder weniger intensiv mal erlernt, benutzt und viele auch wieder nach jahrelanger Nichtbenutzung wieder vergessen, darunter diverse Assembler, Ursprachen wie Fortran, Cobol, Algol, BASIC, Lernsprachen wie Pascal und Modula-2, Kuriositäten wie APL und Occam, auch Forth, Unpraktisches wie Objective-C, Schräges wie Lisp und Prolog, Praktisches wie C und C++, Skriptiges wie Perl, Ruby, etwas Python, etwas Lua, PHP, Javascript, moderneres wie Rust, enttäuschendes wie Java, komisches wie Scala und noch jede Menge anderes Zeug, was mir gerade spontan nicht einfällt.

Ich denke, ich habe schon etwas Überblick. Wobei mir übrigens ganz massiv auf den Wecker geht (und vielen Leuten meines Alters ebenfalls), dass es so überflüssig viele Sprachen gibt, die sich darin unterscheiden, dass sie ein und dieselbe Sache mit der soundsovielten Syntax machen und alle Begriffe und Schlüsselworte einfach mal wieder neu erfinden oder permutieren, ohne irgendwas neu oder besser zu machen. Irgendwann tut man sich echt schwer damit, ob jetzt ein Strichpunkt dahintergehört oder nicht, weil andauert irgendwer irgendwo meint, jetzt gerade mal wieder irgendeine neue Sprache erfinden zu müssen ohne Neues zu erfinden.

Spielzeugsprache

PHP war ursprünglich nur ein Experiment, ein proof of idea, die nochmal besser gemacht werden sollte, sich dann aber schon festgefressen hatte, und das nicht mehr zu ändern wäre, ohne inkompatibel zu werden. PHP ist quasi ein Betriebsunfall.

Schon damals fiel auf, dass PHP groteske Fehler hatte. In der Anfangszeit hat PHP einfach alle URL-Parameter als Variablen gesetzt, was dazu führte, dass ein Angreifer durch Konstruktion des URL beliebige Variablen setzen konnte. Es hat nach meiner Erinnerung Jahre gedauert, bis man eingesehen hat, dass das eine dumme Idee ist und es zunächst optional (wegen der Rückwärtskompatiblität) und dann dauerhaft geändert hat.

Sowas prägt sich bei mir ein.

Mischung von Seiteninhalt und Sprachelementen

PHP murkst Programmteile und Webseiteninhalte beliebig durcheinander. Sowas wie klare Templates oder eine Struktur (z. B. MCV – Model Controller View) gibt’s nicht, man rotzt und murkst es halt einfach so hin.

Das ist enorm gefährlich. Denn dadurch sind statische Daten udn Programme kaum getrennt. Ein kleiner Konfigurationsfehler im Webserver, und in PHP-Text wird nicht interpretiert, sondern einfach als Text ausgegeben. Häufig enthalten PHP-Skripte aber Passworte und ähnliche vertrauliche Daten, etwa für die Datenbank. Die so eben gar zu leicht vom Angreifer gelesen werden können.

Dem kann man zwar begegnen, indem man in den WWW-Baum nur Skripte mit include-Anweisungen legt und die vertraulichen Daten dann außerhalb des Dateibaums, auf den der Webserver selbst zugreifen kann. Aber es macht kaum einer. Man muss es immer von Hand nachträglich fummeln.

Und selbst wenn man es machte, dann müsste man zwei Dateibäume pflegen, zwei zip-Archive verwalten: Den im Web-Baum und den außerhalb.

Konstruktionsfehler Routing

Der Grund, warum ich PHP für broken by design halte, ist, dass es zwischen dem URL-Raum und den PHP-Skripten keine Routing-Instanz sondern eine 1:1-Beziehung gibt. Der Angreifer kann durch Bau des URLs bestimmen, welches der PHP-Skripte im Zugriffsraum des Servers gestartet wird.

Und das ist Murks.

Ich will mal am Beispiel erklären, warum. Vor Jahren hat mir mal einer das Blog aufgebohrt und Backdoors und Porno-Proxies implantiert. Viel ist nicht passiert, ich habe es durch Hinweise gemerkt, entfernt, untersucht. Was war passiert? Ich war damals auf der Suche nach einem passenden Theme, hatte verschiedene ausprobiert, und letztlich selbst eines geschrieben. Eines der fremden Themes, die ich probiert habe, hatte eine Sicherheitslücke. Obwohl ich das Theme längst wieder deaktiviert und aus der Konfiguration gestrichen hatte, lag das noch im Dateibaum herum und konnte deshalb vom Angreifer, der wusste, dass dieses Theme eine Macke hat, direkt aufgerufen werden, obwohl es in der Konfiguration deaktiviert war. Einfach, weil es im Pfad da war.

Und dann kam dazu, dass WordPress Bilder, die man einbinden will, einfach in den normalen Web-Baum reinlädt, ein Verzeichnis muss dafür für den Webserver schreibbar sein, und die Endung nicht prüft. Der Angreifer konnte also in das Verzeichnis, das für Bilder gedacht ist, einfach „Bilder” mit der Endung .php ablegen, die dann – obwohl eigentlich nur Daten da sein sollten – ausgeführt wurden.

Ich sag’s mal frei heraus: Sowas ist einfach absolute Scheiße und darf nicht passieren.

Eine Konstruktion, in der ein Angreifer „Daten” hochladen kann, die per Konstruktion nicht von Programmen zu unterscheiden sind, und sie dann einfach ausführen kann, indem er einfach ihren Pfad als URL aufruft, ist ultimativer Mist. Die Trennung von Programmen und Daten ist elementar, und unter gar keinen Umständen darf ein Angreifer irgendwelche von ihm vorgegebenen Daten als Programm ausführen lassen.

Interpreter statt Compiler

Ja, Interpretersprachen sind bequem. Ich mag sehr gerne Ruby.

Aber sie haben ein gewaltiges Problem: Viele Fehler werden erst zur Laufzeit entdeckt. Beispielsweise ob Funktion und Funktionsaufruf mit Typ, Parametern und so weiter zusammenpassen oder überhaupt denselben Namen haben.

Und das ist für Produktiv- und Feindkontakt-Einsätze übel.

Ein Compiler mag zwar für Entwickler mitunter lästig sein, aber er hat den großen Vorteil (neben schnellerem Code), dass er eine Menge Prüfungen vorweg nimmt, etwa ob jeder Funktionsaufruf auch die Funktion findet und die Parameter und Typen passen.

Laien-Community

Das ist jetzt etwas überspitzt bezeichnet, aber mir fiel gerade keine bessere Formulierung ein.

So der Typ, der mir da schreibt, ist symptomatisch. HTML+PHP ist verhältnismäßig einfach und ohne sonstige Kenntnis einzusetzen, weshalb sich da eine Biotop für Webentwickler gebildet hat, die das und sonst nichts können, so quasi das BASIC des Internet-Zeitalters. Und das Ergebnis ist halt viel Murks.

Miserable Wartbarkeit

Wir haben einen Vereinswebserver mit etwa 100 virtuellen Domains.

Es ist jetzt aber nicht so, dass es da von den PHP-Programmen eine Version gebe, die wir mit dem normalen Update/Upgrade für alle pflegen, wenn wir etwa eine neue Version eines Apache-Webservers installieren. Die gilt dann für alle.

PHP-Programme sind aber in der Regel nicht „mandantenfähig” und in der Regel auch nicht installationsfähig, zumindest nicht ohne manuelles Nachfummeln. Das führt dazu, dass nicht wir als Admins eine Version von der Software X, die irgendwas macht, installieren und aktualisieren, die dann alle Vereinsmitgliedern benutzen, die das wollen, sondern jedes einzelne Mitglied lädt sich von irgendeiner Webseite irgendein zip herunter und packt das in seinem Webverzeichnis irgendwo aus um da irgendwo irgendeinen Ticker oder irgendein Fotoalbum oder weiß der Kuckuck was zu betreiben – und das dann die nächsten 10 Jahre nie mehr anzufassen.

Das können wir als Admins nicht mehr zentral warten und überwachen, weil die Software im Bereich der Mitglieder herumliegt, und selbst wenn wir da reingreifen (obwohl’s uns dann eigentlich nichts angeht), wissen wir oft nicht, was das für Software ist, woher sie kommt, oder überhaupt nur, was für eine Version das ist, weil das nur auf der Webseite oder im Dateinamen des zips stand, aber nicht in den PHP-dateien. Und dann wissen wir nicht mal, was wir austauschen können, weil die Mitglieder ja irgendwas selbst dran gefummelt haben können (und das selbst nicht mehr wissen).

Das ist, was Wartung und Sicherheit angeht, ein regelrechter Gau, ein großer Haufen Mist, durch den keiner durchblickt.

Das Zeug ist nicht ordentlich wartbar.

Programmierstil

Katastrophe. Durcheinander wie Kraut und Rüben, die Leute blubbern einfach drauf los.

Ich habe vor vielen Jahren mal versucht, WordPress so zu modifizieren, dass ich HTTP und HTTPS parallel mit demselben Blog machen kann.

Das habe ich entnervt aufgegeben, weil ich irgendwann gemerkt habe, dass das ein fürchtliches Gestrüpp aus mindestens drei verschiedenen Programmierstilen war und mit jeder Version immer nur noch eine neue Lage Kuhfladen obendrauf kam. Da kommt immer einer und baut noch irgendein Feature oder irgendeinen Trick ein und der Haufen wird immer größer, aber aufräumbar sah das nicht mehr aus.

Und PHP ermöglicht mit seiner Struktur auch keinen sauberen Stil, fördert im Gegenteil das Durcheinander und Gemurkse.

Lesbarkeit

Viele PHP-Programme sind schwer lesbar, schlicht weil es willkürlich durcheinander wie Kraut und Rüben geht. Die Struktur ist einfach nicht so, dass sie aufgeräumtes Programmieren fördert.

Fazit

Ich halte nichts von PHP. Das ist einfach Mist, Schrott. Typisches Ding für Webseitenfummler ohne ernstliche Ausbildung.

Es gibt manchmal dynamische Kleinigkeiten, für die das noch OK ist, und es soll ja auch einfach umsetzbar sein, aber sobald das etwas komplexer oder gar ein Projekt wie WordPress oder all die anderen Content Management Systeme ist, ist PHP eindeutig untauglich, weit überfordert und das Ergebnis vom Standpunkt der Sicherheit, Wartbarkeit und Qualität, wenn, dann nur mit erheblicher Zusatzsorgfalt und sehr guten Entwicklungsprozessen und Sicherheitsprüfung vertretbar.

PHP ist noch in Ordnung, wenn man in einer Webseite mal irgendwas dynamisch erzeugtes auftauchen soll, aber ab einer gewissen Komplexität ist das nichts mehr.

Alternativen

Java/JVM/Servlets

Ich mag Java nicht und die JVM nur wenig, aber die hier angesprochenen Probleme sind da deutlich besser gelöst bzw. treten gar nicht erst auf. Da hat man einen normalen Webserver für statischen Kram, dann die JVM, auf der die Software für das dynamische läuft, und hintenraus eine Datenbank oder sowas, alles klar und sauber getrennt.

Ruby on Rails

Ja, ich weiß, das ist auch heikel, das nach außen zu geben, würde ich jetzt auch nicht ohne weiteres tun, benutze es aber für nicht-öffentliche (=eigene) Dinge sehr gerne.

Das ist einfach von der Struktur deutlich klarer und aufgeräumter. Datenbank, Datenmodelle, Controller, Views mit Templates, eine klare, aufgeräumte Sache mit sauberem Routing.

Rust/Iron

Da ist jetzt Vorsicht geboten, denn mit Rust habe ich nur wenig, mit Iron noch gar nichts gemacht. Weiß nicht mal, wie weit Iron entwickelt ist und ob das noch aktiv ist. Und mir fehlen in Rust einfach ein paar Sprachkonstrukte.

Aber: Rust ist enorm in Bezug auf das, was der Compiler alles prüft. Es ist sogar anfangs ziemlich schwierig, überhaupt ein Programm zu schreiben, das der Compiler akzeptiert, weil der auch noch die Speicherverwaltung exzessiv prüft. Dafür sind damit die typischen Fehler von C und C++ (zumindest ältere Versionen) abgefangen. Wenn man es denn mal schafft, ein Programm zu compilieren, dann läuft das ziemlich stabil und zuverlässig.

So etwas in dieser Art würde ich mir als Alternative vorstellen.