Daaron schrieb:
Wieso? Offene Typisierung mag manche Leute etwas irritieren, aber sie ist definitiv flexibel. Die freie Wahl, ob man nun objektorientiert schreibt oder nicht, ist DEFINITIV flexibel. Und auch die Menge an leicht verfügbaren Schnittstellen ist absolut genial.
Oder störst du dich an der Performance-Aussage? Vielleicht solltest du mal FastCGI probieren...
Ich betreibe noch einige PHP-Installationen (Oh Wunder, alle für WordPress

) die allesamt mittels PHP-FPM per FCGI an den Webserver (Nginx) angebunden sind. Natürlich wird auch APC genutzt
Im Vergleich zu anderen FCGI-Anwendungen, beispielsweise in Go geschrieben, ist und bleibt die Performance aber ein schlechter Witz. Damit meine ich sowohl Programmlaufzeit, Speichereffizienz /-verbrauch als auch CPU-Last.
In Sachen Flexibilität ist immer der Blickwinkel entscheidend. Für den Otto-Normal-Anwender scheint PHP auf den ersten Blick flexibel zu wirken, da sich der Anwender nicht um Type-Conversions u.Ä. kümmern muss.
Gleiches gilt aber auch für JavaScript und viele andere Skriptsprachen und funktionale Programmiersprachen.
Zieht man nun aber die Erweiterbarkeit der Programmiersprache in Betracht, sieht man bei PHP schnell schwarz. Ohne Erweiterung des PHP-Interpreters um zusätzliche Module gerät man schnell an die Grenzen des Machbaren, sofern die Anwendung über einfache Text-Ausgabe und grundlegende Kommunikation mit den populären relationalen Datenbanksystemen (MySQL, SQLite3 etc.) hinausgeht.
Mich persönlich stört aber vor allem das Grundprinzip wie PHP-Programme ausgeführt werden. In Endeffekt werden für jeden Programmaufruf (hier jeder Hit auf eine PHP-basierte Website) alle benötigten PHP-Dateien neu geparsed, bevor dieser zu
Bytecode kompiliert wird um diesen anschließend zu nativen Maschinencode zu übersetzen und auszuführen.
Natürlich gibt es hier mit APC, XCache und Co. Versuche das Problem zu lindern, indem der Bytecode gecached wird und nur neu erzeugt wird, sofern sich der Hashwert der betreffenden Dateien geändert hat. Wirklich lösen können diese das Problem aber auch nicht und im Vergleich zu nativen Programmen, die in C, C++, Go o.Ä. geschrieben wurden, bleibt ein riesiger Overhead bei jedem Programmaufruf.
Zudem nimmt diese Funktionsweise, die für jeden Aufruf eine neue Instanz erzeugt, dem Entwickler eines der mächtigsten Werkzeuge, da er nicht "Aufruf-übergreifend" programmieren kann. Um mal wieder den Bezug zu WordPress herzustellen, hier ein kleines Beispiel: Hätte man eine Blog-Software, die in einer ernstzunehmenden Programmiersprache geschrieben wurde und als native Anwendung auf dem Server läuft, so könnte prinzipiell der gesamte Datensatz im Systemspeicher, also als Variablen innerhalb des Programms verwaltet werden. Bei einem Aufruf der Website müssten die Daten nur noch in schickem HTML verpackt ausgegeben werden. Eine Kommunikation mit einer Datenbank wäre hier überflüssig. Im Normalfall ist dies eines der größten Flaschenhälse überhaupt bei PHP-Anwendungen.
Letztendlich wird man aber dennoch eine Datenbank benutzen, da Systemspeicher (RAM) leider begrenzt und zudem auch flüchtig ist. Irgendwann wird das Programm sicher auch mal mehr oder weniger freiwillig beendet werden

Jedoch wird man trotzdem überwiegend mit den im Systemspeicher zwischengespeicherten Daten arbeiten. Erst bei Änderungen, z.B. bei einem neuen Kommentar würde Datenbankkommunikation erforderlich. Im Gegensatz zu PHP könnte dies jedoch asynchron zu dem eigentlichen Programmaufruf geschehen, da die Laufzeit ja nicht an diesen gebunden ist. Diese Möglichkeit der zu den eigentlichen Programmaufrufen asynchronen Ausführung des Programms ermöglicht aber noch viel mehr wunderbar einfache Dinge als das zugegebenermaßen nicht wirklich gute Beispiel

Kleine Gedankenansätze wären hier zum Beispiel Benutzerstatistiken und Datensätze die in bestimmten Intervallen aktualisiert werden sollen. WordPress "löst" dies über sehr umständliche "WP-Crons"

(Es wird bei jedem Aufruf geprüft, ob noch Aufgaben anstehen. Gibt es keine Besucher auf der Seite, werden die Aufgaben also auch nicht ausgeführt)
Bei PHP ist ein Zwischenspeichern von Daten über mehrere Programmaufrufe nur umständlich über externe Lösungen wie APC möglich, dass Cachen insgesamt wird hier also deutlich erschwert.
Ich empfehle jedem einfach mal ein kleines Web-Projekt z.B. in
Go umzusetzen. Natürlich ist dies erstmal völlig fremd und erfordert etwas Einarbeitung. Jedoch wird man schnell merken, wie limitiert PHP eigentlich ist und wie sehr man dort herum gepfuscht hat. Ich persönlich muss PHP leider noch ab und zu für Kunden einsetzen. Privat und für eigene Projekte bewegt mich aber nichts in der Welt mehr zurück zu PHP
