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

The Problem with Implicit Scoping in CoffeeScript

lucumr.pocoo.org

Post reply on HN
Print view View original

71–80 of 137 posts

Re: The Problem with Implicit Scoping in CoffeeScript

#71

Post by masklinn »

nas wrote: post #45
showell30 wrote: post #16

Earlier quoted context omitted.

Well, fine, but Python2 had the inverse problem--you couldn't mutate top-level variables without awkward "global" statements.

Yes, and it's very uncommon that you need to do that. I learned Scheme years ago before I learned Python (in 1993, I think). At first I was dismayed by Python's lack of non-local assignment. However, in years of Python programming I can count the times I needed the ability on one hand. I haven't yet found a need for 'nonlocal'. Obviously it depends on programming style. In Coffeescript you don't have something akin t…

> However, in years of Python programming I can count the times I needed the ability on one hand. I haven't yet found a need for 'nonlocal'.

Might have to do with Python itself as well: because it's function-scoped and it tends to avoid higher-order function (in part due to the limitations of its anonymous functions), there are far less occasions write to lexical closures than in Scheme, Smalltalk or Ruby.

Re: The Problem with Implicit Scoping in CoffeeScript

#72

Post by dtf »

the_mitsuhiko wrote: post #29
showell30 wrote: post #23

Earlier quoted context omitted.

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…

> I wish that he would allow comments on his blog. Why? Hackernews and reddit exist and everybody is free to send me a mail or contact me on twitter. This way I do not have to moderate any comments or deal with spam. > 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. And do what? Duplicating an issue that is already there?…

For what it's worth, thanks for that detailed article. I've just used Coffeescript for a large-ish WebGL project and had no idea of that behaviour. I got freaked out when I got to the bottom of that first fragment and saw log vs log.

I'm going to keep using Coffeescript, I love it. Maybe this kind of scoping isn't the best decision for modularity and teamwork, but on reflection at least the rules are simple and consistent enough for a single programmer to keep in mind.

Re: The Problem with Implicit Scoping in CoffeeScript

#73

Post by rimantas »

the_mitsuhiko wrote: post #29
showell30 wrote: post #23

Earlier quoted context omitted.

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…

> I wish that he would allow comments on his blog. Why? Hackernews and reddit exist and everybody is free to send me a mail or contact me on twitter. This way I do not have to moderate any comments or deal with spam. > 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. And do what? Duplicating an issue that is already there?…

  > How else should I communicate that?
Who says you should?

Re: The Problem with Implicit Scoping in CoffeeScript

#74

Post by barrkel »

equark wrote: post #55
oinksoft wrote: post #6

@mitsuhiko Not gonna happen ;) Forbidding shadowing altogether is a huge win, and a huge conceptual simplification. How arrogant! You'd think he'd step back for a second and consider the suggestion, but it sounds like he's on autopilot.

Don't jump the gun. The reason is that he's already had many discussions about this and has formed an opinion. See: https://github.com/jashkenas/coffee-script/issues/712 https://github.com/jashkenas/coffee-script/issues/238 Whether he's right is another question. But if you don't like his decision you can use the Coco ( https://github.com/satyr/coco ) fork which fixes it by introducing := for nonlocal assignment.

The reasoning basically seems to be "if you misuse this feature (i.e. have top-level symbols), you'll get bugs (like the OP discovered), therefore don't misuse this feature (i.e. keep your top scopes clean), and therefore you won't get bugs, and therefore it's not a problem with CoffeeScript".

It shouldn't take a lot of thought to see why this is a somewhat user-hostile, passive-aggressive approach for a language. If something is ill-advised, the language should actively steer you away from it, not dissuade you with subtle bugs a few thousand lines of code down the road.

I think this scheme would be more workable if sigils or similar conventions of some kind were mandatory for top-level symbols. Then it would be much harder to accidentally wander into this problem. The language he seems to be drawing inspiration from, Ruby, does do this.

Re: The Problem with Implicit Scoping in CoffeeScript

#76

Post by itmag »

strait wrote: post #47
tjholowaychuk wrote: post #30

Earlier quoted context omitted.

99% of the popular people out there are just above average enough to make useful projects for those lesser experienced. Most truly talented people are not very well known, they're busy hacking on v8, the kernel etc. Tools for average programming just get more of a spotlight. Is Express complex? no, people just use it, is coffeescript complex? no, is boostrap complex? no..

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…

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 working and extendable program in a reasonable amount of time, that does something new and useful.

I would also say a criterion is that he really understands abstraction and how to get more from less. Ie think of how John Carmack creates abstraction which is just right for the problem (and in C at that). Or think about the metalinguistic paradigm in programming (or OOP used right, for that matter). Or how JQuery (and these days Coffeescript) makes client-side web code clean and accessible to everyone, without the previous Javascript hacks and DOM-spaghetti. An average programmer just plods along and hacks out a solution in a linear manner, a great programmer will traverse levels of abstraction to not only solve the problem but also shine a light at it from a superior perspective.

Re: The Problem with Implicit Scoping in CoffeeScript

#77

Post by locci »

showell30 wrote: post #33
locci wrote: post #20

Earlier quoted context omitted.

I think this is a recurring discussion from the dawn of coffeescript. See for example: https://github.com/jashkenas/coffee-script/issues/238 I really don't understand why this isn't being fixed: doesn't global by default break encapsulation? I'm probably missing something, but this is the main reason I haven't tried coffeescript yet.

Just to be completely clear, variables are only at top level scope if you declare them at top-level scope. The variables "x" below are completely encapsulated within f1 and f2. The variables at top-level scope are intentional in the code below--I really do intend f1, f2, and how_many_times_functions_have_been_called to refer to the same entity throughout the file. how_many_times_functions_have_been_called = 0 f1 = ->…

Yes, I probably wasn't very clear: what I meant is that a programmer writing a function somewhere in a program must have a complete knowledge of the scope where the function is and will be in the future, including changes in global variables exposed by the interpreter/browser. In the end I would find me forced to add a prefix to all the variables in order to avoid collisions, just like I would be forced to do, if the language only had a single global scope.

This behaviour seems quite unreasonable to me, but I haven't been able to find explanations about it, other than it's expected behaviour.

Re: The Problem with Implicit Scoping in CoffeeScript

#78

Post by iso8859-1 »

strait wrote: post #64
murloc wrote: post #54

Earlier quoted context omitted.

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.

Average of what? I'd bet 80% of 40-year-olds wouldn't be able to pass a high school level maths exam.

Re: The Problem with Implicit Scoping in CoffeeScript

#79

Post by iso8859-1 »

tjholowaychuk wrote: post #38
murloc wrote: post #35

Earlier quoted context omitted.

Easy, he hand picked a 100 people of the JS community (including him) and then decided that hes the only competent programmer amongst them.

umm no haha, I'm certainly amongst the average. Trust me writing parsers is very trivial, I've written many. Thinking you're a good programmer is perhaps the most naive thing you can do

Parsing: the solved problem that isn't: http://news.ycombinator.com/item?id=2327313

Re: The Problem with Implicit Scoping in CoffeeScript

#80

Post by cheald »

notSorella wrote: post #24
showell30 wrote: post #16

Earlier quoted context omitted.

Well, fine, but Python2 had the inverse problem--you couldn't mutate top-level variables without awkward "global" statements.

That's a whole different matter, which can't make you shoot yourself in the foot without knowing it for any non-trivial code. CoffeeScript's scoping forces you to always keep track of whatever is enclosing the current scope ALL THE WAY TO THE TOP. This is way too much when your function doesn't need to access outer variables (which should be the minority of the cases). So, problem is, you either make all your functio…

I actually agree with his stance against shadowing variables, just on philosophical grounds. It encourages good, descriptive naming. On the other hand, I acknowledge that sometimes it's desirable to shadow outer variables. I think it should be discouraged, but not prevented.

I think the big problem with Coffeescript's behavior is that it can introduce some damn subtle bugs that can be really hard to track down if you don't know what you're looking for, because you're not able to explicitly specify scope semantics. It's even worse if you're polluting higher-scope variables of the same type, because it becomes even less obvious where the error comes from.

Coffeescript more or less shares Ruby's scoping rules, but there's a cultural difference between the Ruby and Javascript communities that makes it a little less workable in Javascript. Specifically, Ruby's "everything is an object", aggressive use of namespacing, and the general idiom that only constants go into the global namespace tends to limit scope issues that could arise from mix-ins.

Coffeescript does attempt to mimic this by providing class semantics and wrapping everything in anonymous functions to limit scope leak, but there's still a lot of temptation to just create a bunch of top-level functions, and that leads to situations like the one described in the blog post.

Post reply on HN