Ist Perl 2016, im Bereich Webentwicklung, noch aktuell - und sollte man lieber PHP oder Perl wählen für einfache 'Backend'-Anwendungen?
Hey, ich überlege gerade ob ich Perl lernen sollte. Weil ich gern meine eigenen 'Backends' schreiben würde. Ich möchte dass man sich auf einer Website einloggen kann und dann in diesem Backend einfach bestimmte Daten wie z.B. die Kosten für verschiedene Produkte oder die Starttermine von Veranstaltungen ändern kann. Ich kenne da einen ziemlich einfachen Weg mit Perl, bei dem quasie für eine art Kalender einfach .dat Dateien geschrieben werden und diese werden dann per .cgi Script in die Website Geladen. Die Informationen die man im Backend verändert, werden in diesen Dateien gespeichert.
Ist dieses Vorhaben schwerer mit PHP oder Perl zu realisieren? Da PHP doch um einiges umfangreicher ist als Perl weiß ich nicht ob ich extra PHP lernen möchte.
Perl ist ja doch schon etwas in die Jahre gekommen, findet es denn 2016 immernoch anwendung bei Websites?
4 Antworten
Ist dieses Vorhaben schwerer mit PHP oder Perl zu realisieren?
Es ist eindeutig VIEL schwerer in PHP als in Perl zu realisieren, und ehrlich gesagt in der PHP Standardinstallation ohne Zusatzmodule unmöglich zuverlässig zu implementieren. (Die Betonung liegt auf "zuverlässig"!)
Dir werden zwar 99,9% aller PHP Entwickler das Gegenteil erzählen, aber die haben i. d. R. auch keinen Schimmer von Race-Conditions, Inter-Prozess-Kommunikation und vernünftiger Synchronisation bzw. Locking.
Außerdem neigen sehr viele von denen zu notorischem Pfuschen und testen auch nicht richtig. (Einzig und allein Unit-Tests sind nämlich KEIN "richtiges" Testen!) Aber das ist ein anderes Thema ...
Da PHP überhaupt nicht auf Parallelität ausgelegt ist, und die entsprechenden Entwickler deshalb oft auch noch nichts davon gehört haben. Aber auch hier werden dir 99,9% der PHPler das Gegenteil erzählen, weil sie meist überhaupt nicht wissen, was "Parallelität" eigentlich überhaupt ist, und damit nicht die parallelen Anfragen an den Webserver gemeint sind.
Fakt ist, dass es mit PHP-Boardmitteln keine portable Möglichkeit gibt, wirklich zuverlässig Datensalat in deiner Kalenderdatei zu verhindern. File-Locking ist ineffizient, unzuverlässig, und hängt von extrem vielen Konfigurations-Einstellungen ab (u. a. Betriebssystem-Typ u. -Version, Dateisystem-Typ u. dessen Konfig, php.ini, Server-Konfig, und noch viel mehr!).
SysV-Locking ist ebenfalls unzuverlässig, hat eine hässliche API und wird früher oder später Deadlocks erzeugen, falls mal ein PHP-Thread sterben sollte. Und vernünftiges POSIX-Locking ist nur mit zusätzlichen Modulen möglich.
Außerdem hat PHP schwere Bugs in seiner Standardbibliothek, die synchronisierten Zugriff selbst mit den oben genannten Notlösungen unmöglich machen.
(Die Funktion file_get_contents() ist zum Beispiel in diesem Zusammenhang völlig unbenutzbar, da sie im Gegensatz zu file_put_contents() kein $flags-Argument unterstützt, und damit für synchronisierten Zugriff erstmal komplett neu geschrieben werden muss.)
Ich möchte nochmal betonen, dass die meisten reinen PHP-Entwickler wirklich (leider) keinen allzu dollen Überblick haben und viele davon meine obigen Äußerungen vermutlich nicht mal nachvollziehen werden können.
Das soll jetzt ausdrücklich kein Bashing sein, aber PHPler haben ihren Ruf nicht umsonst. Gibt aber natürlich auch Ausnahmen! (Ein paar zumindest ... hahaha) :)
Kommen wir nun zu Perl: Locking ist kein Problem. Fertig! :)
Ich kenne da einen ziemlich einfachen Weg mit Perl, bei dem quasie für eine art Kalender einfach .dat Dateien geschrieben werden und diese werden dann per .cgi Script in die Website Geladen.
Wenn du dir natürlich um synchronisierten Dateizugriff - wie oben im PHP-Teil beschrieben - keine Gedanken machst, bietet Perl bei deinem Vorhaben natürlich keine nennenswerten Vorteile gegenüber PHP.
Sei aber gewarnt, dass File-Locking auch unter Perl-Entwicklern weit verbreitet ist! Aber immerhin funktioniert das dort wenigstens zuverlässig. :)
Allerdings ist es in Perl - im Gegensatz zu PHP - trivial einfach, sodass du dich a) mal kurz damit beschäftigen solltest (Stichwort POSIX IPC), da du ansonsten b) irgendwann Datensalat erhalten wirst und deine gesamten Kalenderdaten kaputt bzw. unzuverlässig fehlformatiert werden!
Falls du dir den ganzen Salat aber ersparen willst, nimm lieber ein Datenbank-System und arbeite mit Transaktionen. Dann ist es mehr oder weniger Wurst, ob du dich für Perl oder PHP entscheidest, da die IPC sowieso von der DB-Implementierung übernommen wird. :)
Also dann viel Spaß mit deinem Kalender! :)
PS: Weder Perl, noch PHP sind die hübschesten Programmiersprachen - beide haben merkwürdige Inkonsistenzen und zeigen teilweise denkwürdiges Verhalten. Aber PHP wird nicht ohne Grund als "der dumme Bruder von Perl" bezeichnet! Behalte das bitte immer im Hinterkopf! :)
Trotzdem spielt die Wahl der Sprache bei deinen geringen Anforderungen fast (!) keine Rolle. Der einzige wichtige Punkt scheint mir die Synchronisation zu sein, und dabei versagt PHP kläglich. Bleibt also nur Perl. :)
PPS: Python und Ruby wären ebenfalls sehr elegante, schicke, moderne und leistungsfähige Alternativen zu Perl! Beide haben auch nicht die Nachteile von PHP im Bezug auf IPC, im Gegenteil, sie sind sogar direkt dafür ausgelegt! Sie wären damit sogar noch besser als Perl geeignet.
Sie sind evtl. eine Üblerlegung wert und damit noch deutlich Einsteigerfreundlicher als Perl! ;)
Ich habe gerade nochmal die "Hole Frucht Diskussion" unter einer der anderen Antworten gelesen, und möchte nochmal kurz darauf hindeuten, dass der von mir beschriebene Datenverlust o. Datensalat nicht nur theoretischer Natur ist, sondern sogar sehr wahrscheinlich ist, wenn du deine Kalender-Site in zwei oder mehr Browsertabs gleichzeitig geöffnet hast, und die Kalenderdaten insgesamt größer sind, als ein Sektor / Cluster deines Dateisystems!
Wenn du also am Abend deinen Browser mit 3 Tabs schließt, und am nächsten Morgen öffnest, wobei die Daten in der Kalenderdatei größer als 4KB sind, kann es leicht passieren, dass du Datenmüll erhältst. Warum das so ist, würde jetzt den Rahmen sprengen, das Problem betrifft aber vielerlei Anwendungen, nicht nur im Web!
Das gemeine daran ist, dass das Problem selbst bei intensivem Testen nicht auffallen wird, wenn entweder a) immer nur mit einem einzigen Prozess oder b) mit sehr kleinen Testdaten gearbeitet wird.Der Fehler tritt dann erst später im Betrieb auf, und ist sehr schwer zu finden. Solche Fehler nennt man deshalb auch "Heisenbugs". :)
Dieses Vorhaben ist auch mit PHP nicht schwer umzusetzen.
Allgemein würde ich für soetwas eher zu PHP tendieren. PHP ist bei den meisten Hostern schon vorinstalliert. Wie das mit Perl aussieht kann ich gerade nicht sagen.
Da bleibt mir nichts als dir zuzustimmen.
Das mit Threads, IPC, File-Locking ist so ne Sache... Da bleibt wirklich nur der Wechsel zu anderen Sprachen.
(Es gibt eine Erweiterung, die Threads in PHP ermöglicht, ich habe damit aber noch nie gearbeitet und kann deshalb nichts weiter dazu sagen: http://www.php.net/manual/de/book.pthreads.php)
Ich würde aber auch sofort auf ein Datenbanksystem setzen. Dann ist das mit den Locks geregelt.
Genutzt wird Perl zwar durchaus noch, aber für so etwas wie ein einfaches CMS würde ich auf jeden Fall PHP bevorzugen, via MySQL z.B. ist da auch das mit dem Speichern (und ggf sortieren / durchsuchen) von Daten sehr komfortabel. Es gibt sicher Bereiche, wo Perl besser ist, aber in dem Bereich imho eher selten. Zudem wird PHP so ziemlich von jedem Hoster unterstützt (bei Perl ist das nicht immer der Fall, vor allem bei den günstigeren Angeboten) und es gibt afaik auch eine deutlich größere Community (also speziell jetzt was Webanwendungen angeht) im Netz.
Grundsätzlich kann man aber fast alles in der Richtung (CMS etc) mit beiden Sprachen umsetzten, mal ist halt die eine etwas schneller / effektiver und mal die andere, wenn du beide ausreichend beherrschst kannst du also im Grunde einfach die nehmen, die dir lieber ist (kommt natürlich auch drauf an, ob da später mal noch andere dran / mit arbeiten sollen, PHP ist halt viel verbreiteter).
Was für PHP spricht , es ist meist bei jedem Server dabei .
Aber wenn Du deine Sachen eh in Perl umsetzen kannst, dann brauchst Du kein PHP . Perl ist auch nicht kleiner oder Größer als PHP , den Perl hat die CPAN
da findest Du auch alles und mehr .
Mit Perl kenn ich mich schon ein bischen aus. Was meinst du wie lange es braucht bis ich das was ich oben geschildert habe mit PHP umsetzen kann?
Wenn ich komplett neu mit PHP anfange.
Da bei PHP alles aufs Webwesen ausgerichtet ist , würde ich sagen , PHP ist einfach leichter zu benutzen . Es gibt schicke Server Variablen die Dir das leben um einiges leichter machen . Bei Perl ist das alles immer so eine Sache . Schick ist auch das man PHP mit dem HTML Mixen kann , so brauch man nicht das , ich gebe am Ende etwas aus und das Ich muss alles Escapen was geht .
Also für deine Anforderungen solltest Du schon nach einer Woche Ahnung haben wie Du etwas in PHP umsetzt . Vieles ist viel einfacher , da PHP ja eigentlich mal als Toolbox für Webseiten gestartet ist und Perl eigentlich als Commandozeilen Tool :)
Man mixt auch in PHP kein Html mit PHP Code, außer man hat keine Ahnung oder will unbedingt unwartbaren Spagehtticode. Ein Framework nutzen und sauber programmieren. Der View Layer hat nichts, aber auch gar nichts, mit dem Businesslayer zu tun.
man kann es auch übertreiben , nur um mal eben eine seite zu machen brauch es natürlich diverse javascripts und diverse frames , damit dann die aktuelle uhrzeit sichtbar ist .
Ja ja , genau , ohne Businesslayer und Layer überhaupt , mixt man natürlich nie HTML und PHP , wäre ja auch gar nicht gut, weil das Projekt sowieso 1000 Seiten hat .
Hole frucht argumentation .
Deine Argumentation ist eine hohle Frucht Argumentation, dass ist eine Standardarchitektur HTML nicht mit PHP zu mixen und ist auch völlig unabhängig der Projektgrösse.
Es ist zwar richtig, dass man View und Controller voneinander trennt, doch letzten Endes kommt man auch beim View nicht drumherum, PHP-Code mit Markup zu vermischen. Irgendwie möchte man ja schon die dynamischen Inhalte in die statische Struktur hineinbekommen.
Sry es ist durchaus üblich und auch legitim PHP und HTML zu mischen.
Allerdings nur in begrenztem maße.
Nur um einen Benutzerzähler zu Programmieren muss man nicht gleich smarty und co mit einbinden. Das wäre völlig Idiotisch. Genauso als wenn jemand nur wegen einem "Alert" jQuery einbinden würde. Oversized nennt sich so etwas.
Dir würde ich schon mal nicht mein Projekt anvertrauen, wenn Du für jede keine Aufgabe gleich ganze Frameworks einbindest und es nicht gebacken bekommst das selbst zu regeln.
PS: Es heisst auch M(odel) V(iew) C(ontroller) nicht Business
mfg
Also gerade DAS ist ein typischer Trugschluss. (siehe dazu meine Antwort)
Wenn einem die geschriebenen und gelesenen Kalenderdaten halbwegs wichtig sind, und man sich darauf verlassen können muss, ist es mit PHP ein absoluter Krampf und wird sehr sehr viel Workaround-Code verlangen!
Den meisten PHPlern ist aber leider nicht mal klar, was bei so einer trivialen Aufgabe alles schief gehen kann. :)