41–50 of 51 posts
You need to get more benefit from the abstraction than the cost. I couldn't find it, in cs. I've made thousands of mistakes (on a daily basis it feels like). In 17 years I don't think I have ever once forgotten to put 'var' in front of a variable declaration.
its not about if you make the mistakes or not per se, its about the removal of unnecessary mental burdens.
> Always compile your code down to JavaScript before posting a question to StackOverflow, or replying to a blog post. You might even learn things about JavaScript itself, too. I don't see author's enormous arrogance backed by any efforts to think about his reasoning.
Are there people that seriously can't just read CoffeeScript as-is? Are there seriously people that can't scan through the CoffeeScript docs in about 20 minutes and pick up the language more or less? The first time I saw CoffeeScript I immediately realized, oh, fuck yes, this is obviously better, and switched over to it immediately. I was productive with it instantly. Is it really something worth spending your time a…
Earlier quoted context omitted.
Agreed completely. My only issue w/coffeescript is that, uh, I like clojurescript better. But clojurescript is all the things coffeescript is, just more ---further from javascript, more concise, less compatible with standard js tools.
coffee-script is not less compatible with standard js tools. Again, "it's just javascript" and you can use backticks in coffee to get embedded js. Common mistake made by coffee-script-nay-sayers.
Earlier quoted context omitted.
coffee-script is not less compatible with standard js tools. Again, "it's just javascript" and you can use backticks in coffee to get embedded js. Common mistake made by coffee-script-nay-sayers.
Give me a break, you know what I mean. When you look at the page source, do you see embedded coffeescript? Can you debug in coffeescript with the standard tools? I know these things aren't possible and shouldn't be expected b/c coffee is a "compiled" language...but you can do them in javascript, and telling the vanilla js programmer that they're "exactly the same" is being less than honest.
What really made the "vanilla js programmer" feel uncomfortable, I speculate, is the correct way of handling javascript oddities, such as handling nulls (`?` in coffee). They are daunting -- but ignorance is no excuse. Once you start to populate these patterns yourself in your javascript, not only would you immediately recognize them in coffee-generated js, but also you'd appreciate that coffee abstracted them.
I think these common points against coffee mostly apply to other compile-to-js languages such as clojure-script, where the generated code almost always made no sense to a "vanilla js programmer".
My biggest fear was debugging, but it was/has been absolutely no issue whatsoever.
Are there people that seriously can't just read CoffeeScript as-is? Are there seriously people that can't scan through the CoffeeScript docs in about 20 minutes and pick up the language more or less? The first time I saw CoffeeScript I immediately realized, oh, fuck yes, this is obviously better, and switched over to it immediately. I was productive with it instantly. Is it really something worth spending your time a…
Verification: lead development of 50MD and 300MD mobile html5 apps for major UK TV's and even people who did see CS first time were able to pick it up quickly. I had literally about 5 cases when I had to answer some chat questions on how CS works, and about the same count when I corrected/optimized some CS usage in a code review.
The productivity gain was impressive. In ducktyping, but esp. in __understanding__ the code quickly.
We're not going back.
Earlier quoted context omitted.
> does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing It can't because it's actually JS, by design. Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Maybe you'd rather be interested in ClojureScript or Dart, which use JS merely as a VM instead of their systemic core. > If a front-ender on my tea…
> Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Now we're effectively losing the "==" operator, which is behaving like in most other traditional scripting languages (e.g. Perl). What did we win by losing an operator? Why obfuscate that this is not the JS "==" operator but most likely the "===" operator?
> What did we win by losing an operator? Why obfuscate?
Type safety, and resistance against both bona fide errors and clueless developers. Sane defaults matter.
Earlier quoted context omitted.
coffee-script is not less compatible with standard js tools. Again, "it's just javascript" and you can use backticks in coffee to get embedded js. Common mistake made by coffee-script-nay-sayers.
Give me a break, you know what I mean. When you look at the page source, do you see embedded coffeescript? Can you debug in coffeescript with the standard tools? I know these things aren't possible and shouldn't be expected b/c coffee is a "compiled" language...but you can do them in javascript, and telling the vanilla js programmer that they're "exactly the same" is being less than honest.
Earlier quoted context omitted.
coffee-script is not less compatible with standard js tools. Again, "it's just javascript" and you can use backticks in coffee to get embedded js. Common mistake made by coffee-script-nay-sayers.
Give me a break, you know what I mean. When you look at the page source, do you see embedded coffeescript? Can you debug in coffeescript with the standard tools? I know these things aren't possible and shouldn't be expected b/c coffee is a "compiled" language...but you can do them in javascript, and telling the vanilla js programmer that they're "exactly the same" is being less than honest.