Magic overdose.

Compare with Go, where you can easily read the whole spec and keep the whole language in your head: http://golang.org/ref/spec

Go is an excellent contrast. Not only is the syntax spartan, but--especially if you include the built-in formatter gofmt--it has a fascist insistence on a uniform coding style. I don't agree with all its stylistic decisions, but I'd rather live with them and have consistency than run into corner cases and gotchas.

I would not consider a 62 pages spec possible to "keep in your head", let alone easily.

The "The Smalltalk Language" section of the last ANSI Smalltalk draft is a more reasonable 28 pages.

I think CoffeeScript seems nice in theory, but in the end, it's something made for people who want to code javascript, without actually using the language. It exchanges some of the terse, functional elegance javascript offers for a different kind of elegance, with its classes and inheritance and such like.

I won't say it's bad, as it is nice to work with when you're writing it, and I do quite like it. But I could never recommend it to someone who didn't have a good knowledge of javascript already.

I don't believe it exchanges any of the elegance. You can do the same things in CoffeeScript that you would in JS, just with less typing. That being said, a knowledge of how the browser will execute your compiled Javascript is crucial.

I personally describe CoffeeScript as "stabby". CS has all these little shortcuts and shorthands which seem great and appear to save time, but many of them are ambiguous, and then you get stabbed by their ambiguity, and you waste time debugging. Python, on the other hand, is still quite concise, but is generally very unambiguous.

I always thought CS was a "kinda-python-y" version of Javascript, though I never actually used it. It surprised me, therefore, to see that the OP considers these two items to be principles applied to the design of the language:

  - Implicit is better than explicit

  - There is more than one way to do it

These are the exact _opposite_ of a couple of the principles of the design of Python[1].

1: http://www.python.org/dev/peps/pep-0020/

Indeed but they obviously seem to apply to CS as he has shown in his examples.

Oh, I agree, it was just surprising to me to see them there.

As I wrote in the other recent CS thread here, I think your coding style must be ill-suited to coffeescript. I've had a few situations where I've had to test things out for myself, but nothing like what you put forth. I just write CS as I would JS and that's that.

To that end, the docs on Coffeescript.org are the reference documentation (as they are the only official documents to reference) and they've suited me just fine. I get the sense that you're looking for a document in the style of ECMA-262, rather than one in the style of MDN.

Right. I've started using CoffeeScript for a side project, and I really appreciate how it fixes most the warts in JS, but I wish they had stopped there rather than making gratuitous syntax changes. Parentheses in function calls is not an actual problem.

I'm afraid that in conjunction with significant whitespace, they're not at all gratuitous. For example:

    describe 'Calculator', ->

      it 'can add two positive numbers', ->
        result = calculator.add 2, 3
        assert result is 5

      it 'can handle negative number addition', ->
        result = calculator.add -10, 5
        assert result is -5 

Mandatory parentheses make significant whitespace lose much of its appeal when passing a block construct into a function. This is a large part of the reason why Python limits lambdas to a single line...

> This is a large part of the reason why Python limits lambdas to a single line...

Python doesn't limit lambdas to a single line, but to a single expression. That is a rather different constraint.

Sorry for the imprecision. It's the same thing to Python, in terms of significant whitespace. Language features that use whitespace for structure are not considered to be expressions, and can't be used as part of a larger computation. In CoffeeScript, they are, and can.

Valid point. Although I'm on the fence about significant whitespace in CS as well; I value fixing JavaScript's glaring flaws much more highly than arguably more convenient but unproven syntax. (The boundary is admittedly fuzzy, e.g. list comprehensions).

Optional parentheses wouldn't be so irritating if the rules for omitting them were universal. Currently, when calling functions with arguments you can omit the syntax, but when calling functions without arguments you must use parentheses. Could the 'dispatch vs variable reference' question be decided with some sort of suffix that preserves the value of whitespace? Something like 'f!' 'g! arg1, arg2'?

I think it would be interesting to see the operational semantics for a very small subset of the language. Applying that type of formalism would likely suss out or highlight the corner cases like the ones highlighted in the article.

Maybe coffeescript programmers could just use their brain and choose not to descend the Infinite Staircase of Obfuscation (the carrot's not worth it). Just because Coffeescript can saw your foot off doesn't mean you have to.

I have used CS on 3 projects and Scala in 2 projects. For me, both CS and Scala have terrible readability. Scala is more worse, I'll need at least 3x to read it than write it. Obviously, YMMV (tm)