PHP vs. PERL

[Nizzan]

Hallo,

ich frage mich gerade was ist denn leichter zu lernen PERL oder PHP? Mit was arbeitet Ihr denn so? Und stimmt die Aussage: Wer Perl kann kann auch PHP?

Kann man mir mal ein paar Unterschiede nennen die für Perl sprechen und ein paar die eben für PHP sprechen?

Was wird im Web mehr eingesetzt PERL oder PHP

Ich hoffe man kann mir diese Fragen mal beantworten.

Gruß Nizzan

[Struppi]

ich frage mich gerade was ist denn leichter zu lernen PERL oder PHP? Mit was arbeitet Ihr denn so? Und stimmt die Aussage: Wer Perl kann kann auch PHP?

Leichter zu lernen ist Perl.

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.

Kann man mir mal ein paar Unterschiede nennen die für Perl sprechen und ein paar die eben für PHP sprechen?

http://verplant.org/perl.vs.php.html
http://www.heckmeck.de/computerstuff/scheiss_php/
http://tnx.nl/php

Was wird im Web mehr eingesetzt PERL oder PHP

Du kannst mit PHP Programmiercode und HTML Code vermischen, das erscheint vielen Anfängern einfacher deshalb wird PHP häufiger eingesetzt-

Struppi.

[Fabian Transchel]

Hi,

ich frage mich gerade was ist denn leichter zu lernen PERL oder PHP? Mit was arbeitet Ihr denn so? Und stimmt die Aussage: Wer Perl kann kann auch PHP?

Leichter zu lernen ist Perl.

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.

Von denen man 2500 auch abschalten kann. Im Gegenzug ist es bei Perl ja auch so, dass man massiv Module dazuladen muss, wenn man etwas, was über HTTP-Ausgabe hinausgeht, machen will, beispielsweise die GDlib. Bei PHP ist es per default drin, tut aber dasselbe wie in Perl, und *kann* rausgenommen werden, wenn man will.

Grüße aus Barsinghausen,
Fabian

[Struppi]

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.

Von denen man 2500 auch abschalten kann. Im Gegenzug ist es bei Perl ja auch so, dass man massiv Module dazuladen muss, wenn man etwas, was über HTTP-Ausgabe hinausgeht, machen will, beispielsweise die GDlib. Bei PHP ist es per default drin, tut aber dasselbe wie in Perl, und *kann* rausgenommen werden, wenn man will.

Das man in PHP Funktionen ausschalten kann wußte ich nicht, trotz allem erschlägt einen ja schon die Funktionsvielfalt in Perl (wenn man die Fragen hier verfolgt merkt man das viele sich nicht die Mühe machen mal perldoc perlfunc anzuschauen).

Du kannst in Perl auch wahlweise die wesentlich bessere imagemagick Bibliothek nutzen, oft reicht es auch aus convert direkt per system Befehl aufzurufen (oft geht es nur um das zuschneiden von Bildern)

Struppi.

[mark chopin]

So ein Quatsch.

Die Leichtigkeit der Erlernbarkeit von Sprachen hängt
doch nicht unbedingt von der Anzahl der Wörter ab.

Die angegebenen Beispiele sind zwar lustig zu lesen,
aber nicht gerade objektiv. Die beiden Autoren entlarven
sich selbst, dass sie sich dank Perl zu unsauberen
Programmiertechniken verleiten haben lassen.

Für Anfänger ist PHP definitiv die bessere Wahl.

[Struppi]

Die Leichtigkeit der Erlernbarkeit von Sprachen hängt
doch nicht unbedingt von der Anzahl der Wörter ab.

sondern?
Der Unterschied zwischen der Grundlegenden Syntax ist zwischen PHP und Perl so gering, dass eigentlich nur dass und evtl. noch die vorhandenen Dokumentation eine Rolle spielt (gerade bei 3000 Funktionen).

Für Anfänger ist PHP definitiv die bessere Wahl.

Nur für Anfänger die vorher HTML gelernt habe, da du dann quasi unmittelbar anfangen kannst.

Struppi.

[dedlfix]

echo $begrüßung;

Leichter zu lernen ist Perl.

Fragst du drei Leute bekommst du vier Meinungen... Ich find's unübersichtliecher aufgrund der vielen Abkürzungsmöglichkeiten

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.

Es gibt Aussagen, die stimmen und sind doch falsch. Einen großen Teil der 3000 Funktionen [1] "braucht kein Mensch". Manche Sachen, für die unter Perl eine "externe" Bibliothek benötigt wird, gehören schon zum Lieferumfang von PHP.

echo "$verabschiedung $name";

[1] Ich nehme mal an, dass das stimmt. Nachzählen will ich das nicht, weil das außer Statistikern niemanden interessiert :-)

[Struppi]

Fragst du drei Leute bekommst du vier Meinungen... Ich find's unübersichtliecher aufgrund der vielen Abkürzungsmöglichkeiten

Das sind keine Abkürzungen, sondern im gegenteil die langform musst du erst extra einbinden (use English), darüber hinaus sind das Systemvariabeln von denen du sowieso i.d.R. nur zwei brauchst ($_ und $1...$9)

Struppi.

[dedlfix]

echo $begrüßung;

Fragst du drei Leute bekommst du vier Meinungen... Ich find's unübersichtliecher aufgrund der vielen Abkürzungsmöglichkeiten

Das sind keine Abkürzungen,

Was dann? Wenn es davon Langformen gibt, dann sind das Abkürzungen :-)

echo "$verabschiedung $name";

[Struppi]

Hallo dedlfix

Das sind keine Abkürzungen,

Was dann? Wenn es davon Langformen gibt, dann sind das Abkürzungen :-)

Nein, die Langformen ist lediglich ein Feature, das durch ein zusätzliches Modul zu Verfügung stellt.

Struppi.

[Sven Rautenberg]

Moin!

Nein, die Langformen ist lediglich ein Feature, das durch ein zusätzliches Modul zu Verfügung stellt.

Aber mal ehrlich: Wer kann sich denn bitteschön diese ganzen "Dollar-Sonderzeichenaufdertastaturwoichdiehälftenichtmalaufanhiebfinde"-Variablen merken. Sorry, aber der Mensch liebt nun einmal Namen (bester Beweis ist die Existenz des DNS), und damit verbunden ist, dass man eben keine kryptischen Kombinationen verwendet, wie hier geschehen. Der daraus entstehende Code ist entweder komplett kryptisch für den ungeübten Leser, oder er ist zwingend zu kommentieren. Ich halte das nicht wirklich für einen Vorteil von Perl.

• Sven Rautenberg

[Siechfred]

Tag Sven.

Nein, die Langformen ist lediglich ein Feature, das durch ein zusätzliches Modul zu Verfügung stellt.
Aber mal ehrlich: Wer kann sich denn bitteschön diese ganzen "Dollar-Sonderzeichenaufdertastaturwoichdiehälftenichtmalaufanhiebfinde"-Variablen merken.

Dafür gibt es das Modul, was Struppi nannte. Wer's gerne anders mag, bindet halt das Modul ein, fertig (siehe CPAN: English.pm).

Ich halte das nicht wirklich für einen Vorteil von Perl.

Ja, da stimme ich dir zu, es ist aber wie immer Geschmackssache.

Siechfred

[Sven Rautenberg]

Moin!

Dafür gibt es das Modul, was Struppi nannte. Wer's gerne anders mag, bindet halt das Modul ein, fertig (siehe CPAN: English.pm).

Und wenn man dann Pech hat, fehlt das Modul (warum auch immer) genau dort, wo man das gebaute Skript just einsetzen muß, während man es in der Entwicklungsumgebung natürlich eigenständig hinzufügen konnte, oder es gar standardmäßig mit der Perl-Installation geliefert bekam.

• Sven Rautenberg

[Struppi]

.... es gar standardmäßig mit der Perl-Installation geliefert bekam.

Es ist ein Standardmodul.

Struppi.

[Sven Rautenberg]

Moin!

.... es gar standardmäßig mit der Perl-Installation geliefert bekam.

Es ist ein Standardmodul.

Module gehen verloren, kaputt, fehlen unerwartet, veralten... :)

• Sven Rautenberg

[Struppi]

Module gehen verloren, kaputt, fehlen unerwartet, veralten... :)

Das Modul hat bei mir das Datum 15.3.2000 und ist genau 190 Zeilen gross (inkl. Kommentar)

Struppi.

[Christian Kruse]

你好 Sven,

Und wenn man dann Pech hat, fehlt das Modul (warum auch immer) genau dort,
wo man das gebaute Skript just einsetzen muß, während man es in der
Entwicklungsumgebung natürlich eigenständig hinzufügen konnte, oder es gar
standardmäßig mit der Perl-Installation geliefert bekam.

Dasselbe gilt für PHP. Vor- bzw. Nachteile eines modularen Systems. Nur kann
man bei Perl Module _immer_ (sic!) auch mit Benutzer-Rechten
nachinstallieren, mit PHP geht das halt nicht.

再见,
克里斯蒂安

[Manuel B.]

Hi,

man bei Perl Module _immer_ (sic!) auch mit Benutzer-Rechten
nachinstallieren, mit PHP geht das halt nicht.

Du kannst PHP auch mit Benutzerrechten Compilieren, also wo liegt der Vorteil bei PERL in diesem Punkt?

[Christian Kruse]

你好 Manuel,

man bei Perl Module _immer_ (sic!) auch mit Benutzer-Rechten
nachinstallieren, mit PHP geht das halt nicht.

Du kannst PHP auch mit Benutzerrechten Compilieren,

Sicher, aber dann nicht nutzen bzw. nur als CGI nutzen und das dann nur mit
grossen Problemen (PHP im CGI-Environment gibt Probleme).

also wo liegt der Vorteil bei PERL in diesem Punkt?

Bei Perl muss ich das nicht. Ich installiere ein Modul als User und kann es
auch im mod_perl-Environment nutzen.

再见,
克里斯蒂安

[Manuel B.]

Hi,

Bei Perl muss ich das nicht. Ich installiere ein Modul als User und kann es
auch im mod_perl-Environment nutzen.

Ich hab bisher immer mit Rootservern gearbeitet, deshalb nie Probleme damit, aber funktionert es wirklich, das du im Userspace ein Modul kompilierst und es auf dem Webserver zur verfügung stellst?

Das wäre IMO eine sicherheitslücke, da man über Umwege ja dann beliebigen Code compilieren könnte.

Wie gesagt, bisher nie versucht, da ich meine Module immer in der Kommandozeile als Root installiert hab.

[Christian Kruse]

你好 Manuel,

Bei Perl muss ich das nicht. Ich installiere ein Modul als User und kann
es auch im mod_perl-Environment nutzen.

Ich hab bisher immer mit Rootservern gearbeitet, deshalb nie Probleme
damit, aber funktionert es wirklich, das du im Userspace ein Modul
kompilierst und es auf dem Webserver zur verfügung stellst?

Sicher. Warum nicht?

Das wäre IMO eine sicherheitslücke, da man über Umwege ja dann beliebigen
Code compilieren könnte.

Eh, das kann ich doch eh, ich nutze doch eine Programmiersprache. Da
brauche ich keine Umwege zu gehen.

Oder meinst du, ich könnte anderen etwas unterschieben? Nein, das geht
nicht. Wenn man Module ausserhalb der Standard-Verzeichnisse (die ja nur
als root beschreibbar sind) einbinden will, muss man dem Interpreter den
vollständigen Pfad dorthin bekanntgeben.

再见,
克里斯蒂安

[Struppi]

Nein, die Langformen ist lediglich ein Feature, das durch ein zusätzliches Modul zu Verfügung stellt.

Aber mal ehrlich: Wer kann sich denn bitteschön diese ganzen "Dollar-Sonderzeichenaufdertastaturwoichdiehälftenichtmalaufanhiebfinde"-Variablen merken.

Ausser $_ und $1..$9 hab ich persönlich fast noch keine andere Variabel benutzt (hin und wieder mal $/ aber sonst nichts). Wobei $_ ebenfalls nur ein Feature ist und $1..$9 ist doch bei anderen Programmiersprachen das Gleiche.

Struppi.

[dedlfix]

echo $begrüßung;

Ausser $_ und $1..$9 hab ich persönlich fast noch keine andere Variabel benutzt (hin und wieder mal $/ aber sonst nichts). Wobei $_ ebenfalls nur ein Feature ist und $1..$9 ist doch bei anderen Programmiersprachen das Gleiche.

Man muss die Dinger nicht selbst werwenden, wenn man sie nicht mag. Das "Problem" ist ja nur, dass man sie trotzdem verstanden/gemerkt haben muss, wenn man fremde Quelltexte lesen möchte, die sowas verwenden.

echo "$verabschiedung $name";

P.S. Ich weiß das sind Geschmacksfragen, deswegen hör ich an dieser Stelle auf, darauf herumzureiten. :-)

[Struppi]

.... Ich halte das nicht wirklich für einen Vorteil von Perl.

das hatte ich gar nicht gelesen.

Wie heißen den in PHP die Variabeln für OUTPUT_RECORD_SEPARATOR oder LIST_SEPARATOR?

Struppi.

[Sven Rautenberg]

Moin!

.... Ich halte das nicht wirklich für einen Vorteil von Perl.

das hatte ich gar nicht gelesen.

Wie heißen den in PHP die Variabeln für OUTPUT_RECORD_SEPARATOR oder LIST_SEPARATOR?

An dieser Stelle zeigt sich nun mal, dass Perl ursprünglich nicht für's Web konzipiert ist, und PHP nicht für die Kommandozeile. In PHP gibt es derartige Sinnlosigkeiten (von denen du ja selbst sagst, dass du sie noch nie benutzt hast) nicht. Wenn ich ein Array mit Trennzeichen ausgeben will, nutze ich die Funktion implode(), und wenn ich an jede Ausgabe von print oder echo noch einen Zusatztext anhängen will, dann mache ich das manuell - es ist in den allermeisten Fällen nämlich nicht sinnvoll, an sämtliche Ausgabebefehle eines Skriptes je Zeile noch etwas anzuhängen.

• Sven Rautenberg

[Struppi]

Wie heißen den in PHP die Variabeln für OUTPUT_RECORD_SEPARATOR oder LIST_SEPARATOR?

An dieser Stelle zeigt sich nun mal, dass Perl ursprünglich nicht für's Web konzipiert ist, und PHP nicht für die Kommandozeile. In PHP gibt es derartige Sinnlosigkeiten (von denen du ja selbst sagst, dass du sie noch nie benutzt hast) nicht. Wenn ich ein Array mit Trennzeichen ausgeben will, nutze ich die Funktion implode(), und wenn ich an jede Ausgabe von print oder echo noch einen Zusatztext anhängen will, dann mache ich das manuell - es ist in den allermeisten Fällen nämlich nicht sinnvoll, an sämtliche Ausgabebefehle eines Skriptes je Zeile noch etwas anzuhängen.

Naja, join gibt es auch in Perl, es ist für Testzwecke manchmal aber ganz Praktisch eine Listenausgabe mit $" = "\n"; zu trennen oder der Ausgabe automatisch ein Newline zuzufügen. Ja, wie gesagt ich nutze es nicht, es ist aber ein Feature und letztlich diskutieren wir hier doch über die Frage:
»... Ich find's [Perl] unübersichtliecher aufgrund der vielen Abkürzungsmöglichkeiten

Was ja so nicht stimmt. sondern es ist ein Feature - das es so in PHP gar nicht gibt - das durch ein Standardmodul menschenlesbarer gemacht wird, dies ist aber in 99,999% aller CGI Anwendungen überflüssig und kommt von daher so gut wie nie zum Einsatz, läßt aber bei Anwendungen u.U. den Quelltext lesbarer erscheinen.

Struppi.

[Christian Kruse]

你好 Sven,

Wie heißen den in PHP die Variabeln für OUTPUT_RECORD_SEPARATOR oder
LIST_SEPARATOR?

An dieser Stelle zeigt sich nun mal, dass Perl ursprünglich nicht für's
Web konzipiert ist, und PHP nicht für die Kommandozeile.

Nee. An dieser Stelle zeigt sich, dass PHP solche Sachen halt nicht zur
Verfügung stellt oder stellen will, mehr nicht.

In PHP gibt es derartige Sinnlosigkeiten (von denen du ja selbst sagst,
dass du sie noch nie benutzt hast) nicht.

Es ist keine Sinnlosigkeit. Es hat seinen Sinn. Es ist performanter, einen
Array mit print @array und dem setzen von $" = ", ";
auszugeben. Es muss nur einmal über die Liste iteriert werden, ohne, dass
ein neuer String erstellt werden muss.

Wenn ich ein Array mit Trennzeichen ausgeben will, nutze ich die
Funktion implode(),

In dem Fall muss erst ein neuer String erstellt werden. Rechenzeit- und
Ressourcen-Verschwendung.

Mal abgesehen davon ist $" nur ein Fall von vielen; ich möchte in Perl z.
B. auf gar keinen Fall den $/ ($INPUT_RECORD_SEPERATOR) missen. Der ist
extremst praktisch.

再见,
克里斯蒂安

[Tom]

Hello,

Aber mal ehrlich: Wer kann sich denn bitteschön diese ganzen "Dollar-Sonderzeichenaufdertastaturwoichdiehälftenichtmalaufanhiebfinde"-Variablen merken. Sorry, aber der Mensch liebt nun einmal Namen (bester Beweis ist die Existenz des DNS), und damit verbunden ist, dass man eben keine kryptischen Kombinationen verwendet, wie hier geschehen. Der daraus entstehende Code ist entweder komplett kryptisch für den ungeübten Leser, oder er ist zwingend zu kommentieren. Ich halte das nicht wirklich für einen Vorteil von Perl.

Prinzipiell magst Du, was die Mnemonik von Namen gegenüber z.B. numerischen Marken betrifft, Recht ahben. Dass aber deshalb der DNS eingeführt wurde, kannst doch gerade _Du_ nicht ernst meinen, oder?

Hier geht es doch im Kern um eine zusätzliche Abstraktionaschicht mit der Möglichkeit, der Dereferenzierung und Ersetzung, alse die Möglichkeit des indirekten Aufrufes. Das ist dann quasi die IVT des Internet.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Leichter zu lernen ist Perl.

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.

Was genau zählst du da? Die Funktionen, die man regelmäßig benötigt? Oder kriegt man mit den Funktionen von Perl genau die 3000 Funktionsergebnisse hin, die PHP in der Lage ist zu liefern? Schätze, wohl eher nicht.

Was PHP an Funktionen anbietet, ist bei Perl in CPAN-Module ausgelagert. Beiden ist gemeinsam, dass man Pech haben kann, wenn die gewünschte Funktionalität nicht installiert ist. Beiden ist gemeinsam, dass man lernen muß, die Funktionalität zu benutzen, sei es nun als "Funktionsname" oder als "Modul". Beiden ist gemeinsam, dass man sie ignorieren kann, wenn man die Funktionalität nicht benötigt.

Was wird im Web mehr eingesetzt PERL oder PHP

Du kannst mit PHP Programmiercode und HTML Code vermischen, das erscheint vielen Anfängern einfacher deshalb wird PHP häufiger eingesetzt-

Man kann als Anfänger in Perl genauso HTML- und Perlcode mischen, man ist aber gezwungen, da jeweils "print" vorzusetzen und sich eventuell mit dem Quoting zu verheddern. Als "gut" wird man solchen Code in beiden Sprachen nicht unbedingt bezeichnen wollen, aber in PHP ist es deswegen einfacher, schnelle Quickhack-Codes auf die Beine zu stellen.

• Sven Rautenberg

[Frank Schönmann]

hi!

Du hast in PHP über 3000 Funktionen gegenüber 200 in Perl.
Was genau zählst du da? Die Funktionen, die man regelmäßig benötigt? Oder
kriegt man mit den Funktionen von Perl genau die 3000 Funktionsergebnisse
hin, die PHP in der Lage ist zu liefern? Schätze, wohl eher nicht.

Klar doch. Weißt du, was eine Turingmaschine ist? ;)

bye, Frank!

[Thomas W.]

Hallo,

Klar doch. Weißt du, was eine Turingmaschine ist? ;)

Ich warte dann mal auf Dein erstes CGI Programm in Postscript :)

Gruss
Thomas

[Tim Tepaße]

Hallo,

Ich warte dann mal auf Dein erstes CGI Programm in Postscript :)

Schade, daß er das dann anscheinend nicht im PS-HTTPD nutzen kann. ;)

Tim

[Bio]

Sup!

Seit ich die Einbindung von RegExp in PHP kenne, finde ich noch stärker als zuvor, dass PHP "saugt".

Gruesse,

Bio

[Siechfred]

Tag Struppi.

Leichter zu lernen ist Perl.

Meine subjektive Meinung ist eher, dass Perl schwerer zu erlernen ist als PHP, weshalb sich offensichtlich viele Anfänger zunächst an PHP versuchen.

Kann man mir mal ein paar Unterschiede nennen die für Perl sprechen und ein paar die eben für PHP sprechen?

Alle Vor- oder Nachteile, die evtl. aufzuzählen wären, sind höchst subjektiv. Perl und PHP sind im Bezug auf die Programmierung von Webanwendungen nahezu deckungsgleich, letztendlich ist es eine Geschmacksfrage, denke ich. Ansonsten meine persönliche Liste der Fürs und Wider:

PHP:
(+) kann überall ausgeführt werden
(+) relativ einfach zu programmieren
(-) unübersichtliche Funktionsvielfalt
(-) Abhängigkeit von der Kompilierung

Perl:
(+) schneller als PHP
(+) viele Module (cpan.org)
(-) ziemlich kryptisch für einen Programmieranfänger
(-) meist nur in cgi-bin ausführbar

Diese Liste ist höchst subjektiv und gilt eher für Programmierer, die keinen Einfluss auf die Konfiguration des Webservers einschließlich der PHP- oder Perl-Version haben.

Siechfred

[Siechfred]

Nachtrag:

Ein großes Plus bekommt Perl noch für die m.E. konsequentere Variablenbehandlung (Skalare, Arrays, Hashes).

Siechfred

[Mathias Bigge]

Hi Siechfred,

Perl:
(-) meist nur in cgi-bin ausführbar

Wieso?

Viele Grüße
Mathias Bigge

[Cybaer]

Hi,

Perl:
(-) meist nur in cgi-bin ausführbar
Wieso?

Weil die Server-Admins es bei vorkonfigurierten Servern es traditionell so eingestellt haben.

Es gibt noch einen weiteren Grund auf reinen MS-Systemen, aber der ist für den Otto-Normal-Gehosteten wohl nicht relevant. ;-)

Gruß, Cybaer

[Mathias Bigge]

Hi Cybaer,

Weil die Server-Admins es bei vorkonfigurierten Servern es traditionell so eingestellt haben.

Das ist tatsächlich eine Einschränkung, wenn auch vielleicht für viele DAUS eine sinnvolle *g* Allerdings kommt sie nicht von Perl, das wollte ich zum Ausdruck bringen. Übrigens stimmt das für die Präsenzen, die ich so kenne nicht, habe gerade nochmal geguckt, aber vielleicht gilt es für die meisten Billigangebote!?

Viele Grüße
Mathias Bigge

[Cybaer]

Hi,

Allerdings kommt sie nicht von Perl, das wollte ich zum Ausdruck bringen.

Das ist keine Frage! :-))

Perl ist es prinzipell egal.

Übrigens stimmt das für die Präsenzen, die ich so kenne nicht, habe gerade nochmal geguckt, aber vielleicht gilt es für die meisten Billigangebote!?

Für die Billigangebote, die Perl/CGIs unterstützen und die ich kenne, gilt es zu 100%.

OK, ich kenne nicht viele *Billig*angebote, die sich den *Luxus* von cgi-bin überhaupt leisten, aber von denen sind es eben 100%. ;-)

Gruß, Cybaer

[Manuel B.]

Hi,

OK, ich kenne nicht viele *Billig*angebote, die sich den *Luxus* von cgi-bin überhaupt leisten, aber von denen sind es eben 100%. ;-)

das hat sich mittlerweile geändert. Seit der Verbreitung von Confixx bieten viele Hoster die Möglichkeit, per Webinterface, CGI auch ausserhalb von cgi-bin zuzulassen.
Das ganze liegt dann im ermessen des Kunden, ob er/sie das will.

Ausser bei meinen Angeboten kenne ich ads auch von einigen anderen Billiganbietern

[Siechfred]

Tag Mathias.

Perl:
(-) meist nur in cgi-bin ausführbar
Wieso?

Michael Schröpl hat es mal ein bisschen zusammengefasst: http://forum.de.selfhtml.org/archiv/1999/4/t3016/#m14565. Ansonsten ist es, soweit mir erinnerlich, traditionell so, dass Perl-Scripte, die als CGI-Anwendungen zum Einsatz kommen, nur innerhalb des Verzeichnisses cgi-bin ("CGI Binaries") ausführbar sind.

Siechfred

[Jan L.]

;-)

Jan

[Struppi]

Hallo Jan L.

[image]

Vermutlich zwei PHP Programmier Koryphäen

Struppi.

[Bio]

Sup!

Vermutlich zwei PHP Programmier Koryphäen

Vermutlich von einer PHP-Programmier-Koryphäe mit Photoshop hingebasteltes Bild?

Gruesse,

Bio

[Tom]

Hello,

Vermutlich von einer PHP-Programmier-Koryphäe mit Photoshop hingebasteltes Bild?

Folgt man der URL am rechten unteren Bildrand, dann muss man vielleicht hinterher seinen ganzen Rechner neu installieren. Verflixtes JavaScript...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian Kruse]

你好 Struppi,

Kann man mir mal ein paar Unterschiede nennen die für Perl sprechen und ein paar die eben für PHP sprechen?

http://verplant.org/perl.vs.php.html
http://www.heckmeck.de/computerstuff/scheiss_php/

Die Jungs glänzen durch Ahnungslosigkeit von PHP. Sorry, aber die Seiten
sind eher lächerlich denn Informativ; sie sitzen offensichtlichem Quatsch
auf.

http://tnx.nl/php

Hab ich mir nach den ersten beiden Beispielen jetzt nicht mehr angeguckt.

再见,
克里斯蒂安

[Struppi]

http://verplant.org/perl.vs.php.html
http://www.heckmeck.de/computerstuff/scheiss_php/

Die Jungs glänzen durch Ahnungslosigkeit von PHP. Sorry, aber die Seiten
sind eher lächerlich denn Informativ; sie sitzen offensichtlichem Quatsch
auf.

ich hab tatsächlich nicht viel Ahnung von PHP macht aber auch keinen Spaß damit zu programmieren.

http://www.heckmeck.de/computerstuff/scheiss_php/

* Request-Paremeter werden umbenannt!
    * Aufrufketten
    * Überraschung mit next
    * Aufbau von HERE-Dokumenten
    * Variablenauswertung in Strings
    * require()
    * Escaping bei regulären Ausdrücken
    * Boolean-Wert von Arrays und Objekten
    * $this-Zwang innerhalb von Objekten
    * checkdate()
    * Array-Indizes: String oder Integer oder was?
    * Inkonsistente Benamsung
    * Versionszählung

Das stimmt alles nicht und ist lächerlich?

Struppi.

[Manuel B.]

Hi,

ich hab tatsächlich nicht viel Ahnung von PHP macht aber auch keinen Spaß damit zu programmieren.

wer keine Ahnung hat, sollte dann aber auch keine Halbwahrheiten verbreiten, wie z.B. "Module in dem Sinn existieren nicht. .... "

* $this-Zwang innerhalb von Objekten

Das hat was mit sauberer Programmierung und OOP zu tun, was PERL immer noch nicht richtig kann. Und ads ist ein riesen Nachteil gegenüber PHP5, das jetzt entgültig OOP unterstützt.

Einen objektiven Vergleich zwischen PERL und PHP kann man nicht machen. Sonst wäre ein direkter Vergleich zwischen C und C++ auch machbar, ist es aber nicht.

Ich sage, wer PHP und PERL objektiv vergleichen will, kommt immer zu dem Schluss, das es nicht möglich ist. Jeglicher Vergleich ist rein subjektiv

[Christian Kruse]

你好 Manuel,

ich hab tatsächlich nicht viel Ahnung von PHP macht aber auch keinen
Spaß damit zu programmieren.

wer keine Ahnung hat, sollte dann aber auch keine Halbwahrheiten
verbreiten, wie z.B. "Module in dem Sinn existieren nicht. .... "

Dem ist schon so. Entweder, etwas ist eincompiliert, oder es ist nicht
eincompiliert. Was anderes geht in PHP nicht. dl() zählt nicht. Gibts nicht
im Safe-Mode, die Module müssen zwangsläufig in einem Verzeichnis liegen,
unter bestimmten Umständen (Apache2 mit Threads z. B.) gibt es dl() nicht.
Ausserdem ist alles im globalen Namespace.

* $this-Zwang innerhalb von Objekten

Das hat was mit sauberer Programmierung und OOP zu tun, was PERL immer
noch nicht richtig kann. Und ads ist ein riesen Nachteil gegenüber PHP5,
das jetzt entgültig OOP unterstützt.

Perl kann alle OO-Konstrukte abbilden; und den $this-Zwang gibt es in Perl
auch.

再见,
克里斯蒂安

[Manuel B.]

Hi,

Dem ist schon so. Entweder, etwas ist eincompiliert, oder es ist nicht
eincompiliert. Was anderes geht in PHP nicht. dl() zählt nicht. Gibts nicht
im Safe-Mode, die Module müssen zwangsläufig in einem Verzeichnis liegen,
unter bestimmten Umständen (Apache2 mit Threads z. B.) gibt es dl() nicht.

dl kannst du auch im SafeMode freigeben und mittlerweile scheint dl() auch mit Threads zu funktionieren. Eine andere erklärung hab ich nicht, ads mein System mit Apache2 Threaded und PHP5 it dl() läuft ;)

Ausserdem ist alles im globalen Namespace.

Bei sauberer Prorgammierung seh ich nicht wirklich das Problem.

Perl kann alle OO-Konstrukte abbilden; und den $this-Zwang gibt es in Perl
auch.

Ich sagte nicht, das PERL keine OO-Konstrukte abbilden kann, ich meine damit, das PERL OOP nicht voll unterstützt (private und public etc) (sollte das mittlerweile anders sein, will ich nichts gesagt haben)

[Christian Kruse]

你好 Manuel,

Dem ist schon so. Entweder, etwas ist eincompiliert, oder es ist nicht
eincompiliert. Was anderes geht in PHP nicht. dl() zählt nicht. Gibts
nicht im Safe-Mode, die Module müssen zwangsläufig in einem Verzeichnis
liegen, unter bestimmten Umständen (Apache2 mit Threads z. B.) gibt es
dl() nicht.

dl kannst du auch im SafeMode freigeben

Wie?

und mittlerweile scheint dl() auch mit Threads zu funktionieren. Eine
andere erklärung hab ich nicht, ads mein System mit Apache2 Threaded und
PHP5 it dl() läuft ;)

In PHP5 ist dl() deprecated.

Ausserdem ist alles im globalen Namespace.

Bei sauberer Prorgammierung seh ich nicht wirklich das Problem.

Eh. Was hat das mit sauberer Programmierung zu tun? Module gehören
gefälligst in einen eigenen Namespace, alles andere ist unsaubere
Programmierung.

Perl kann alle OO-Konstrukte abbilden; und den $this-Zwang gibt es in
Perl auch.

Ich sagte nicht, das PERL keine OO-Konstrukte abbilden kann, ich meine
damit, das PERL OOP nicht voll unterstützt (private und public etc)
(sollte das mittlerweile anders sein, will ich nichts gesagt haben)

Das ist seit Perl5 schon nicht mehr so.

再见,
克里斯蒂安

[dedlfix]

echo $begrüßung;

http://www.heckmeck.de/computerstuff/scheiss_php/

* Aufrufketten

Das erste Beispiel geht mittlerweile in PHP5

* Überraschung mit next

for ($i=0; $i<10; $i++) {
  if ($i < 5) {
    next;
  }
  print "$i ";
}

Tja, hätte der Autor mal lieber auch die Notices eingeschaltet, dann würde er sehen, dass das next nicht als Schlüsselwort sondern als Konstante interpretiert wird. Und da diese nicht existiert, macht PHP automatisch einen String draus (siehe auch $array[ohneAnführungszeichen]).
Das Schlüsselwort für den nächsten Schleifendurchlauf lautet continue;

* Variablenauswertung in Strings

Lässt sich als "foo {$array['key']} bar" schreiben.

* require()

warum sollte man nicht HTML-Teile, mehrfach einladen? Nicht immer verbergen sich nur Funktionen in Include-Dateien.

Das stimmt alles nicht und ist lächerlich?

Und für die anderen Unterschiede: Mein Gott, PHP ist PHP und nicht Perl. Wer die Syntax nicht mag oder sich mit Unterschieden zu anderen Sprachen nicht abfinden will, soll's lassen.

echo "$verabschiedung $name";

[Christian Kruse]

你好 Struppi,

http://www.heckmeck.de/computerstuff/scheiss_php/

* Request-Paremeter werden umbenannt!

Stimmt.

* Aufrufketten

Stimmt.

* Überraschung mit next

next setzt in PHP einen Array-Pointer weiter. continue ist das
Schlüsselwort, dass einem den Schleifendurchlauf erhöht -- wie in C. Dass
es keinen Manual-Eintrag zu next gibt, ist gelogen:

http://de3.php.net/next

* Aufbau von HERE-Dokumenten

Ist in Perl auch nicht anders (Newline-Problematik).

* Variablenauswertung in Strings

Er hat das Manual nicht gelesen. Manual sagt: um komplexe Datenstrukturen
in Strings interpolieren zu lassen, soll man {} benutzen. Und natürlich
funktioniert dort dann auch

$zusammenfassung = "Anzahl: {$daten['statistik']['anzahl']}";

* require()

Stimmt.

* Escaping bei regulären Ausdrücken

Stimmt.

* Boolean-Wert von Arrays und Objekten

Dasselbe gilt bei Perl:

  
package myobject;  
  
sub new {  
  return bless {};  
}  
  
package main;  
  
$x = new myobject();  
  
if(%$x) {  
  die "yes";  
}  
else {  
  die "no";  
}  

* $this-Zwang innerhalb von Objekten

Dasselbe gilt für Perl.

* checkdate()

Die Reihenfolge der Parameter als Argument anzubringen zeugt von
Argumentlosigkeit.

* Array-Indizes: String oder Integer oder was?

Was ist daran bitte ein Argument?

* Inkonsistente Benamsung

Ist in Perl auch nicht anders.

* Versionszählung

Wenn man sich an dokumentierte Schreibweisen hält, ist der Code innerhalb
einer Major-Version in allen Versionen lauffähig. Mir wäre kein Fall
bekannt, wo dem nicht so ist; wahr allerdings ist, dass der Code dann uU
nicht mehr läuft, wenn man undokumentierte Features nutzt. Deshalb sind
sie ja auch undokumentiert.

Ich bin ja wahrlich kein Freund von PHP, aber wenn man über PHP meckert,
sollte man bitte auch wirklich Ahnung haben, wovon man redet.

再见,
克里斯蒂安

[Struppi]

* Aufrufketten

Stimmt.

scheint ja nicht mehr zu stimmen https://forum.selfhtml.org/?t=107572&m=670565

* require()

Stimmt.

wobei auch hier das Argument von https://forum.selfhtml.org/?t=107572&m=670565 die Argumentation entkräftet.

* Boolean-Wert von Arrays und Objekten

Dasselbe gilt bei Perl:

if(%$x) {

Naja, das ist ja ein bisschen geschummelt, oder?
warum soll man hier auf einen HASH prüfen?

* $this-Zwang innerhalb von Objekten

Dasselbe gilt für Perl.

Da wollte der Autor wohl darauf hinaus dass du das Objekt in Perl beliebig nennen kannst. wobei das ganze eher an dem "OO" Konzept von Perl liegt.
Ob das ein Vorteil ist weiß ich nicht für OO Gurus sicher nicht

* Array-Indizes: String oder Integer oder was?

Was ist daran bitte ein Argument?

$arr["1"] and $arr[1] refer to the same element.
$arr["-1"] and $arr[-1] refer to different elements.

Das kann durchaus Stolperfallen bieten, wobei die autovivikation von Perl eine ähnliche Falle ist.

* Inkonsistente Benamsung

Ist in Perl auch nicht anders.

In Modulen kommt dies sicher vor aber bei den Perl funktionen ist doch eine gewisse Konsistenz vorhanden

Ich bin ja wahrlich kein Freund von PHP, aber wenn man über PHP meckert,
sollte man bitte auch wirklich Ahnung haben, wovon man redet.

Stimmt, ich werd mich in Zukunft zurück halten ;-)

Mir haben die letzten Einblicke in PHP Skripten, die ich mir in der letzter Zeit angeschaut hatte, jegliches Interesse an dieser Sprache vermiest, wer jahrelang use strict und warnings verwöhnt ist, ist doch ein bisschen erstaunt wenn du in  relativ etablierten PHP Projekte die Warnungen anschaltest.

Struppi.

[Christian Kruse]

你好 Struppi,

* Aufrufketten

Stimmt.

scheint ja nicht mehr zu stimmen https://forum.selfhtml.org/?t=107572&m=670565

Ja, in PHP5 hat sich viel geändert.

* require()

Stimmt.

wobei auch hier das Argument von
https://forum.selfhtml.org/?t=107572&m=670565 die
Argumentation entkräftet.

Ich habe es nicht als Argument gegen PHP gesehen... ich fand es lächerlich,
das als Argument anzuführen.

* Boolean-Wert von Arrays und Objekten

Dasselbe gilt bei Perl:

if(%$x) {

Naja, das ist ja ein bisschen geschummelt, oder?
warum soll man hier auf einen HASH prüfen?

Weil genau das ist, was in PHP passiert. Ansonsten werden Äpfel und Birnen
verglichen.

* $this-Zwang innerhalb von Objekten

Dasselbe gilt für Perl.

Da wollte der Autor wohl darauf hinaus dass du das Objekt in Perl
beliebig nennen kannst. wobei das ganze eher an dem "OO" Konzept von Perl
liegt. Ob das ein Vorteil ist weiß ich nicht für OO Gurus sicher nicht

Nein, ich denke, er sprach vom weglassenkönnen, das kann man in den anderen
OO-Sprachen nämlich.

Mir haben die letzten Einblicke in PHP Skripten, die ich mir in der
letzter Zeit angeschaut hatte, jegliches Interesse an dieser Sprache
vermiest, wer jahrelang use strict und warnings verwöhnt ist, ist doch
ein bisschen erstaunt wenn du in  relativ etablierten PHP Projekte die
Warnungen anschaltest.

Ja... PHP heisst nicht umsonst “Pubertierende Hauptschüler Programmieren” *g*

再见,
克里斯蒂安

[Struppi]

Ja... PHP heisst nicht umsonst “Pubertierende Hauptschüler Programmieren” *g*

oder eben Hauptschülerinnen
https://forum.selfhtml.org/?t=107572&m=668284

(wobei ich nichts gegen Hauptschüler hab, mein Abschluß steht nicht viel weiter oben auf der prestige Leiter)

Struppi.

[at]

Hallo.

(wobei ich nichts gegen Hauptschüler hab, mein Abschluß steht nicht viel weiter oben auf der prestige Leiter)

Du bist Diplom-Verwaltungsfachwirt?
MfG, at

[Struppi]

(wobei ich nichts gegen Hauptschüler hab, mein Abschluß steht nicht viel weiter oben auf der prestige Leiter)

Du bist Diplom-Verwaltungsfachwirt?

*psst*

Struppi.

[Siechfred]

Tag Christian.

PHP heisst nicht umsonst “Pubertierende Hauptschüler Programmieren” *g*

Und was ist mit Pathologically Eclectic Rubbish Lister?

Siech*SCNR*fred

[Christian Seiler]

Hallo Struppi,

Mir haben die letzten Einblicke in PHP Skripten, die ich mir in der letzter Zeit angeschaut hatte, jegliches Interesse an dieser Sprache vermiest, wer jahrelang use strict und warnings verwöhnt ist, ist doch ein bisschen erstaunt wenn du in  relativ etablierten PHP Projekte die Warnungen anschaltest.

Mein lokales /var/log/apache/error_log wächst auch jeden Tag, weil irgendwelche Perl-Module aus CPAN auch laufen Warnungen produzieren. Schelchten Code kann man mit jeder Programmiersprache schreiben, und nur, weil etwas etabliert ist, ist es noch lange nicht gut.

Viele Grüße,
Christian

[Struppi]

Mir haben die letzten Einblicke in PHP Skripten, die ich mir in der letzter Zeit angeschaut hatte, jegliches Interesse an dieser Sprache vermiest, wer jahrelang use strict und warnings verwöhnt ist, ist doch ein bisschen erstaunt wenn du in  relativ etablierten PHP Projekte die Warnungen anschaltest.

Mein lokales /var/log/apache/error_log wächst auch jeden Tag, weil irgendwelche Perl-Module aus CPAN auch laufen Warnungen produzieren. Schelchten Code kann man mit jeder Programmiersprache schreiben, und nur, weil etwas etabliert ist, ist es noch lange nicht gut.

Hab ich keine Probleme mit Modulen, meistens liegt's auch gar nichzt an den Modulen.
Aber dass man durchaus schlechten Code mit Perl zusammenfrickeln kann ist klar.

Struppi.

[Christian Seiler]

Hallo Struppi,

Hab ich keine Probleme mit Modulen,

Dann nutzt Du halt andere. :-)

meistens liegt's auch gar nichzt an den Modulen.

Sondern? Wenn dann Meldungen kommen wie "use of undefined variable" oder so ähnlich und dann Zeilen in der .pm-Datei angegeben werden, obwohl ich das Modul definitiv korrekt nach Anleitung eingebunden habe, dann liegt das m.M.n. definitiv am Modul.

Viele Grüße,
Christian

[Siechfred]

Tag Christian.

Sondern? Wenn dann Meldungen kommen wie "use of undefined variable" oder so ähnlich und dann Zeilen in der .pm-Datei angegeben werden, obwohl ich das Modul definitiv korrekt nach Anleitung eingebunden habe, dann liegt das m.M.n. definitiv am Modul.

Nein, es liegt meistens an unsauberen Aufrufen von Methoden, die das Modul zur Verfügung stellt. Aber grundsätzlich hast du Recht, dass man so manchem CPAN-Modul nicht unbedingt über den Weg trauen kann. Soweit es jedoch um die Standardmodule geht, werden nach meiner Erfahrung Warnungen in der Regel durch unsauberen Code in den aufrufenden Skripten verursacht.

Siechfred

[Christian Seiler]

Hallo Siechfred,

Aber grundsätzlich hast du Recht, dass man so manchem CPAN-Modul nicht unbedingt über den Weg trauen kann. Soweit es jedoch um die Standardmodule geht, werden nach meiner Erfahrung Warnungen in der Regel durch unsauberen Code in den aufrufenden Skripten verursacht.

Ich sagte ja auch nichts von wegen Standardmodulen, ich sagte nur aus CPAN.

Ich will ja nicht sagen, dass so etwas _an sich_ ausschließlich an den Modulen liegt. Mir ging es ja im Urprungsposting nur um folgendes:

Mir haben die letzten Einblicke in PHP Skripten, die ich mir in der letzter Zeit angeschaut hatte, jegliches Interesse an dieser Sprache vermiest, wer jahrelang use strict und warnings verwöhnt ist, ist doch ein bisschen erstaunt wenn du in  relativ etablierten PHP Projekte die Warnungen anschaltest.

Ich habe lediglich ein Beispiel geliefert, dass das gleiche auch bei etablierter (CPAN ist für mich etabliert) Perl-Software der Fall ist (bei bestimmten, schlecht programmierten CPAN-Modulen), und dass das insofern kein Argument gegen PHP ist, nur, weil die Leute in PHP Schrott zusammenprogrammieren - was Struppi ja gesagt hatte. Mehr wollte ich gar nicht sagen.

Viele Grüße,
Christian

[Siechfred]

Tag Christian.

[...] Mehr wollte ich gar nicht sagen.

Na, dann ist ja gut :-)

Nee, im Ernst. Ich hatte vor einiger Zeit mal eine Diskussion bezüglich CPAN vs. PEAR, im Rahmen derer sich herausstellte, dass CPAN trotz aller Schwächen um Längen besser ist als PEAR (die Intention hinter beiden ist ja ähnlich). Das habe nicht ich so gesagt, sondern der Diskussionsteilnehmer aus der PHP-Ecke. Insofern kann man Perl inkl. Standardmodule nur mit PHP inkl. einkompilierter Module vergleichen, ganz ohne CPAN, PEAR und Konsorten. Insofern wollte ich da lediglich in Bezug auf Perl was richtig stellen, auch wenn ich damit vielleicht offene Türen einrenne oder tausendfach im Archiv recherchierbaren Kaffee wieder aufwärme, wer weiß :-)

Siechfred

[Struppi]

meistens liegt's auch gar nichzt an den Modulen.

Sondern? Wenn dann Meldungen kommen wie "use of undefined variable" oder so ähnlich und dann Zeilen in der .pm-Datei angegeben werden, obwohl ich das Modul definitiv korrekt nach Anleitung eingebunden habe, dann liegt das m.M.n. definitiv am Modul.

Ich kenne diese Warnungen auch, aber bisher kamen die undefinierten Variabeln dann immer von meinem Skript.

Struppi.