The Problem with Implicit Scoping in CoffeeScript • Hacker News Board

Re: The Problem with Implicit Scoping in CoffeeScript

#91

Post by Someone » Thu, Dec 22, 2011, 1:42 PM UTC

whateverer wrote: post #89

wisty wrote: post #63

Earlier quoted context omitted.

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…

No, the Javascript model is "you name things with `var`, you mutate things with `=`". Python went for a more complicated scheme of having every variable in a function be a new binding when first assigned, and then it's just mutation (i.e. 'local'), unless explicitly declared to be nonlocal, but it still makes sense with their... penchant for mutable state. And Coffescript instead went over to PHP to have some of the…

No, the Javascript model is "you name things with `var`, you mutate things with `=`".

If only it were that simple. It also has "you create thing with `var` and sometimes with `=`", plus it does not have block scope:

    if( true)
    {
       var x = 1;
    }
    // x == 1 here.

Re: The Problem with Implicit Scoping in CoffeeScript

#92

Post by showell30 » Thu, Dec 22, 2011, 1:45 PM UTC

the_mitsuhiko wrote: post #81

showell30 wrote: post #61

Earlier quoted context omitted.

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.

The CoffeeScript sourcecode itself does not advocate it. It uses functions named like 'last', 'starts', 'ends', 'extend' etc.

You are correct about "last", "start's, etc., but there are also good examples in the CS sourcecode of easily avoiding naming conflicts with a sensible naming convention:

  browser.coffee:CoffeeScript = require './coffee-script'
  coffee-script.coffee:{Lexer,RESERVED} = require './lexer'
  coffee-script.coffee:    {Module} = require 'module'
  command.coffee:{EventEmitter} = require 'events'
  grammar.coffee:{Parser} = require 'jison'
  lexer.coffee:{Rewriter, INVERSES} = require './rewriter'
  nodes.coffee:{Scope} = require './scope'
  nodes.coffee:{RESERVED} = require './lexer'
  repl.coffee:{Script}     = require 'vm'

Re: The Problem with Implicit Scoping in CoffeeScript

#93

Post by colin_jack » Thu, Dec 22, 2011, 1:50 PM UTC

showell30 wrote: post #23

statictype wrote: post #13

Earlier quoted context omitted.

Everyday there seems to be a new post on HN, complete with inflammatory headline, criticizing Coffeescript in someway because it doesn't work in the exact way the author expected. There are lots of people throwing in their $0.02 on how the language should work without having joined the mailing list or seen any discussions on the thought process behind its features. I'm not saying the suggestion made isn't reasonable,…

In fairness, Armin (the author the blog post) did engage Jeremy (the author of coffeescript) on this issue over twitter. I wish that he would allow comments on his blog. I also wish that he could engage the broader CS community in a proper forum before dissing the language and/or creating a fork of the language. He's overreacting. This whole blog post apparently started because he had a naming collision with "log" in…

> He's overreacting. This whole blog post apparently started because he had a naming collision with "log" in one of his programs

Surprised at that reaction, he's had a problem and he's written an excellent blog post about it.

Re: The Problem with Implicit Scoping in CoffeeScript

#94

Post by lnanek » Thu, Dec 22, 2011, 1:54 PM UTC

swannodette wrote: post #67

wisty wrote: post #63

Earlier quoted context omitted.

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.

He is talking about if you don't do anything extra (in this case, use the var keyword). Much like the nonlocal keyword in Python requires knowing about it and wanting to use it in order to actually use it and get the non-default behavior.

Re: The Problem with Implicit Scoping in CoffeeScript

#95

Post by cvshepherd » Thu, Dec 22, 2011, 2:25 PM UTC

> The simple solution is to either add a nonlocal keyword like Python has or to introduce a := parameter that works like = but explicitly overrides a higher level variable.

I disagree. The simple solution to this is to write tests.

Re: The Problem with Implicit Scoping in CoffeeScript

#96

Post by the_mitsuhiko » Thu, Dec 22, 2011, 2:48 PM UTC

mhansen wrote: post #90

I'll copy below jashkenas' longer answer from the old github issue about this, https://github.com/jashkenas/coffee-script/issues/712#issuec... """ Sorry, folks, but I'm afraid I disagree completely with this line of reasoning -- let me explain why: Making assignment and declaration two different "things" is a huge mistake. It leads to the unexpected global problem in JavaScript, makes your code more verbose, is a hug…

> As an existence proof, Ruby gets along just fine without it.

Missing that Ruby stops scoping variables at a method and uses separate lexical scoping rules for constants thereby avoiding this issue mostly.

Re: The Problem with Implicit Scoping in CoffeeScript

#97

Post by the_mitsuhiko » Thu, Dec 22, 2011, 2:54 PM UTC

tjholowaychuk wrote: post #88

itmag wrote: post #76

Earlier quoted context omitted.

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 uninitiated shake their head and crown me a genius. Sounds interesting, tell me more. Personally, I would say that a truly talented programmer is simply someone who is very capable in mathematics and can produce a work…

jQuery nor coffeescript really imply "clean" client-side code, in fact I would argue that most uses of jQuery are the opposite if you compare communities like mootools. As far as coffeescript goes you still need a good sense of structure like regular javascript, nothing new there really.

Mootools still disqualifies itself in my mind by patching around on builtins.

Re: The Problem with Implicit Scoping in CoffeeScript

#98

Post by tjholowaychuk » Thu, Dec 22, 2011, 2:57 PM UTC

the_mitsuhiko wrote: post #97

tjholowaychuk wrote: post #88

Earlier quoted context omitted.

jQuery nor coffeescript really imply "clean" client-side code, in fact I would argue that most uses of jQuery are the opposite if you compare communities like mootools. As far as coffeescript goes you still need a good sense of structure like regular javascript, nothing new there really.

Mootools still disqualifies itself in my mind by patching around on builtins.

certainly, but that's besides the point. If you look at the jQuery community vs the others, jQuery's is filled with much much more spaghetti code

Re: The Problem with Implicit Scoping in CoffeeScript

#99

Post by swannodette » Thu, Dec 22, 2011, 3:36 PM UTC

lnanek wrote: post #94

swannodette wrote: post #67

Earlier quoted context omitted.

"everything you do is global, unless you know better" That is not the JavaScript model at all.

He is talking about if you don't do anything extra (in this case, use the var keyword). Much like the nonlocal keyword in Python requires knowing about it and wanting to use it in order to actually use it and get the non-default behavior.

var is not extra in JavaScript the way nonlocal is in Python. var is a language construct that any good JavaScript program must use.

Re: The Problem with Implicit Scoping in CoffeeScript

#100

Post by swannodette » Thu, Dec 22, 2011, 3:47 PM UTC

mhansen wrote: post #90

I'll copy below jashkenas' longer answer from the old github issue about this, https://github.com/jashkenas/coffee-script/issues/712#issuec... """ Sorry, folks, but I'm afraid I disagree completely with this line of reasoning -- let me explain why: Making assignment and declaration two different "things" is a huge mistake. It leads to the unexpected global problem in JavaScript, makes your code more verbose, is a hug…

and well-factored code has very few variables in the top-level scope -- and they're all things like namespaces and class names

Unless you happen to embrace JavaScript's functional side and write lots of top level helper functions (in a closure of course after which you export)

shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope.

This smells of static enforcement - strange for a language expounding JavaScript's dynamic nature and an odd departure from "it's just JavaScript".

Shadowing doesn't fit well in languages with closures-by-default

Not sure what evidence this is based on given the heap of great languages with closures-by-default that give programmers more control over scope without introducing goofy constructs like special assignment operators or global/nonlocal keywords.

CoffeeScript breaks the one real form of encapsulation (which includes the power of naming) that JavaScript has - function locals.