»PHP (recursive acronym for "PHP: Hypertext Preprocessor")«, so steht es in Kapitel Eins der PHP Dokumentation. "Perl" dagegen ist ein Akronym für "Practical Extraction and Report Language". Warum sollte ich meine Zeit damit verschwenden, einen HTML-Preprocessor, der vermutlich als Preprozessor schon m4 unterlegen ist, mit einer Sprache, die für Strings und String-Bearbeitung jeglicher Art geschrieben wurde, vergleichen? Schließlich vergleiche ich ja auch nicht ein Bierfass mit einer Tropfschale oder einen schweizer Taschenmesser mit einer Nagelfeile.. Der Grund ist, dass viele Benutzer der Nagelfeile, sich selbst PHP-"Programmierer" nennend, über eine krass verzerrende Wahrnehmung verfügen. Sie behaupten nicht nur, dass es PHP mit Perl aufnehmen könnte, sondern denken sogar Argumente dafür zu haben, dass PHP eine Programmiersprache sei.
Um den Vergleich zumindest ein bisschen objektiv zu machen gehe ich nur auf generelle Aspekte und Bereiche rund um dynamische Webinhalte ein. Immerhin das Gebiet auf dem PHP noch die beste Figur macht und, leider, "Marktführer" ist. Der Einfachheit halber beziehe ich mich manchmal auf mod_perl, auch wenn ich von Perl spreche. Sollte ich hier versehentlich grobe Unwahrheiten verbreiten, lasst es mich bitte wissen. Jetzt aber viel Spass ;)
| Perl / mod_perl | PHP | |
|---|---|---|
| Variablen | Perl kennt Scalare, Arrays und Hashes. Dabei unterscheiden sich Scalare noch, unter Anderen in Strings, Nummern und Referenzen. Variablen können (Modul-)Global, Modul-Privat oder lexikalisch deklariert werden. Mit sogenannten "Closures" kann man auch eine Art "Funktions Globale" Variablen erzeugen. |
PHP kennt Scalare und "associative
Arrays", also Hashes.
"Referenzen" sind eigentlich
Variablen-Aliase; "richtige"
Referenzen existieren nicht. Variablen
können nicht deklariert werden,
bzw. können deklariert werden,
aber das hat keinen Einfluss auf die
Lebensdauer der Variable und macht auch
sonst keinen Unterschied. Namespaces
gibt es nur in der Form, dass eine
Funktion ihren eigenen Namespace haben
kann (wenn dies in der
php.ini entsprechend
aktiviert wurde) und in diesen dann die
globalen Variablen importieren muss,
falls sie diese benutzen möchte.
|
| Einsatzgebiete | Kann vielfältig für fast alle Aufgaben eingesetzt werden. Die Ursprüngliche String- und Dateiverarbeitungssprache ist mit ihren Aufgaben gewachsen und gilt heute als "duct tape of the internet". |
Ist praktisch
auf Web-Anwendungen beschränkt. Es
besteht zwar die Möglichkeit, PHP
mit "CLI" zu bauen, aber
selbst dann muss man den Interpreter
mit php -q aufrufen um
einen HTTP-Header zu unterdrücken.
Tatsächliche, Nicht-Web-Programme,
die in PHP geschrieben sind, sind
extrem selten und akademischer Natur.
|
| Dokumentation | Perl selbst umfasst über 100 Manpages, die von der Sprach-Syntax bis zu Implementierungsdetails alles abdecken was wissenswert über Perl ist oder sein könnte. Homepages rund um CPAN bieten für alle und jedes Perl-Modul die entsprechende Dokumentation als Webpage an. Ist das Modul erst mal installiert kann die Dokumentation durch den Integrierten POD-Mechanismus leicht eingesehen, in Manpages umgewandelt und auf andere Art und Weise weiterbehandelt werden. |
$ man php
Sagt das nicht schon alles? Die
Dokumentation auf der Homepage
behandelt zwar auf den ersten Blick
alle möglichen "Module",
aber der Teufel steckt im Detail: So
werden "deprecated functions"
garnicht mehr dokumentiert - auch wenn
es in älteren Versionen keine
Alternative gibt und sich das Interface
inzwischen geändert hat (Beispiel:
No manual entry for php domxml_open_mem und
xmldoc). Häufig
werden Konstanten zwar aufgelistet,
eine Beschreibung über ihre
Wirkung aber fehlt (Beispiel:
DOMXML_LOAD_SUBSTITUTE_ENTITIES).
Und ich bin über das DOM-XML-Modul
noch nicht hinausgekommen..
|
| Erweiterbarkeit | Das Comprehensive Perl Archive Network (kurz: CPAN) beherbergt und strukturiert unzählige Perl-Module um den Funktionsumfang quasi beliebig auszubauen. Mit XS und SWIG stehen zwei leistungsfähige Schnittstellen zur Integration von C-Code zur Verfügung. | Module in dem Sinn existieren nicht. Dateien, die eingebunden werden, werden komplett in den jeweiligen Namespace geladen. Libraries, die lediglich eine C-Schnittstelle besitzen müssen in den PHP-Interpreter gelinkt werden, was für Produktivsysteme keine Option ist. |
| Beständigkeit | Syntax und Semantik der Perl-Primitiven hat sich seit der Version 5 nicht mehr geändert. Für die "Pragmas" und Module gilt das nicht so uneingeschränkt: Das "warnings"-Pragma kam beispielsweise erst in der Version 5.6 dazu, die IO-Layer sind in der Version 5.8 neu. Die Kern-Funktionalität ist aber die gleiche geblieben. "Einstellungen", die das Verhalten des Interpreters ändern, werden durch das Laden bestimmter "Pragmas" vorgenommen und sind so von jeden Script selbst zu bestimmen. |
PHP's Beständigkeit leidet
darunter, dass alle "Module"
Bestandteil der Sprache sind. Daher
werden dauernd neue Funktionen
hinzugefügt und alte umbenannt,
ändern sich Parameter und
verschwinden Konstante; und das sogar
zwischen Patch-Versionen. Zum Beispiel
hat sich die Semantik der Funktion imagegd2 zur
Version 4.3.2 hin geändert. Das
größte Problem allerdings
ist, dass wichtige Verhaltensmerkmale
von globalen Einstellungen in der
php.ini anhängen. So
zu programmieren, dass der Code
unabhängig von Einstellungen in
dieser Datei ist, ist eine
Herausforderung der sich die Wenigsten
stellen.
|
| Geschwindigkeit | Zwar ist es nicht gerade sinnvoll sich bei Scriptsprachen Gedanken über die Performance zu machen, aber wer sich trotzdem dafür interessiert kann im The Computer Language Shootout nachlesen dass Perl schneller ist als PHP. | |
| Perl / mod_perl | PHP | |
|---|---|---|
| Strings |
Perl kennt zahlreiche Wege Strings zu
definieren. Neben den typischen single-
und double-quotes werden sogenannte
"here-doc"- und
"Quote-Like"-Operatoren zur
Verfügung gestellt. Konstrukte wie
qq( ... ) machen
in einer Umgebung mit vielen Quotes im
String das Leben leichter.
"here-doc"-Operatoren
können auch in Funktionsaufrufen
und ähnlichen Umgebungen verwendet
werden.
|
PHP bietet ebenfalls single- und
double-Quotes an und beherrscht
"here-doc"-Operatoren.
Die here-docs funktionieren aber anders
als in der Bourne Shell und Perl. Nicht
nur, dass PHP das Konstrukt
"<<<"
verwendet, auch das Semikolon folgt auf
das schließende Wort. Ausserdem
gibt es keine Möglichkeit die
Variablenersetzung auszuschalten oder
here-docs in Funktionsaufrufen zu
verwenden. Eine weitere Besonderheit
von PHP sind "magic quotes":
Dieses tolle "Feature"
escaped in allen Strings, die als
Parameter übergeben werden, die
Quote-Zeichen. Das ist sehr sinnvoll,
weil.. Ja, warum eigentlich? Escapen
funktioniert in HTML nicht mit
Backslashes und auch SQL verwendet
»""«..
|
| Webserver-Integration | mod_perl kann als "Handler" für jede der elf Phasen eines HTTP-Requests dienen. Eine dieser Phasen ist die "Response Phase", alle anderen haben mit der Generierung der Contents wenig zu tun. Entsprechend vielseitig kann mod_perl zum Beispiel zum Loggen in Datenbanken, Zugriffsbeschränkungen und vieles weitere eingesetzt werden. mod_perl Module wie Apache::ePerl stellen in HTML eingebettetes Perl, ganz ähnlich zu PHP, zur Verfügung. |
PHPs Interaktion mit dem Webserver ist
mehr oder weniger auf die Variable
$_SERVER beschränkt,
mit der man ein paar Informationen
über den Webserver erfragen kann.
Ansonsten eignet sich PHP nur um
Content zu generieren. Und selbst hier
muss man sich vorsehen, dass PHP nicht
von selbst behauptet es handle sich um
text/html..
|
| Perl / mod_perl | PHP | |
|---|---|---|
| FlatFile Datenbanken | Mit dem core-Modul DB_File besteht eine komfortable und mächtige API zur Berkley DB. Auserdem existiert noch das AnyDBM_File Framework als einheitliche Schnittstelle zu weiteren DBM Formaten. | PHP bietet zwar auch die Möglichkeit auf viele Datenbanken zuzugreifen, aber weder durch eine einheitliche API (zur Zeit, also August 2005, gibt es 13 verschiedene connect-Befehle) noch sind zusätzliche Datenbanken problemlos nachrüstbar. Platzhalter in Queries, die das Kompilieren weiterer Anfragen ersparen, sind genausowenig möglich wie ein sinnvoller Umgang mit Transaktionen. |
| Relationale Datenbanken | Die DBI wurde als API für Datenbanken konzipiert. Diese extrem mächtige Rahmenstruktur ist Datenbank unabhängig und bedient sich sogenannter "DBD"s, die die Treiberschicht zwischen der DBI und der eigentlichen Datenbank bilden. Diese DBDs sind für fast (?) alle Datenbanken verfügbar, zum Beispiel: mySQL, PosgreSQL, CVS, Oracle und sogar ODBC und Excel. | |
| Persistenz | Datenbank-Verbindungen und Statement-Handles können halbwegs problemlos persistent angelegt und verwendet werden. Der Programmierer muss sich allerdings entweder selbst darum kümmern oder explizit Apache::DBI verwenden. | Datenbank-Verbindungen werden per default versucht persistent zu halten. Das Problem ist vielmehr, dass auch Ergebnisse gecached werden, was bei unvorsichtigem Umgang zu Massenvernichtung von Arbeitsspeicher führt. Und Usern, für die "magic quotes" eingeführt wurden, unterstelle ich einen unvorsichtigen Umgang. |
Dynamische Grafiken stehen fast schon so häufig auf dem Programm eines Webdesigners wie dynamische Webseiten. Ob das nun grundsätzlich gut oder schlecht ist, ist eine andere Geschichte. Sowohl Perl als auch PHP bieten Möglichkeiten, Grafiken "on-the-fly" zu erzeugen. Perl wie gewohnt mit Hilfe von Modulen, PHP wie erwartet mit "build-in"-Funktionen.
| Perl / mod_perl | PHP | |
|---|---|---|
| GD | Das Modul GD.pm von Lincoln Stein stellt die komplette GD-API unter Perl zur Verfügung. | PHP hat, falls zur Zeit des kompilierens mit der GD verlinkt, ebenfalls die Funktionalität der GD. Dass dazu Tausend und eine Funktion in den default "Namespace" importiert werden werden PHP Anhänger vermutlich noch zur Design-Ideologie erheben.. |
| Andere | Im CPAN finden sich viele weitere Module für grafische Belange, von alternativen Formaten, wie "VRML", über alternative Bibliotheken, etwa Image::Magick, bis zu Graph-Modulen wie GD::Graph. Von den Möglichkeiten, die die Gimp-Integration eröffnen ganz zu schweigen.. | PHP besitzt Support für einige wenige weitere Formate, zum Beispiel "SWF". Für einzelne Anwendungsgebiete, etwa das Zeichnen von Graphen, gibt es Code von externen Anbietern. |
Meine ganz persönlichen Gründe die eine Programmiersprache zu bevorzugen und eine andere nicht zu mögen unterliegen weder obligatorischen Zwängen, faktischer oder politischer Korrektness noch objektiver Auseinandersetzung mit der anderen Sprache. Nur um es nochmal zu betonen: Diese gesamte Gegenüberstellung ist subjektiv!
| für Perl / mod_perl | gegen PHP |
|---|---|
|
|