There are things about coffeescript that I just don't think are good ideas, like "unless" or "if" at the end. The person reading the code will think "Ok, now I'm doing x ... oh wait I'm not". the flow of it is just backwards.

The "myFunction(item) for item in array" syntax also seems wrong way around. You use "item" before you say what it is.

I'm not an expert. These are just initial impressions, but coffeescript seems to have some good ideas, but tries to do too much. It would be interesting to see what thought process went into deciding to include certain constructs. Was it just an experiment? Are there reasons that might persuade me?

Ultimately the better JavaScript is also going to be JavaScript.

    > It would be interesting to see what thought process 
    > went into deciding to include certain constructs. 

Happy to oblige. There's plenty of reading material and conversations about most language decisions available here:

https://github.com/jashkenas/coffee-script/issues?direction=...

As to the existence of (optional) postfix "unless" and "if" -- does it also sound backwards to you when someone says:

    "Call your mother if it's her birthday."

... in English? If that doesn't sound so crazy, then consider the CoffeeScript:

    call mom if mom.birthday.isToday()

It's a little thing, that hopefully you can take advantage of to make short conditionals more readable then the JSLint-style JavaScript:

    if (mom.birthday.isToday()) { call(mom); }

The problem is we're mainly conditioned to expect the condition up front, notwithstanding Perl's initial slide down this slippery slope. Ugly syntax seems an argument for improving the syntax, not changing the grammar.

    if mum.birthday.isToday(): call(mum)

Does a language need three ways to say "if x do y" ? or maybe there's an "unless !x do y" construct and it's 4 ways.

This to me looks like going out of your way to have lots of ways to do the same thing. I never cared for it in PERL either.

The argument that "it reads like English" is not one that I like much - The history of making programming languages read like English is a long succession of dead ends. Programming languages work more like formal maths proofs than they do like English prose. Rather make the language readable on its own terms.

> The history of making programming languages read like English is a long succession of dead ends.

There certainly have been notable failures, such as Applescript, but I find it hard to dismiss Coffeescript, Ruby, SQL and FORTRAN which have all been quite popular.

I like SQL, not for the english-ish keywords, but for the strong mathematical underpinnings.

You left out a notable example of Cobol - Which would you rather read: "Add 1 to someValue Giving someValue", or "someValue++" ?

"myFunction(item) for item in array" is a list comprehension a lot of languages have ... among them python and haskell. It's really nothing special.

Hell, it's very similar to how "map" works in most functional languages -> "map function items"

Something about using a language that is essentially syntax sugar for a different language just doesn't sit right with me.

I'd much rather they fixed javascript, than use coffeescript.

Although this might be unfair to coffeescript, I haven't given it a proper try-out yet :)

All languages above assembler are as syntax surgary as coffee script.

Don't be silly — assembler is just sugar for machine code.

That's not true at all, even something as low-level as C shifts the semantics dramatically away from how assembler works.

C functions conceptually in a half-assed attempt at making the computer behave marginally more like a Harvard Machine than a Von Neumann one.

OTOH, coroutines are easier to bring about in assembler than in C.

But then you have to wait for browser adoption. Maybe you'll safely be able to use this syntax in 4 or 5 years.

There's other places where we see JavaScript. For example in node.js, where you could use this stuff in production immediately.