Die Arbeiten an der nächsten PHP-Version 7.3 laufen auf Hochtouren. Auch PHP 8 wirft bereits seine Schatten voraus. Wann die Major-Version kommt, steht jedoch noch in den Sternen. Zeit für ein Gespräch mit dem anerkannten PHP-Experten Arne Blankerts (thePHP.cc).

entwickler.de: Einen Blogbeitrag hattest Du mit „Why PHP 7.2 Is Important“ betitelt. Kannst du bitte noch einmal zusammenfassen, was das Release an interessanten Neuerungen gebracht hat?

Arne Blankerts: Das mit dem Zusammenfassen ist gar nicht so einfach. Auf den ersten Blick erscheint PHP 7.2 wie ein klassisches Maintenance-Release: ein paar Bugfixes hier, ein paar Performance-Tweaks dort. Wie wir nicht zuletzt beim Aktualisieren unseres Buchs „PHP 7 Explained“ feststellen konnten, stimmt das aber nur zum Teil: Mit PHP 7.2 werden nämlich auch viele alte Zöpfe zum Abschneiden vorbereitet. Sprich, veraltete Funktionalitäten wurden als deprecated markiert, um dann später in Version 8 der Sprache entfernt zu werden. Auch ist PHP mit der Version 7.2 deutlich strenger geworden – beispielsweise erzeugt ein var_dump(UNDEFINIERT);jetzt ein E_WARNING und nicht einfach nur eine E_NOTICE wie früher. Was wie ein BC-Break aussehen mag, ist in der Praxis keiner, denn die Wahrscheinlichkeit, dass die Anwendung trotz des Fehlens der Konstanten UNDEFINIERT wie geplant funktioniert hat, tendiert gegen Null. Zu guter Letzt sind einige eher merkwürdig anmutende Konstrukte entfernt worden, von denen hoffentlich keiner wusste, dass es sie überhaupt gab oder die schlicht unsinnig sind. Oder wer hat beispielsweise schon mal in der Praxis ein (unset)$variable gesehen? PHP 7.2 ist damit ein wichtiger, aufräumender Schritt zur weiteren Stabilisierung der Sprache und eigentlich weit mehr als die eher unscheinbare Versionsnummer vermuten lässt.

entwickler.de: PHP 8 wirft seine Schatten voraus. Was erwartest du von der kommenden Major-Version?

Arne Blankerts: Es gibt viele spannende Experimente, Erweiterungen und RFCs, die es in eine mögliche Version 8 von PHP schaffen könnten. Auch wenn es natürlich Spaß machen kann, sich zu überlegen, welche davon eine ernsthafte Chance haben, so ist eine Version 8.0 noch in sehr weiter Ferne. Wirklich sicher erwarten kann man daher wohl nur, dass PHP 8 erneut schneller sein wird und eben alle in 7.x als deprecated markierten Dinge verschwunden sein werden.

Bei aller Fokussierung auf Geschwindigkeit wird es spannend sein zu sehen, ob sich die Beschleunigung der Codeausführung noch merklich auf Antwortzeiten auswirkt: Die meisten Webanwendungen sind heute bereits so I/O-lastig – sei es durch Datenbanken oder auch (Micro-)Services –, dass PHP dann im Zweifel nur noch schneller wartet. Auch die mögliche parallele Codeausführung in Threads würde da nur helfen, wenn mit mehreren Quellen unabhängig voneinander gesprochen werden muss. Bei einer klassischen Webanwendung oder einem API passiert das allerdings eher selten.

Wenn ich mir etwas für PHP 8 wünschen dürfte, dann eher, dass die Sprache als solches sich weiterentwickelt. Und zwar um Dinge wie Typed Properties und Immutable Classes and Properties, die sich beide gerade im RFC-Stadium befinden. Des Weiteren bin ich gespannt, wie es mit PDO weitergeht, denn hier lauern aktuell gleich zwei Probleme: Zum einen gibt es nach meinem Wissen keine aktive Weiterentwicklung, zum anderen gibt es noch immer ungeklärte Lizenzfragen bezüglich der jeweiligen Bibliotheken der Datenbankclients, sofern man diese auf neuere Versionen aktualisieren oder mit ausliefern wollen würde.

entwickler.de: Mit PHP 7.2 wurde ein Bruch zur alten Generation vollzogen. Oder nicht? Was spricht dafür, sich von PHP 5 endgültig zu verabschieden? Und was macht der Entwickler, der mit seiner veralteten Version mitten in einem Projekt steckt?

Arne Blankerts: Ich bin nicht sicher, ob man hier schon von einem Bruch reden sollte: Mit Veröffentlichung der Version 7.2 wurden zwar, wie bereits erwähnt, etliche Dinge als deprecated markiert, dies hat aber rein funktionell erst einmal keine Auswirkungen auf die Anwendungen. Wenn man mal von zusätzlichen Logeinträgen oder eben Deprecated Notices absieht. Alles andere wäre auch falsch und nach den Regeln des Semantic Versioning nicht vertretbar. Wem nach dem Update auf PHP 7.2 übrigens wegen der neuen Deprecated Notices die Tests auf die Nase fallen, der kann, sofern PHPUnit zum Testen verwendet wird, die Zeit bis zur Anpassung der Codebasis überbrücken, indem der Schalter convertDeprecationsToExceptions auf false gestellt wird. Dies sollte aber aus hoffentlich offensichtlichen Gründen keine Dauerlösung sein. Für die letzte Version von PHP 5, die Version 5.6, endete die aktive Unterstützung durch das PHP-Projekt vor über einem Jahr. Das bedeutet, dass selbst für gegebenenfalls nervige Bugs keine Fehlerbehebung mehr erfolgt. Ausgenommen davon sind noch Sicherheitsprobleme, allerdings auch nur noch bis Ende dieses Jahres. Danach ist aus Sicht des PHP-Projekts endgültig Schluss mit PHP 5. Wem das als Motivation noch nicht reicht, schließlich bieten Redhat und Co. im Rahmen ihrer unterstützten LTS-Distributionen auch weiterhin Sicherheitspatches für alte PHP-Versionen, der wird als Nächstes Probleme bekommen, aktuelle Versionen seiner Tools, Frameworks oder sonstiger Komponenten einsetzen zu können. Wir haben dazu 2016, zum Ende der aktiven Unterstützung von PHP 5.6, mal eine Übersicht veröffentlicht: Praktisch keine aktuelle Version der bekannten Frameworks wird nach 2018 noch mit PHP 5 funktionieren.

Im Gegensatz zu einigen anderen Sprachen, die bei einem Versionssprung gerne mal vollständig inkompatibel zur Vorgängerversion sind, ist das PHP-Projekt immer bemüht, Brüche in der Abwärtskompatibilität zu vermeiden. Das zahlt sich auch hier aus, denn trotz der vielen auch grundlegenden Änderungen in PHP 7, halten sich die harten Kompatibilitätsprobleme zu PHP 5.6 in Grenzen. Und selbst wer noch auf 5.5 oder gar noch älteren Versionen sitzt, der wird beim Umstieg zwar eventuell mit etwas mehr Arbeit konfrontiert sein, aber auch hier ist nicht alles verloren und ein Umstieg auf PHP 7 generell möglich. Die grundsätzliche Kompatibilität einer Codebasis mit PHP 7.x lässt zudem sehr gut mit Tools wie php7cc feststellen.

Und selbst für Entwickler, die noch nicht von den in PHP 7 hinzugewonnen Fähigkeiten der Sprache profitieren können oder wollen, bietet der Umstieg Vorteile: Neben der massiv gesteigerten Performance und der verbesserten Speicherverwaltung gibt es eben auch aktive Unterstützung durch das PHP-Projekt und die Community.

Wenn ich mir etwas für PHP 8 wünschen dürfte, dann eher, dass die Sprache als solche sich weiterentwickelt.

entwickler.de: Was erwartest du in Zukunft von den PHP-Entwicklungsumgebungen?

Arne Blankerts: Entwicklungsumgebungen sind, zumindest für mich, ein zweischneidiges Schwert. Ich erinnere mich noch ziemlich genau an die Zeit, als ich PHP in einem einfachen Texteditor entwickelt habe und mich schon über simples Syntaxhighlighten gefreut habe, denn Eclipse und Co. waren für mich unbenutzbar. Diese Zeiten sind glücklicherweise lange vorbei und PhpStorm hat gefühlt den Markt übernommen und dürfte als die IDE gelten. Ob diese Entwicklung jetzt gut ist oder nicht, muss jeder für sich selbst beantworten, schätze ich. Gefährlich wird es aber, wenn Entwickler sich nicht mehr darauf konzentrieren, eine sinnvolle Anwendung zu programmieren, sondern vor allem darauf, die IDE bzw. die aktivierten Inspections glücklich zu machen. Oder sie sich auf die eingebaute Magie verlassen und eigentlich gar nicht mehr wissen, warum da jetzt ein bestimmtes Fragment an Quellcode automatisiert erzeugt wurde.

Nichtsdestotrotz gehe ich stark davon aus, dass die automatische Codeanalyse und das Codeverständnis der IDE weiter ausgebaut und so eine noch tiefergehende Unterstützung der Entwickler möglich wird. Ich hoffe hier vor allem auf noch leistungsfähigere Refactorings und auch die Vermeidung von False Positives. Vermutlich werden auch weitere Werkzeuge über die IDE direkt ausführbar und nutzbar. Allerdings muss ich zugeben, dass ich hier vermutlich altmodisch bin und so ziemlich alle Tools unabhängig von der IDE ausführe.

entwickler.de: Wie schätzt du die Zukunft von PHP ein? Stichwort „PHP ist tot“. Kann PHP mit der aktuellen rasanten Weiterentwicklung der konkurrierenden Programmiersprachen mithalten?

Arne Blankerts: In die Zukunft zu blicken ist immer schwierig. Wenn man allerdings in die Vergangenheit schaut, um daraus möglicherweise etwas für die Zukunft ableiten zu können, so ist PHP bereits mehrfach für tot erklärt worden und ist gefühlt jedes Mal eher gestärkt aus der Sache herausgekommen. Der eine oder andere wird sich vielleicht noch an den Hype um Ruby on Rails erinnern und wie klar es schien, dass das Ende von PHP quasi vor der Tür stand. Heute haben wir mit PHP 7 das schnellste und von den Sprachfeatures her mächtigste PHP aller Zeiten und – je nach dem wen man fragt – einen Marktanteil von 80 Prozent oder mehr. Tot fühlt sich für mich anders an.

Ich finde in diesem Zusammenhang auch den aktuellen Hype um Serverless faszinierend: Das, was PHP von seinen Gegnern immer gern als Nachteil angedichtet wurde – das Prinzip der Shared Nothing Architecture –, soll jetzt die Rettung der Welt bringen und ist auf einmal etwas Tolles und Neues. Was für andere Umgebungen und Sprachen hingegen einem Paradigmenwechsel gleich kommen mag, ist für PHP und seine Entwickler altbekannt und gewohntes Territorium.

Überhaupt frage ich mich, warum wir gerade in der PHP-Welt ständig Angst haben, etwas zu verpassen oder hinterher zu hinken, ein bisschen so, wie es Uncle Bob in einem Blogpost von 2016 beschreibt – ständig auf der Suche nach dem Next Big Thing, nur um bereits funktionierende Werkzeuge und erprobte Herangehensweisen wegwerfen zu können und wieder bei null starten zu müssen. Wenn ich mir die anderen Sprachen unter diesen Gesichtspunkten anschaue, sehe ich vor allem unterschiedliche Syntaxen, aber kaum wirkliche Vorteile gegenüber PHP oder gar konzeptionell Neues.

Als eine erfreuliche Ausnahme wäre für mich das Konzept für Variablen in Rust zu nennen, welches unter anderem vorsieht, dass Variablen standardmäßig immutable sind. Ein wirklicher Vorteil, um ungewolltem Überschreiben von Werten und Typen zu begegnen. Eine mögliche Einführung in PHP wird auch – mal wieder – in einem RFC angedacht und auf der Internals-Mailingliste diskutiert. JavaScript hingegen, das sich ja vor allem Dank Node.js und dessen npm quasi einer Renaissance erfreut, wird immer mehr von einer funktionalen zu einer klassisch objekt-orientierten Sprache verbogen und auch Supersets wie TypeScript fügen, nüchtern betrachtet, vor allem altbekannte Sprachkonstrukte und Programmierparadigmen hinzu. So ganz falsch scheint mir PHP da mit seiner etablierten Toolchain, dem offensichtlich immer noch modernen Shared-Nothing-Konzept und aktuellen Sprachfeatures für die nächste Zukunft nicht aufgestellt zu sein.

Der Sprachkern von PHP und die Ausführungsumgebung sind darauf angelegt, beliebige Bibliotheken und neue Funktionen leicht und schnell in der Sprache zur Verfügung zu stellen: PHP ist wie die Borg in Star Trek – es fügt die Fertigkeiten anderer den eigenen hinzu, um Perfektion zu erreichen. So zumindest hat es Kristian Köhntopp, Urgestein der deutschen PHP-Community, schon vor Jahren ziemlich treffend auf den Punkt gebracht.

entwickler.de: Vielen Dank für dieses Interview!