"5 Strengths of PHP"

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