That said, the annoying ones for me are links to Google+ things, the URL says "google.com" but the content is various.

[1]: http://js2coffee.org/

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.

Lots more discussion here: https://news.ycombinator.com/item?id=3379962

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.

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/...

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.

My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.

Please don't say something along the lines of, 'If you hire bad coders, what do you expect to happen?' Bad coders are almost inevitable, and their harm should be confined to code they actually write. Their bad code shouldn't have spooky action at a distance on good code someone else wrote.

Of course you can. You simply enclose the block in an immediate function (using "do") and declare your local variables as parameters to the function. Do that, and it is impossible for any outer scope to screw your code up.

If you're working on a project where lots of coders of questionable aptitude are going to have commit access, you make declaring local variables this way a required convention.

If you're working on a project where changes get approved by a small number of capable maintainers, then you:

1. Do not allow commits that create short or common names (i, x, arr, log, etc.) in high scope levels, and

2. Require that short or common names in inner scopes be declared using local scoping via "do".

Now, should CoffeeScript give some nicer sugar to encourage this kind of local variable use? Yes, probably. But it is incorrect to say that CS doesn't give you the tools to protect yourself from outer scope pollution.

https://github.com/satyr/coco

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...]

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.

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.

http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

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.

1. @ = this

2. -> to => solves almost every context problem

3. Object notation by simply using colons ':'

    $('body').css
      color: 'red'
      background: 'blue'

5. jsondata?[2]?.hierarchy?.url

6. Optional brackets allow very terse/clean code:

    setTimeout ->
      statement
    , 1000

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.

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.

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.

you can get it to work on mobile safari in portrait if you zoom in / out ... but that just too hacky

You might want to try providing it in HTML format.

maybe people should stop writing unindented ugly blocks in their non-indent-significant language then?

In C if I shift a block of code a quick gg=G will reformat and reindent. Possible because blocks are explicit and whitespace is separate from scope. By the same token autogeneration of {}'s is impossible in C. This is obvious but obfuscated in Python from whitespaces' overloading.

The issue is autogeneration of blocks. In any language blocks are a fundamental aspect of programming. Blocks affect the function of a program. Since we lack self-programming computers we also lack autogeneration of blocks. Python's issue is that a non-fundamental aspect of programming has been paired with a fundamental aspect of programming.

Python's "issue" is that it considers readability as a fundamental aspect of programming and that whitespace is critical to that end. Whether that suits a particular programmer is a matter of personal preference.

Oh I beg to differ. I've seen lots of terrible unindented or patchily-indented code. Especially in Wordpress plugins.

One can write readable code with Coffeescript , i use parenthesis in big scripts because it is more readable , and i dont use classes where not appropriate.

CS helped me write better javascript without the badparts so i dont need to be a human compilator and fix javascript each time i write it. I should not have to.

http://mparaiso.github.com/Coordinates.js/

It is not for everyone , but significant white spaces are not a problem if one is used to indent his code properly. I tried typescript too , which is good, but i found coffeescript more expressive. The truth is , i enjoy writing CS , i dont writing JS.

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

How the hell am I suppose to read that?

Someone said that CoffeeScript is designed to be more writable than readable, and I'd tend to agree with that. But frankly, after having worked with it for the better part of a year, I prefer reading it than JS for just about everything. It's an acquired taste, but don't knock it till you try it :)

it's not exactly a shining example of good coffeescript, but I think this is equivalent js

    MyApp.president = Ember.Object.create({
        fullName: function(){
            return this.get('firstName') + ' ' + this.get('lastName');
        }.property('firstName', 'lastName')
    })

    MyApp.president = Ember.Object.create
        fullName: (
            -> "#{@get 'firstName'} #{@get 'lastName'}"
        ).property('firstName', 'lastName')

Anyway, style does matter and were this line written with readability in mind you wouldn't make this mistake.

Also, I would definitely abstract over @get and property:

    makeProperty = (attrs...) -> 
        func = () -> (@get(x) for x in attrs).join(" ")
        func.property(attrs...)

    MyApp.president = Ember.Object.create(
        fullName: makeProperty("firstName", "lastName")
    )

If you write beautiful javascript, you will write beautiful coffeescript and it will be 20-60% smaller. Reading less lines is less reading, this helps me.

MyApp.president = Ember.Object.create(({fullName: (function() {return this.get('firstName')+' '+this.get('lastName');}).property('firstName', 'lastName')}));

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

Since Discourse is planning on being around long after ES6 becomes widely available, it was a winning argument.

http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

Also, one of the big reasons the Discourse devs liked CoffeeScript is because it makes it hard to commit common JS errors. Building JSHint into their workflow can help bring this protection back.

There's other perfectly valid reasons to use pure-JS on a large open source project, but the ES6 thing is a red herring IMHO.

2) One may prefer a more explicit language, filled with semicolons, curly braces, and "function" functions.

That said, I personally would have greatly preferred it as CoffeeScript, which I use regularly on projects where the people I work with have the same preference.

The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then.

For me it's not hard to imagine a CoffeeScript 2.0 release at some point next year that targets ES6. It could make a few syntax changes, and ship with some helper tools (or a 3rd would create it) to detect possibilities in your previous code and tell you where you need to tweak to make it compatible.

Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then; there's no reason it has to happen now.

Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

CoffeeScript is to JavaScript as Closure is to the JVM.

Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.

So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.

But the new features of ES6 aren't features of CoffeeScript. Why would we expect them to be?

It's like noting that Java 7 adds support for strings to switch statements and wondering how the syntax of Closure is going to change in response.

There is no strict requirement for the languages to be tied together at a syntax level, they just "compile" to something compatible.

There may be strong technical reasons for the CoffeeScript compiler to take advantage of the new features of ES6, but that doesn't force a change to CoffeeScript-the-language. (In other words, it can target ES6 while remaining backward compatible.)

I wouldn't be surprised to discover I'm missing something, but I'm genuinely confused why this is seen as a technical problem. It's not that CoffeeScript-the-language is "not interested in the new features of ES6", but that, technically speaking, CoffeeScript-the-language is not interested in ES-the-language at all.

Apples and oranges. (Or maybe lemons and limes.)

As an aside, I do see this as a potential social problem. CoffeeScript would probably like to remain conceptually-compatible with JavaScript, and that gets much harder if the two have different semantics for similar syntax-es, but I'm going to guess this isn't the only example of it.

"First, Dvorak is very good at keeping fingers on home row - 71% of keystrokes land there (compare this with 34% for QWERTY). This alone is worth the price of admission. Dvorak bottom row usage is very low at 9% (15% for QWERTY). Dvorak favours the right hand by 14% (QWERTY favours left by 15%). Dvorak has more uniform finger usage and makes greater use of the pinky (18% vs QWERTY's 10%). The cumulative run statistics illustrate Dvorak's strength in alternating hands. 62% of successive keystrokes on Dvorak do not use the same hand (rh(0)) and 88% of adjacent keystrokes use the same hand at most once (rh(1)). In contrast, with QWERTY only 51% of successive keystrokes do not use the same hand and only 76% use the same hand at most once. QWERTY forces the typist to use the same hand repeatedly, which limits the amount of rest and increases effort. Dvorak's preference for the use of the right-hand give it longer right hand runs with only 47% of keystrokes that use the right hand being followed by use of the left hand (61% for QWERTY). The corresponding statistic for the left hand is reversed, with Dvorak at 76% and QWERTY at 42%."[1]

The authors of the Reason Magazine article from 1996 that you linked to stated that "Ergonomic studies also confirm that the advantages of Dvorak are either small or nonexistent." But the authors cited only one nameless, undated study. This promotion of QWERTY isn't surprising seeing as how Reason Magazine is written by ideologues whose goals include the promotion of the idea that the invisible hand of the market is never wrong.

You should consider getting your information from specialists who are active researchers rather than the writings of non-specialists from previous decades.

[1] http://mkweb.bcgsc.ca/carpalx/?dvorak

I would stick with CoffeeScript until it becomes painful. There is relatively little downside risk. If and when you have great people refusing to contribute code because they hate CoffeeScript, well, that'll be a pain point. On the other hand, what if you get a bunch of other people who like contributing code because they can do it in CoffeeScript?

Are there meaningful statistics collected? Until there are, or at least a weighty collection of anecdotes, I'm sure there's something more important to worry about.

Also it looks like one of the core dev doesn't like CS much, which might have precipitated things a bit [1].

[1] http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

The sheer mass of anti-CoffeeScript FUD ironically makes it more likely that they'll get more contributions if they go back to JavaScript. ;) YOU might know people who seriously consider Erlang and Clojure, but most people respond badly to superficial syntactical differences.

Of course, is "contributions" really the best metric? What about productivity or quality? And can they make it so that people can easily contribute JavaScript?

(Even among people I know, I've heard such irrational FUD against CoffeeScript. And I know it's FUD because none of their boogiemen came true after I aggressively introduced it into their codebase. They now use it every day without concern. Most people hate innovation, including programmers.)

In particular, the ES6 argument sounds like FUD. Did they link to timelines and CoffeeScript developers' opinions? And where's the tradeoff analysis comparing the immediate productivity benefits of CoffeeScript vs some future ES6 event?

Now, this only affects the first official client. I imagine that there will be a CS port of the JS client as soon as the switch is made. That's the great thing about using a client to a REST API - you can have several different front-ends. If this was to be the only client, I'm not sure if I would support using JS over CS.

(btw, I'm @benaiah on meta.discourse.org - I'm in the referenced thread)