Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: what is "this"?

howtonode.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: JavaScript: what is "this"?

#41

Post by avibryant »

tumult wrote: post #6
audionerd wrote: post #4

Earlier quoted context omitted.

I think the author is just citing how influential Scheme was to JavaScript's design. 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.

Maybe he wanted to. If that was his goal, I think he failed. 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. Yes, I have, and have read, Coders at Work. I don't see how it's relevant. JavaScript and Scheme shar…

Oh, come on, you're cherry picking the features that suit your argument. If we include "garbage collected", that gets rid of C and C++. If we include "dynamically typed", that gets rid of OCaml, ML, Haskell. If we include "single namespace for functions and variables", that gets rid of Ruby, Io, and Perl. Now we're down to JavaScript, Python, and Scheme, which, yes, are all in basically the same family of languages. If you add the (admittedly subjective) feature "small language spec", that gets rid of Python, and we're left with JavaScript and Scheme as the only two mainstream languages with that particular feature set.

Re: JavaScript: what is "this"?

#42

Post by avibryant »

tumult wrote: post #6
audionerd wrote: post #4

Earlier quoted context omitted.

I think the author is just citing how influential Scheme was to JavaScript's design. 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.

Maybe he wanted to. If that was his goal, I think he failed. 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. Yes, I have, and have read, Coders at Work. I don't see how it's relevant. JavaScript and Scheme shar…

They share only one defining feature? Bullshit. If we include "garbage collected", that gets rid of C and C++. If we include "dynamically typed", that gets rid of OCaml, ML, Haskell. If we include "single namespace for functions and variables", that gets rid of Ruby, Io, and Perl. Now we're down to JavaScript, Python, and Scheme, which, yes, are all in basically the same family of languages. If we include the (admittedly subjective) feature "small language spec", that gets rid of Python, and we're left with JavaScript and Scheme as the only two mainstream languages with those particular defining features.

If I were describing JavaScript to someone who was a programming language expert but somehow was never exposed to it, I would describe it as "Scheme, with C syntax, no tail calls, and a strange prototype-based object system".

Re: JavaScript: what is "this"?

#43

Post by jimbokun »

devinj wrote: post #13
tumult wrote: post #3

It's not entirely our fault, the language was designed to work like one thing (scheme-like), but look like another (c-like). 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 repea…

Egh, some of those other languages are more Scheme-like than others. In particular, Javascript is certainly more scheme-like than Java, which lacks even first-class functions, for example. And, well, Python is basically just Lisp with different syntax (or so Norvig claims; I'm not sure I'd go that far: http://norvig.com/python-lisp.html ). So I can't really agree that it's not any more Scheme-like than anything else…

Javascript's scoping is also closer to Scheme's lexical scoping, I think. If you always use var for local variables, their scope will always be the immediately enclosing function. With Python, the scope of a variable is less clear. To me, the combination of first class functions, anonymous function syntax, and lexical scope are very high on the list of features that make a language "Scheme-like."

Re: JavaScript: what is "this"?

#44

Post by demallien »

erlanger wrote: post #37
tolmasky wrote: post #36

Earlier quoted context omitted.

1. As described this has serious issues when you reach depths greater than 1. This is why prototype has to use the hack of passing in a special super variable through the function arguments. This is also why in ExtJS, doing something that in any other language is a simple "super.method()" requires doing the following (from their own subclassing examples): Ext.ux.IconCombo = function(config) { // call parent construct…

> The "var fn" of course doesn't work with private member variables since you need one for each individual instance, This makes me believe that you have no idea what you're talking about.

That is just a ridiculous thing to say to Francisco Tomalsky - I think he's already demonstrated that he knows a thing or two about hacking JavaScript (see Cappuccino - http://cappuccino.org/learn/). How about you respond by giving us a code example that shows how he is wrong, rather than trolling?

Re: JavaScript: what is "this"?

#45

Post by devinj »

jimbokun wrote: post #43
devinj wrote: post #13

Earlier quoted context omitted.

Egh, some of those other languages are more Scheme-like than others. In particular, Javascript is certainly more scheme-like than Java, which lacks even first-class functions, for example. And, well, Python is basically just Lisp with different syntax (or so Norvig claims; I'm not sure I'd go that far: http://norvig.com/python-lisp.html ). So I can't really agree that it's not any more Scheme-like than anything else…

Javascript's scoping is also closer to Scheme's lexical scoping, I think. If you always use var for local variables, their scope will always be the immediately enclosing function. With Python, the scope of a variable is less clear. To me, the combination of first class functions, anonymous function syntax, and lexical scope are very high on the list of features that make a language "Scheme-like."

How are Python's scoping rules less clear? They are identical to Javascript's (and Scheme's), except that instead of defaulting to global scope, they default to local scope (which can be overridden with `global foo`). Also, it has one extra kind of scope, class scope. I would agree with you if you said Python's class scope is rather strange, of course.

Re: JavaScript: what is "this"?

#46

Post by sesqu »

The var statement declares a variable as local to the current scope and the entire current scope, not just from the var statement onward. These local variables shadow any existing variables from outer scopes.

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

Re: JavaScript: what is "this"?

#47

Post by papercrane »

sesqu wrote: post #46

The var statement declares a variable as local to the current scope and the entire current scope, not just from the var statement onward. These local variables shadow any existing variables from outer scopes. 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…

Since the comparison happens before var is declared, it will always evaluate to 'true'. I believe the author was thinking about something like so:

    (function(name) { var cmp = function() { return name=="tim"; }; var name; return cmp();})("tim");
This still evaluates to true, but I believe it has to do with the rules of shadowing. If you change the declaration to 'var name="bob";' it will return false.

Re: JavaScript: what is "this"?

#48

Post by creationix »

sesqu wrote: post #46

The var statement declares a variable as local to the current scope and the entire current scope, not just from the var statement onward. These local variables shadow any existing variables from outer scopes. 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…

Good catch, I'm looking into this one. I know I've seen this behavior before in some JS environment. I'm glad it's not the case for V8 and will shortly update the article.

Re: JavaScript: what is "this"?

#49

Post by xtho »

tumult wrote: post #11
xtho wrote: post #8

Earlier quoted context omitted.

This point of view is also maintained by D Crockford[1] who is supposed to know JavaScript's background. [1] IIRC eg in this presentation: http://www.infoq.com/presentations/The-State-and-Future-of-J...

"Some other guy who other people say is right said something similar. Here is a link to a talk he once did."

Some guy who happens to be a member of the ecmascript committee ...
Post reply on HN