Interview: Die Entwickler sind schlecht, nicht PHP
Zeev Suraski: Stimmt, Zend ist für die Kernkomponenten von PHP verantwortlich. Als wir mit der Arbeit an der Zend Engine II begannen, ging es uns in erster Linie um eine deutlich bessere Objektorientierung und eine exzellente Infrastruktur zur Entwicklung objektorientierter Erweiterungen. Und wir haben beides erreicht.
Die neuen Möglichkeiten der Objektorientierung sind mächtig und erlauben es Nutzern, objektbasierte Applikationen mit Standard-OO-Methoden wie Design-Pattern zu entwickeln. Dies zeigt sich schon jetzt in einigen PHP-5-Applikationen und Büchern zu PHP 5.
Ebenso wichtig ist aber auch der Erfolg des APIs, das die Zend Engine II für OO-Erweiterungen bietet und erst die Entwicklung einiger der interessantesten Funktionen von PHP 5 erlaubte. Dazu zählt SimpleXML von Sterling Hughes, Marcus Broeger und Rob Richards, die Unterstützung von Web-Services via SOAP von Dmitry@Zend, die neue COM/.NET-Integration von Wez Furlong und das MySQLi-Modul von Georg Richter.
Golem.de: Thies Arntzen und Sterling Hughes zeigten vor gut einem Jahr, dass PHP und die Zend Engine I noch viel Potenzial für Geschwindigkeitssteigerungen bieten. Was ist in Bezug auf Leistung und Geschwindigkeit von PHP 5 zu erwarten?
Suraski: Der Fokus bei PHP 5 lag sicher nicht bei einer Geschwindigkeitssteigerung. PHPs aktuelle Geschwindigkeit ist exzellent und es gibt zahlreiche Lösungen zur Leistungssteigerung. Ich denke es ist am wichtigsten, den Nutzern die von ihnen benötigten Funktionen zur Verfügung zu stellen, viel wichtiger, als in einigen synthetischen Benchmarks 5 Prozent mehr Leistung herauszuquetschen. Daher halte ich Sterlings Arbeit an SimpleXML für viel wichtiger als seine Arbeit an diesen Performance-Patches.
In echten Applikationen trägt die Leistung der zu Grunde liegenden Engine nur ein kleiner Mosaikstein in der Liste von Faktoren, die für die Geschwindigkeit der Applikation verantwortlich ist. Die Qualität des in PHP geschriebenen Codes und die verwendeten Performance-Management-Tools spielen eine viel größere Rolle. Meiner Erfahrung nach haben Performance-Probleme immer mit schlecht designtem Code oder fehlenden Performance-Management-Tools zu tun.
Dennoch gibt es einige interessante Änderungen in PHP 5, die sich auf die Leistung auswirken, insbesondere wenn es um objektorientierten Code geht. Dank des neuen Objektmodells sollten objektorientierte Applikationen etwas schneller werden – schließlich werden weniger Daten kopiert. Wir denken zudem darüber nach, einige der von Thies und Sterling vorgeschlagenen Änderungen zu integrieren, nachdem PHP 5.0 erschienen ist – vielleicht schon in PHP 5.1.
Golem.de: Auf der einen Seite zählt die sehr flache Lernkurve zusammen mit der Möglichkeit, einfache Web-Entwicklungen schnell umzusetzen, zu den größten Stärken von PHP. Auf der anderen Seite wird gerade dies aber auch immer als eine der größten Schwächen von PHP bezeichnet, verleitet dies doch zu "schlampigem" Programmieren. Wie sehen sie diesen Widerspruch?
Suraski: Wie ich schon gesagt habe, sind es vor allem die Fähigkeiten, Erfahrungen und das Talent der Entwickler, die Einfluss auf die Qualität von Applikationen haben. Ein wenig talentierter Entwickler wird mit Java ebenso fehlerhafte und ineffiziente Applikationen entwickeln können wie ein guter Entwickler exzellente, verlässliche und stabile Applikationen mit PHP entwickeln kann. Aber es stimmt, viele der Nutzer, die heute in PHP entwickeln, haben wenig Informatik-Kenntnisse, wenn überhaupt, was bedeutet, dass sie leicht Gefahr laufen, typische Fehler zu machen. Ich denke, das ist einer der Gründe, warum einige PHP als "schlechte Sprache" empfinden, denn große Teile des in PHP geschriebenen Codes wurden von kaum erfahrenen Entwicklern verfasst.
Schaut man sich aber einmal die Tatsache an, dass diese Nutzer in der Lage sind, dank der einfachen Nutzung von PHP unabhängig zu entwickeln, stellt sich die Sache ganz anders dar. Es ist kaum vorstellbar, dass jemand ohne große Kenntnisse in der Lage ist, mit der Entwicklung in C++ oder Java zu beginnen.
Golem.de: Wie Sie schon sagten, bietet PHP 5 eine deutlich bessere Unterstützung für eine objektorientierte Entwicklung. Dennoch ist PHP noch weit davon entfernt, eine Sprache zu sein, die von Grund auf für eine objektorientierte Entwicklung designt wurde. Warum also spielt gerade die Objektorientierung eine so große Rolle für PHP?
Suraski: Ich glaube, dass PHP 5 all die Funktionen bietet, die man von einer Scriptsprache erwarten kann. Es gibt grundlegende Dinge – Kapselung, Vererbung und bis zu einem gewissen Grad auch Polymorphismus -, die es Entwicklern erlauben, objektorientierte Applikationen auf Basis der eigenen Erfahrungen und dem eigenen Wissen um Objektorientierung zu entwickeln.
Es sind vor allem zwei Dinge, weshalb wir Objektorientierung in PHP für wichtig halten. Zum einen sind das die Vorlieben der Nutzer. Wenn Sie sich die zahlreichen PHP-Applikationen, die veröffentlicht wurden, anschauen, werden Sie feststellen, dass viele die weniger optimale OO-Syntax von PHP 4 nutzen. Es gab zahllose Anfragen von Nutzern bezüglich einer besseren Objektorientierung in PHP und wir haben uns entschieden, darauf zu reagieren.
Zum anderen glauben wir, dass das neue OO-Modell es PHP erlauben wird, seine Präsenz im Unternehmensbereich stärker auszuweiten. Eine bessere Akzeptanz im Unternehmensbereich hat das Potenzial, das Leben von allen PHP-Nutzern zu verbessern, entstehen dadurch doch mehr Jobs, bessere Werkzeuge und eine insgesamt verbesserte Technik.
Golem.de: Zend hat zusammen mit Sun angekündigt, die Integration von PHP und Java zu vereinfachen. Was können Entwickler davon erwarten?
Suraski: Das Ergebnis der JSR-Initiative ist eine formale Spezifikation, die beschreibt, wie eine Scriptsprache mit Java zusammenarbeiten kann und umgekehrt. Die Referenz-Implementierung für diese JSR ist PHP, was meiner Meinung nach zeigt, welchen Stellenwert Sun PHP in Bezug auf die J2EE-Welt beimisst. Ich denke, dass dies Entwicklern langfristig die Möglichkeit bietet, bei der Entwicklung von J2EE-Server-Applikationen JSP durch PHP zu ersetzen. Und das wäre in meinen Augen ein großer Schritt, kann PHP bei der schnellen und verlässlichen Entwicklung von mächtigen Web-Front-Ends doch eine exzellente, komplementäre Komponente zu Java darstellen. Dies ist aber nur durch die Erweiterungsmöglichkeiten der Zend Engine II möglich.
Golem.de: Wo sehen Sie die Grenzen für PHP? In welchen Situationen sollten Entwickler auf andere Lösungen wie Java ausweichen?
Suraski: Ich denke, es ist sehr schwer, Grenzen zu ziehen, wenn man über so mächtige Sprachen wie Java, PHP, C++ oder Perl spricht. Letztendlich, so sagte Turing, sind sie alle äquivalent ... Auch wenn ich mich wiederhole, ich denke, das hat viel mit den Entwicklern zu tun und nicht nur mit dem jeweiligen Problem, das es zu lösen gilt. Entwickler mit umfangreichen Kenntnissen in PHP werden bessere Applikationen schreiben, wenn sie PHP statt einer anderen Sprache nutzen. Um objektiv zu sein, muss ich aber sagen, dass dies auch für alle anderen Sprachen gilt. Naja, abgesehen von LISP vielleicht.
Wenn man mich zwingt zu sagen, wofür PHP am besten geeignet ist, würde ich definitiv "Web-Applikationen" antworten. Ich glaube, dass PHP eine exzellente Wahl für jedwede Web-Applikation ist. In gleicher Weise liegt die Stärke von J2EE in erster Linie bei transaktionalen Applikationen. Glücklicherweise wird man bald aber nicht mehr wählen müssen, sondern kann beide zusammen verwenden.
Golem.de: Um PHP in Traffic-intensiven Umgebungen einzusetzen, ist der Einsatz von Code-Caching unabdingbar – etwas, das für viele ein Kernbaustein der Standard-PHP-Distribution sein sollte. Für einige sieht es aber so aus, als sei die Tatsache, dass Zend ein entsprechendes kommerzielles Produkt anbietet, dafür verantwortlich, dass PHP ohne "Beschleuniger" ausgeliefert wird. Würden Sie dem zustimmen?
Suraski: Als wir 1999 die Zend Engine entwickelten, haben wir auf ein erweiterbares API geachtet, so dass Entwickler Plug-Ins für PHP entwickeln können. Plug-Ins wie Debugger, Code Caches Optimizer und anderes. Sicherlich war die Idee, kommerzielle Lösungen dafür anzubieten, dabei eines der Ziele, aber wir entschieden uns für ein offenes, erweiterbares API, um es jedem zu ermöglichen, an diesem Spiel teilzunehmen.
Vor dem Hintergrund der unterschiedlichen Geschäftsmodelle, die rund um Open Source existieren, ist dies derzeit sicherlich das Community-freundlichste Modell. Wir zwingen niemanden, unsere Produkte zu kaufen und jeder kann PHP nutzen, verkaufen oder verändern, wie immer er möchte, ohne mit uns zu sprechen. Es existiert ein Wettbewerb, und meiner Meinung nach fördert dieser Innovationen, wie sich schon mehrfach gezeigt hat und sich auch in Zukunft zeigen wird.
Technisch gesehen gibt es zudem einen signifikanten Unterschied zwischen einem Beschleuniger und jedem anderen Teil von PHP, denn es ist die einzige Komponente, die durch die Nutzung des Shared Memory nicht zu 100 Prozent isoliert ist. Damit ist es der heikelste Teil eines PHP-basierten Systems und ein Fehler, der hier auftritt, kann weitreichende Auswirkungen auf den Server haben. Die Tatsache, dass Zend in diesem Bereich eine Lösung mit kommerziellem Support und Recovery-Optionen auf kommerziellem Niveau anbietet, ist ein wirklicher Mehrwert für Unternehmen und könnte in dieser Form nicht angeboten werden, wenn sie in PHP integriert wäre.