[serve_yay]

I agree, `this` is a disaster. But, I just can't hardly think of another language where the people working in it mostly don't know the types. (Well, OK, PHP devs probably mostly don't)

And I don't just mean run-of-the-mill blub programmers who dabble in jQuery, I mean some of the best devs I've ever seen in any language. I had a self-proclaimed JS expert tell me that JS has integers and floats as distinct types. Even the people I work with every day who are fantastic did not know that function and array are not types.

Of course, things like `typeof` don't help the situation, so I don't put the blame squarely on programmers' shoulders. And obviously you can get a lot done without knowing that, technically, functions are just objects that can be called. But it still strikes me as kinda crazy.

[barrkel]

"technically, functions are just objects that can be called"

How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'?

What happens when you try to call an object - what's the error? Try it, in a few of your favourite javascript interpreters:

    ({})()

It seems clear to me that functions are more than "just" objects in JS. You can't start out with a random {} and turn it into a function. JS functions are a subtype of JS objects, but they are a distinct type. You can't substitute an object where a function is expected - you get a type error - but you can substitute a function where an object is expected.

[serve_yay]

> How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'?

You can't, by definition. Here is the relevant section of the ECMAScript 5 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3

Basically, an object which implements call will always cause `typeof` to return "function". But the broader point is that `typeof` will lie to you and you shouldn't trust it for, you know, determining the types of values. (For example, the type of null is null, but `typeof null` returns "object".)

As I noted above, this behavior of `typeof` is part of what causes the confusion around types in JS devs.

> You can't substitute an object where a function is expected - you get a type error - but you can substitute a function where an object is expected.

This is true, but not inconsistent with the notion that functions are objects which can be called. I encourage you to read the spec I linked above, or a draft of ES6.

[barrkel]

There's types as defined in a spec, and types according to type theory.

In short, I think the spec is incorrect in its use of the concept of types; or incomplete.

You'll note that the spec uses the concept of "internal properties" to distinguish between the different things one can do with values. From a type theory perspective, these internal properties and the implied permitted operations come close to type definitions. It's a matter of perspective, then, when one is using the word 'type' as defined by a particular language's spec, or 'type' as in programming language pragmatics / type theory POV. For the generalist programmer who knows more than one language, a broader concept of types is usually more useful.

Further, the spec uses these internal properties solely to define the semantics of the language, and they are not necessarily visible artifacts of any implementation. Talking about them as if they were concrete confuses the map with the territory.

[foldr]

>Basically, an object which implements call will always cause `typeof` to return "function".

Are there any implementations which actually do this? In Node:

typeof({ call: function () { } }) --> 'object'

({ call: function () { } })() --> TypeError: object is not a function