1. 52
  1.  

  2. 39

    Nit-pick: Unless @mikas is Gary Bernhardt, the “author” checkbox should not be checked.

    1. 23

      I enjoyed this quite a bit when I first saw it, and I still do kinda enjoy the original - it was never meant to be taken too seriously of course and it succeeds as a joke - but since then, the word “wat” has become a trigger of rage for me.

      These things tend to have a reasonable explanation if you take the time to understand why it does what it does. They tend to be predictable consequences of actually generally useful rules, just used in a different way than originally intended and coming out a bit silly. You might laugh but you can also be educated.

      But you know how often I see people taking the time to try to understand the actual why? Not nearly as often as I see people saying “WAT” and just dismissing things and calling the designers all kinds of unkind things. And that attitude is both useless and annoying.

      1. 38

        These things tend to have a reasonable explanation if you take the time to understand why it does what it does. They tend to be predictable consequences of actually generally useful rules, just used in a different way than originally intended and coming out a bit silly.

        For me the most important takeaway is that rules might make sense by themselves, but you have to consider them in the bigger picture, as part of a whole. When you design something, you must keep this in mind to avoid bringing about a huge mess in the completed system.

        1. 4

          Exactly. It is generally underappreciated how incredible hard language design is. The cases Bernhardt points out are genuine design mistakes and not just the unfortunate side effects of otherwise reasonable decisions.

          That’s why there are very few languages that don’t suffer from ugly corner cases which don’t fit into the whole or turn out to have absurd oddities. Programming languages are different, contrary to the “well, does it really matter?” mindset.

          1. 3

            I don’t know. What I always think about JS is that R4RS Scheme existed at the time JS was created and the world would be tremendously better off if they had just used that as the scripting system. Scheme isn’t perfect but it is much more regular and comprehensible than JS.

            1. 3

              I think one have to remember the context in which JavaScript was created; I’m guessing the main use case was to show some funny “alert” pop-ups here and there.

              In that context a lot of the design decisions start to make sense; avoid crashes whenever possible and have a “do what I mean” approach to type coercion.

              But yeah, I agree; we would’ve all been better off with a Scheme as the substrate for maybe 80% of today’s end-user applications. OTOH, if someone would’ve told Mozilla how successful JS would become we could very well have ended up with some bloated, Java-like design-by-committee monstrosity instead

            2. 2

              I don’t think I know a single (nontrivial - thinking about brainfuck/assembly maybe) programming language with no “unexpected behaviour”.

              But some just have more or less than others. Haskell, for example, has a lot of these unexpected behaviours but you tend not to fall on these corner cases by mistake. While in javascript and Perl, it is more common to see such a “surprise behaviour” in the wild.

              Another lesson I gather from this talk is that you should try to stick as much as possible in your well-known territory if you want to predict the behaviour of your program. In particular, try not to play too much with “auto coercion of types”. If a function expects a string, I tend not to give it a random object even if when I tried it, it perform string coercion which will most of the time be what I would expect.

              1. 1

                Well, there are several non-trivial languages that try hard not to surprise you. One should also distinguish betweem “unexpected behaviour” and convenience features that turn out to be counterproductive by producing edge-cases. This is a general problem with many dynamically typed languages, especially recent inventions: auto-coercion will remove opportunities for error checking (and run-time checks are what make dynamically typed languages type-safe). By automatic conversion of value types and also by using catch-all values like the pervasive use of maps in (say) Clojure, you effectively end up with untyped data. If a function expects a string, give it a string. The coercion might save some typing in the REPL, but hides bugs in production code.

            3. 3

              In javascript, overloading the + operator and the optional semicolon rules I would call unforced errors in the language and those propagate through to a few other places. Visual Basic used & for concatenation, and it was very much a contemporary of JS when it was new, but they surely just copied Java’s design (which I still think is a mistake but less so given the type system).

              Anyway, the rest of the things shown talk I actually think are pretty useful and not much of a problem when combined. The NaNNaN Batman one is just directly useful - it converts a thing that is not a number to a numeric type, so NaN is a reasonable return, then it converts to string to join them, which is again reasonable.

              People like to hate on == vs === but…. == is just more useful. In a dynamic, weakly typed language, things get mixed. You prompt for a number from the user and technically it is a string, but you want to compare it with numbers. So that’s pretty useful. Then if you don’t want that, you could coerce or be more specific and they made === as a shortcut for that. This is pretty reasonable. And the [object Object] thing comes from these generally useful conversions.

              1. 3

                == vs ===

                It definitely makes sense to have multiple comparison operators. Lisp has = (numeric equality), eq (object identity), eql (union of the previous two), equal (structural equality).

                The problem is that js comes from a context (c) in which == is the ‘default’ comparison operator. And since === is just ==, but more, it is difficult to be intentional about which comparison you choose to make.

                1. 1

                  Well, a lot of these things boil down to implicit type coercion and strange results due to mismatched intuitive expectations. It’s also been shown time and again (especially in PHP) that implicit type coercions are lurking security problems, mostly because intuition does not match reality (especially regarding == and the bizarre coercion rules). So perhaps the underlying issue of most of the WATs in here simply is that implicit type coercion should be avoided as much as possible in languages because it results in difficult to predict behaviour in code.

                  1. 1

                    Yeah, I perfer a stronger, static type system and that’s my first choice in languages. But if it is dynamically typed… I prefer it weaker, with these implicit coercion. It is absurd to me to get a runtime error when you do like var a = prompt("number"); a - whatever; A compile time error, sure. But a runtime one? What a pain, just make it work.

                    1. 3

                      Lots of dynamic languages do this (e.g. Python, Ruby, all Lisp dialects that spring to mind), and IME it’s actually helpful in catching bugs early. And like I said, it prevents security issues due to type confusions.

              2. 10

                Yeah, I think that this talk was well-intentioned enough, but I definitely think that programmers suffer from too much “noping” and too little appreciation for the complexity that goes into real-world designs, and that this talk was a contributor… or maybe just a leading indicator.

                1. 6

                  There was a good talk along these lines a couple of years ago, explaining why javascript behaves the way it does in those scenarios, and then presenting similar ‘WAT’s from other languages and explaining their origins. Taking the attitude of ‘ok this seems bizarre and funny, but let’s not just point and laugh, let’s also figure out why it’s actually fairly sensible in context’.

                  Sadly I can’t find it now, though I do remember the person who delivered it was associated with ruby (maybe this rings a bell for somebody else).

                  1. 1

                    Isn’t the linked talk exactly the talk you’re thinking about? Gary is ‘associated with’ Ruby and does give examples from other languages as well.

                    1. 2

                      No. I was thinking of this, linked else-thread.

                  2. 3

                    While things might have an explanation, I do strongly prefer systems and languages that stick to the principle of least surprise: if your standard library has a function called ‘max’ that returns the maximum value in an array and a function called ‘min’ that returns the position of the minimum element instead, you are making your language less discoverable and putting a lot of unnecessary cognitive load on the user.

                    As someone who has been programming for over 20 years and is now a CTO of a small company that uses your average stack of like 5 programming languages on a regular basis I don’t want to learn why anymore, I just want to use the functionality and be productive. My mind is cluttered with useless trivia about inconsistent APIs I learned 20, 15, 10 years ago, the last thing I need is learning more of that.

                  3. 18

                    Katie McLaughlin gave a really good talk at Kiwi Pycon (and PyCascades where I saw it) where she dives into why all of the oddities in wat do what they do. It’s a bit longer, but definitely worth a watch. https://www.youtube.com/watch?v=AxJB2sWMS-k

                    That being said, I tend to view wat as a fun palate cleanser, more than a super serious talk. I also keep around a number of talks and articles which I tend to view in a similar light. I like revisiting them every once in a while when I’m having a bad day.

                    1. 5

                      I’ve always wondered, what was the context of this talk? People seem to be pretty warmed-up before it even begins, and the good reception contributes quite a bit to the hilarity.

                      1. 12

                        I think it was in a series of “lightning round talks”, so probably all short and funny like this one and in quick succession.

                        1. 7

                          That’s exactly what it was. A high energy, humorous take on the result of intersecting design decisions. (As noted elsewhere in these comments: each decision had good reasons in isolation but the combination produced some … interesting … effects.)

                        2. 1

                          Yeah, I don’t think that was the main talk.

                        3. [Comment removed by moderator pushcx: You're adding nothing to the conversation here by heaping scorn.]

                          1. 7

                            why

                            1. 3

                              Right? No-one coerced them into watching it.

                              1. [Comment removed by moderator pushcx: You're adding nothing to the conversation here by heaping scorn.]

                                1. 4

                                  Could you elaborate more? Is there something in particular you don’t like about it?

                                  Saying you “hate this talk”, that it’s “the worst talk of all time”, and calling it “idiotic” aren’t very productive ways to have a conversation.

                              2. [Comment removed by moderator pushcx: Please don't encourage ranting or pick fights.]