:roflmao:

Die Beweise für deine jedesmal sachlichen Argumente pro Perl / contra PHP bleiben wohl wie immer wieder aus... :p

Wenn du PHP als eine Art Perl bezeichnest kommt mir das grausen...
Und komm' mir ja nicht wieder mit dem Sch*, dass PHP aus Perl hervorgeht... Wir haben 2003! ;)

:lol: Darüber kann ich wirklich nur lachen... :D s.o. Beweise?

~

Beweise?

1) Fuer jede unterstuetzte Datenbank ein eigenes Modul anstatt einer eleganten Abstraktionsschicht?
Ja klar, es gibt jede menge ZUSAETZLICHER Module, aber wie gut sind die?
DBI/DBD von Perl sind erprobt, funken gut, ... - ich hab unter PHP noc nix vergleichbares und eleganteres gesehen.

2) Regular Expresions
Braucht man in einer textbasierten Welt (HTML, XML, ...) wie einen Bissen Brot.
Unter PHP brauch ich eine eigene Funktionen dafuer, kann die RegExen nicht einmal kommentieren, ...

3) SMTP-Unterstuetzung?
Eine relativ "neue" Sprache und dann brauche ich ein externes Programm zum Mailen? Sind wir in den 80ern? Da haette ich mir doch mehr erwartet.

4) Flexibilitaet
PHP - "PERSONAL HomePage" in der urspruenglichen Intention. Und wirklich weiterentwickelt hat es sich nicht. Fuer Webloesungen mag es ja ganz nett sein, wenn man noch keine ordentliche Sprache gelernt hat, aber mehr wuerde ich damit nicht machen, da wuerde ich noch eher ein VB-Script auf einem Windows-Server schreiben, bevor ich das mit Perl mache.
Unter Perl kann ich Webappliaktionen, GUI-Apps und Kommandozeilenscripts erstellen, alle laufen gleich stabil, gleich performant und mit einer Funktionalitaet, die ihresgleichen sucht. Und wenn ich ein klein wenig aufpasse, brauch ich das script fuer Linux, Windows, VMS, OS/2, AIX, .... ueberhaupt nicht aendern.

5) Erweiterbarkeit
Es gibt kaum eine Funktion, fuer die es nicht auch schon ein Perl-Modul gibt. Ueber ppm oder Bundle::CPAN lassen diese sich BEQUEM UND EINFACH installieren - auch, wenn es Abhaengigkeiten gibt.
Vergleichbares befindet sich fuer PHP bestenfalls im Aufbau.

Und Deine Beweise?


P.S.:
PHP ist aus Perl entstanden. Ich betone das immer wieder, da mir Leute Features als PHP-Features verkaufen wollen, die eigentlich aus Perl kommen.

:mad2:

Als Autor dieser PHP Beispielscripte glaube ich kaum das du in der Position bist, so über PHP zu reden :rolleyes:

Ja! Wird auch Zeit. Hast du bis jetzt nämlic himmer vorenthalten.

Hm, DBI ist wohl kein ZUSÄTZLICHES Modul, oder was ? :p

Sicher darfst (kannst?) du das.

Hätte PHP das, würdest du meckern, dass man nicht auf stabile altbewährte Sachen zurückgegriffen hat.

Willst du behaupten, dass das Perl kann, aber PHP nicht?

Meine Beweise sind tagtäglich auf der ganzen Welt zu beobachten...

Deine Apathie PHP gegenüber muss fast krankhaft sein, denn ich würde verstehen, dass du Perl VB vorziehst, aber umgekehrt?
:rolleyes:

~

noch zum thema ?
 

hi !

erstmal vielen dank für eure antworten/unterstützung - v.a. an diejenigen die mir geholfen haben. :rolleyes:

warum manche soche fragen gleich für einen streit als anlass nehmen müssen ist mir unklar.
ist das nicht bissl lächerlich ? ..."dies ist besser als jenes" - o.k., muss zugeben - früher im kindergarten waren solche streiterein amüsant, aber irgendwann wird das dann doch langweileig, oder ?

genaug damit.

@_m3: ich weiß schon, was apache und php sind. meine web-anwendung verwendet php und apache und u.a. hat sie die aufgabe, daten aus einer db periodisch abzufragen und daraus berechnungen anzustellen und wieder in die db zurückzuschreiben.
natürlich - dazu kann man ein eigenes programm schreiben, aber ich dachte halt, dass es einfacher wäre, das auch gleich via php zu machen, nachdem der "web-anzeige-teil" der appl. in php ist und das gaze vom kunden wartbar sein soll (!) eine db-anbindung, mailfunktionalität, http-protokoll übertragung usw. ist imho. in php viel einfacher zu realisieren, als in einem eigenständigen z.B. C++ programm. btw....perl find ich recht interessant - will ich mir bei gelegenheit näher ansehen.

countdown halt ich für keine lösung. dachte eben eher an ein php skript und irgendeine möglichkeit, dass ich dem apache sage, dass er dieses alle 2 stunden periodisch aufrufen soll.

@käptn: keine idee diesbezütlich ?
...du hast mir ja schon öfter bei meinen php-fragen geholfen. ;)

also wie gsagt - thx für eure unterstützung und seid´s nett zueineander. :)

nochwas: findet ihr, dass asp.net "weiterentwickelter" ist als php ?
einsatzgebiet: web-appl. mit db abfrage für ca. 10000 user.
perl kommt für mein derzeitiges projekt nicht in frage - entscheidung ist bereits für php gefallen. (auch seitens d. kunden)
...ist nur eine frage - bitte keine streiterei deswgen.

fg
-hannes

Biri! :)

Das ist kein Streit!
Das ist ein netter kleiner Flamewar - einer von denen, in welchen m3 immer wieder die alten lauwarmen Argumente aus den Löchern kriechen läßt. :D


Bez. ASP .Net:
Hatten wir die Frage nicht schon mal?
Na jedenfalls würde ich zu ASP.NET raten, wenn du auf Win mit z.B. MSSQL arbeitest.
Was sollte auf MS Technologien performanter sein als MS Technoligien?

Zum Thread:
Cron wär natürlich ideal.
Aber wenn du auf Win arbeitest, solltest du vielleicht einmal den Taskplaner antesten.
UND: du kannst natürlich PHP problemlos auf der Kommandozeile laufen lassen.

~

aso. ;)

hab das mal sagen müssen, weil die diskussion nix mehr mit dem thema des threads zu tun hatte - stimmt, die frage bezügl. asp gabst schon mal, aber meinungen ändern sich ja und ich fands passend weil gerade perl vs. php "diskutiert" wurde...

wg. taskplaner:
also diesen so einstellen, dass der taskplaner alle 2 stunden:
"php.exe meinscript.php" ausführt.

hmmm - wenn das script dann fertig ist, müsst ich den "kommandozeilen php-interpreter" wieder beenden.
kommt sich der auch nicht mit dem apache php modul in die quere ?
welche instanz interpretiert die php befehle, wenn php als apache modul läuft und gleichzeitig die php.exe gestartet wird ?
hmmm - kann nicht einschätzen, ob dieser ansatz gscheit ist...

fg
-hannes

So, nachdem meine "Chefin" mich gestern vom Computer weggezogen hat, bin ich wieder da :D

Schon, aber im Gegensatz zu PHP ist Perl auf externe Module ausgelegt - das ist eine Designsache und da finde ich den Perl-Ansatz deutlich eleganter.

ad RegEx-Kommentieren:
RegExen sind zumeist recht komplexe Konstrukte, die in einem professionellen Script Dokumentiert gehoeren. Natuerlich kann ich in PHP vor der preg_match() die RegEx kommentieren, aber so
sieht das doch wesentlich klarer und intuitiver aus, oder?


Na klar ;) :D
Nein, ernsthaft. Wenn ich sehe, dass Leute einen "legitimen" Massenmailer in PHP implementierne, der Mails an zigtausend Adressen schickt, dreht sich mir der Magen um. a) wird da fuer jedes Mail das externe Programm aufgerufen ("tolle" Performance) und dann wundern sie sich, warum das Script im Browser in ein Timeput laeuft.
Und da frag ich mich dann schon ...

Nicht so gut, nicht so elegant und nicht so schnell wie Perl.

MS Software wird auch auf der ganzen Welt eingesetzt und die Leute kommen langsam drauf, dass es nicht unbedingt die Beste Loesung ist ;)

LOL, so schlimm ist es nicht. Und bevor ich in VB "programmier", greif ich lieber zu JavaScript oder PHP ;)
Wir hatten das Thema eh schon oefter. Ich kenn, wenns hoch kommt, 2 gute PHP-Programmierer, die wissen, was sie tun. Der Rest sind wannabies, deren Scripts ich nicht einmal auf meinen Server laufen lassen wuerde, wenn ich alles gejailt haette.
Aber ich hab kein Problem damit, wenn diese Leute bei PHP bleibe, so bleibt der Standard fuer Perl-Scripts so hoch, wie er jetzt ist.
Aber kapetn: Mit fehlt noch Deine Liste, warum PHP besser als Perl ist (ausser, dass es die geileren Groupies gibt ;) )

@Biri: Wie kaeptn schon sagte, ist nur ein freundlicher Flamewar, no personal harm intended. Dass dafuer Dein Thread herhalten muss, faellt wohl unter Kollateralschaden ;)

Zu Deinem Thread: Wieso sollten sich die Kommandozeile und der Interpreter fuer Apache in die Quere kommen? Als mod fuer Apache laufen ja auch mehrere PHP-Instanzen gleichzeitig.
Und der Kommandozeileinterpreter beendet sich automatisch, wenn das SCript zu Ende ist.

das nette am taskplaner => bei jeder sommer und winterzeitumstellung gehen die jobs nicht mehr => neu einplanen.

das ist natürlich optimal wenn man weltweit über 300 server mit entsprechend vielen jobs hat :mad: :rolleyes:

Hat wer gesagt, dass der Taskplaner brauchbar ist? ;)
Zum Glueck gibts online eine Menge Alternativen. :)