nicht angemeldet
Moin!
Für alle Verbesserungswünsche gilt: RFC schreiben, Unterstützer gewinnen, Voting überstehen.
So viel Engagement will ich für PHP nicht aufbringen, dafür ist mir die Sprache persönlich zu rückständig, die Update-Politik zu konservativ. Es bereitet mir einfach keine Freude. Wie auch immer, dass der Entwicklungsprozess inzwischen so offen ist, begrüße ich sehr.
Und damit ist die Diskussion eigentlich schon zu Ende:
Das, was von der PHP-Community vorgeschlagen wurde für PHP 7, das wurde entweder nach Diskussion umgesetzt oder abgelehnt. Alles, was du hier anführst, interessiert in der PHP-Community offenbar zu wenig, als dass sich jemand drum kümmern würde.
Insofern kann ich die Kritik "Chance verpasst" nicht nachvollziehen, denn das, was umgesetzt wurde, stand eben exakt so auf dem Fahrplan. Nodejs-artiges Programmieren stand nicht drauf.
Syntax-Änderungen sind nicht mal einfach eingebaut. Du musst kompatibel zu existierendem Code bleiben.
Ich habe nicht behauptet, dass man das mal eben so machen könnte. Jedes neue Feature ist natürlich mit Arbeit verbunden, ganz besonders, wenn die Sprache so weite Verbreitung genießt. Und dennoch halte ich PHPs Closures für zu wortreich, um damit expressiven Code zu schreiben. Mir ist auch keine andere Sprache bekannt, die sowas wie eine use-Klausel benutzt. Soweit ich mich erinnere hat man damit eine Performance-Optimierung in der Garbage-Collection fokusiert, die sonst nicht möglich gewesen wäre. Das ist ja auch ein gutes Argument, allerdings zu Lasten des Sprachdesigns und damit auf Kosten derjenigen, die damit entwickeln müssen.
Warum PHP für Closures "use" benutzt, müsstest du die Implementierer zu PHP 5.3-Zeiten fragen (damals gab es noch keinen so strukturierten Featureprozess). Einer von denen war früher hier im Forum sehr aktiv: Christian Seiler. Der andere gehört zu den PHP-Core-Entwicklern: Dmitry.
Es war seinerzeit eher eine Machbarkeitsstudie, "weil man's kann". Damals, Ende 2008, war von NodeJS nichts zu hören und zu sehen, und bei Javascript-Engines war gerade das große Performance-Rennen im Gange - Javascript war, verglichen zu heute, also noch grottig lahm.
Dafür, dass PHP also eigentlich absolut nichts mit Javascript-Paradigmen zu tun hatte, und dass Christian und Dmitry sich in den grundsätzlichen Vorgaben, die PHP seinerzeit (und auch bis heute) hatte, bewegen mussten, sind die Closures und Lambdafunktionen recht gelungen.
Außerdem wünsche ich mir ein asynchrones Event-Handling für langlebige PHP-Prozesse
Kann man sich machen, wenn man will. Braucht die Mehrheit von Wordpress-Blogs nicht.
Ich finde schon, dass blockierende IO-Operationen ein Performance-Flaschenhals in jeder Anwendung sind und bin mir sicher, dass auch Wordpress von einem asynchronen IO-Modell profitieren würde.
Damit werden dann aber die Programmzusammenhänge komplexer. Schließlich brauchst du ja irgendwas sinnvolles zu tun, während du auf I/O wartest.
In diesem Sinne ist PHP übrigens problemlos parallelisiert: Während der eine Request auf I/O wartet, ist die CPU ja für den anderen Prozess frei und kann schon die Seite rendern. Das bringt der einzelnen Anfrage nichts, aber dem Gesamtbild.
Performance-Optimierungen für endrekursive Funktionen sind ein Muss, vor allem sollten endrekursive Funktionen keine Stackoverflows auslösen. Pattern-Matching bei Funktionsdefinitionen wäre der Hit.
Ich finde 100% Performanceoptimierung für realen Code schon ganz nett.
Da beißt sich die Katze doch in den Schwanz: Endrekursive Funtkionen sind nicht real, weil sie in PHP nicht performant und zuverlässig sind. Auf der anderen Seite stimme ich dir voll und ganz zu, dass die unternommen Perfromanceoptimierungen Würdigung verdienen.
Ich würde diesen Vorschlag allerdings als Spezialfallsonderoptimierung ansehen. Wieviele rekursive Funktionen hat man denn gewöhnlich in seinem Code? Und wie intensiv werden die aufgerufen? Und wie gut kann man das debuggen?
Wenn die Applikationen, die derzeit für Benchmarking von PHP 7 vs. HHVM genutzt werden, viel Gebraucht von Rekursion machen würden, wäre das bestimmt aufgefallen und schon umgesetzt.
Das Modulsystem von PHP ist der Grund, warum heutzutage alle damit Arbeiten, und warum man fast alle beliebige Infrastruktur an PHP anbinden kann.
Was interessiert dich als PHP-Entwickler die Implementierung der Extensions?
Kannst du das näher erläutern? Meiner Meinung nach ist nämlich genau das Gegenteil der Fall. PHPs require/include forciert doch gerade, dass Module in PHP geschrieben werden müssen. Haskells Modulsystem in Kombination mit der foreign Language API oder EcmaScript2015 Module sind in diesem Punkt doch wesentlich liberaler. Sie gestatten es Sofware-APIs anderer Systeme entweder nahtlos oder nur mit schmalen Wrappern einzubetten. PHP-Erweiterungen in C oder C++ sind damit verglichen äußerst selten außerhalb des privilegierten PHP-Kerns anzutreffen.
Du kritisierst "Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert." - anscheinend ist dir also die Anbindung von Modulen an PHP suspekt. Aber warum interessieren dich als PHP-Entwickler die internen Mechanismen, mit denen PHP dir ein Modul und damit eine Funktionserweiterung zur Verfügung stellt? Ärgerlich wird's ja nur, wenn Module nicht host-übergreifend verfügbar sind, das ist dann allerdings "nur" ein Environmentproblem und lösbar. Das dynamische Dazuladen von Modulen mit dl() ist ja eher als nicht-existent anzusehen, insbesondere wegen der Security-Implikationen und der grundsätzlichen Inkompatibilität zu den Threadsafe-Builds.
Apropos threadsafe: PHP kann Threads. Ist relativ simpel anzuwenden, halt so, wie andernorts vermutlich auch. Nutzt nur keiner - weil es komplizierter ist, sich Code auszudenken, der parallel abläuft und am Ende gemeinsame Ergebnisse zusammenzuführen, als einfach alles in einer geordneten Reihenfolge nacheinander zu tun. Wenn das schnell genug ist: Warum sollte man sich mit Race-Conditions o.ä. rumschlagen müssen?
Du kannst bereits jetzt im Namespace arbeiten und die gesamte Welt um dich herum ignorieren.
Namespaces sind dann der Workaround, den man heute gehen muss.
In Javascript ignoriert man doch auch alles außer "the good bits".
Du unterstellst mir schon wieder, ich wünschte mir diese Features so "mir-nichts-dir-nichts" herbei. Ich habe nie etwas in diese Richtung behauptet, im Gegenteil ich bin mir des enormen Arbeitsaufwandes durchaus bewusst und würdige die geleistete Arbeit in höchstem Maße.
Aber wenn du kritisierst, dass mit PHP 7 eine Chance verpasst worden wäre, und dann eine riesige Liste von Dingen präsentierst, die da alle noch reingehören sollten... das klingt nicht gerade so, als ob du akzeptierst, dass PHP so ist, wie es ist (und sich in einigen Punkten noch weiterentwickeln sollte), sondern dass PHP doch eigentlich noch mal schnell das alles hätte einbauen können.
Du weißt, warum PHP 6 gescheitert ist? Man baut nicht mal eben UTF-8-Unterstützung ein. In meiner täglichen Arbeit vermisse ich da jedenfalls nichts. Es gibt UTF-8-fähige Stringfunktionen, wenn man denn mal eine braucht.
Ja, PHP 6 ist auch an dem überambitionierten Ziel gescheitert UTF8-Support in die Sprache einzubetten. Das war ein katasrophaler Folgeschaden, den dieser frühe Designfehler nach sich gezogen hat. Heute ist PHP daher in diesem Punkt genauso weit wie vor PHP 6. Das ist schade und das kritisiere ich an der heutigen Version von PHP. Die Argumente haben sich seither ja nicht geändert.
Mir fehlt tatsächlich die Phantasie, mir vorzustellen, was UTF-8-Support über die bestehenden Stringfunktionen (mb_*) hinaus für einen nennenswerten Vorteil hätte. Ja, ich könnte mit $string[2] auf das dritte Zeichen zugreifen, nicht auf das dritte Byte wie jetzt. Ich benutze/warte/entwickle derzeit keinerlei Code, bei dem das irgendwie relevant wäre. Und der ist überall komplett UTF-8-fähig.
Grüße Sven