In der o.g. c't-Zeitschrift findet sich u.a. ein Artikel "Vorhang auf - 10 Hoster-Pakete mit PHP und Datenbank für den dynamischen Webauftritt". (S.122ff)
Im Abschnitt "Skriptsprachen" wird dort verkündet, daß Perl im Webbereich "stark an Bedeutung verloren" hätte, und die Hälfte der im Artikel betrachteten Hoster gar kein CGI mehr anbieten. Als Grund mutmaßt der Autor über die Hoster: "Denkbar ist, dass sie darin eine Möglichkeit sehen, ihre Server vor wild laufenden Perl-Skripten zu schützen." (S.125)

Ich empfinde das als eine haarsträubende und ärgerliche Behauptung. (Von dem, daß im Artikel CGI mit Perl gleichgesetzt wird sehe ich eh' mal ab.) Lassen sich seitens der Hoster bei PHP besser Schranken setzen als bei Perl? Was meint ihr dazu?

naja, das kommt darauf an, welche hoster da getestet werden.
seriöse hoster setzen niemals mod_php sein, sondern php auch nur als cgi in verbindung mit suexec, um zu verhindern, dass jeder ein script mit den rechten des webservers ausführen darf.
mittlerweile gibt es aber immer mehr, gerade kleine, die einfach mod_php nehmen und auf alles weitere scheißen.

natürlich gibt's bei php einige built-in-schranken, die man setzen kann, aber die können immer noch bugs beinhalten (was sie ja nicht selten auch taten) und vor allem ersetzen sie keinen richtig konfigurierten server. ich mein, schön und gut, wer's gerne hat, dass jeder der anderen leute, die auf einem shared hosting liegen, seine sachen durchstöbern und passworte auslesen kann, warum nicht. wer das nicht mag, wird ohne cgi nicht auskommen, egal, ob perl oder php oder was auch immer, weil was anderes einfach nicht geboten wird. aber naja, die ct kauft ja auch artikel von, sagen wir mal, mäßig qualifizierten ein, um inhalte zu einem bestimmten thema zu haben (und weil's vermutlich billiger ist, einen studenten einen artikel schreiben zu lassen, der sich ein bisschen in foren umgesehen hat, als jemanden, der wirklich im thema steckt)

Meine Güte, warum seit wann ist PHP kein CGI? Wäre mir neu.
mod_php einzusetzen hat da ab und an üble Tücken udn nicht jede Hoster ist wirklich kompetent.

RalphFFM+2008-07-26 11:21:32--

Als Grund mutmaßt der Autor über die Hoster: "Denkbar ist, dass sie darin eine Möglichkeit sehen, ihre Server vor wild laufenden Perl-Skripten zu schützen." (S.125)

Wenig Sachverstand, hat da der Autor.

Auf seriösen Shared-Server wird nur suexec angewandt.
Und randalieren kann so ein Skript nicht, das hat begrenze Resourcen und Laufzeit.

Aber es ist schön zu lesen wie in aller Regelmäßigkeit PHP hochgejubelt wird, natürlich dann indirekt auch die löchrichen Anwendungen mit SQL-/XSS-/XSRF-Lücken gefördert.

Macht nix, Leute, nehmt PHP, dann habt ihr wenigstens viele Einbrüche und Angriffe auf euren Systemen.

Mein Bruder arbeitet gerade an einem PHP Script. Nach drei Wochen ist er jetzt so langsam mit den Nerven fertig. Der vorherige Programmierer hat ein unwartbares Moster geschaffen mit sinnlos bennannten globalen Variablen, zu unterschiedlichen Zwecken genutzt, in verschieden Dateien definiert. Includeorgien die je nach dem wo sie eingefügt werden anders arbeiten. Keine Namensräume , kaum Funktionen, keine Fehlerbehandlung, keine Kommentare.

Verrückt ist, dass das auf einem Server läuft, auf einem anderen mit identischer Hardware, Software und Konfiguration, alle Naselang zu Speicherüberläufen führt.

Und aus meiner Erfahrung ist so was kein Einzelfall. Ich kenne keine andere Scriptsprache dessen Interpreter so unberechenbar ist. Manchmal glaube ich es hängt mit den Mondzyklen oder den Sternen zusammen, ob ein PHP-Script funktioniert oder nicht.

PHP mag ja ganz nett sein um einen Counter in eine Seite zu Basteln oder ein Menu zu erstellen, aber für komplexere Aufgaben ist ungeeignet.

Was habe ich geflucht als ich in einem PHP-Script die Datenanbindung ändern sollte.

Naja, man kann mit PHP schon auch sauber coden. Aber leider meint halt jeder Frickler im Web, er muss seinen Mist eben auch in PHP verbrechen und die Sprache machts einem halt leider auch sehr einfach...

Die meisten PHP-Projekte werden ohne Sachverstand und Planung geführt.
Und jeder trägt einen neuen Patch mit einer neuen Macke bei.

Un ich finde die Namensgebung der eingebauten Funktionen in PHP höchst unglücklich - Bandwurm(name) ist eklig.

Sicher kannst du sinnvoll codieren in PHP, aber wer hat denn Projektplanung gelernt? PHP wurschtelt doch jeder. Das kann man so schön in HTML einbinden. Und Variablen, global? Das schreibt mann so hin, ist ja schließlich kein Compiler wie C, der meckert. Oh, was vergessen? Schnell ein include() oder ein passthru().

PS: Noch schlamperigen, unlesbaren Code ermöglicht nur in Perl.
Nur die meisten codieren nicht so übel.
Dank Damian mit seinem "Gutes Benehmen in Perl" und den guten LehrerInnen hier im Forum. ;)

GwenDragon+2008-07-26 14:29:18--

Die meisten PHP-Projekte werden ohne Sachverstand und Planung geführt.
Und jeder trägt einen neuen Patch mit einer neuen Macke bei.

Un ich finde die Namensgebung der eingebauten Funktionen in PHP höchst unglücklich - Bandwurm(name) ist eklig.

Sowas kann auch bei Perl passieren. Ich glaube, Perl wird diesen Ruf der aussterbenden Programmiersprache erst verlieren, wenn es populäre Programme gibt, über die auch Bildzeitungsleser regelmäßig im Web stolpern. Wenn aber jede Webseite ein PHP-Board einsetzt, würde ich als unbedarfter Mensch auch glauben, dass PHP verbreiteter ist, und Perl an Bedeutung verliert.
Das ist nur PR-Kram.

Ist C nicht auch ausgestorben seitdem es C++ oder C# gibt?

Schlimm, die c't wird auch immer schlechter in der Qualität.

GwenDragon+2008-07-26 14:36:00--

Schlimm, die c't wird auch immer schlechter in der Qualität.

In der letzten Ausgabe war ein interessanter Artikel zu einem FPGA-Entwicklungsmodul. Aber im großen und ganzen hast du Recht. Seit der Umstellung auf den vierzehntägigen Zyklus ist es nicht mehr das selbe wie früher.

Tja, die gute c't ist wohl am aussterben. Bildzeitung sieht man ja auch viel öfter am Kiosk.