"5 Strengths of PHP"

[tami]

hi alle,

just stumbled upon: http://technosophos.com/2014/05/14/5-strengths-of-php.html

mfg

tami

[hotti]

hi,

just stumbled upon: http://technosophos.com/2014/05/14/5-strengths-of-php.html

Sehr schön. Komplexe Datenstrukturen (1) gibt es in jeder PL. 3 und 4 sind ein Witz, verglichen mit Perl/CPAN und was ich in PHP vermisse, sind z.B. phpdoc -f <funktionsname> oder phpdoc <modulname> oder phpdoc -q <query> womit sich mal eben so nebenbei eine Hilfe auf der Kommandozeile anfordern lässt. 5 ist ähnlich wie in Perl und ich frage mich seit über 10 Jahren, wie 2 zustande kommt.

Viele Grüße.

PS: 1 ist auch nüscht neues, <cite>Programme sind letztlich konkrete Formulierungen abstrakter Algorithmen, die sich auf bestimmte Darstellungen und Datenstrukturen stützen. </cite> Niklaus Wirth 1975

[M.]

Mahlzeit,

was ich in PHP vermisse, sind z.B. phpdoc -f <funktionsname> oder phpdoc <modulname> oder phpdoc -q <query> womit sich mal eben so nebenbei eine Hilfe auf der Kommandozeile anfordern lässt.

phpdoc ist, ebenso wie perldoc, kein Bestandteil der Sprache sondern was externes. Oder hat sich das inzwischen geändert und perldoc ist direkter Bestandteil von Perl?
Was ich damit sagen will, wenn dir was fehlt, bau es dir, bei Perl hat ja auch jemand was gebaut, weils gefehlt hat.
Das hat aber generell mal nicht mit der Programmiersprache zu tun sondern mit Angebot und Nachfrage. Wenn ich per Apigen ne Doku erzeuge, ist die Doku halt so gut wie der Programmierer den Code geschrieben hat, gleiches gilt für Perldoc.

Da PHP primnär nicht in der Kommandozeile genutzt wird, halte ich persönlich die Doku im Browser als ausreichend. Und selbst wenn ich in Perl arbeite, nutze ich keine Doku aus der Kommandozeile, bisher keinen Bedarf gehabt. Aber Anforderung sind so vielfältig wie die Anzahl der Programmierer mulitpliziert mit der Anzahl der Programmiersprachen ;)

Natürlich nur meine, nicht repräsentative, Meinung.

[hotti]

hi,

phpdoc ist, ebenso wie perldoc, kein Bestandteil der Sprache sondern was externes. Oder hat sich das inzwischen geändert und perldoc ist direkter Bestandteil von Perl?

Irgendwo müssen die Texte ja stehen, also in Perl isses die POD und was wäre Perl ohne POD?

Was ich damit sagen will, wenn dir was fehlt, bau es dir, bei Perl hat ja auch jemand was gebaut, weils gefehlt hat.

Wenn die Texte vorliegen, kein Thema: perldoc -f, die Texte sind aus der POD extrahiert.

Das hat aber generell mal nicht mit der Programmiersprache zu tun sondern mit Angebot und Nachfrage. Wenn ich per Apigen ne Doku erzeuge, ist die Doku halt so gut wie der Programmierer den Code geschrieben hat, gleiches gilt für Perldoc.

Vor vielen Jahren (1996) habe ich mal ein bischen mit Delphi programmiert, mein Ziel war ein CD-Player mit DB-Anbindung zum Speichern Title/Interpret und CD-Wiedererkennung. Das habe ich geschafft, maßgeblich dafür war die vorzügliche Dokumentation per Windows-Help-Dateien zur Programmiersprache Pascal mit der ich bis dahin und später nie wieder was zu tun hatte.

Es muss nicht der Editor sein oder die Kommandozeile, wo die Hilfe herkommt, aber sie sollte schon als Packungsbeilage vorhanden und unabhängig von einer Internetverbindung sein.

SELFHTML ist auch ein gutes Beispiel, mann, Alter, was haben wir das kopiert, damit es lokal verfügbar und stets griffbereit ist :)

Btw., neben der POD gibts in Perl die Doku auch in HTML und die wird automatisch ergänzt, wenn bspw. ein Modul mit ppm install Astro::Coord installiert wird, genauso wie bei einer Installation von CPAN, i.d.R. ist die POD in Moduldateien eingebettet und Programme zum Extrahieren der POD (pod2text, pod2latex...) liegen in bin/

H.

[tami]

hi hotti,

mit dem SciTE ging das mit Windows, dort wurde in der (PHP).chm (oder wie das heitß/hieß) dann (ich glaube sogar es war die selfhtml-doku) nach dem Begriff gesucht. War praktisch für einen Anfänger. Das ließ sich aber auch so modizieren, dass man mit dem unterlegten Wort in die php.net-Suchte hüpfen konnte (unter Linux).

mfg

tami

[M.]

Mahlzeit,

Es muss nicht der Editor sein oder die Kommandozeile, wo die Hilfe herkommt, aber sie sollte schon als Packungsbeilage vorhanden und unabhängig von einer Internetverbindung sein.

Und was hindert dich, die Doku von PHP runterzuladen?
Dass du damit auf die Suchfunktion verzichtest, ist natürlich Geschmacksache. Allerdings ist es IMO wesentlich komfortabler, wenn ich auf nem lokalen Webserver einen kompletten Spiegel einrichte.

Wie das geht ist wunderbar beschrieben: http://www.php.net/mirroring.php

Ich persönlich sehe absolut keinen Vorteil von Perl gegenüber PHP in dieser Hinsicht. Und wie erwähnt, wenn ich mit Perl programmiere, hab ich trotzdem die Doku im Browser offen, da es einfach komfortabler ist. Kommandozeile ist was feines, aber in diesem Fall macht sie nicht wirklich Sinn.

[Sven Rautenberg]

Moin!

SELFHTML ist auch ein gutes Beispiel, mann, Alter, was haben wir das kopiert, damit es lokal verfügbar und stets griffbereit ist :)

PHP: http://php.net/download-docs.php

q.e.d.

- Sven Rautenberg

[hotti]

PHP: http://php.net/download-docs.php

ausgepackt 55 MB HTML, das ist ja ein richtiger BLOB.

q.e.d.

Das q steht für Quantity, vermute ich.

[M.]

Mahlzeit,

ausgepackt 55 MB HTML, das ist ja ein richtiger BLOB.

Ist das dein Ernst? Erst bemängelst du die fehlende Möglichkeit, dir die Doku offline verfügbar zu haben und dann ist es dir zuviel Doku?
Also da liegt der Verdacht verdammt nah, dass du nur versuchst, OHO gegenüber Perl schlecht zu machen. Wenn dem nicht so ist, lass es mich verstehen, wo dein Problem liegt.

[hotti]

ausgepackt 55 MB HTML, das ist ja ein richtiger BLOB.

Ist das dein Ernst?

Absolut. Ich kann Dir nicht einmal sagen, wann mein FF diese Datei vollständig geladen hätte, weil ich das abgebrochen habe.

Erst bemängelst du die fehlende Möglichkeit, dir die Doku offline verfügbar zu haben und dann ist es dir zuviel Doku?

Ein BLOB ist keine Dokumentation.

Also da liegt der Verdacht verdammt nah, dass du nur versuchst, OHO gegenüber Perl schlecht zu machen. Wenn dem nicht so ist, lass es mich verstehen, wo dein Problem liegt.

Problematisch erscheint mir eher der Aufwand, diesen BLOB aktuell zu halten (Porter- wie Leserseitig), zumal sich gerade bei den ungezählten Built-in-Funktionen ständig was ändert.

[M.]

Mahlzeit,

Absolut. Ich kann Dir nicht einmal sagen, wann mein FF diese Datei vollständig geladen hätte, weil ich das abgebrochen habe.

Und weil du nicht in der Lage bist, auf den Link zu klicken, über dem steht "Many HTML files", ist die Doku schuld?

Ein BLOB ist keine Dokumentation.

Und Lesen ist eine Kunst, die ich dir bisher zugetraut hab.

Also da liegt der Verdacht verdammt nah, dass du nur versuchst, OHO gegenüber Perl schlecht zu machen. Wenn dem nicht so ist, lass es mich verstehen, wo dein Problem liegt.

Obige und folgende Aussage(n) von dir bestätigt meine obige Annahme. Du nimmst den Download, der mit Sicherheit Probleme macht und verwendest ihn zum Schlechtmachen. Traurig, wenn du das nötig hast. Perl hat das nicht nötig, ist ne tolle und mächtige Sprache. Wenn du das nötig hast, ist das ein Armutszeugnis für dich.

Problematisch erscheint mir eher der Aufwand, diesen BLOB aktuell zu halten (Porter- wie Leserseitig), zumal sich gerade bei den ungezählten Built-in-Funktionen ständig was ändert.

Du hast meinen Link dazu gar nicht gelesen, oder? Da steht genau drin, wie du deinen lokalen Mirror automatisch aktuell halten kannst.

[Whouzuo]

Perl hat das nicht nötig, ist ne tolle und mächtige Sprache. Wenn du das nötig hast, ist das ein Armutszeugnis für dich.

http://www.zehn.de/toll-6442646-6

[hotti]

hi,

Obige und folgende Aussage(n) von dir bestätigt meine obige Annahme. Du nimmst den Download, der mit Sicherheit Probleme macht und verwendest ihn zum Schlechtmachen.

Das ist und macht sich von selbst schlecht. Und wie ich schrieb: Für die Porter ist das auch schwer zu pflegen.

Du hast meinen Link dazu gar nicht gelesen, oder? Da steht genau drin, wie du deinen lokalen Mirror automatisch aktuell halten kannst.

Das ist schon besser. Noch besser finde ich jedoch die Lösung, wie in Perl gemacht, eine eingebettete Dokumentation in einem portablen Dateiformat mit dazugehörigen Tools zum Konvertieren in andere Formate (text, latex, html). Auf ein paar Schalter für perldoc habe ich ja auch schon hingewiesen, da gibt es noch mehr.

Die Vorzüge dieser Art von Dokumentation, für die es auch man-Pages gibt (Linux & Co), kannst Du allerdings erst richtig kennen und schätzenlernen, wenn Du damit arbeitest, online wie offline.

Viele Grüße!

[M.]

Mahlzeit,

Das ist schon besser. Noch besser finde ich jedoch die Lösung, wie in Perl gemacht, eine eingebettete Dokumentation in einem portablen Dateiformat mit dazugehörigen Tools zum Konvertieren in andere Formate (text, latex, html). Auf ein paar Schalter für perldoc habe ich ja auch schon hingewiesen, da gibt es noch mehr.

Und das die Doku, die eher eine geringe Anzahl Anwender überhaupt benötigt, immer mitgeschleift wird, ist für dich kein Nachteil?
Ich sehe darin einen massiven Nachteil. Ich will das, was ich brauche einzeln laden können und nicht, dass es mir aufgezwungen wird. Ich stehe nunmal auf Selbstbestimmung.

Die Vorzüge dieser Art von Dokumentation, für die es auch man-Pages gibt (Linux & Co), kannst Du allerdings erst richtig kennen und schätzenlernen, wenn Du damit arbeitest, online wie offline.

Ich arbeite mit Manpages, wenn ich grad keine online-Doku verfügbar habe. Ich ich weiss es nicht zu schätzen, dass die Bedienung wesentlich komplizierter als im Browser ist. Manpages sind nur dann sinnvoll, wenn ein Rechner keine grafische Oberfläche hat.

Ich lass dir ja deine Meinung, aber offensichtliche Nachteile (zusätzliche Dateigrösse für evtl. nicht benötigte Doku) als Vorteil verkaufen zu wollen, ist entweder unüberlegt oder ein Steinzeitgedanke.

[Der Martin]

Hallo,

PHP: http://php.net/download-docs.php
ausgepackt 55 MB HTML, das ist ja ein richtiger BLOB.

ich weiß ja nicht, was du runtergeladen hast; bei mir waren's 8MB Download, und etwa 75MB nach dem Entpacken (HTML chunked, .tar.gz).

Das q steht für Quantity, vermute ich.

Was mir im Vergleich zur Online-Doku fehlt, ist die Suchfunktion, und die User-Contributed Notes.

Ciao,
 Martin

[M.]

Mahlzeit,

ich weiß ja nicht, was du runtergeladen hast; bei mir waren's 8MB Download, und etwa 75MB nach dem Entpacken (HTML chunked, .tar.gz).

Er hat das "Single HTML file" runtergeladen. War für ihn wohl die einzige Möglichkeit, weiter gegen PHP zu wettern, denn andere Argumente hat er ja nicht.

[1UnitedPower]

Meine Herren!

PHP: http://php.net/download-docs.php

ausgepackt 55 MB HTML, das ist ja ein richtiger BLOB.

q.e.d.

Das q steht für Quantity, vermute ich.

Ich arbeite ja immer noch an einer Offline-Version für unser Wiki, die entpackte Version, die ich derzeit erzeugen kann umfasst 1,1 GB. Da wartet noch ein Stück Arbeit. Das größere Problem sind aber derzeit Darstellungsfehler und vereinzelte Online-Links, die sich nicht auflösen lassen.

[Matthias Apsel]

Om nah hoo pez nyeetz, 1UnitedPower!

Ich arbeite ja immer noch an einer Offline-Version für unser Wiki,

Cool.

die entpackte Version, die ich derzeit erzeugen kann umfasst 1,1 GB.

Nicht cool.

Da wartet noch ein Stück Arbeit.

Es braucht keine Versionshistorie offline zur Vefügung gestellt zu werden, also alles was »&oldid=« im Link hat, braucht nicht abgegrast zu werden.

Seiten lassen sich ja einfach als XML exportieren. Wenn man die Seiten der Kategorie CSS einmal inklusive und einmal exklusive aller Versionen exportiert, dann ist das Verhältnis der Dateigrößen 845kB : 22.031kB.

Matthias

[1UnitedPower]

Meine Herren!

just stumbled upon: http://technosophos.com/2014/05/14/5-strengths-of-php.html

Meh, der Artikel ist grauenhaft einseitig. Die Kritik an PHPs Arrays ist dem Autor offensichtlich bekannt. Wir reden von Inkonsistenzen der Array-Funktionen, das Needle-Haystack-Problem erwähnt der Autor ja selber. Es geht um eine nervig-lange Literal-Schreibweise, zumindest dieses Problem wird von neueren PHP-Versionen behoben. Es geht um den prozeduralen Programmierstil, der einem von Arrays aufgezwungen wird – natürlich gibt es auch die ArrayObject-Klasse (super Name btw.), aber die Klasse ist so unvollständig wie meine nicht-existente Briefmarkensammlung. All die funktionalen Methoden array_walk, array_reduce, array_map usw. die der Autor selber feiert, fehlen in dieser Klasse. Es geht darum, dass Programmier-Konzepte gemischt werden, PHPs Arrays sind geordnete Hashmaps, auch das weiß der Autor, und das sorgt gemeinhin für sehr viel Verwirrung. Und alles womit er dieser Kritik entgegnet, ist ernsthaft folgender Satz?

except that PHP arrays are just so darn useful.

Natürlich sind PHPs Arrays irgendwo nützlich, in einer Programmiersprache in der es keine Alternative gibt, keine Sets, keine Maps, keine Buffer, keine Objekt-Literale, keine native JSON-Unterstützung.

Das nächste große Geschütz ist eine naive Milchmädchen-Rechnung: PHP ist so verbreitet, das wird schon seine Gründe haben. Wenn alle von der Brücke springen… usw… Außerdem wäre es doch sehr viel interessanter zu wissen, welche Seiten Abstand von PHP genommen haben, und wieso. Mein Gesamt-Eindruck ist, dass sich Seiten, die sehr viel Benutzerinteraktion erfordern (insbesondere also Web-Apps) sich vermehrt von PHP abwenden.

Die Dokumentation ist wirklich ziemlich vollständig, da gebe ich dem Autor ausnahmsweise recht. Aber auch da kann man kritisieren, es gibt keinen offiziellen PHP-Standard, immer wenn es um die wirklich trickigen Bits geht, ist man verlassen, muss man sich selber durchbeißen.

"Surprisingly Good Standard Libraries". Schon wieder ist der Autor offensichtlich im Bilde über die herrschende Kritik und dann folgt eine lausige Argumentation nach dem Schema "Aber wenn wir die Kritik mal außer Acht lassen, und uns nur die schönen Aspekte angucken, dann gibt es nur schöne Aspekte".

Und dann als Krönung dieser Satz:
PHP doesn't crash.
"It fails silently" rumort es da in mir.
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.

Der Artikel liest sich wie die sehr verzweifelte Rechtfertigung eines PHP-Entwicklers, nicht wie eine differenzierte Diskussion der Programmiersprachen-Features. Ich bin kein Fan von PHP, aber ich glaube auch, dass PHP seine guten Aspekte hat, Closures, Generators und die Reflect-API um mal ein paar Beispiele zu nennen.

[Klawischnigg]

Hi there,

Meine Herren!

ja eh...;)

zu allem von Dir Moniertem möcht ich doch was anmerken: den besten Grund, PHP zu verwenden hat der Autor gar nicht erwähnt und der entgeht vielen Kritikern wie Dir, die das eher von einer akademischen Seite sehen - man kann mit PHP in sehr kurzer Zeit (damit meine ich nicht nach kurzer Einarbeitung!) Webseiten und auch Applikationen erstellen. Das ist wichtig, wenn man Geld dafür nimmt.
Man mag jetzt Argumente einwerfen, von wegen Wartbarkeit und nicht-optimale Lösung etc. ect. aber das interessiert im Grunde zurecht niemanden. Ich meine, hier geht es nicht um die Steuerung von Kernkraftwerken oder um Operationsroboter sondern um Anwendung, von denen es in der Mehrzahl ohnehin besser gewesen wäre, sie wären nie geschrieben worden. Und die, so meine Erfahrung, auch keiner Wartung bedürfen, weil sich die Auftraggeber kindlich darüber so freuen, daß sie auf Google "gefunden" werden, wenn sie den genauen Wortlaut ihrer Domain eingeben, daß sie keinen Bedarf für Verbesserungen sehen.
Was ich eigentlich damit sagen wollte, man muss eben auch den praktischen Aspekt betrachten, und da steckt PHP eigentlich alle anderen (ähnlichen) Programmiersprachen ein...

[tami]

hi 1UnitedPower,

Meine Herren!

just stumbled upon: http://technosophos.com/2014/05/14/5-strengths-of-php.html

Meh, der Artikel ist grauenhaft einseitig. Die Kritik an PHPs Arrays ist dem Autor offensichtlich bekannt. Wir reden von Inkonsistenzen der Array-Funktionen, das Needle-Haystack-Problem erwähnt der Autor ja selber. Es geht um eine nervig-lange Literal-Schreibweise, zumindest dieses Problem wird von neueren PHP-Versionen behoben. Es geht um den prozeduralen Programmierstil, der einem von Arrays aufgezwungen wird

Kapiere ich nicht, wie Arrays einen prozeduralen Programmierstil aufzwingen. Wie geht das und wie geht das besser, anders?

Natürlich sind PHPs Arrays irgendwo nützlich, in einer Programmiersprache in der es keine Alternative gibt, keine Sets, keine Maps, keine Buffer, keine Objekt-Literale, keine native JSON-Unterstützung.

Auch hier kapiere ich nicht den Vorteil, den ein JSON-Objekt gegenüber einem Array hat oder haben soll. Vermutlich fehlt mir die Erfahrung. 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?

Das nächste große Geschütz ist eine naive Milchmädchen-Rechnung: PHP ist so verbreitet, das wird schon seine Gründe haben. Wenn alle von der Brücke springen… usw… Außerdem wäre es doch sehr viel interessanter zu wissen, welche Seiten Abstand von PHP genommen haben, und wieso. 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).

Die Dokumentation ist wirklich ziemlich vollständig, da gebe ich dem Autor ausnahmsweise recht. Aber auch da kann man kritisieren, es gibt keinen offiziellen PHP-Standard, immer wenn es um die wirklich trickigen Bits geht, ist man verlassen, muss man sich selber durchbeißen.

Und was ist da zB. so richtig trickyBit?

"Surprisingly Good Standard Libraries". Schon wieder ist der Autor offensichtlich im Bilde über die herrschende Kritik und dann folgt eine lausige Argumentation nach dem Schema "Aber wenn wir die Kritik mal außer Acht lassen, und uns nur die schönen Aspekte angucken, dann gibt es nur schöne Aspekte".

Und dann als Krönung dieser Satz:
PHP doesn't crash.
"It fails silently" rumort es da in mir.

Tut es das? Ich kenne nur die Fehlermeldungen.

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. Zu Golang finde ich dann aber Leaving Go.

Der Artikel liest sich wie die sehr verzweifelte Rechtfertigung eines PHP-Entwicklers, nicht wie eine differenzierte Diskussion der Programmiersprachen-Features. Ich bin kein Fan von PHP, aber ich glaube auch, dass PHP seine guten Aspekte hat, Closures, Generators und die Reflect-API um mal ein paar Beispiele zu nennen.

Weiß immer noch nicht, was Closures in PHP bringen sollen. Private Variablen habe ich auch so und Konflikte mit externen Skripten gibt es auch nicht ...;

Ansonstn (http://blog.someguy123.com/dispelling-the-hate-against-php/): "Conclusion

The PHP ecosystem has evolved from the horrid mess it was a decade ago. 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."

mfg

tami

Ps. http://de.wikipedia.org/wiki/Laravel
"Laravel ist ein Open-Source-PHP-Web-Application-Framework, das dem MVC-Muster folgt. Es wurde 2011 von Taylor Otwell initiiert. Die Laravel-Community wird von Cartalyst gesponsert, einem Unternehmen, das Add-ons für Laravel und andere Frameworks herstellt und verkauft. Laut einem Artikel von Bruno Skvorc auf der Website sitepoint.com ist Laravel das zukunftsträchtigste Framework 2014"

[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.

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

[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

[1UnitedPower]

Meine Herren!

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.

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

Zum Beispiel wegen Vererbung. Wenn ich eine etwas spezifischere Klasse haben möchte, zum Beispiel ein Array, das keine Mehrfachvorkommen erlaubt, also eine Menge, könnte ich einfach von Array eine Klasse ableiten, ein paar Methoden überschreiben, vielleicht ein paar neue hinzufügen und gut ist.

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Für alle nicht Hardcore-Funktionale-Programmierung-Gurus, ist die erste Variante denke ich einfacherer zu lesen.

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.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Ich finde es schlicht expressiver zu wissen, um welche mathematische Struktur es sich handelt. Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen. Noch schlimmer, wenn dann nicht mal die expressiven Methoden wie Map/Reduce benutzt werden, sondern ein Dschungel von Schleifen mir entgegenspringt. Bei einem map-Aufruf weiß ich, dass da wieder ein Array bei raus kommt, mit genau der gleichen Anzahl an Elementen, bei einem reduce weiß ich, dass da irgendetwas aggregiert wird. Das ist eine enorme Lese-Hilfe.

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 lese den Satz so:
Unterm Strich ist Nebenläufigkeit und non-blocking I/O in JavaScript und Go dennoch einfacher zu programmieren.

[Matthias Apsel]

Om nah hoo pez nyeetz, 1UnitedPower!

[…] zum Beispiel ein Array, das keine Mehrfachvorkommen erlaubt, also eine Menge, […]

In der Mathematik darf eine Menge auch Elemente mehrfach enthalten. Das kommt auch recht häufig vor, zum Beispiel bei Messwerten. Das und die geforderte Endlichkeit unterscheidet sie von der Datenstruktur Menge.

Matthias

[1UnitedPower]

Meine Herren!

Om nah hoo pez nyeetz, 1UnitedPower!

[…] zum Beispiel ein Array, das keine Mehrfachvorkommen erlaubt, also eine Menge, […]

In der Mathematik darf eine Menge auch Elemente mehrfach enthalten. Das kommt auch recht häufig vor, zum Beispiel bei Messwerten. Das und die geforderte Endlichkeit unterscheidet sie von der Datenstruktur Menge.

Jein. So unterscheidet sich die Auffassung der Physiker von der der Mathematiker. Streng genommen führen Physiker aber auch Mengen von Messpunkten, nicht -werten. Also zum Beispiel ein Tupel aus Zeitpunkt und Messwert. Bei äquidistanter Verteilung auf der Zeitachse, oder wenn die Zeitachse einfach unwesentlich ist, benutzen Physiker gerne ihre Kurzschreibweise.

[Matthias Apsel]

Om nah hoo pez nyeetz, 1UnitedPower!

Jein. So unterscheidet sich die Auffassung der Physiker von der der Mathematiker. Streng genommen führen Physiker aber auch Mengen von Messpunkten, nicht -werten. Also zum Beispiel ein Tupel aus Zeitpunkt und Messwert. Bei äquidistanter Verteilung auf der Zeitachse, oder wenn die Zeitachse einfach unwesentlich ist, benutzen Physiker gerne ihre Kurzschreibweise.

Nicht nur streng genommen. Ein Messergebnis ist immer ein Tupel, mindestens ein geordnetes Paar = 2-Tupel. Allerdings kann es da auch identische Paare geben, etwa wenn man den Zusammenhang zwischen Spannung und Stromstärke untersucht.

Matthias

[tami]

hi 1UnitedPower,

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

Zum Beispiel wegen Vererbung. Wenn ich eine etwas spezifischere Klasse haben möchte, zum Beispiel ein Array, das keine Mehrfachvorkommen erlaubt, also eine Menge, könnte ich einfach von Array eine Klasse ableiten, ein paar Methoden überschreiben, vielleicht ein paar neue hinzufügen und gut ist.

Deswegen aber würde Facebook nicht Hack entwickeln, denke ich mal.

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Method-Chaining geht aber auch in PHP. Und klar, es muss ersterer Code umgesetzt werden.

$produkte->get("Preis")->reduce($sum);

Wenn das so überhaupt Sinn macht. Eine Produktklasse hätte vielleicht auch schlicht eine "getTotal()"-Methode.

Ich erkenne auch hier nicht wirklich den Nutzen, den es ja haben muss, wenn FB in Hack dafür extra "Collections" "erfindet". Ich sage nicht, dass es keinen gibt. Es muss ja ne Menge Arbeit sparen, sonst würden sie es nicht machen.

Für alle nicht Hardcore-Funktionale-Programmierung-Gurus, ist die erste Variante denke ich einfacherer zu lesen.

Lesbarkeit ist ein Muss, keine Frage.

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.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Ich finde es schlicht expressiver zu wissen, um welche mathematische Struktur es sich handelt. Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen. Noch schlimmer, wenn dann nicht mal die expressiven Methoden wie Map/Reduce benutzt werden, sondern ein Dschungel von Schleifen mir entgegenspringt. Bei einem map-Aufruf weiß ich, dass da wieder ein Array bei raus kommt, mit genau der gleichen Anzahl an Elementen, bei einem reduce weiß ich, dass da irgendetwas aggregiert wird. Das ist eine enorme Lese-Hilfe.

Nu, ich vergleiche es jetzt erstmal mit einem "Objekt", oder einer Zeile einer Tabelle.

Man hat doch ansonsten aber in PHP immer die Möglichkeit, Funktionalität in einer Klasse zu ergzeugen. Vielleicht ist ja "Collections" sowas wie eine Helferklasse? Oder ist das ein neuer Datentyp in Hack?

mfg

tami

[Whouzuo]

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Method-Chaining geht aber auch in PHP. Und klar, es muss ersterer Code umgesetzt werden.

$produkte->get("Preis")->reduce($sum);

Wenn das so überhaupt Sinn macht. Eine Produktklasse hätte vielleicht auch schlicht eine "getTotal()"-Methode.

Du hast das nicht ganz verstanden. Du schreibst keine "Produkte"-Klasse, du schreibst eine "Produkt"-Klasse, die genau ein Produkt beschreibt. Dann machst du eine Liste, in die du mehrere dieser Produkte (Produkt-Objekte) reinschmeißt. Irgendwann willst du dann den Preis bestimmen und das geht so wie 1UnitedPower beschrieben. Eine "Produkte"-Klasse wie in deinem Beispiel das $produkte braucht es dafür gar nicht (das wäre sogar eher schädlich).

Ich erkenne auch hier nicht wirklich den Nutzen, den es ja haben muss, wenn FB in Hack dafür extra "Collections" "erfindet". Ich sage nicht, dass es keinen gibt. Es muss ja ne Menge Arbeit sparen, sonst würden sie es nicht machen.

Ganz einfach: damit nicht jeder einzelne der tausenden PHP Programmierer so wie du eben die Collections sozusagen für sich selbst als Klassen (und dann noch schlecht wiederverwendbar) nachbauen muss. =)

[tami]

hi Whouzuo,

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Method-Chaining geht aber auch in PHP. Und klar, es muss ersterer Code umgesetzt werden.

$produkte->get("Preis")->reduce($sum);

Wenn das so überhaupt Sinn macht. Eine Produktklasse hätte vielleicht auch schlicht eine "getTotal()"-Methode.

Du hast das nicht ganz verstanden. Du schreibst keine "Produkte"-Klasse, du schreibst eine "Produkt"-Klasse, die genau ein Produkt beschreibt. Dann machst du eine Liste, in die du mehrere dieser Produkte (Produkt-Objekte) reinschmeißt. Irgendwann willst du dann den Preis bestimmen und das geht so wie 1UnitedPower beschrieben. Eine "Produkte"-Klasse wie in deinem Beispiel das $produkte braucht es dafür gar nicht (das wäre sogar eher schädlich).

https://forum.selfhtml.org/?t=217720&m=1496513

Ich erkenne auch hier nicht wirklich den Nutzen, den es ja haben muss, wenn FB in Hack dafür extra "Collections" "erfindet". Ich sage nicht, dass es keinen gibt. Es muss ja ne Menge Arbeit sparen, sonst würden sie es nicht machen.

Ganz einfach: damit nicht jeder einzelne der tausenden PHP Programmierer so wie du eben die Collections sozusagen für sich selbst als Klassen (und dann noch schlecht wiederverwendbar) nachbauen muss. =)

https://forum.selfhtml.org/?t=217720&m=1496531

mfg

tami

[Whouzuo]

Du hast das nicht ganz verstanden. Du schreibst keine "Produkte"-Klasse, du schreibst eine "Produkt"-Klasse, die genau ein Produkt beschreibt. Dann machst du eine Liste, in die du mehrere dieser Produkte (Produkt-Objekte) reinschmeißt. Irgendwann willst du dann den Preis bestimmen und das geht so wie 1UnitedPower beschrieben. Eine "Produkte"-Klasse wie in deinem Beispiel das $produkte braucht es dafür gar nicht (das wäre sogar eher schädlich).

https://forum.selfhtml.org/?t=217720&m=1496513

[http://forum.de.selfhtml.org/?t=217720&m=1496516]

Ich erkenne auch hier nicht wirklich den Nutzen, den es ja haben muss, wenn FB in Hack dafür extra "Collections" "erfindet". Ich sage nicht, dass es keinen gibt. Es muss ja ne Menge Arbeit sparen, sonst würden sie es nicht machen.

Ganz einfach: damit nicht jeder einzelne der tausenden PHP Programmierer so wie du eben die Collections sozusagen für sich selbst als Klassen (und dann noch schlecht wiederverwendbar) nachbauen muss. =)

https://forum.selfhtml.org/?t=217720&m=1496531

Genau. =)

[1UnitedPower]

Meine Herren!

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

Zum Beispiel wegen Vererbung. Wenn ich eine etwas spezifischere Klasse haben möchte, zum Beispiel ein Array, das keine Mehrfachvorkommen erlaubt, also eine Menge, könnte ich einfach von Array eine Klasse ableiten, ein paar Methoden überschreiben, vielleicht ein paar neue hinzufügen und gut ist.

Deswegen aber würde Facebook nicht Hack entwickeln, denke ich mal.

Nein, das würden sie sicher nicht. Das wollte ich auch nicht vermitteln. Dir ist sicher aufgefallen, dass ich auf deinen längeren Hack-Abschnitt gar nicht eingegangen bin, schlicht weil ich mich in dem Thema nicht genug auskenne. Ich möchte dir nur die bestehende Kritik an PHPs Arrays erläutern. Wenn ich den Finger erhebe und die nachfragst, sollte ich  schließlich in der Lage sein, meine Kritik verteidigen zu können ;)

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

Method-Chaining geht aber auch in PHP. Und klar, es muss ersterer Code umgesetzt werden.
$produkte->get("Preis")->reduce($sum);

Ja für Objekte geht das. Arrays sind in PHP leider keine Objekte.

Wenn das so überhaupt Sinn macht. Eine Produktklasse hätte vielleicht auch schlicht eine "getTotal()"-Methode.

Die müsste ja auch irgendwie implementiert werden. Beispiele hinken natürlich, gerade in der Programmierung, sie werden immer geschaffen um einen konkreten Sachverhalt zu illustrieren. Einfach eine fertige Methode "getTotal()" zu benennen hätte mir nicht bei der Veranschaulichung geholfen.

Ich erkenne auch hier nicht wirklich den Nutzen, den es ja haben muss, wenn FB in Hack dafür extra "Collections" "erfindet". Ich sage nicht, dass es keinen gibt. Es muss ja ne Menge Arbeit sparen, sonst würden sie es nicht machen.

Wie gesagt, ich kenne mich mit Hack nicht genügend aus. Aber scheinbar herrschte Unzufriedenheit über die Natur von PHP Arrays. Die Kritik an den Arrays besteht und lässt sich nicht abstreiten, das war es, was ich an dem ursprünglichen Artikel so heftig kritisiert habe: Der Autor weiß, dass Kritik besteht und tut sie ab mit einem "Arrays sind so verflixt nützlich". Das ist inhaltlich völlig wertlos. Meine Kritik richtete sich ja vor allem gegen den Artikel, nicht gegen PHP selbst. Da wäre mir noch schlechtere Features in den Sinn gekommen.

Man hat doch ansonsten aber in PHP immer die Möglichkeit, Funktionalität in einer Klasse zu ergzeugen. Vielleicht ist ja "Collections" sowas wie eine Helferklasse? Oder ist das ein neuer Datentyp in Hack?

Nur nochmal fürs Protokoll, von Hack und den Beweggründen von Facebook weiß ich nicht viel, deswegen möchte ich mich nicht an diesem Teil der Diskussion beteiligen. Aber ich werde mir die Sprache bei Zeit mal zu Gemüte führen.

[molily]

Hallo,

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Für alle nicht Hardcore-Funktionale-Programmierung-Gurus, ist die erste Variante denke ich einfacherer zu lesen.

Man sollte noch einmal prozedural und funktional unterscheiden. Das obige Beispiel ist eher funktional, da Werte und Funktionen im Vordergrund stehen. Funktionen bilden Werte auf andere Werte ab und geben diese i.d.R. ohne Nebeneffekte zurück. Das kann soweit gehen, dass Datenstrukturen unveränderbar sind und jede Operation einen neuen Wert erzeugt.

Funktionale Programmierung ist in vielen multiparadigmatischen Sprachen möglich, darunter auch JavaScript. Lodash hatte ich als Beispiel schon genannt. Verwirrend ist das höchstens bei dynamisch typisierten Sprachen, weil nicht klar ist, für welche Typen Funktionen definiert sind und was die Typen der Rückgabewerte sind. Dass map eine Liste mit n Elementen auf eine Liste mit n Elementen abbildet, muss man in der objektorientierten wie bei der funktionalen Schreibweise wissen.

Jedenfalls ist die PHP-Standard-Library nicht funktional, sondern größtenteils prozedural, weil sie die Eingabewerte oft »destruktiv« ändert. Und die eingebauten PHP-Funktionen sind keine First-Class-Objects. Im »Userspace« gibt es immerhin mittlerweile Closures. Siehe auch functional-php.

Mathias

[Sven Rautenberg]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Ja, natürlich ist das Cheaten. ;)  Ich will illustrieren, dass ihr eventuell (aber wirklich nur eventuell) auf einem Low-Level-Niveau der Bearbeitung von Datenstrukturen Recht habt, aber ab einem gewissen Abstraktionsgrad wird es irrelevant, wie schön lesbar die Low-Level-Operationen sind, weil man vermutlich keine komplexe Applikation mehr auf Assembler-Niveau schreiben würde.

Und an der Stelle ist es dann interessant, welche eigenen, nutzbringenden höheren Funktionalitäten man braucht und anbietet, und wie sich diese benutzen lassen.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

Und auf diesem Level gedacht wird man sich beispielsweise ausdenken, dass es aus irgendeinem Business-Grund eine Liste von Produkten gibt, bei der jedes Produkt einen Preis hat, und es gibt einen Business-Grund dafür, dass man den Gesamtpreis dieser Produktliste wissen will.

Also ist  gesamt = produkte.gesamtpreis(); ein legitimer Ansatz auf hohem Abstraktionsgrad, ohne dass man konkret die Berechnungsvorschrift bestimmen muss - aber es wird vermutlich irgendwas mit Addition und Multiplikation sein.

Solange man nicht "die gesamte Welt" in seiner Produktliste hat und deren Preis bestimmen will, sondern es sich um realististe Warenkörbe in Shops handelt, dürfte der theoretisch erzielbare Parallelisierungsvorteil von Map-Reduce gegenüber iterativen Ansätzen nicht ins Gewicht fallen.

Ich finde es schlicht expressiver zu wissen, um welche mathematische Struktur es sich handelt.

Wenn man mit mathematischen Strukturen operiert, ist das sicherlich schlau.

Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen.

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Noch schlimmer, wenn dann nicht mal die expressiven Methoden wie Map/Reduce benutzt werden, sondern ein Dschungel von Schleifen mir entgegenspringt. Bei einem map-Aufruf weiß ich, dass da wieder ein Array bei raus kommt, mit genau der gleichen Anzahl an Elementen, bei einem reduce weiß ich, dass da irgendetwas aggregiert wird. Das ist eine enorme Lese-Hilfe.

Du kannst natürlich schlechten, weil komplexen, Code als Negativbeispiel heranziehen, um gegen PHP-Arrays zu argumentieren. Ich stelle die Frage, ob man nicht genauso in einer Schlingpflanzenwelt von Closures und Callbacks zugrundegehen kann.

- Sven Rautenberg

[Whouzuo]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Du wirst aber keine Klasse haben, "produkte" heißt oder? ;)
Warenkorb.gesamtpreis() könnte ich mir noch vorstellen, aber das ist semantisch dann auch etwas anderes. Denn nicht immer stellt eine Liste an Produkten einen Warenkorb dar.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

...und diese ist fest mit den Datenstrukturen gekoppelt. Denn Datenstrukturen sollen ja Dinge aus der realen Welt abstrakt repräsentieren - sonst bräuchten wir sie nicht. Und Dinge, die in der realen Welt sehr oft vorkommen, werden eben als gängige Datenstrukturen von der Sprache bereitgestellt, sodass sie nicht mehr selbst gebastelt werden müssen. Dazu gehören Listen, Maps und anderes.

Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen.

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Wenn man das tut, dann ist es auch okay. Nur leider, muss man sich dann z.B. "normalen" Listen erstmal selbst definieren anstatt arrays dafür benutzen zu können. Trotzdem stimme ich dir in diesem ersten von dir genannten Punkt zu.

[Sven Rautenberg]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Du wirst aber keine Klasse haben, "produkte" heißt oder? ;)

'...haben, DIE "produkte" heißt, oder?'

"produkte" ist im Sinnzusammenhang der Variablenname, nicht der Klassenname.

Warenkorb.gesamtpreis() könnte ich mir noch vorstellen, aber das ist semantisch dann auch etwas anderes. Denn nicht immer stellt eine Liste an Produkten einen Warenkorb dar.

Richtig, aber genau das ist mein Kernpunkt: Wenn man darüber redet, in welchem Sinnzusammenhang eine Ansammlung von mehreren Produkten zu sehen ist, und was man damit so alles machen kann, dann ist genau das das Argument gegen generische Collections ohne sinnvolle Methoden, die eben genau diesen Sinnzusammenhang widerspiegeln.

Listen von Produkten - das könnte in einem Shop ein Warenkorb sein. In diesem Sinnzusammenhang kann ein Produkt ein oder mehrere Male im Warenkorb liegen, wird einen Preis haben und es wird sinnvoll sein, den Warenkorb nach seinem Gesamtpreis zu fragen.

Listen von Produkten - das könnte auch einfach eine Teilmenge der Produkte in einer bestimmten Shop-Kategorie sein, die man sich anzeigen lassen will. In diesem Zusammenhang ist ein Gesamtpreis absolut sinnlos, ebenso eine Anzahl. Allerdings wird man wohl besonderen Einfluss auf die Reihenfolge nehmen wollen, denn Produkte in solchen Listenansichten lassen sich gerne nach diversen Kriterien sortieren, z.B. nach Preis, Beliebtheit, Bewertung oder Gewicht.

Listen von Produkten - das wird nach dem Klick auf den Bestellbutton eben kein Warenkorb, sondern eine Order sein, die zwar immer noch Anzahl, Preis und Gesamtpreis umfasst, jetzt aber auch Dinge wie Inventar, Lieferstatus, Retouren etc. - das aber individuell pro Produkt. Die Order selbst dürfte hingegen noch Dinge wie Zahlungsstatus, Lieferstatus etc. enthalten.

Natürlich kann man alle drei Listen von Produkten mit ein-und-derselben Collection realisieren, die einfach nur anbietet, mit Map-Reduce die passenden Funktionen auf diese Liste zu werfen, um jeweils unterschiedliche Ergebnisse zu erzielen. In einfachen Software-Konstruktionen dürfte das vermutlich auch ein schneller Weg sein. In komplexer Business-Software funktioniert das eher nicht. Da muss man sich nicht nur Gedanken machen, was ein Produkt überhaupt ist, und was das Besondere an seiner Listenform ist. Man muss sich auch Gedanken machen, wie die einzelnen Listen ineinander zu überführen sind.

Wie wird aus einer angezeigten Produktliste ein Warenkorb? Wie wird aus einem Warenkorb eine Order? Beide Schritte machen mit der Liste von Produkten irgendetwas - und was genau, das ist vermutlich der Kern der Businesslogik, um die sich die Applikation dreht.

Insofern ist es absolut gerechtfertigt, wenn man für Businesslogik Klassen entwirft, die diese Logik in Code umsetzen, und deshalb sachgerechte Methoden anbieten, um diese Transformationen unmißverständlich umzusetzen. Beispielsweise durch $order = $customer->orders($basket);. Mit einem Kundenobject $customer, einem Warenkorbobjekt $basket und einem Orderobjekt $order (letztere enthalten jeweils eine Liste von Produkten).

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

...und diese ist fest mit den Datenstrukturen gekoppelt. Denn Datenstrukturen sollen ja Dinge aus der realen Welt abstrakt repräsentieren - sonst bräuchten wir sie nicht. Und Dinge, die in der realen Welt sehr oft vorkommen, werden eben als gängige Datenstrukturen von der Sprache bereitgestellt, sodass sie nicht mehr selbst gebastelt werden müssen. Dazu gehören Listen, Maps und anderes.

Nein, ich glaube eher nicht, dass die Businesslogik FEST mit Datenstrukturen gekoppelt ist. Tatsächlich würde ich eher glauben, dass die Businesslogik sehr fest strukturiert ist, die zugehörigen Daten aber tatsächlich einem relativ starken Wandel unterliegen können.

Beispiel: SEPA. Die konkreten Kontoverbindungsdaten haben sich ziemlich massiv geändert. Die drumherumliegende Logik einer Kontoverbindung auch. Auf höherer Ebene hingegen hat sich eigentlich nichts getan: Eine Kundenbestellung mit Zahlungsart "Abbuchung" braucht eine gültige Kontoverbindung.

Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen.

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Wenn man das tut, dann ist es auch okay. Nur leider, muss man sich dann z.B. "normalen" Listen erstmal selbst definieren anstatt arrays dafür benutzen zu können. Trotzdem stimme ich dir in diesem ersten von dir genannten Punkt zu.

Wie ich oben ausführte, will man das sogar, weil auch Listen Logiken implementieren. PHP bietet dafür auch ausreichend Basismaterial an, dass man verwenden könnte: Diverse Interfaces (Countable, Traversable, ArrayAccess) und Objekte (ArrayIterator, ArrayObject, SplFixedArray, SplObjectStorage, SplDoublyLinkedList).

Es gilt allerdings der Satz aus dem Aufhänger-Artikel: Native PHP-Arrays sind so verdammt nützlich, es gibt selten einen Grund, sie nicht zu verwenden.

- Sven Rautenberg

[Whouzuo]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Du wirst aber keine Klasse haben, "produkte" heißt oder? ;)

'...haben, DIE "produkte" heißt, oder?'

"produkte" ist im Sinnzusammenhang der Variablenname, nicht der Klassenname.

Warenkorb.gesamtpreis() könnte ich mir noch vorstellen, aber das ist semantisch dann auch etwas anderes. Denn nicht immer stellt eine Liste an Produkten einen Warenkorb dar.

Richtig, aber genau das ist mein Kernpunkt: Wenn man darüber redet, in welchem Sinnzusammenhang eine Ansammlung von mehreren Produkten zu sehen ist, und was man damit so alles machen kann, dann ist genau das das Argument gegen generische Collections ohne sinnvolle Methoden, die eben genau diesen Sinnzusammenhang widerspiegeln.

Listen von Produkten - das könnte in einem Shop ein Warenkorb sein. In diesem Sinnzusammenhang kann ein Produkt ein oder mehrere Male im Warenkorb liegen, wird einen Preis haben und es wird sinnvoll sein, den Warenkorb nach seinem Gesamtpreis zu fragen.

Richtig, aber irgendwie musst du das ganze ja innerhalb des Warenkorbs implementieren. Und dort hast du dann genau das, was oben beschrieben ist: eine Liste von Produkten und deren Gesamtpreis musst du berechnen.

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

...und diese ist fest mit den Datenstrukturen gekoppelt. Denn Datenstrukturen sollen ja Dinge aus der realen Welt abstrakt repräsentieren - sonst bräuchten wir sie nicht. Und Dinge, die in der realen Welt sehr oft vorkommen, werden eben als gängige Datenstrukturen von der Sprache bereitgestellt, sodass sie nicht mehr selbst gebastelt werden müssen. Dazu gehören Listen, Maps und anderes.

Nein, ich glaube eher nicht, dass die Businesslogik FEST mit Datenstrukturen gekoppelt ist. Tatsächlich würde ich eher glauben, dass die Businesslogik sehr fest strukturiert ist, die zugehörigen Daten aber tatsächlich einem relativ starken Wandel unterliegen können.

Mit dem "fest" meinte ich, dass eine Änderung der Businesslogik zwangsläufig mit einer Änderung der Datenstrukturen (z.B. einer Änderung von Klassen) einhergeht. Natürlich nur (bevor du jetzt wieder pingelig wirst ;), wenn auch Objekte betroffen sind oder deren Abhängigkeiten, nicht wenn sich die Mehrwertsteuer um x% erhöht.

Beispiel: SEPA. Die konkreten Kontoverbindungsdaten haben sich ziemlich massiv geändert. Die drumherumliegende Logik einer Kontoverbindung auch. Auf höherer Ebene hingegen hat sich eigentlich nichts getan: Eine Kundenbestellung mit Zahlungsart "Abbuchung" braucht eine gültige Kontoverbindung.

Aber die Repräsentation einer Kontoverbindung sieht jetzt anders aus. Wäre das nicht so, hätte auch nichts angepasst werden müssen. =)

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Wenn man das tut, dann ist es auch okay. Nur leider, muss man sich dann z.B. "normalen" Listen erstmal selbst definieren anstatt arrays dafür benutzen zu können. Trotzdem stimme ich dir in diesem ersten von dir genannten Punkt zu.

Wie ich oben ausführte, will man das sogar, weil auch Listen Logiken implementieren. PHP bietet dafür auch ausreichend Basismaterial an, dass man verwenden könnte: Diverse Interfaces (Countable, Traversable, ArrayAccess) und Objekte (ArrayIterator, ArrayObject, SplFixedArray, SplObjectStorage, SplDoublyLinkedList).

Na anscheinend nicht genug. Sonst hätte Facebook ja nichts dazugebastelt. =)

[1UnitedPower]

Meine Herren!

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Ja, natürlich ist das Cheaten. ;)

Das Beispiel hat offenbar für Verwirrung gesorgt, ich verweise einfach mal an die Erklärung, die ich tami zum selben Thema gegeben habe.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

Datenstrukturen ziehen sich durch jede Anwendungsschicht, die wird man nur schwer wegabstrahieren können. Und selbst wenn das gelingt, dann sind sie in irgendeiner Schicht relevant. Bei der Eröterung von low-level Programmiersprachen-Features ist es nicht hilfreich, nicht darüber zu sprechen und uns bewusst Gedanken zu machen, wie wir sie wegabstrahieren.

Solange man nicht "die gesamte Welt" in seiner Produktliste hat und deren Preis bestimmen will, sondern es sich um realististe Warenkörbe in Shops handelt, dürfte der theoretisch erzielbare Parallelisierungsvorteil von Map-Reduce gegenüber iterativen Ansätzen nicht ins Gewicht fallen.

Es ging mir nie um Parallelisierung, sondern um eine ausdrucksstarke Programmierweise.

Wann immer ich eine Schleife sehe:
for ( $array as $key )
Weiß ich nichts darüber, was die Schleife mit dem Array macht.

map dagegen teilt mir mit, da wird für jedes Element im Array irgendein anderer Wert berechnet.
reduce sagt mir, da wird jetzt was aggregiert.

Ich finde es schlicht expressiver zu wissen, um welche mathematische Struktur es sich handelt.

Wenn man mit mathematischen Strukturen operiert, ist das sicherlich schlau.

Auch darüber hinaus. Die Prinzipien sind auf so viele Echtwelt-Beispiele übertragbar. Lottozahlen sind Tupel. Menschenansammlungen sind Mengen. Einkaufslisten können wirklich mal als geordnete Hash-Map aufgefasst werden. Zuordnungen von Anzahlen zu Produkten und geordnet in der Reihenfolge, in der sie im Supermarkt stehen. Aber von zwei Lottoziehungen weiß ich, dass es nicht viel Sinn ergibt, sie zu vereinigen. Wenn ich in einem Quelltext lese da wird ein Tupel initialisiert, dann weiß ich im weiteren Verlauf, dass Vereinigung, Durchschnitt, Exklusion usw. keine Rolle spielen. Ich kriege einen Eindruck von der zweckmäßigen Bestimmung dieser Sammlung.

Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Aus meiner Sicht schon. Die Bedeutung verkommt zu einem Haufen irgendwas, ein Haufen erklärt sich mir nicht.

Noch schlimmer, wenn dann nicht mal die expressiven Methoden wie Map/Reduce benutzt werden, sondern ein Dschungel von Schleifen mir entgegenspringt. Bei einem map-Aufruf weiß ich, dass da wieder ein Array bei raus kommt, mit genau der gleichen Anzahl an Elementen, bei einem reduce weiß ich, dass da irgendetwas aggregiert wird. Das ist eine enorme Lese-Hilfe.

Du kannst natürlich schlechten, weil komplexen, Code als Negativbeispiel heranziehen, um gegen PHP-Arrays zu argumentieren.
Ich stelle die Frage, ob man nicht genauso in einer Schlingpflanzenwelt von Closures und Callbacks zugrundegehen kann.

Da gebe ich dir recht, Closures und Callbacks bedürfen auch ihrer eignen Patterns, um nicht zur Callback-Hell zu werden. Der Griff geht dann häufig zu Promises oder Streams. Die Kette spielt sich vor meinem inneren Auge so ab: Map/Reduce ist ein Ansatz um iterativen Spaghetti-Code zu vermeiden. Benannte Funktionen und Promises sind Heilmittel gegen die Callback-Hell.

[Der Martin]

Hallo,

[...] Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

ich habe noch nie Lotto gespielt und kenne vielleicht nicht die Feinheiten, aber: Ich dachte bisher immer, bei den Lottozahlen käme es gerade *nicht* auf die Reihenfolge bzw. Position an, weil die gezogenen Zahlen doch sowieso aufsteigend sortiert werden. Oder was hab ich da falsch verstanden?

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

Ja, aber die kann auch nur dann optimal arbeiten, wenn die gewählten Datenstrukturen zur Aufgabe passen.

Datenstrukturen ziehen sich durch jede Anwendungsschicht, die wird man nur schwer wegabstrahieren können. Und selbst wenn das gelingt, dann sind sie in irgendeiner Schicht relevant. Bei der Eröterung von low-level Programmiersprachen-Features ist es nicht hilfreich, nicht darüber zu sprechen und uns bewusst Gedanken zu machen, wie wir sie wegabstrahieren.

Ganz im Gegenteil: In Low-Level-Programmiermodellen (z.B. Assembler, bedingt auch noch C) ist es sinnvoll, wenn nicht gar nötig, die zugrundeliegenden Datenstrukturen und ihre Zusammenhänge und Abhängigkeiten zu verstehen, ja, letztendlich zu verstehen, wie es "funktioniert" - etwas, das höhere Programmiersprachen gern verschleiern, weil's der gewöhnliche Programmierer nicht unbedingt wissen muss oder will.

Lottozahlen sind Tupel.

Nein. Lottozahlen sind eher Mengen (im datenbanktechnischen Sinn). Die Anzahl der Elemente ist zwar immer gleich, das könnte für Tupel sprechen; Tupel sind aber geordnete Konstrukte (sie haben eine eindeutige erste, zweite, dritte ... Position), und mehrere Positionen können den gleichen Wert haben. Koordinaten wären etwa ein schönes Beispiel für Tupel. Lottozahlen nicht.

So long,
 Martin

[1UnitedPower]

Meine Herren!

Hallo,

[...] Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

ich habe noch nie Lotto gespielt und kenne vielleicht nicht die Feinheiten, aber: Ich dachte bisher immer, bei den Lottozahlen käme es gerade *nicht* auf die Reihenfolge bzw. Position an, weil die gezogenen Zahlen doch sowieso aufsteigend sortiert werden. Oder was hab ich da falsch verstanden?

Oh, echt? Ja ich habe auch noch nie Lotto gespielt und ich dachte die Reihenfolge der Ziehung wäre relevant.

Datenstrukturen ziehen sich durch jede Anwendungsschicht, die wird man nur schwer wegabstrahieren können. Und selbst wenn das gelingt, dann sind sie in irgendeiner Schicht relevant. Bei der Eröterung von low-level Programmiersprachen-Features ist es nicht hilfreich, nicht darüber zu sprechen und uns bewusst Gedanken zu machen, wie wir sie wegabstrahieren.

Ganz im Gegenteil:

Ist dir die doppelte Verneinung entgangen? Sonst sehe ich nicht, wo wir uns widersprechen.

Lottozahlen sind Tupel.

Nein. Lottozahlen sind eher Mengen (im datenbanktechnischen Sinn).

Stimmt Wikipedia gibt dir Recht. Ich wäre ein grauenhafter Lotto-Spieler. Die Kombinatorik und Wahrscheinlichkeitsrechnung schiebt aber sowieso einen rationalen Riegel vor diese Option ;)

[Der Martin]

Hi,

Bei der Eröterung von low-level Programmiersprachen-Features ist es nicht hilfreich, nicht darüber zu sprechen und uns bewusst Gedanken zu machen, wie wir sie wegabstrahieren.
Ganz im Gegenteil:
Ist dir die doppelte Verneinung entgangen? Sonst sehe ich nicht, wo wir uns widersprechen.

nein, die ist mir nicht entgangen - ich meinte "ganz im Gegenteil" eigentlich als Bekräftigung deiner Aussage: Es ist nicht nur nicht hilfreich, sie zu ignorieren, sondern ganz im Gegenteil, man *muss* darüber reden.

Ciao,
 Martin

[1UnitedPower]

Meine Herren!

Wann immer ich eine Schleife sehe:
for ( $array as $key )
Weiß ich nichts darüber, was die Schleife mit dem Array macht.

map dagegen teilt mir mit, da wird für jedes Element im Array irgendein anderer Wert berechnet.
reduce sagt mir, da wird jetzt was aggregiert.

Schicksalhaft wie manche Informationen mir zeitlich passend so zu fliegen.
Favoring Curry, ein Artikel über Currying in JavaScript, hat ein paar eindrucksvolle Beispiele, die näher an der Realität sind als mein eigener Erguss da oben, insbesondere unter dem Punkt Don't Care: I'm Not a Math Geek!

[tami]

hi 1UnitedPower,

Wann immer ich eine Schleife sehe:
for ( $array as $key )
Weiß ich nichts darüber, was die Schleife mit dem Array macht.

map dagegen teilt mir mit, da wird für jedes Element im Array irgendein anderer Wert berechnet.
reduce sagt mir, da wird jetzt was aggregiert.

Schicksalhaft wie manche Informationen mir zeitlich passend so zu fliegen.
Favoring Curry, ein Artikel über Currying in JavaScript, hat ein paar eindrucksvolle Beispiele, die näher an der Realität sind als mein eigener Erguss da oben, insbesondere unter dem Punkt Don't Care: I'm Not a Math Geek!

Vorab wie dort verlinkt: http://fr.umio.us/why-ramda/

mfg

tami

[tami]

hi tami,

hi 1UnitedPower,

Wann immer ich eine Schleife sehe:
for ( $array as $key )
Weiß ich nichts darüber, was die Schleife mit dem Array macht.

map dagegen teilt mir mit, da wird für jedes Element im Array irgendein anderer Wert berechnet.
reduce sagt mir, da wird jetzt was aggregiert.

Schicksalhaft wie manche Informationen mir zeitlich passend so zu fliegen.
Favoring Curry, ein Artikel über Currying in JavaScript, hat ein paar eindrucksvolle Beispiele, die näher an der Realität sind als mein eigener Erguss da oben, insbesondere unter dem Punkt Don't Care: I'm Not a Math Geek!

Vorab wie dort verlinkt: http://fr.umio.us/why-ramda/

und http://buzzdecafe.github.io/code/2014/05/16/introducing-ramda/

mfg

tami

[Sven Rautenberg]

Moin!

Ps. http://de.wikipedia.org/wiki/Laravel
"Laravel ist ein Open-Source-PHP-Web-Application-Framework, das dem MVC-Muster folgt. Es wurde 2011 von Taylor Otwell initiiert. Die Laravel-Community wird von Cartalyst gesponsert, einem Unternehmen, das Add-ons für Laravel und andere Frameworks herstellt und verkauft. Laut einem Artikel von Bruno Skvorc auf der Website sitepoint.com ist Laravel das zukunftsträchtigste Framework 2014"

Nein, ist es nicht. Solch eine Behauptung dürfte keiner näheren Betrachtung standhalten.

Im Gegenteil habe ich bei Laravel das Gefühl, dass die Programmierer irgendwas falsch machen. Wie sonst ist es zu erklären, dass sich auf Stackoverflow alle Fragen zum Thema Composer bei Problemen mit einem Framework fast ausschließlich um Laravel drehen? Leider kann ich es nicht genauer benennen, aber es fällt mir auf.

- Sven Rautenberg

[tami]

hi Sven,

Ps. http://de.wikipedia.org/wiki/Laravel
"Laravel ist ein Open-Source-PHP-Web-Application-Framework, das dem MVC-Muster folgt. Es wurde 2011 von Taylor Otwell initiiert. Die Laravel-Community wird von Cartalyst gesponsert, einem Unternehmen, das Add-ons für Laravel und andere Frameworks herstellt und verkauft. Laut einem Artikel von Bruno Skvorc auf der Website sitepoint.com ist Laravel das zukunftsträchtigste Framework 2014"

Nein, ist es nicht. Solch eine Behauptung dürfte keiner näheren Betrachtung standhalten.

Im Gegenteil habe ich bei Laravel das Gefühl, dass die Programmierer irgendwas falsch machen. Wie sonst ist es zu erklären, dass sich auf Stackoverflow alle Fragen zum Thema Composer bei Problemen mit einem Framework fast ausschließlich um Laravel drehen? Leider kann ich es nicht genauer benennen, aber es fällt mir auf.

Weißt Du denn, warum Facebook da seinen ganzen Code auf Hack umstellt?

"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 werden ja die "Collections" als Erweitrung von Arrays hervorgehoben, um mit Funktionen wie map() und filter() funktionalen Programmierstil zu erleichtern. Das muss doch irgend eine größere Rolle dann intern bei denen spielen, oder?

Was so relevant an Closures in PHP ist, weiß ich auch immer noch nicht. Ich dachte immer, private Klassen-Variablen würden den selben Zweck erfüllen und dieses Variablen-Einschließen wäre insbesondere wichtig wenn Codes auf verschiedenen Quellen zusammengeführt werden, was ja bei Javascript regelmäßig der Fall ist, nicht aber bei PHP.

mfg

tami

[tami Linksetzer]

hi tami,

Weißt Du denn, warum Facebook da seinen ganzen Code auf Hack umstellt?

"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."

https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/

mfg

tami

[tami]

hi tami,

hi tami,

Weißt Du denn, warum Facebook da seinen ganzen Code auf Hack umstellt?

"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."

https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/

http://docs.hhvm.com/manual/en/hack.collections.php ...

"Currently, Hack implements the following concrete collection types:

Vector: An ordered, index-based list collection.

ImmVector: An immutable, ordered, index-based list collection.

Map: An ordered dictionary-style collection.

ImmMap: An immutable, ordered dictionary-style collection.

Set: A list-based collection that stores unique values.

ImmSet: An immutable, list-based collection that stores unique values.

Pair: An index-based collection that can hold exactly two elements."

Warum hat das Zend-Framework zB. nicht "sowas"?

filter() und map() sind bei der Map-Klasse ja vorhanden http://docs.hhvm.com/manual/en/class.hack.maptktv.php.

mfg

tami

[Sven Rautenberg]

Moin!

Weißt Du denn, warum Facebook da seinen ganzen Code auf Hack umstellt?

Nein, und ich würde bestreiten wollen, dass die das großflächig "einfach so" tun. Wenn, dann im Rahmen einer Migrationsstrategie, die an gewissen Hotspots mittels Hack noch Performance rauskitzeln kann.

"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.

Eine der typischen Anwendungen für PHP-Arrays ist, mehr als ein Object desselben Typs zu enthalten. Es liegt auf der Hand, hier Typsicherheit zugunsten von Performance zu implementieren.

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."

Convenience.

Da werden ja die "Collections" als Erweitrung von Arrays hervorgehoben, um mit Funktionen wie map() und filter() funktionalen Programmierstil zu erleichtern. Das muss doch irgend eine größere Rolle dann intern bei denen spielen, oder?

Vermutlich gibts viel zu mappen und zu filtern bei Facebook.

Was so relevant an Closures in PHP ist, weiß ich auch immer noch nicht. Ich dachte immer, private Klassen-Variablen würden den selben Zweck erfüllen und dieses Variablen-Einschließen wäre insbesondere wichtig wenn Codes auf verschiedenen Quellen zusammengeführt werden, was ja bei Javascript regelmäßig der Fall ist, nicht aber bei PHP.

Closures erlauben Funktionsdefinitionen, die noch nicht ausgeführt werden, aber im Kontext der Definition ablaufen. Sowas kriegt man mit privaten Klassenvariablen nicht hin.

- Sven Rautenberg

[tami]

hi Sven,

Closures erlauben Funktionsdefinitionen, die noch nicht ausgeführt werden, aber im Kontext der Definition ablaufen. Sowas kriegt man mit privaten Klassenvariablen nicht hin.

Das hört sich korrekt an. Ich verstehe sowas allerdings immer erst, wenn ich ein Beispiel vor Augen habe. Wonach würde ich googlen, um eins zu finden?

mfg

tami

[Texter mit x]

"5 Strengths of PHP"

Meh, der Artikel ist grauenhaft einseitig.