

The WHY of WAT - understanding why 'JavaScript is Crazy' - amirhhz
http://blog.caplin.com/2012/01/27/the-why-of-wat/

======
rdtsc
> ... he pokes fun at some apparently crazy behaviours in Ruby and Javascript.

I am sorry, but that still is crazy behavior. You can excuse it with a
historical perspective ("well it had to hide errors from users") or by
explaining "the why" like you do, that still doesn't make that behavior less
crazy.

~~~
karterk
Not trying to defend the craziness, but, when you are trying to do []+{} and
"foo"-1, you can kinda expect unexpected results if you know that JS does type
coercion.

~~~
jlouis
That is not the problem here. The problem is that this might by the code piece
"x + y" where x and y is in your scope and happens to be [] and {}. The
resulting value is then highly confusing to a programmer. A language that
enforces explicit type conversion (some call these strongly typed languages)
would not allow this, but require you to write something like "string(x) +
string(y)" if you _really_ wanted such behaviour.

I think it is rather bad semantics actually.

~~~
ricardobeat
I can't imagine a single situation where you expect variables used in a sum
operation to be arrays/objects. _That_ would be highly confusing.

You always have the option to use

    
    
        Number(x) + Number(y)
        (+x) + (+y)
        String(x) + String(y)

~~~
jerf
"I can't imagine a single situation where you expect variables used in a sum
operation to be arrays/objects."

That's precisely the problem. You don't expect them, but there's nothing to
prevent it from happening, so it does.

Your proposed solutions don't solve the problem, they occur too late. By the
time you're adding together two non-numbers (and non-strings) you've already
lost, trying desperately to cast them to numbers first is also wrong, along
with so verbose that nobody will ever do it.

~~~
ricardobeat
Yeah, that was stupid.

What I mean though is I can't imagine code that gives chance for this to
happen. Putting an array where a number should be is a very visible mistake.

------
gambler
This is not "WHY", this is "HOW exactly". I bet the reason why JavaScript has
these behaviors is due it being developed as a browser scripting language.
Authors didn't want the entire script terminating because some part of it was
buggy. This could have been handled by some clever isolation and error-
recovery mechanism, but it wasn't. Probably due to time constraints.

These kinds of things are one of the reasons why I really don't like the idea
of everything (including server-side and standalone apps) being written in
JavaScript.

~~~
pfraze
That's fair, but PHP has the same level of WTF, and is (I'd argue) less
elegant than JS.

~~~
archgoon
Sorry, I'm missing something. Is the grandparent a big advocate of PHP? Why is
PHP being brought into this?

~~~
pfraze
It's a language that is heavily used for server apps, which the top post was
saying JS shouldn't do. My point was, quirks like these haven't outweighed the
advantages of PHP, and I don't think they should for JS either.

------
vmind
This is only part of the why. The other part is the valueOf function which you
can specify in order to control what the value of an object is when coerced.

So for instance:

    
    
        var arr1 = [1,2,3], arr2 = [1,2,3,4];
        console.log(arr1 + arr2); // "1,2,31,2,3,4"
        arr1.valueOf = function () { return this.length; };
        arr2.valueOf = arr1.valueOf;
        console.log(arr1 + arr2); // 7

------
bilalhusain
text only cache, courtesy google:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.caplin.com/2012/01/27/the-
why-of-wat/&hl=en&strip=1)

and a duckduckgo tip

    
    
        !cache http://blog.caplin.com/2012/01/27/the-why-of-wat/

~~~
nailer
Full version cache, so the lines aren't unreadably long:

[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.caplin.com/2012/01/27/the-
why-of-wat/&hl=en&strip=0)

------
shdon
The original presentation was nicely done, but knowing how things work in
JavaScript (even though I don't know Ruby) meant I didn't exactly have that
WTF-experience. This article explains it nicely to those who had.

~~~
VMG
I think this kind of misses the point. Even if you understand _why_ JavaScript
behaves this way, it doesn't mean that the behavior is sane.

JavaScript without type coercion would have been safer and saner in my
opinion.

~~~
dexen
Type coertion is a language feature just like some other risky-yet-helpfull
features. Take for example pointers: any programming language without pointer
is safer†, but pointers help you express certain things concisely and thus
avoid some classes of bugs. Heck, a knife with dull blade is safer just as
well, but that doesn't increase its overall utility.

Compare with:

 _> UNIX was not designed to stop its users from doing stupid things, as that
would also stop them from doing clever things._ — Doug Gwyn

\--

†except that you can generate NullPtrException in the pointerless Java. Ask
yourself, WAT?

~~~
gambler
That's awfully generic and doesn't address the criticism. What are the
examples of useful type coertion? What do they achieve? Are there no better
ways to achieve those same goals without introducing bug-prone, WAT-inducing
behaviors?

For example, string concatenation could have been handled by a separate
operator.

~~~
prodigal_erik
To be fair, Eich was required to imitate java and finish in a couple of weeks
for marketing reasons, and string + int -> string was one of java's mistakes.

------
Achshar
Well i'v never understood the problems with JavaScript but maybe it's because
i haven't done things how other languages do it. But js is very "open" and
bound free. Especially with functions and objects. They make sense to someone
who is new to OOP. maybe its not follow how things are usually done in other
languages but that does not mean its necessarily a bad thing. If you think
something doesn't make sense that does not mean its wrong. i am learning c and
i have to say typed variables must be faster but they are difficult to gasp at
first. In fact its a nightmare to make variables of a certain type, it limits
my thought process when i have to think what the variable's type is after
every line of code. Strings look like a huge deal. The fact that i have to
predetermine the length of a string is laughable. Its my string and it can be
as long as i want it to be anywhere in my code. (yes i now sound immature but
this is my experience until now, call it a rant if you may) Alot of things
need to be known before we can write a meaningful program. Thats not the case
with js or even with php to some extent.

~~~
Peaker
These difficulties in C are not "craziness", they are for very good reasons.

Unbounded strings have much more complex and potentially less optimal
semantics than bounded strings, need to be allocated in different ways, etc. C
makes tight resource control possible, and to do that it sacrifices a lot of
ease. You have to think about resources when programming. In many scenarios,
this is a good thing.

~~~
slowpoke
_> C makes tight resource control possible, and to do that it sacrifices a lot
of ease._

I'm not a C programmer (yet), but I would say that depends on what you define
as "easy" or "simple". What I am is an Arch Linux user, and I embrace KISS -
Keep It Simple, Stupid. Arch understands "simple" as "technically elegant and
uncomplicated", but that doesn't mean it's easy to understand or foolproof to
use - for the inexperienced user, that is. C is an incredibly powerful tool
exactly because it is this kind of simple.

What I also am is someone who learned programming with Python, and I initially
couldn't understand the appeal of C-oid languages either. But I've since
realized it's all about using the right tool for the job. A programmer is a
mechanic, and a mechanic that only knows how to use a hammer is a pretty
useless mechanic (in general, of course. If all you deal with are nails then
it's not an impediment to your abilities).

~~~
Peaker
There's of course the view that a programmer is a mathematician :-)

But I agree we need various tools to cover the necessary ground.

------
bdg
>Error establishing a database connection

Does anyone have a mirror?

~~~
amirhhz
Yes, sorry, Caplin server's didn't expect the load! It's being worked on.

------
geraldalewis
> It can be a prefix ‘this number is positive’ operator where it operates on a
> single number.

`+` in this context is the "Unary + Operator" which coerces a value to a
number via the internal `toNumber` method of the operand.

It doesn't make the number positive:

    
    
        node> +-1 // -1

------
hcarvalhoalves
Automatic type coercion feels like a double-barreled shotgun, with one of the
barrels pointed back at you:

0\. Is only marginally useful 1\. You have to be careful with what are you
loading, and where 2\. Will sooner or later blow up in your face

------
logn
The syntax doesn't bug me too much. Most of it is documented fairly well. The
craziest thing about JavaScript is a lack of any good online reference for
their classes and methods. JavaScript documentation usually just resorts to a
key example or a brief description without covering all the details.

~~~
phoboslab
Mozilla's MDN is great:
<https://developer.mozilla.org/en/JavaScript/Reference>

~~~
jacobolus
Add “MDN” to any javascript-related google query to get the MDN page at the
top of the results page. Examples: “operator precedence mdn”, “string mdn”,
“slice mdn”.

------
onfocusin
don't explain it! you are killing the fun...

