4 ms·

If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no d

by ansman 14y ago

If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no difficulty learning CS if you know JS. I've been coding CS for over a year now and I like it, I've never found it hard to debug and it's just easier to read.

eurleif 14y ago
CoffeeScript's scoping is broken. http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffeescript/ http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffe...
- snprbob86 14y ago
  I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken". Lots more discussion here: https://news.ycombinator.com/item?id=3379962 https://news.ycombinator.com/item?id=3379962
  - ataggart 14y ago
    BTW, ClojureScript has proper lexical scope.
    - snprbob86 14y ago
      I'm not sure if you're telling me, or telling other folks in this thread, but for the record: I've fixed bugs in the ClojureScript compiler related to preserving the lexical scoping semantics :-) It's actually quite a tricky process and involves shadow tracking, symbol generation, self-calling function wrappers, and a bunch of other nonsense to deal with JavaScript's crummy semantics.
  - batgaijin 14y ago
    Um... I believe JS does have proper lexical scoping. Could you source any evidence to the contrary?
    - snprbob86 14y ago
      JavaScript's lexical scoping is function-level. There is no block level lexical scoping, so variables are "hoisted" to the containing scope. This is why people use the (function(foo){...})(bar) trick to create lexical scopes, such as when looping (CoffeeScript's `do` keyword embodies this pattern). In my opinion, "proper" lexical scope implies shadowing without hoisting.
      - dclowd9901 14y ago
        If you understand hoisting as a characteristic of JavaScript, its behavior is very predictable, and thus, hardly broken -- merely tricky if you've yet to encounter a hoisting-related issue. That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.
- notb 14y ago
  That article points out a design decision that the author disagrees with. It does not prove that CoffeeScript's scoping is broken.
  - eurleif 14y ago
    The whole point of lexical scoping is that code in an inner scope can't mess with an outer scope's variables without meaning to. CoffeeScript doesn't achieve that. The same code in an inner scope means different things depending on whether the outer scope uses the same variable names. It's broken.
    - notb 14y ago
      Lexical scoping is a term to classify languages. The 'point' is to make it easier to understand how a language behaves. If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE. Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/actually-YOU-dont-understand-lexical-scope.md https://github.com/raganwald/homoiconic/blob/master/2012/09/...
      - mistercow 14y ago
        Also, using really common identifier names (like "log") in outer scopes is a bad idea regardless of how your language's scoping works. Writing `{log} = Math` at the top of the file is just polluting your namespace for no good reason. You shouldn't do it, just like you shouldn't use `from math import *` in Python.
        eurleif 14y ago
        But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code). Enforcing best practices by throwing errors where other languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.
- rst 14y ago
  There are Coffeescript forks that try to deal with issues like this. Here's one that takes a different approach on a bunch of 'em, including the scoping: https://github.com/satyr/coco https://github.com/satyr/coco
- snogglethorpe 14y ago
  Of course, that link author suggests adopting a Python-like design instead, and Python is even more broken (Python has the most insanely awful scoping rules I've ever seen). Really the problem is implicit declarations of any sort; they're great for one-liners, but they really suck when you're writing real software. [But if you've gotta have 'em, please, at least don't copy Python...]
- jashkenas 14y ago
  Nope. CoffeeScript's scoping is working the way it's supposed to be ;) It's actually a funny thing -- out of all of the folks who actually have tried playing around with CoffeeScript in earnest (participated in issues or the mailing list), I can count on the fingers of one hand the number who have actually disliked working with the scoping semantics. There's a far larger number of folks who like to worry about the scope semantics without ever having tried it.
  - anon1385 14y ago
    In other words, No True CoffeeScript User dislikes the scoping rules…
msutherl 14y ago
Indeed, the claim that JavaScript developers can't read CoffeeScript seems odd to me. As a novice JS developer, I could read CoffeeScript the first time I saw it and it took me a day to be fluent. For me there's a noticeable productivity and enjoyment boost from the more terse syntax and that makes it more than worth it for me.
- elliotanderson 14y ago
  There's not doubt it is readable (I'm quite a fan of the language too) - the problem is with writing it as a novice. This post highlights some of the issues with magic and whitespace: http://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153/33 http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
  - msutherl 14y ago
    I don't know, you would just never write "foo = bar->". It looks bad and it's wrong. White-space sensitive languages are great because they reward you for writing with style, plus you don't have to worry about matching and aligning braces all the time.
chime 14y ago
I've made some pretty large apps in CS, by myself and in teams. So many good things in CS that I can no longer live without when writing front-end code: 1. @ = this 2. -> to => solves almost every context problem 3. Object notation by simply using colons ':' $('body').css color: 'red' background: 'blue' 4. statement if condition 5. jsondata?[2]?.hierarchy?.url 6. Optional brackets allow very terse/clean code: setTimeout -> statement , 1000 7. (function_argument = 'default_value') -> 8. Automatic return on last line 9. I also like how CS handles scoping, even though others might not. My very few globals are ALLCAPS and everything else is local scoped. I don't do things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere. Add jQuery/Backbone/Underscore/Bootstrap to the mix and you can develop some very large, complex apps with CS in a very clean way. Of course, people may not like some of the above syntax but I love not having to write/parse 2x as much code.
- goblin89 14y ago
  CS offers a lot of nice syntax sugar, indeed. It helps with many common mistakes made in JS code (missing `var`s and use of '==' operator come to mind). However, it also provides a few new ways to shoot yourself in the foot. Automatic return may be one example. Generally, thanks to terser syntax, the code may become illegible very quickly—especially in an environment with many contributors and little care about coding style. IMO successful CoffeeScript usage in larger projects requires strict coding guidelines. Maybe the language would even benefit from more ‘centralized’ and opinionated approach, like Python's PEPs.
- wereHamster 14y ago
  > 8. Automatic return on last line This is all good and fine until you realize that this will bite your ass when you need to write performance-sensitive code. So you end up with lots of explicit 'return' statements at the end of your functions. > 9. things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere. It's not only for saving keystrokes, but may also be improving performance. Some reason people add `local _G = _G` to the top of Lua source files to speed up access to _G.

by ansman 14y ago

eurleif 14y ago

CoffeeScript's scoping is broken. http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffeescript/ http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffe...

snprbob86 14y ago
I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken". Lots more discussion here: https://news.ycombinator.com/item?id=3379962 https://news.ycombinator.com/item?id=3379962
- ataggart 14y ago
  BTW, ClojureScript has proper lexical scope.
  - snprbob86 14y ago
    I'm not sure if you're telling me, or telling other folks in this thread, but for the record: I've fixed bugs in the ClojureScript compiler related to preserving the lexical scoping semantics :-) It's actually quite a tricky process and involves shadow tracking, symbol generation, self-calling function wrappers, and a bunch of other nonsense to deal with JavaScript's crummy semantics.
- batgaijin 14y ago
  Um... I believe JS does have proper lexical scoping. Could you source any evidence to the contrary?
  - snprbob86 14y ago
    JavaScript's lexical scoping is function-level. There is no block level lexical scoping, so variables are "hoisted" to the containing scope. This is why people use the (function(foo){...})(bar) trick to create lexical scopes, such as when looping (CoffeeScript's `do` keyword embodies this pattern). In my opinion, "proper" lexical scope implies shadowing without hoisting.
    - dclowd9901 14y ago
      If you understand hoisting as a characteristic of JavaScript, its behavior is very predictable, and thus, hardly broken -- merely tricky if you've yet to encounter a hoisting-related issue. That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.
notb 14y ago
That article points out a design decision that the author disagrees with. It does not prove that CoffeeScript's scoping is broken.
- eurleif 14y ago
  The whole point of lexical scoping is that code in an inner scope can't mess with an outer scope's variables without meaning to. CoffeeScript doesn't achieve that. The same code in an inner scope means different things depending on whether the outer scope uses the same variable names. It's broken.
  - notb 14y ago
    Lexical scoping is a term to classify languages. The 'point' is to make it easier to understand how a language behaves. If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE. Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/actually-YOU-dont-understand-lexical-scope.md https://github.com/raganwald/homoiconic/blob/master/2012/09/...
    - mistercow 14y ago
      Also, using really common identifier names (like "log") in outer scopes is a bad idea regardless of how your language's scoping works. Writing `{log} = Math` at the top of the file is just polluting your namespace for no good reason. You shouldn't do it, just like you shouldn't use `from math import *` in Python.
      - eurleif 14y ago
        But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code). Enforcing best practices by throwing errors where other languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.
rst 14y ago
There are Coffeescript forks that try to deal with issues like this. Here's one that takes a different approach on a bunch of 'em, including the scoping: https://github.com/satyr/coco https://github.com/satyr/coco
snogglethorpe 14y ago
Of course, that link author suggests adopting a Python-like design instead, and Python is even more broken (Python has the most insanely awful scoping rules I've ever seen). Really the problem is implicit declarations of any sort; they're great for one-liners, but they really suck when you're writing real software. [But if you've gotta have 'em, please, at least don't copy Python...]
jashkenas 14y ago
Nope. CoffeeScript's scoping is working the way it's supposed to be ;) It's actually a funny thing -- out of all of the folks who actually have tried playing around with CoffeeScript in earnest (participated in issues or the mailing list), I can count on the fingers of one hand the number who have actually disliked working with the scoping semantics. There's a far larger number of folks who like to worry about the scope semantics without ever having tried it.
- anon1385 14y ago
  In other words, No True CoffeeScript User dislikes the scoping rules…

msutherl 14y ago

Indeed, the claim that JavaScript developers can't read CoffeeScript seems odd to me. As a novice JS developer, I could read CoffeeScript the first time I saw it and it took me a day to be fluent. For me there's a noticeable productivity and enjoyment boost from the more terse syntax and that makes it more than worth it for me.

elliotanderson 14y ago
There's not doubt it is readable (I'm quite a fan of the language too) - the problem is with writing it as a novice. This post highlights some of the issues with magic and whitespace: http://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153/33 http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
- msutherl 14y ago
  I don't know, you would just never write "foo = bar->". It looks bad and it's wrong. White-space sensitive languages are great because they reward you for writing with style, plus you don't have to worry about matching and aligning braces all the time.

chime 14y ago

I've made some pretty large apps in CS, by myself and in teams. So many good things in CS that I can no longer live without when writing front-end code: 1. @ = this 2. -> to => solves almost every context problem 3. Object notation by simply using colons ':' $('body').css color: 'red' background: 'blue' 4. statement if condition 5. jsondata?[2]?.hierarchy?.url 6. Optional brackets allow very terse/clean code: setTimeout -> statement , 1000 7. (function_argument = 'default_value') -> 8. Automatic return on last line 9. I also like how CS handles scoping, even though others might not. My very few globals are ALLCAPS and everything else is local scoped. I don't do things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere. Add jQuery/Backbone/Underscore/Bootstrap to the mix and you can develop some very large, complex apps with CS in a very clean way. Of course, people may not like some of the above syntax but I love not having to write/parse 2x as much code.

goblin89 14y ago
CS offers a lot of nice syntax sugar, indeed. It helps with many common mistakes made in JS code (missing `var`s and use of '==' operator come to mind). However, it also provides a few new ways to shoot yourself in the foot. Automatic return may be one example. Generally, thanks to terser syntax, the code may become illegible very quickly—especially in an environment with many contributors and little care about coding style. IMO successful CoffeeScript usage in larger projects requires strict coding guidelines. Maybe the language would even benefit from more ‘centralized’ and opinionated approach, like Python's PEPs.
wereHamster 14y ago
> 8. Automatic return on last line This is all good and fine until you realize that this will bite your ass when you need to write performance-sensitive code. So you end up with lots of explicit 'return' statements at the end of your functions. > 9. things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere. It's not only for saving keystrokes, but may also be improving performance. Some reason people add `local _G = _G` to the top of Lua source files to speed up access to _G.