Live data from Hacker News

The Problem with Implicit Scoping in CoffeeScript

lucumr.pocoo.org

61–70 of 137 posts

Re: The Problem with Implicit Scoping in CoffeeScript

#61
post #42

Earlier quoted context omitted.

You are correct that variable scoping goes all the way to the top, but nobody is forcing you to create top-level variables with overloaded names like "log". Seriously, if you have a file that uses log files and logarithms, just take some care to distinguish the concepts. Use "log_file" for log files; use "logarithm" or "Math.log" for inverse exponentation.

> Use "log_file" for log files; use "logarithm" or "Math.log" for inverse exponentation. Just clarifying; are you actually suggesting this, or was that sarcasm?

It's a serious suggestion. Instead of introducing four top-level variables (log, sin, cos, and tan), just introduce one (Math) that wouldn't possibly conflict with a local.

Re: The Problem with Implicit Scoping in CoffeeScript

#62
post #36

FWIW this is how CS works: top_level_variable = null f = -> top_level_variable = "hello" f() console.log top_level_variable # prints hello

The concern is that because Coffeescript automatically scopes variables to the scope of their first reference, it can introduce maintenance issues. Consider the following: foo = -> bar = "woot!" console.log bar This compiles to: var foo; foo = function() { var bar; bar = "woot!"; return console.log(bar); }; bar is locally scoped to foo(). Now, 2 weeks later and 200 lines earlier, you come along and define: bar = -> a…

Thanks for this! Way better explanation than the blog post :)

Is there anyway to make the scope explicit in coffeescript?

Re: The Problem with Implicit Scoping in CoffeeScript

#63
post #5
post #2

Scheme got this right in 1970. There is no excuse to design a new language this way.

I agree with this wholeheartedly--Scheme use an extremely simple scoping model that is nonetheless more expressive than Python (before 3, I guess) and CoffeeScript's. In fact, I only really completely understood JavaScript's model--and realized that, even if a little awkward, it was fundamentally elegant--after writing a Scheme interpreter.

I think Python's is deliberately unexpressive, forcing you to use local variables pretty much everywhere. This tends to decouple stuff, which is usually good. The model is "everything you do is local, unless you know better, and want to jump through a lot of hoops". Coffeescript works a similar way.

Javascript seems to have the model "everything you do is global, unless you know better".

I'm not a big Javascript hater, but this is one very sore point.

Re: The Problem with Implicit Scoping in CoffeeScript

#64
post #54
post #47

Earlier quoted context omitted.

Perhaps you are being too hard on yourself. The majority (more than half) of the well known programmers truly are "superstars". It's all very subjective, though. Where is the standard for complexity or even cleverness? How is it different than simply being esoteric. Maybe I am personally fascinated with regular expressions and after much study, can belt out a half page of parse and extract 'magic' that would make the…

I think it has already been proven that there is no obvious correlation between being capable in mathematics and being a talented programmer. Thats so 1950's

Not a direct coorelation, but there is certainly a dependence on being capable in mathematics. A math wizard does not make a good programmer, but one cannot be hopelessly average in math and be a talented programmer.

Re: The Problem with Implicit Scoping in CoffeeScript

#65
post #36

Earlier quoted context omitted.

The concern is that because Coffeescript automatically scopes variables to the scope of their first reference, it can introduce maintenance issues. Consider the following: foo = -> bar = "woot!" console.log bar This compiles to: var foo; foo = function() { var bar; bar = "woot!"; return console.log(bar); }; bar is locally scoped to foo(). Now, 2 weeks later and 200 lines earlier, you come along and define: bar = -> a…

Thanks for this! Way better explanation than the blog post :) Is there anyway to make the scope explicit in coffeescript?

No. That's the crux of the complaint. In plain Javascript, you can use "var x" to scope x to the current scope (and in 1.7, you can use 'let' to scope to the current block, not just to a function), but there's no corollary in Coffeescript, since Coffeescript manages scoping for you automagically. It's a convenience 99% of the time, but the 1% of the time that it's not, it's a giant pain in the ass. If there were something like var/let/local, you could solve the problem manually, but as the Twitter exchange indicated, there is no plan to add it.

The solution/workaround is "use descriptive names and avoid polluting scopes", but the reality of software development is that you're eventually going to cross those wires, and it's going to make you crazy until you figure out what happened.

Re: The Problem with Implicit Scoping in CoffeeScript

#66
post #36

Earlier quoted context omitted.

The concern is that because Coffeescript automatically scopes variables to the scope of their first reference, it can introduce maintenance issues. Consider the following: foo = -> bar = "woot!" console.log bar This compiles to: var foo; foo = function() { var bar; bar = "woot!"; return console.log(bar); }; bar is locally scoped to foo(). Now, 2 weeks later and 200 lines earlier, you come along and define: bar = -> a…

Thanks for this! Way better explanation than the blog post :) Is there anyway to make the scope explicit in coffeescript?

Yes, create the variable as a function argument.

Re: The Problem with Implicit Scoping in CoffeeScript

#67
post #63
post #5

Earlier quoted context omitted.

I agree with this wholeheartedly--Scheme use an extremely simple scoping model that is nonetheless more expressive than Python (before 3, I guess) and CoffeeScript's. In fact, I only really completely understood JavaScript's model--and realized that, even if a little awkward, it was fundamentally elegant--after writing a Scheme interpreter.

I think Python's is deliberately unexpressive, forcing you to use local variables pretty much everywhere. This tends to decouple stuff, which is usually good. The model is "everything you do is local, unless you know better, and want to jump through a lot of hoops". Coffeescript works a similar way. Javascript seems to have the model "everything you do is global, unless you know better". I'm not a big Javascript hate…

"everything you do is global, unless you know better"

That is not the JavaScript model at all.

Re: The Problem with Implicit Scoping in CoffeeScript

#69

I found one of the referenced links in Github issue #712 quite interesting: http://www.rubyist.net/~matz/slides/rc2003/mgp00010.html Source: https://github.com/jashkenas/coffee-script/issues/712#issuec...

These links explain the thought process behind CS's current behavior:

https://github.com/jashkenas/coffee-script/issues/712#issuec...

https://github.com/jashkenas/coffee-script/issues/712#issuec...

Re: The Problem with Implicit Scoping in CoffeeScript

#70
post #63
post #5

Earlier quoted context omitted.

I agree with this wholeheartedly--Scheme use an extremely simple scoping model that is nonetheless more expressive than Python (before 3, I guess) and CoffeeScript's. In fact, I only really completely understood JavaScript's model--and realized that, even if a little awkward, it was fundamentally elegant--after writing a Scheme interpreter.

I think Python's is deliberately unexpressive, forcing you to use local variables pretty much everywhere. This tends to decouple stuff, which is usually good. The model is "everything you do is local, unless you know better, and want to jump through a lot of hoops". Coffeescript works a similar way. Javascript seems to have the model "everything you do is global, unless you know better". I'm not a big Javascript hate…

The point of the linked article is that this is not the CoffeeScript way at all (although the author wishes it was).
Post reply on HN