nicht angemeldet
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.
Ich weiß nur, dass das Iterieren über Arrays mit den $key und $value Paaren einfach ist, dass es einfacher mMn. nicht geht. In Javascript durch ein Objekt zu laufen ist keineswegs einfacher ...; und was mehr will man?
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.
Mein Gesamt-Eindruck ist, dass sich Seiten, die sehr viel Benutzerinteraktion erfordern (insbesondere also Web-Apps) sich vermehrt von PHP abwenden.
Da frage ich mich (weil ich wissen will, wo und wie Ruby, Python, Golang oder NodeJS das besser machen), warum es (noch) so viele und immer neue Frameworks für PHP gibt (Symfony, Yii, CakePHP, ZendFramework, Laravel).
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.
Und wenn der Autor seine Schlüsse über die PHP-Threads zieht, wird nicht einmal ein Vergleich mit Ereignis-basiertem Design gezogen, die Technik, die spätestens seit Node.js so viel Aufmerksamkeit auf sich zieht.
Jo, das wüsste ich gerne mal, wie das praktisch aussieht. Wenn ich nach Node.js gegooglet habe und dann Golang dazu genommen habe, zieht Node glaube ich den kürzeren.
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.
Zu Golang finde ich dann aber Leaving Go.
Okay, solche Probleme muss man erst einmal haben.
"I recommend that people try it out again with a modern framework, as I've seen many developers who've moved away from PHP to Ruby, Python, and Node, and then came back once they seen how great PHP is with a recent framework which uses all the nice features of recent PHP versions, as well as Hack, Facebooks new language based on top of PHP."
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.
Mathias
Der Martin
Matthias Apsel