PHP oder Perl?

[bigred2010]

Hi @all,

ich möchte für meine Kollegen eine Weboberfläche entwickeln, über der sie eine Datei Verwalten können. Hintergrund ist der, dass ich das die ganze Zeit für sie machen muss und ich das endlich los werden will.

Es muss eine Datei ausgelesen werden und die Ausgelesen "Blöcke" sollen dann von den Kollegen über die Weboberfläche geändert werden. Nach den Änderungen soll ein Dienst durchgestartet werden.

In welcher Sprache würdet ihr das Problem lösen? Ich kenn mich etwas mit PHP und auch mit Perl aus.

[shinuma]

Was meinst du mit Dienst? Ein Dienst bei Windows oder allgemein ein Programm?

Windows oder Linux?

[bigred2010]

Ja, sorry, das ganze Läuft unter Linux.

[Mr Unix]

Ja, sorry, das ganze Läuft unter Linux.

Im letzten Linux Magazin war ein Vergleich verschiedener Sprachen. Ich wuerde Perl vorziehen, aber auch nur weil ich PHP nicht mag. Bei verschiedenen Suchmaschinen findest du massig vergleiche. Hier einer von vielen:

PHP in contrast to Perl

[Aiun]

he he, da muss ich aber dringend widersprechen.

Der vergleich (den du da gepostet hast) vergleicht die Radbreite zwischen automarken.

Es macht keinen Sinn funktionsanzahl oder namenslänge zu vergleichen.:upps

PHP und perl können grob das gleiche, wobei ich k.A. über die Objektorientierung in perl habe.

perl hat (für mich) einen großen nachteil, es wird schnell unleserlich und nur schwer lesbar/dokumentierbar. alle anderen Sprachen die ich bisher gesehen habe zeigen eine gewisse minimal-lesbarkeit des codes durch ihre funktions oder klassennamen.

[Mr Unix]

Es macht keinen Sinn funktionsanzahl oder namenslänge zu vergleichen.:upps

Das wird in dem Dokument auch nicht gemacht. Um es zu verstehen, sollte man es zuerst lesen und erst danach urteilen. :eek

PHP und perl können grob das gleiche, wobei ich k.A. über die Objektorientierung in perl habe.

Das war mir neu, aber ich lasse mich gerne belehren. Mag sein, dass ich das letzte mal vor acht Jahren PHP angefasst habe, aber damals konnte es Perl nicht mal das Wasser reichen. Kein XS-Interface, weder Lexical noch Dynamic Scoping, kein CPAN, keine Moeglichkeit die Shell in system() zu uebergehen, nicht threadsafe und ein Binary das einen Monsterheap verursacht... Hat sich das etwa seit 5.x geaendert?

perl hat (für mich) einen großen nachteil, es wird schnell unleserlich und nur schwer lesbar/dokumentierbar.

Das liegt wohl einzig und allein beim Programmierer. Meiner Meinung nach hat Perl mit POD (man perlpod) eine hervorragende Dokumentationsmoeglichkeit dabei. Die Dokumentation ist direkt beim Code. So kann man sich nicht rausreden, dass man "vergessen" hat die Dokumentation mit dem Code zu aendern.

Wenn jeder die Pragmas strict und warnings verwendet und sich an man perlstyle haelt, dann bleibt der Code sehr leserlich. :e@sy

[bigred2010]

Hi,

danke für eure Hilfe

Ich denke ich werde das ganze in Perl lösen.

Die letzten Argumente von Mr Unix haben mich doch überzeugt

Viele Grüße

Marcus

[geloescht_JesterDay]

Es muss eine Datei ausgelesen werden und die Ausgelesen "Blöcke" sollen dann von den Kollegen über die Weboberfläche geändert werden. Nach den Änderungen soll ein Dienst durchgestartet werden.

Hmmm...

Kein XS-Interface, weder Lexical noch Dynamic Scoping, kein CPAN, keine Moeglichkeit die Shell in system() zu uebergehen, nicht threadsafe

Man könnte ja auch argumentieren, dass ein Porsche besser als ein Fiat ist, wenn einen die Mama fragt mit welchem Auto sie zum Einkaufen fahren soll

[bytebrain]

[...]

perl hat (für mich) einen großen nachteil, es wird schnell unleserlich und nur schwer lesbar/dokumentierbar. [...]

Servus

Da muss ich dir widersprechen. Mein Perl-Sourcecode ist keineswegs unleserlich. Wenn man sich an gewisse Vorgaben hält ist auch Perl-Code sehr leserlich. Und dokumentieren geht mit POD zum Beispiel sehr gut (so dokumentiere ich meine Perl-Klassen).

Was das Problem nun anbelangt:

Für Webanwendungen würde ich immer PHP verwenden, da PHP imho im Web-Bereich besser ist. Wobei Perl grad im parsen/bearbeiten von Dateien seine große Stärke hat.

Gruß,

bytebrain