The baseless assertion rears its head again. People keep repeating this, and it's not true. JavaScript is not Scheme. It's not any more Scheme-like than Java, C++, Python, Perl, or many other languages. Lua and Ruby are far more Scheme-like than JavaScript.
I've commented before on people repeating this statement without ever examining it. I don't want to dredge up the arguments against it again ( http://news.ycombinator.com/item?id=1171202 ), mostly I just want to whine at it because it's so annoying. Why do you have to make JavaScript seem like something it's not? Are you trying to seem cooler by equating the language you work in to Scheme? What's wrong with JavaScript just being what it is?
In "Coders at Work", page 141, Brendan Eich talks about wanting to build a scheme-like language for the browser. The c-like syntax was adopted because Netscape wanted it to look like Java.
Scheme: First-class functions, tail-call elimination, macros,
hygienic macros, write and parse the AST directly.
JavaScript: First-class functions.
Scheme: Immutable arrays and lists, mutable strings.
JavaScript: Mutable-only arrays, immutable-only strings.
It is interesting to imagine what could have happened if Netscape had shipped with a Lisp. Probably a lot more people would hate Lisp today!
So I can't really agree that it's not any more Scheme-like than anything else out there. I do agree it's not particularly Scheme-like.
[1] IIRC eg in this presentation: http://www.infoq.com/presentations/The-State-and-Future-of-J...
'this' takes all of about 5 minutes to understand in Javascript. It's pretty logical and there aren't really any surprises. Same with the prototypal inheritance.
=== "Provides convenience functions for working with prototype chains." That has nothing to do with what makes the this keyword special in JavaScript, beyond prototypes affecting this' properties.
Yes, that's pretty much what an object system is, isn't it? It's some convenience behaviour, but it would be nice if the language had a built-in way of doing things that wasn't so inconvenient.
a=1
$a = 1;
function qqq() {
global $a;
unset( $a );
}
qqq();
var_dump( $a );
When running, I want enough flexibility to move freely but not so much that my knees break. When programming, I'd like to rely on "undefined" not being 6, and I'd even like to have a reasonable built in dictionary type that other code can't extend to add keys to by default, or overwrite "hasOwnProperty".
I.e. you just create reference to a global variable. Unsetting reference just breaks the tie between variable name and content.
Err, I tested this on Chrome's Inspector console, and I don't see such behaviour. The article says name should be undefined at the time of the comparison in the below code, but it isn't (and I frankly can't see why anyone would want it to be). Is this a feature of my execution environment, or have I just completely misunderstood what the author means?
(function(name){var cmp=name=="tim"; var name; return cmp})("tim") // returns true (function(name) { var cmp = function() { return name=="tim"; }; var name; return cmp();})("tim");
There's a $.hitch plugin in JQuery, it doesn't come with it by default.