Wat

Pffth, you just need to learn Hebrew before you learn PHP. That says "double dot twice".

This was introduced by Zend, which is israeli. Thus the Hebrew.

I first saw that error in a pre-Google world. It took a few days for me to figure out what it meant.

  $ php -r '::'
  Parse error: parse error in Command line code on line 1

Edit:

Hrm, if I try it on my DreamHost account, I get something more similar to yours:

  $ php -r '::'
  Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in Command line code on line 1

This appears to be a peculiarity of the REPL implementations, not a difference between V8 and JSC. d8 (and the Chrome console) behaves the same way as jsc, while you can make d8 and jsc behave the same as the node REPL by wrapping each statement in parentheses:

  d8> ([] + [])
  
  d8> ([] + {})
  [object Object]
  d8> ({} + [])
  [object Object]
  d8> ({} + {})
  [object Object][object Object]

I don't even understand what the last node.js entry is. Is that an array with two objects?

Also, I'm on an old version of node, but my output matches jsc.

That is exactly what I was wondering: what you say must be true, but I could not find any equivalent of what you see here for any other profession.

But maybe it is just because I write code for a living...

But of course, anyone that actually wants to protect against XSS attacks won't allow user input to be evaluated. If they did want to allow user-supplied Javascript, they wouldn't blacklist, they would whitelist (by parsing the user-supplied script and using the AST to emit only whitelisted operations).

JavaScript has a strong design principle of not throwing errors for syntactically valid constructs. The most common way it accomplishes this is through gratuitous use of implicit type conversions. It does a lot of implicit string conversions, even on things that you would think of as error codes, like undefined or NaN.

JavaScript went down the path of being a "forgiving" language because it was intended to provide "extra" (non-core) functionality, under a lot of environments, in the hands of non-experts. It made sense at the time that it should fail silently rather than noisily to not crash the page it was on. It also tried to help amateurs who just banged on code until it did what they wanted, by generally doing something rather than nothing, and by trying to infer intended behavior from undisciplined code. It was never intended to make large-scale or robust applications, so it didn't make decisions that would facilitate that use-case.

The Ruby stuff apparently isn't bizarre. From what I've read, Ruby creates variables as it encounters an assignment to them when parsing the code. So, when you have

   a = a

The JavaScript stuff, I think, comes from operator overloading. The plus operator is overloaded to allow adding strings to concatenate them, and it will do type conversion to get compatible types, so "wat"+1 results in the 1 being converted to a string, and then the strings are concatenated. Since the minus operator is not so overloaded, "wat"-1 instead is treated as numerical subtraction. JavaScript allows string to be used as numbers, so "123"-1 gives 122. However "wat" is not a string that represents a number, so gives NaN when forced to be treated as a number, and "wat"-1 is thus NaN.

Javascript was a rush job. And the ECMA spec was needed early due to industry pressure. So where perl and (to a lesser extent) python were able to just bury their early goofs in a pile of incompatible versions bumps, Javascript had its encased in the proverbial carbonite of an international standard. Which is sad, really, because in a lot of other ways it's the cleanest scripting language of its generation.

Welcome to the world of JavaScript. This response is NaN.

For more sadness, see: http://wtfjs.com

Fun fact: the creator of Javascript posts on HN. Maybe he'll answer your question.

Really? You don't think this is funny at all? Maybe it's because I'm in my mid twenties, but I think my father would even find this funny and he knows little to none about programming.

There's no laugh track; that's the audience.

Yeah count me in the "not a hacker, I guess" crowd, this stuff isn't very funny.

I didn't laugh because I was so worried that if I didn't laugh I wouldn't be considered a hacker :(

It's jsc (comes with Webkit) - it's present on Mac OS X by default in

/System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Resources/jsc

You can just do:

sudo ln /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Resources/jsc /bin/jsc

To be able to invoke it directly from the command line.

<shamelessplug>If you want to use any of these inside emacs check out my js-comint mode: http://js-comint-el.sourceforge.net/ Makes it really easy to do things like write code in one buffer and execute it in another. </shamelessplug>

Looks like something that comes as part of Webkit:

http://trac.webkit.org/wiki/JSC

No. I'm with you man. The way he said it was seriously bugging me. At the same time I couldn't justify my annoyance with an alternative pronunciation that made sense.

Perhaps some memes should never be vocalized.

Handy way to make some padding:

    function pad(n, c) { return Array(n+1).join(c); }

    // pad(6, "-") === "------"

It's Keynote. I recorded those sessions as screencasts, then sliced them into tiny pieces so I can advance them perfectly with my talking. There are 37 slides in that four-minute talk. In some cases, the slices are only two or three frames long.

That's probably one of the more logical examples. I'd have expected an exception from any other language, though (Javascript I know doesn't tend to type error).

Well, .join(x) joins an array into a string, with x as the separator. First of all what does Array(16) make? Effectively it should make an array with null 16 times. Now, JavaScript seems to think null is a blank string, a string with the text 'null', or a zero depending on the context.

The first thing it should do is TypeError that null is not a string. Or don't join null fields because there is nothing there.

If is does convert null to '', then it should TypeError on string - int. If it is not going to TypeError it should do something sensible, like slice the string

  > Array(16).join("wat".slice(0,-1)) + " Batman!"
  'wawawawawawawawawawawawawawawa Batman!'

JavaScript nuttiness:

Now it's zero:

  > null + 1
  1

  > null + "text"
  'nulltext'

  > [null, null, null].join()
  ',,'

If it doesn't work, error:

  >>> "wat" - 1
  Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for -: 'str' and 'int'

  >>> ','.join([None, None, None])
  Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
  TypeError: sequence item 0: expected string, NoneType found

  >>> ','.join([str(i) for i in [None, None, None]])
  'None,None,None'

  >>> ','.join([str(i) for i in [None, None, None] if i])
  ''

A TypeError.

If you've ever gone through a phase (or a graduate degree!) of thinking deeply about programming language design, you might, as I do, find Javascript's expression evaluation behavior to be just about the funniest thing around.

It's on the front page, but at the bottom. DAS is a small one-man business, so I did the design myself (and I'm not a good designer). Sorry about that. :)

I feel like we've been suffering extra-much from this effect lately...

Wat.

wow, you must be the best hacker ever congrats