"5 Strengths of PHP"

[tami]

hi molily,

Hallo,

Kapiere ich nicht, wie Arrays einen prozeduralen Programmierstil aufzwingen.

Das Arbeiten mit Arrays in PHP tut es. Alle Operationen auf Arrays sind Prozeduren: array_foo, array_bar, array_qux.

Das gilt natürlich für die meisten Grundtypen in PHP.

Wie geht das und wie geht das besser, anders?

Objektorientiert. Objekte haben Methoden bzw. ihnen werden Nachrichten geschickt. So funktionieren Arrays in den meisten objektorientierten Sprachen.

myArray.filter(), oder myArray.sort() habe ich dann? so für sich genommen erschließt sich ja erstmal nicht, warum das von nachteil sein sollte oder könnte stattdessen $myArray = filter($myArray) etc.pp. zu notieren ...; aber es muss ja gute gründe (s. hack) geben.

Wie 1UnitedPower sagt, man will eine saubere Trennung zwischen Listen, Hashes/Dictionaries, Sets, Tuples… Darauf lassen sich komfortabel spezifische Operationen definieren, sodass das händische Durchlaufen nur noch selten vorkommt. Man schaue sich einmal Enumerable, Hash und Array in Ruby an, oder die Fähigkeiten von Lodash.

so richtig offensichtlich erschließt sich mir der vorteil da erstmal nicht. die notation von arrays (in php) und objekten (json) ist oder hashes (ruby) ist ja auch fast deckungsgleich.

PHP ist halt weit verbreitet, es läuft auf jedem Billighoster ohne Servergebastel, ist einfach einzurichten. Viele Menschen können PHP, viele Anwendungen basieren schon auf PHP. Außerdem werden die Sprachfeatures von PHP nach und nach erweitert, sodass neue Programmierstile und die elegantere Umsetzung bekannter Pattern möglich werden. Ergo, es entstehen neue PHP-Frameworks. PHP hat ja auch gewisse Anwendungsbereiche, in denen es nicht einfach zu ersetzen ist. Die werden aber im Vergleich zur gesamten Webprogrammierung immer kleiner, da die Software-Welt diverser wird. Dank SaaS ist es einfacher geworden, komplexe Anwendungen zu verteilen. Bei PHP dominiert eher das Hochladen von Dateien per FTP auf einen Webspace.

Node ist dahingehend schrecklich umständlich, weil es immer noch größtenteils mit Callbacks arbeitet. Vieles wird auf Streams umgestellt und es gibt ent-sprechende Helfer. Andere setzen auf ES6 Promises und Generators. Bei Go fühlt sich I/O von der Benutzung her synchron an, aber es ist nicht-blockend.

Unterm Strich ist es in JavaScript und Go dennoch einfacher, Nebenläufigkeit und non-blocking I/O zu programmieren.

"Unterm Strich ist es in JavaScript" ... wer ist jetzt "es"?

Ich werde ja nicht müde, es zu betonen: Facebook hat Hack nicht aus Liebe zu PHP, sondern wegen Schmerzen mit ihrer riesigen PHP-Codebase, wegen Unmengen an »Technical Debt« entwickelt. Eine bestehende PHP-Codebase zu Hack migrieren ergibt vielleicht Sinn, aber ich sehe keine Gründe, neue Projekte auf Hack aufzubauen. Da gibt es wahrlich schönere Sprachen.

Bei Heise und Facebook selbst liest sich das etwas anders: [Zitat Heise]: "Die neue Sprache setzt Facebooks HHVM (Hip Hop Virtual Machine) voraus, eine PHP-Code in Bytecode kompilierende virtuelle Maschine. HHVM bietet darüber hinaus einen Type-Checker, der gewährleisten soll, dass alle typisierten Informationen richtig sind. Hack wiederum ermöglicht es dem Programmierer, eindeutige Datentypen zu definieren. Auch gibt es in PHP nicht zu findende Collections, mit denen sich Arrays nuancenreicher als die Array-Funktion von PHP nutzen lassen sollen. Für Hack spreche auch, dass es durch Lambda-Funktionen den Einsatz von Closures vereinfache. Lambda-Ausdrücke waren erst kürzlich auch in Java 8 eingeführt worden. Zusätzlich unterstützt die Sprache Generics, Nullable Types und Typ-Aliasing."

Und bei Facebook: "Collections provide a clean, type-safe alternative to PHP arrays. We designed them specifically to work well with static typing and generics. The Collections API offers many classic higher-order functions such as map() and filter() to facilitate functional programming styles.

Lambda expressions give a concise syntax for creating closures. While PHP has closures, it requires the programmer to explicitly name the variables they need to use from enclosing scopes. With Hack's lambda expressions, we automatically infer these uses, saving you needless work. Lambda expressions make it more convenient to take full advantage of the Collections API."

Da wird wohl also ein Bedarf bei beidem sein.
Thomas Schlüter bei phpmagazin schreibt zwar von 5 Gründen gegen Hack, aber es steht da auch: "Besonders beliebt und auch im Sinne der Softwarequalität von hohem Stellenwert sind Generics und die Möglichkeit, eine starke Typisierung anzuwenden – ohne jedoch dazu gezwungen zu werden. Hinzu kommen Collections, XHP und die Keywords await und async für asynchrone Entwicklung."

Mich würde ja mal (abgesehen von der Typensicherheit) mal interessieren, wie (s.a. The new PHP PHPs experiencing a renaissance, with improvements and new standards
PHPs experiencing a renaissance, with improvements and new standards] PHP-Entwickler zu diesen Notwendigkeiten stehen: "Facebook has also made great progress on its alternative open-source PHP engine, the HipHop Virtual Machine (HHVM). HHVM uses a just-in-time compilation technique to provide incredible performance while still allowing the ease-of-use to which PHP developers are accustomed. Like the PHP Zend Engine, HHVM also includes FastCGI support. HHVM’s goal in early 2014 is to have 100% unit test pass for the top twenty PHP frameworks, and it recently announced a development roadmap for the next six months. Keep an eye on HHVM. I have a feeling it will drastically change the PHP landscape over the next few years."

mfg

tami