Wat?
In der D NewsGroup entdeckt und definitiv sehenswert: https://www.destroyallsoftware.com/talks/wat
the more they change the more they stay the same
Ehrlich gesagt verstehe ich den Hype um dieses Video nicht. Die Bilder sind nett mit dem Hang zu "seht mal wie cool ich bin" und sein Vortragsstil ist amüsant, doch ich bin wohl humorlos, als das ich die Beispiele bei JavaScript nicht unglaublich witzig sondern (mit einer Ausnahme) nachvollziehbar finde.
Wird ein leeres Array ( String([]) => "" ) in einen String konvertiert, ist das der leere String. Witzig? Nein. Kann man so machen.
Wird der "+"-Operator auf etwas anderes als Zahlen angewandt, wird dieses andere in einen String verwandelt. Witzig? Nein. Kann man so machen. Macht Java auch so und wenn es nicht so wäre, wäre es komisch (nicht im Sinne von witzig) für jeden, der Java kennt.
Also steht [] + [] für String([]) + String([]) und wenn man zwei leere Strings addiert erwarte ich wieder einen leeren String. Witzig? Nein.
Bei seinem zweiten JavaScript-Beispiel irrt der Vortragende.
Die String-Repräsentation eines Objektliterals - egal ob leer oder nicht - ist "[object Object]". Das kann man gut finden oder nicht. Jedenfalls zeigt er da nicht ein Objekt, sondern einen String. Nun entspricht damit [] + {} dem Ausdruck "" + "[object Object]" und das gibt offensichtlich den String (aber nicht das Object-Exemplar) "[object Object]". Witzig? Nein.
Das dritte Beispiel ist zugegeben verwunderlich. Der "+"-Operator ist eben nicht kommutativ wie angenommen. Ist er aber auch bei Java nicht. Hier wird erst das linke und dann das rechte Argument ausgewertet. Es gilt, dass der "+"-Präfix-Operator krampfhaft versucht, aus seinem Argument eine Zahl zu machen. Somit ist +[] die Zahl 0, entspricht damit Number([]). Auch +"" ist 0 und +"5" wäre 5. Hängt damit zusammen, wie true und false berechnet werden, ich sage nur int(bool([])) in Python. Somit kann man + als Kurzform für Number() benutzen, so wie mal ""+ als Kurzform String() nutzen kann. Gut? Nein. Aber ist nun mal so.
Da der Wert von {} undefined ist, sagt der "+"-Operator, dass er seine Argumente nicht in Strings, sondern das zweite in eine Zahl verwandelt werden soll. Und das, obwohl ( undefined + 0 ) eigentlich NaN wäre und nicht 0. Nun ja...
Das vierte Beispiel ist dann wieder nachvollziehbar. {} hat den Wert undefined und irgendwas plus undefined ist NaN - Not a Number.
Ein leeres Array, dessen Elemente undefined ist, wird übrigens natürlich nicht durch 16 Kommas repräsentiert, sondern 16x undefined, getrennt durch Kommas, wie ein anderes Array auch. Und die Darstellung wird mit join() erzeugt und das macht aus undefined den Leerstring (obwohl String(undefined) der String "undefined" wäre). Man kann's mit dem Missverstehen auch übertreiben. Natürlich wäre schön, wenn da [undefined, undefined, ...] stehen würde, hat man aber anders definiert, man siehe auch ( Array(16).join("wat") ).
Und natürlich ist ein String, der nicht als Zahl repräsentiert werden kann und von dem man eine Zahl abziehen will, NaN, denn Number("wat") (oder auch +"wat") ist bereits NaN und NaN - 1 ist natürlich auch NaN und da String(NaN) gleich "NaN" ist, und undefined bei join() nicht zu sehen ist, gibt sein Beispiel natürlich 16x wat. Witzig? Nein.
Stefan
Wird ein leeres Array ( String([]) => "" ) in einen String konvertiert, ist das der leere String. Witzig? Nein. Kann man so machen.
Wird der "+"-Operator auf etwas anderes als Zahlen angewandt, wird dieses andere in einen String verwandelt. Witzig? Nein. Kann man so machen. Macht Java auch so und wenn es nicht so wäre, wäre es komisch (nicht im Sinne von witzig) für jeden, der Java kennt.
Also steht [] + [] für String([]) + String([]) und wenn man zwei leere Strings addiert erwarte ich wieder einen leeren String. Witzig? Nein.
Bei seinem zweiten JavaScript-Beispiel irrt der Vortragende.
Die String-Repräsentation eines Objektliterals - egal ob leer oder nicht - ist "[object Object]". Das kann man gut finden oder nicht. Jedenfalls zeigt er da nicht ein Objekt, sondern einen String. Nun entspricht damit [] + {} dem Ausdruck "" + "[object Object]" und das gibt offensichtlich den String (aber nicht das Object-Exemplar) "[object Object]". Witzig? Nein.
Das dritte Beispiel ist zugegeben verwunderlich. Der "+"-Operator ist eben nicht kommutativ wie angenommen. Ist er aber auch bei Java nicht. Hier wird erst das linke und dann das rechte Argument ausgewertet. Es gilt, dass der "+"-Präfix-Operator krampfhaft versucht, aus seinem Argument eine Zahl zu machen. Somit ist +[] die Zahl 0, entspricht damit Number([]). Auch +"" ist 0 und +"5" wäre 5. Hängt damit zusammen, wie true und false berechnet werden, ich sage nur int(bool([])) in Python. Somit kann man + als Kurzform für Number() benutzen, so wie mal ""+ als Kurzform String() nutzen kann. Gut? Nein. Aber ist nun mal so.
Da der Wert von {} undefined ist, sagt der "+"-Operator, dass er seine Argumente nicht in Strings, sondern das zweite in eine Zahl verwandelt werden soll. Und das, obwohl ( undefined + 0 ) eigentlich NaN wäre und nicht 0. Nun ja...
Das vierte Beispiel ist dann wieder nachvollziehbar. {} hat den Wert undefined und irgendwas plus undefined ist NaN - Not a Number.
Ein leeres Array, dessen Elemente undefined ist, wird übrigens natürlich nicht durch 16 Kommas repräsentiert, sondern 16x undefined, getrennt durch Kommas, wie ein anderes Array auch. Und die Darstellung wird mit join() erzeugt und das macht aus undefined den Leerstring (obwohl String(undefined) der String "undefined" wäre). Man kann's mit dem Missverstehen auch übertreiben. Natürlich wäre schön, wenn da [undefined, undefined, ...] stehen würde, hat man aber anders definiert, man siehe auch ( Array(16).join("wat") ).
Und natürlich ist ein String, der nicht als Zahl repräsentiert werden kann und von dem man eine Zahl abziehen will, NaN, denn Number("wat") (oder auch +"wat") ist bereits NaN und NaN - 1 ist natürlich auch NaN und da String(NaN) gleich "NaN" ist, und undefined bei join() nicht zu sehen ist, gibt sein Beispiel natürlich 16x wat. Witzig? Nein.
Stefan
Humor? Nein. Aber ist nun mal so. 
MorgenGrauen: 1 Welt, 8 Rassen, 13 Gilden, >250 Abenteuer, >5000 Waffen & Rüstungen,
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Niemand hat behauptet, dass die Sachen nicht nachvollziehbar sind. Die Sache ist halt, dass die Ergebnisse eben oft bizarr wirken weil es aufzeigt dass weak typing an sich erstmal wie ne praktische Idee klingt, aber im großen und ganzen eher unpraktisch und fehleranfällig als gut ist.sma hat geschrieben:Die Bilder sind nett mit dem Hang zu "seht mal wie cool ich bin" und sein Vortragsstil ist amüsant, doch ich bin wohl humorlos, als das ich die Beispiele bei JavaScript nicht unglaublich witzig sondern (mit einer Ausnahme) nachvollziehbar finde.
Wegen + ist es halt eine ewige Diskussion, was das "richtige" Verhalten ist. Bei 1 + 1 ist es ja klar, aber bei "a" + "b" kann man sich bereits streiten was das richtige Verhalten ist: "ab"? "c"? 97 + 98? Und bei 1 + "1" wird es dann noch umstrittener. OCaml findet ja auch schon dass 1,5 + 1,5 nicht in Ordnung ist und verweist auf den +. Operator...
Ich hatte letztens auch einen Bug in meinem JavaScript-Code, wo der Key eines Objektes implizit in einen String umgewandelt wurde. Witzig? Nein. Kann man so machen. Hilfreich? Auch nein.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
lunar
@Leonidas: So gesehen ist jede Sprache "bizarr". Implizite Typumwandlungen gibt es in fast jeder Sprache (vielleicht abgesehen von Haskell), man hätte dieses Video auch gut über Java oder C++ drehen können. Letztlich sogar über Python, denn letztlich verhält sich Python ganz genauso und erlaubt beliebige Typumwandlungen bei der Anwendung von Operatoren, man muss sie halt nur entsprechend implementieren. Der Unterschied besteht lediglich darin, dass die eingebauten Typen weniger implizite Umwandlungsregeln haben.
Mit starker und schwacher Typisierung hat das wenig zu tun, diese Begriffe sind ohnehin reichlich schwammig.
Mit starker und schwacher Typisierung hat das wenig zu tun, diese Begriffe sind ohnehin reichlich schwammig.
Ich schmeiß einfach noch mal ganz kommentarlos zwei dazu passende Links in die Runde: http://www.reddit.com/r/programming/com ... hy_of_wat/ -> http://blog.caplin.com/2012/01/27/the-why-of-wat/
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, steht dir frei ein solches Video über Java und C++ zu drehen, wäre sicher auch lustig. (Außerdem bin ich mir nicht sicher ob OCaml explizite Typumwandlungen hat, was ein Problem ist wenn man beliebige Datentypen "printen" will)lunar hat geschrieben:@Leonidas: So gesehen ist jede Sprache "bizarr". Implizite Typumwandlungen gibt es in fast jeder Sprache (vielleicht abgesehen von Haskell), man hätte dieses Video auch gut über Java oder C++ drehen können.
Wie du sagtest, der Unterschied ist dass Python weniger davon hat und vor allem weniger die einem dann Probleme bereiten. In Python kann man sowas implementieren, ganz recht. In JavaScript ist sowas überall implementiert und man wird es nicht los.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice