Perl vs. PHP - konkretes Beispiel eines größeren Vorteils?
0 0 0 0 
Patrick Andrieu
0 0
0 0
Perl vs. PHP - konkretes Beispiel eines größeren Vorteils?
Hallo,
ich lese mich gerade ein wenig in den Artikel "Webtechnologien"
(http://de.selfhtml.org/intro/technologien/php.htm ein, gerade zum Thema PHP. Jetzt lese ich Folgendes:"Manche Dinge, die sich ein Entwickler von dynamischen Web-Seiten wünscht, sind in Perl nur schwer und über Umwege zu erreichen. Gute Perl-Programmierer bekommen zwar jedes Problem in den Griff - aber der Weg zum guten Perl-Programmierer ist weit und lang."
Über Perl-Grundkenntnisse verfüge ich zwar, dennoch würde mir jetzt kein konkreter Fall in den Sinn kommen, in dem die Generierung einer dynamischen Seite mit Perl einen wesentlichen Nachteil in puncto Umständlichkeit des Codese bringen würde. Hat vielleicht jemand ein Beispiel?
Mfg Peter
-
Hallo,
Über Perl-Grundkenntnisse verfüge ich zwar, dennoch würde mir jetzt kein konkreter Fall in den Sinn kommen, in dem die Generierung einer dynamischen Seite mit Perl einen wesentlichen Nachteil in puncto Umständlichkeit des Codese bringen würde. Hat vielleicht jemand ein Beispiel?
Prinzipiell ist PHP (im Gegensatz zu perl) von vorn herein speziell für das Bauen dynamischer Seiten gemacht worden...und insofern vielleicht "weniger umständlich".
(Beispiel: Für sinnvolle Verarbeitung von Formularen muss man in Perl entweder was programmieren und zusätzliche Bibliotheken (wie CGI) benutzen, bei PHP geht es "out of the box"). Auch ist Perl-Code vielleicht für den Anfänger, der vorher ggf. andere Sprachen gemacht hat, etwas gewöhnungsbedürftig, weil durch die zahllosen Freiheiten doch einiges etwas ungewohnt ist.Trotzdem kann ich die Meinung des Autors eigentlich nicht teilen, im Gegenteil: Gerade weil Perl eine Universalsprache ist, finde ich das Angebot an Zusatzbilbiotheken umfangreicher und somit auch die Möglichkeiten umfangreciher als in PHP.
Was mir bei PHP besser gefällt, ist die Objektorientierung - die finde ich in Perl nicht gut gelöst.
Aber das ist Geschmackssache.-
Hi,
jo, du hast im Prinzip Recht, doch das Argument mit den Formularen finde ich nicht so tragend, so fern man die entsprechende CGI-Bibliothek eben geladen hat (eine Code-Zeile ?).
Überhaupt scheint mir der Satz "es dauert lange, ein guter Perl-Programmierer zu werden" doch eher als Lückenfüller zu fungieren, weniger als konkrete Information. Das finde ich ehrlich gesagt ziemlich peinlich, doch gibt es in Selfhtml einiger solcher Passagen die durch schwammige Formulierung Information vorgaukeln.
Die Universalität empfinde ich in puncto Portierbarkeit oder Kommunikation mit anderen Sprachen ebenso als immensen Vorteil.MfG Peter
-
-
Moin Moin!
Ich halte Perls Taint-Mode bei allen Programmen, die Daten aus dem Netz oder von unpriviligierten Benutzern verarbeiten, für einen der größten Vorteile. Denn er zwingt dazu, Eingaben zu validieren. Vergißt man das Validieren, bricht Perl das Programm gnadenlos ab, sobald man mit unvalidierten Daten an irgendwelche kritischen Funktionen herangeht. Natürlich kann man an der Stelle auch Mist bauen und schlicht jeden Müll validieren, aber das ist eine andere Geschichte.
Dazu kommt DBI, das eine EINHEITLICHE Schnittstelle für alle möglichen Datenbanken anbietet, von winzigen Flat-File-DBs bis hin zu riesigen DB-Clustern. Verkneift man sich RDBMS-spezifische SQL-Erweiterungen, kann man Applikationen schreiben, die auch tatsächlich von Flat-File-DBs bis zu DB-Clustern ohne einzige Änderung am Code laufen.
Oh, und ein zentrales Repository mit Modulen für wirklich jedes noch so verrückte Problem habe ich so noch bei keiner anderen Sprache außer TeX gesehen. (OK, technisch gesehen ist es nicht zentral, sondern ein Netz von Mirror-Servern. Aber das sieht man im Alltag nicht.)
An PHP stört mich vor allem, dass man an einigen Stellen gegen Einsteins "so einfach wie möglich, aber nicht einfacher verstoßen hat", als man Perl abkupferte. $, @ und % haben einen Sinn, den man auf der PHP-Seite anscheinend nicht verstanden hat. Kontext ist in PHP ein Fremdwort, ebenso Namespaces.
Perls einheitliche Sort-Funktion, der man bei Bedarf eine Vergleichsroutine mitgibt, kann alles nach beliebigen Kriterien sortieren. In PHP muß man sich mit einem großen Haufen Sortierfunktionen herumschlagen, die alle auf irgendeinen besonderen Vergleich spezialisiert sind. Analoges gilt z.B. auch für Such- und Ersetzfunktionen. PHP ist inkonsistent. Funktionen haben ausgewürfelte Namen, erwarten Parameter in überraschend unterschiedlicher Reihenfolge, und haben merkwürdige Rückgabewerte.
PHP hat viel zu viel Zeug im Sprachkern, der eigentlich in Module gehört. (z.B. Datenbank-Schnittstellen). Perl 4 hatte das Problem ebenfalls, weil zu der Zeit noch niemand auf die Idee gekommen war, Schnittstellen dynamisch nachzuladen. Das war vor 18 Jahren. PHP schlägt sich damit heute noch rum.
PHP "Magic Quotes" - mir fehlen die Worte. Offenbar hat man allerdings mittlerweile eingesehen, dass das nicht die beste Idee war.
Mehr:
Klar, Perl hat auch Macken und Altlasten:
* Support für DBM-Files gehört nicht in den Kern, sondern in Module. Ebenso SysV-IPC, Sockets, getpwnam/getgrnam/gethostbyname/...-Funktionen. Reste von Perl 4.
*eval { BLOCK }; if ($@) { ... }hieße besser try/catch/finally.
* wantarray hieße besser wantlist.
* warnings und strict sind nicht standardmäßig eingeschaltet.
* Features von 5.10 (defined-or-Operator, switch-case mit Smart Matching alias given-when-default, say) müssen explizit überuse feature 5.10eingeschaltet werden, damit alte Scripte nicht auf die Nase fallen.
* defined-or kommt viel zu spät
* say() ist eine nette Idee, aber so etwas triviales kann man auch selbst als Funktion implementieren, wenn man es braucht. Andererseits spart einem die Implementation von say() im Kern genau diese Mühe.
* Perl steht tierisch auf Kriegsfuß mit Dateinamen unter Windows, weil es nicht die Unicode-APIs mit den "langen" Dateinamen nutzt.
* Die fork()-Emulation unter Windows ist eine Krücke. Besser als nichts, aber nicht sonderlich kompatibel mit Scripten, die Unix-Verhalten erwarten.
* perlcc, JPL
* Pseudo-Hashes
* In-place-Sorting ist nur eine interne Optimierung, kann aber nicht explizit gecoded werden.@a=sort @a;wird ab 5.10 optimiert, ich hätte aber lieber so etwas wiesort_inplace(@a)gesehen.
* $^T alias $BASETIME und insbesondere die jedes mal umgerechneten Rückgabewerte von -M, -A und -C sind grober Unfug. Andererseits kann man natürlich auch stat benutzen.
* stat, gmtime und localtime liefern im List-Kontext Arrays statt Hashes mit brauchbaren Namen. File::stat bringt wenigstens für stat() Abhilfe.
* open modifiziert sein erstes Argument (Typeglob oder Scalar), statt ein File-Objekt zurückzugeben
* open mischt Dateinamen und Dateimodus (mittlerweile kann man Modus und Namen getrennt angeben)
* open und andere Funktionen erzeugen weder Warnungen noch Fehler, wenn ein Perl-String mit eingebetteten NUL-Bytes an eine darunter liegende C-Funktion übergeben und dadurch abgeschnitten wird. (Poision NUL byte)Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hallo,
wie ich euch so verstehe, scheint eher der Einsatz von PHP "ein Griff ins Klo" zu sein, ganz anders als in SELFHTML dargestellt? Ich muss gestehen, bin ein bisschen entsetzt darüber, hätte ich doch mehr technische Sachlichkeit und Übersicht erwartet. Wenn ein Laie diesen Artikel zum erstmal mal zu Gesich bekommt, wird er mit lauer Halbwahrheiten und Semiwissen geüttert.
Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.Somit gibt es scheinbar kein Beispiel, auf das das genannte Zitat zutrifft - damit hätten wir noch eher eine Lüge als eine Halbwahrheit.
MfG Peter
-
Hallo Peter!
wie ich euch so verstehe, scheint eher der Einsatz von PHP "ein Griff ins Klo" zu sein,
<polemik style="an">PHP ist ein Griff ins Klo</polemik>
Ehrlich, bald werde ich müssen, aber mir wachsen schon graue Haare (obwohl ich sie alle zwei Tage wegrasiere)...
Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
Weil es vielleicht stimmt, dass es einfacher ist, PHP zu lernen, wenn man damit anfängt, eine Programmiersprache zu lernen. Wer aber Perl geleckt hat, der hat seine liebe Not, auf PHP umzusteigen - es sei denn, er muss, weil einige Provider nur noch PHP anbieten und der Hype es so will.
Weil Alexander über genügend Background verfügt, um über Perl und PHP objektiv zu urteilen - ohne einen Glaubenskrieg zu entfachen.
Viele Grüße aus Frankfurt/Main,
Patrick--
_ - jenseits vom delirium - _
Diblom [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
J'ai 10 ans! | Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt? -
Moin Moin!
wie ich euch so verstehe, scheint eher der Einsatz von PHP "ein Griff ins Klo" zu sein, ganz anders als in SELFHTML dargestellt?
Tja, mein Onkel hat seinen Lebensunterhalt unter anderem dadurch verdient, dass er ein paar Jahrzehnte lang in fremder Leute Klos gegriffen hat. Ich brauch das nicht.
Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.Jetzt gibt es sie. Die beiden verlinkten Seiten gibt's aber schon etwas länger, und dort gibt es auch nochmal ganz ansehnliche Linksammlungen.
Ich gebe zu, dass ich zwei Standard-Aussagen von mir zu PHP schlicht und ergreifend vergessen habe, die ich meinen Kunden und Chefs immer wieder an den Kopf werfe:
1. "Pubertierende Hauptschüler Programmieren"
2. "Es gibt zwei Arten, PHP zu betreiben: Unsicher und abgeschaltet."Nummer 1 ist ein Doppel-Vorurteil, das ich in aller Regel etwas länger begründe. Kurz gesagt ist die Code-Qualität bei PHP oft unter aller Sau, weil PHP es so leicht macht, auf den ersten Blick brauchbare Ergebnisse zu produzieren. Bei genauerer Betrachtung stellt man dann aber fest, das sehr viel fehlt: Sicherheitsprüfungen, edge cases, locking, escaping, usw. PHP ist ein hervorragendes Rapid Prototyping Tool für Web-Anwendungen, eben weil man schnell eine Demo zusammenhacken kann. Aber für den Produktiveinsatz ist eine solche Demo in aller Regel ungeeignet, und PHP steht dem Entwickler dann sehr im Weg, wenn er aus der Demo eine Produktivversion bauen soll.
Nummer 2 ist eine grobe Vereinfachung. Natürlich kann man PHP sicher betreiben, aber der notwendige Aufwand und das notwendige Wissen überschreitet die Fähigkeiten des typischen PHP-Coders bei weitem. PHP selbst macht es einem sicherheitsbewußten Entwickler oder Administrator nicht leichter. Ich möchte nicht dafür garantieren müssen, dass ein PHP-Server so sicher konfiguriert ist, dass niemand eindringen kann. Für meine Perl-basierten Anwendungen lege ich die Hand ins Feuer. Spätestens die routinemäßigen Angriffe auf gar nicht vorhandene PHP-Anwendungen (typischerweise phpMyAdmin und phpBB) in den Server-Logs bestätigen meine Einstellung zu PHP immer wieder.
Natürlich bedeutet der Einsatz von Perl nicht automatisch Sicherheit. Die Behauptung, dass allein die Wahl der Programmiersprache eine Anwendung automatisch 100% sicher macht, überlasse ich lieber den Java-Propagandisten.
Wer keine Ahnung hat, kann mit Perl mindestens genauso viel Schaden anrichten wie mit PHP. *hust* Matt Wright *räusper* Der Punkt ist schlicht und ergreifend, dass Perl mir Werkzeuge gibt, Standard-Fehler zu vermeiden: warnings, strict, Taint Mode, und einen großen Satz gut geprüfter Standard-Libraries. Es versucht allerdings nicht, Standard-Fehler ungefragt durch Automatiken zu reparieren (Magic Quotes).
Die Tatsache, dass Perl nicht bei jedem Hosting-Paket verfügbar ist, und nicht komplett ohne Nachdenken aktiviert werden kann, sortiert schonmal die komplett Ahnungslosen aus. Kleine Gemeinheiten einiger Hoster (Perl ist in /opt/local/perl5/bin/perl statt in /usr/bin/perl) verstärken das noch. Effekt: "Mit PHP ist das alles viel leichter und einfacher". Das sorgt dafür, dass es weniger Ahnungslose auf der Perl-Seite gibt und mehr auf der PHP-Seite. Oft setzen die Hoster alte bis antike Perl-Versionen ein, so dass nicht jedes irgendwo zusammenkopierte Perl-Script sofort läuft. Das schiebt noch mehr Leute zu PHP. Shell-Zugriff gibt es oft gar nicht, an das Error-Log kommt man nur sehr umständlich oder gar nicht heran, und wenigstens 1&1 macht mit Perl *SEHR* merkwürdige Sachen über mod_rewrite und einen selbstgestrickten Wrapper. Das sind noch mehr Hürden, die noch mehr Laien zu PHP treibt und von Perl fernhält.
Der für Perl-Entwickler sehr positive Effekt ist, dass sich die meisten Black Hats auf die leichten Ziele einschießen. Warum sich an Perl die Zähne ausbeißen, wenn man von Laien draufkopierte und nicht ansatzweise abgesicherte phpMyAdmin- und phpBB-Installationen in Massen übernehmen kann? Das gleiche Spiel wie bei Windows vs. MacOS/Linux und IE vs. FF/Opera.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Moin!
»» Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
»» So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.Hm, "neutral"...
Jetzt gibt es sie. Die beiden verlinkten Seiten gibt's aber schon etwas länger, und dort gibt es auch nochmal ganz ansehnliche Linksammlungen.
Ja, aber sie sind auch schon uralt und beziehen sich auf die Situation vor fünf Jahren.
Seitdem hat sich bei PHP eine Menge getan. Und bei Perl?
Ich gebe zu, dass ich zwei Standard-Aussagen von mir zu PHP schlicht und ergreifend vergessen habe, die ich meinen Kunden und Chefs immer wieder an den Kopf werfe:
- "Pubertierende Hauptschüler Programmieren"
- "Es gibt zwei Arten, PHP zu betreiben: Unsicher und abgeschaltet."
Zwei Polemiken, die nicht gerechtfertigt sind.
Nummer 1 ist ein Doppel-Vorurteil, das ich in aller Regel etwas länger begründe. Kurz gesagt ist die Code-Qualität bei PHP oft unter aller Sau, weil PHP es so leicht macht, auf den ersten Blick brauchbare Ergebnisse zu produzieren.
Bei Perl genauso. Die Qualität des Codes hängt direkt proportional von den Fähigkeiten des Programmierers ab, aber gar nicht von den Eigenschaften der Programmiersprache.
Bei genauerer Betrachtung stellt man dann aber fest, das sehr viel fehlt: Sicherheitsprüfungen, edge cases, locking, escaping, usw. PHP ist ein hervorragendes Rapid Prototyping Tool für Web-Anwendungen, eben weil man schnell eine Demo zusammenhacken kann. Aber für den Produktiveinsatz ist eine solche Demo in aller Regel ungeeignet, und PHP steht dem Entwickler dann sehr im Weg, wenn er aus der Demo eine Produktivversion bauen soll.
Du wirst zugeben, dass diese Behauptung schlicht unbewiesene Polemik ist. Nimm einen Programmierer, der Perl schlecht kann, und lass ihn irgendeine Demo zusammenhacken, da wird auch Code rauskommen, den man eigentlich direkt in die Tonne tritt, wenn's danach weitergehen und produktiv werden soll.
Nummer 2 ist eine grobe Vereinfachung. Natürlich kann man PHP sicher betreiben, aber der notwendige Aufwand und das notwendige Wissen überschreitet die Fähigkeiten des typischen PHP-Coders bei weitem.
Schlechte Coder schreiben schlechten Code. Wo ist da der Bezug zur Programmiersprache?
PHP selbst macht es einem sicherheitsbewußten Entwickler oder Administrator nicht leichter. Ich möchte nicht dafür garantieren müssen, dass ein PHP-Server so sicher konfiguriert ist, dass niemand eindringen kann. Für meine Perl-basierten Anwendungen lege ich die Hand ins Feuer.
Auf den SELFHTML-Servern läuft PHP und Perl für unterschiedliche Anwendungen. Ich habe bislang noch keinen Eindringlingszwischenfall feststellen müssen.
Spätestens die routinemäßigen Angriffe auf gar nicht vorhandene PHP-Anwendungen (typischerweise phpMyAdmin und phpBB) in den Server-Logs bestätigen meine Einstellung zu PHP immer wieder.
Und die routinemäßigen Angriffe auf IIS-Schwachstellen etc. existieren ebenfalls, sind nach meiner Wahrnehmung deutlich häufiger, und beweisen trotzdem nicht, dass der aktuelle IIS ein unsicherer Webserver ist.
Natürlich bedeutet der Einsatz von Perl nicht automatisch Sicherheit. Die Behauptung, dass allein die Wahl der Programmiersprache eine Anwendung automatisch 100% sicher macht, überlasse ich lieber den Java-Propagandisten.
PHP tritt mittlerweile erfolgreich an, Java an vielen Stellen des Servereinsatzes für Webapplikationen Konkurrenz zu machen.
Wer keine Ahnung hat, kann mit Perl mindestens genauso viel Schaden anrichten wie mit PHP. *hust* Matt Wright *räusper*
Eben. Das ist genau der Punkt: Schlechter Programmierer == schlechter Code. Programmiersprachenunabhängig.
Der Punkt ist schlicht und ergreifend, dass Perl mir Werkzeuge gibt, Standard-Fehler zu vermeiden: warnings, strict, Taint Mode, und einen großen Satz gut geprüfter Standard-Libraries. Es versucht allerdings nicht, Standard-Fehler ungefragt durch Automatiken zu reparieren (Magic Quotes).
Der Standard-Auslieferungszustand für magic_quotes ist "aus", das Feature ist in Version 5.3.0 deprecated und wird in 6.0 rausgeworfen werden, weil die PHP-Entwickler erkannt haben, dass diese Automagie problematisch ist. Darauf weiter herumzureiten ist also nicht hilfreich.
Sowas wie "Warnings" und "Strict" kriegt PHP eigentlich auch ganz gut hin, um zur Entwicklungszeit ungünstige Konstrukte anzumeckern. Die Standard-Librarys sind bei PHP entweder direkt einkompilierte Module, oder etwas aus der PEAR-Bibliothek.
Und der taint mode - naja, fühlt sich auch eher wie ungute Automagie an - bei PHP war sowas ja böse... :)
Abgesehen davon gibt es auch für PHP Erweiterungen, die die Sicherheit im laufenden Betrieb erhöhen - ich weise da nur mal auf Suhosin hin, sehr empfehlenswert.
Die Tatsache, dass Perl nicht bei jedem Hosting-Paket verfügbar ist, und nicht komplett ohne Nachdenken aktiviert werden kann, sortiert schonmal die komplett Ahnungslosen aus. Kleine Gemeinheiten einiger Hoster (Perl ist in /opt/local/perl5/bin/perl statt in /usr/bin/perl) verstärken das noch. Effekt: "Mit PHP ist das alles viel leichter und einfacher". Das sorgt dafür, dass es weniger Ahnungslose auf der Perl-Seite gibt und mehr auf der PHP-Seite. Oft setzen die Hoster alte bis antike Perl-Versionen ein, so dass nicht jedes irgendwo zusammenkopierte Perl-Script sofort läuft. Das schiebt noch mehr Leute zu PHP. Shell-Zugriff gibt es oft gar nicht, an das Error-Log kommt man nur sehr umständlich oder gar nicht heran, und wenigstens 1&1 macht mit Perl *SEHR* merkwürdige Sachen über mod_rewrite und einen selbstgestrickten Wrapper. Das sind noch mehr Hürden, die noch mehr Laien zu PHP treibt und von Perl fernhält.
Und das sind alles Dinge, die man auch als Perl-Entwickler nicht haben will, weil es ein echt blöder Extra-Aufwand ist, den man lieber mit sinnvolleren Dingen zubringen würde.
Klar, die leichtere Zugänglichkeit von PHP für den Einsteiger ist der Grund, warum man heute viel leichter PHP-Entwickler finden kann, und mit etwas Suchen auch ausreichend qualifizierte Kräfte. Bei Perl ist das schon deutlich schwieriger - was auch ein Grund dafür sein kann, warum Perl keine Sprache ist, die für Webapplikationen riesige Verbreitung gefunden hat.
Der für Perl-Entwickler sehr positive Effekt ist, dass sich die meisten Black Hats auf die leichten Ziele einschießen. Warum sich an Perl die Zähne ausbeißen, wenn man von Laien draufkopierte und nicht ansatzweise abgesicherte phpMyAdmin- und phpBB-Installationen in Massen übernehmen kann? Das gleiche Spiel wie bei Windows vs. MacOS/Linux und IE vs. FF/Opera.
Du meinst, es ist gut, wenn Sicherheitslücken zwar eingebaut, aber nicht ausgenutzt werden, weil sich eh' niemand dafür interessiert, weil die Sprache als obsolet betrachtet wird? :)
- Sven Rautenberg
-
Moin Moin!
»» »» Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
»» »» So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.Hm, "neutral"...
Ich hab nie behauptet, dass meine Postings neutral seien.
»» Jetzt gibt es sie. Die beiden verlinkten Seiten gibt's aber schon etwas länger, und dort gibt es auch nochmal ganz ansehnliche Linksammlungen.
Ja, aber sie sind auch schon uralt und beziehen sich auf die Situation vor fünf Jahren.
Seitdem hat sich bei PHP eine Menge getan. Und bei Perl?Vor 5 Jahren: 5.8.3
Heute: 5.10.0 (Release-Datum: 18. Dezember 2007)
Nahe Zukunft: 5.10.[1-5]
Ferne Zukunft: 5.12.x, 6.0Dokumentation der Änderungen: ->5.8.4 ->5.8.5 ->5.8.6 ->5.8.7 ->5.8.8 ->5.10.0
»» Ich gebe zu, dass ich zwei Standard-Aussagen von mir zu PHP schlicht und ergreifend vergessen habe, die ich meinen Kunden und Chefs immer wieder an den Kopf werfe:
»»
»» 1. "Pubertierende Hauptschüler Programmieren"
»» 2. "Es gibt zwei Arten, PHP zu betreiben: Unsicher und abgeschaltet."Zwei Polemiken, die nicht gerechtfertigt sind.
»» Nummer 1 ist ein Doppel-Vorurteil, das ich in aller Regel etwas länger begründe. Kurz gesagt ist die Code-Qualität bei PHP oft unter aller Sau, weil PHP es so leicht macht, auf den ersten Blick brauchbare Ergebnisse zu produzieren.
Bei Perl genauso. Die Qualität des Codes hängt direkt proportional von den Fähigkeiten des Programmierers ab, aber gar nicht von den Eigenschaften der Programmiersprache.
»» Bei genauerer Betrachtung stellt man dann aber fest, das sehr viel fehlt: Sicherheitsprüfungen, edge cases, locking, escaping, usw. PHP ist ein hervorragendes Rapid Prototyping Tool für Web-Anwendungen, eben weil man schnell eine Demo zusammenhacken kann. Aber für den Produktiveinsatz ist eine solche Demo in aller Regel ungeeignet, und PHP steht dem Entwickler dann sehr im Weg, wenn er aus der Demo eine Produktivversion bauen soll.
Du wirst zugeben, dass diese Behauptung schlicht unbewiesene Polemik ist. Nimm einen Programmierer, der Perl schlecht kann, und lass ihn irgendeine Demo zusammenhacken, da wird auch Code rauskommen, den man eigentlich direkt in die Tonne tritt, wenn's danach weitergehen und produktiv werden soll.
»» Nummer 2 ist eine grobe Vereinfachung. Natürlich kann man PHP sicher betreiben, aber der notwendige Aufwand und das notwendige Wissen überschreitet die Fähigkeiten des typischen PHP-Coders bei weitem.
Schlechte Coder schreiben schlechten Code. Wo ist da der Bezug zur Programmiersprache?
Libraries, Frameworks, Standard-Anwendungen.
»» PHP selbst macht es einem sicherheitsbewußten Entwickler oder Administrator nicht leichter. Ich möchte nicht dafür garantieren müssen, dass ein PHP-Server so sicher konfiguriert ist, dass niemand eindringen kann. Für meine Perl-basierten Anwendungen lege ich die Hand ins Feuer.
Auf den SELFHTML-Servern läuft PHP und Perl für unterschiedliche Anwendungen. Ich habe bislang noch keinen Eindringlingszwischenfall feststellen müssen.
Ich habe nie behauptet, dass PHP grundsätzlich nicht sicher zu konfigurieren ist, und dass man in PHP keinen sicheren Code schreiben kann. Ich halte es nur für wesentlich schwieriger.
»» Der Punkt ist schlicht und ergreifend, dass Perl mir Werkzeuge gibt, Standard-Fehler zu vermeiden: warnings, strict, Taint Mode, und einen großen Satz gut geprüfter Standard-Libraries. Es versucht allerdings nicht, Standard-Fehler ungefragt durch Automatiken zu reparieren (Magic Quotes).
Der Standard-Auslieferungszustand für magic_quotes ist "aus",
Auch bei den PHP-Installationen der gängigen Hoster?
das Feature ist in Version 5.3.0 deprecated und wird in 6.0 rausgeworfen werden, weil die PHP-Entwickler erkannt haben, dass diese Automagie problematisch ist.
Wann wird 6.0 bei den Hostern angekommen und 5.x abgeschaltet sein?
Manitu hat PHP4 erst 2008 ausgeschaltet, Strato bietet PHP 4 immer noch an, ebenso 1&1.
Bei den Perl-Versionen sieht es leider nicht besser aus. 5.8 ist bei den Hostern noch nicht angekommen.
Magic Quotes für Get, Post und Cookies (magic_quotes_gpc) sind bei 1&1 EINgeschaltet, sowohl für PHP4 als auch für PHP5.
Darauf weiter herumzureiten ist also nicht hilfreich.
So lange es in der Praxis eingeschaltet ist, sollte man zumindest darauf Hinweisen, das PHP so einen Unsinn macht.
Sowas wie "Warnings" und "Strict" kriegt PHP eigentlich auch ganz gut hin, um zur Entwicklungszeit ungünstige Konstrukte anzumeckern.
"eigentlich" oder wirklich?
Die Standard-Librarys sind bei PHP entweder direkt einkompilierte Module, oder etwas aus der PEAR-Bibliothek.
Was nicht da ist, kann nicht angegriffen werden.
Und der taint mode - naja, fühlt sich auch eher wie ungute Automagie an - bei PHP war sowas ja böse... :)
Der Taint Mode versucht nicht, irgendetwas gerade zu biegen, was ein schlampiger Programmierer verbockt hat, wie es PHP mit den Magic Quotes macht. Der Taint Mode bricht die Verarbeitung mit einer Fehlermeldung komplett ab, wenn unverifizierter Input an kritische Funktionen (system, exec, open, rename, ...) weitergegeben wird, egal ob explizit (Parameter) oder implizit (%ENV). Das ist ganz ausführlich in perlsec dokumentiert und hat absolut nichts magisches an sich.
Abgesehen davon gibt es auch für PHP Erweiterungen, die die Sicherheit im laufenden Betrieb erhöhen - ich weise da nur mal auf Suhosin hin, sehr empfehlenswert.
Wer benutzt die standardmäßig?
Ist die bei den gängigen Hostern verfügbar?
Bei Manitu, Strato und 1&1 habe ich jedenfalls keinen Hinweis darauf gefunden.
»» Die Tatsache, dass Perl nicht bei jedem Hosting-Paket verfügbar ist, und nicht komplett ohne Nachdenken aktiviert werden kann, sortiert schonmal die komplett Ahnungslosen aus. Kleine Gemeinheiten einiger Hoster (Perl ist in /opt/local/perl5/bin/perl statt in /usr/bin/perl) verstärken das noch. Effekt: "Mit PHP ist das alles viel leichter und einfacher". Das sorgt dafür, dass es weniger Ahnungslose auf der Perl-Seite gibt und mehr auf der PHP-Seite. Oft setzen die Hoster alte bis antike Perl-Versionen ein, so dass nicht jedes irgendwo zusammenkopierte Perl-Script sofort läuft. Das schiebt noch mehr Leute zu PHP. Shell-Zugriff gibt es oft gar nicht, an das Error-Log kommt man nur sehr umständlich oder gar nicht heran, und wenigstens 1&1 macht mit Perl *SEHR* merkwürdige Sachen über mod_rewrite und einen selbstgestrickten Wrapper. Das sind noch mehr Hürden, die noch mehr Laien zu PHP treibt und von Perl fernhält.
Und das sind alles Dinge, die man auch als Perl-Entwickler nicht haben will, weil es ein echt blöder Extra-Aufwand ist, den man lieber mit sinnvolleren Dingen zubringen würde.
Da gebe ich Dir vollkommen recht.
»» Der für Perl-Entwickler sehr positive Effekt ist, dass sich die meisten Black Hats auf die leichten Ziele einschießen. Warum sich an Perl die Zähne ausbeißen, wenn man von Laien draufkopierte und nicht ansatzweise abgesicherte phpMyAdmin- und phpBB-Installationen in Massen übernehmen kann? Das gleiche Spiel wie bei Windows vs. MacOS/Linux und IE vs. FF/Opera.
Du meinst, es ist gut, wenn Sicherheitslücken zwar eingebaut, aber nicht ausgenutzt werden, weil sich eh' niemand dafür interessiert,
Apple hat mit exakt dieser der Argumentation tonnenweise Hardware vertickt und tut es noch heute.
weil die Sprache als obsolet betrachtet wird? :)
Eher wegen des "Millionen Fliegen können nicht irren"-Prinzips.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
Moin,
wie ich euch so verstehe, scheint eher der Einsatz von PHP "ein Griff ins Klo" zu sein, ganz anders als in SELFHTML dargestellt?
Das würde ich so auch nicht sagen. Vieles in PHP finde ich wie gesagt gut oder gar besser als in Perl gelöst (Beispiel: Objektorientierung, jedenfalls meiner meinung nach) - aber eben auch nicht alles.
Oft wird PHP auch die leichte Erlernbarkeit als Nachteil angelastet ("nichts für ernsthafte Programmierer, nur was für Kiddies,...") - was ich aber prinzipiell nicht so sehe. Gerade WENN eine Programmiersprache leicht zu erlernende Konzepte hat, ist sowas ein Vorteil.
Letztendlich führt aber das Programmiersprachen-Bashing zu nichts.
Einem Programmierer sollte es eh egal sein, ob er seine Software in C, C++, C#, Java, Perl, PHP, Ruby, Python oder was auch immer schreibt, da es meist auf das Anwendungsszenario ankommt.
=> Mein persönliches Fazit:
Ich habe ursprünglich mit Perl angefangen und erst im Job auch mal PHP gemacht. Mittlerweile programmiere ich etwas lieber in PHP als in Perl - das ist aber eine persönliche Vorliebe (ich mag Java, und die Objektorientierungs-Syntax in PHP ist näher an der von Java als die von Perl)Aber just im Moment bastele ich z.b. privat an einer Mini-Webanwendung für meine NSLU, und auf diesem Kistchen (266 MHZ, 32 MB Ram) zählt einfach Geschwindigkeit und Speicherbedarf extrem - und nach meinem persönlichen(!) Empfinden laufen darauf(!) einfach PHP-Anwendungen LANGSAMER, wohingegen ich die Perl-Performance recht beeindruckend finde (was nicht heisst, dass man generell behaupten kann, PHP sei zu langsam) - mal ganz abgesehen davon, dass PHP darauf noch nicht installiert ist, und eine reguläre Paketinstallation auf dem Ding eine halbe Ewigkeit dauert.
=> Ich kehre also zurück zu den Wurzeln :)
(Und ja, "Nägel mit Köpfen" zu machen, und das Ding gleich in C zu programmieren, kam mir auch in den Sinn ;) ).
-
-
-
Hallo,
[..] Manche Dinge, die sich ein Entwickler von dynamischen Web-Seiten wünscht, sind in Perl nur schwer und über Umwege zu erreichen.
Das nenne ich Polemik.
Fakt: Ich selbst habe beruflich viele Jahre Tools fürs Netzwerkmanagement geschrieben, ungezählte Scripts und Webanwendungen mit oder ohne Datenbankanbindung und alles in Perl. Auf jeden Fall hängt da mehr dran, als ein bissl HTML-Code oder ein paar Grafiken zum Browser zu schicken, da sind auch Prozesse nachgelagert, die im Hintergrund laufen, inclusive Libraries die dafür zu schreiben sind und alles ist in Perl zu machen.
Perl kennt 'strict;' und '-w', unterschiedet zwischen Groß~ und Kleinschreibung, das sind Dinge, die beim Erstellen von Scripts mit mehreren tausend Zeilen Code nicht wegzudenken sind, egal ob da objektorientiert oder sonstwie programmiert wird.
Vergiss den Satz da oben, eine Frage nach einem Beispiel ist überflüssig.
Schöne Grüße,
Hotte--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein. -
Über Perl-Grundkenntnisse verfüge ich zwar, dennoch würde mir jetzt kein konkreter Fall in den Sinn kommen, in dem die Generierung einer dynamischen Seite mit Perl einen wesentlichen Nachteil in puncto Umständlichkeit des Codese bringen würde. Hat vielleicht jemand ein Beispiel?
Ich bringe einen Punkt, wo in in Perl einen Mangel sehe.
Würde ich php verwenden, würde ich vorbehaltlos auf UTF-8 setzen.
Diese Haltung kann ich in Perl noch nicht einnehmen, da ich immer auch noch für Perl 5.6 schreiben muss.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
