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.

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.

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

--
Der Unterschied zwischen Java und JavaScript ist größer als der zwischen satt und Sattel.

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.

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. =)

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.

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.

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.