TL;DR: Coffeescript should be seen as a way to enforce good Javascript style, and as such it does a decent job.
That's an interesting and very defensible PoV. However, even considered as such, it has some serious warts:
* It has no clearly-defined semantics: it's an accretion of rewriting tricks, and as such, it's often very hard to predict how two tricks will interact together, especially when they involve indentation and line-breaks.
* It tries to support too many cute idioms, which leads to too many ways to do things. There ought to be one obviously best way to do each thing, for the sake of maintenance and readability.
Now, if we consider CS as a presentation layer for JS, then its proper place is in an IDE, not as a compiler. Ideally, files should be stored as JS and converted back to CS transparently when editing. Mixes of real JS and CS->JS code should mesh together gracefully. When a piece of CS is highlighted, the corresponding JS should be shown as a tooltip. And of course, when a backtrace is produced, it should be translated from JS lines to CS lines transparently.
Today, CS fancies itself as a compiler, i.e. something which produces object code which should never be dealt with by the programmer. As such, it fails. If it presented itself as a representation/refactoring abstraction, it would be much easier to embrace. Of course, the implementation/integration with an IDE would be an order of magnitude harder than a text->text processor, and would make the language^Wtool liable to editor wars.
From the coffeescript website:
CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.
Coffeescript has never presented itself otherwise. What causes the confusion is pointless discussions about semantics and people who don't fully understand the point of coffescript teaching other people about it and writing over zealous blogposts.
All programming languages are human convenience. The computer cares not about list comprehensions or splats. It just reads hi/low. Coffeescript is a tool that enables you to write those hi/lows more conveniently. It doesn't care if its called a language or a form of mixed martial arts. It's just there to help you if you want it to.
https://en.wikipedia.org/wiki/CompilerA compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language ...)
> Coffeescript has never presented itself otherwise.
My point was not to disparage the author, his intentions, his lucidity, nor even the resulting language. When people receive something packaged as a compiler (a file->file traduction tool to invoke from the command line and to include in building scripts), they naturally understand it as a compiler, and judge its qualities as a compiler.
And by "compiler", I mean the informal concept that people spontaneously put behind gcc or javac, not any attempt to formally classify a kind of data conversion tool. Among associated expectations, there's this idea that the abstraction provided by the compiler doesn't leak: you generally don't need to know about ASM/bytecode while using GCC/javac. CS doesn't shield you from the generated JS, and as such, it falls short of most people's expectations about a compiler.
Looking at these expectations from a different perspective, as does Raganwald, is very interesting.
When talking about compiling computer languages. It would help if we were all using the standard definition of a compiler.
I'm glad you've got your own definition but using it only serves to confuse the discussion.
Furthermore, your argument is weak. The only reason you don't need to be more familiar with the technologies supporting gcc and javac is because they are robust and much older. If you were there at the beginning of their development you most certainly would have needed to be more familiar with their underlying platforms. In fact many would argue you'd be a better programmer if you did now.
Another reason your argument could be weak: Does a line number mapper between coffeescript and its generated javascript completely nullify your argument?
At that point I wouldn't need to ever look at the generated source and would care only about it's execution. That sounds pretty much exactly like a "compiled" language to me.
The technical term for what CoffeeScript is doing — a compiler that doesn't need a global view of the program and does local source transformations — is a transpiler.
> Now, if we consider CS as a presentation layer for JS, then its proper place is in an IDE, not as a compiler
I disagree. Forcing programmers to use a certain IDE to accomplish productivity gains is a bad road to go down. It discourages innovation, stifles competition and makes it hard to integrate the "compilation" in to other parts of your development cycle.
"There ought to be one obviously best way to do each thing, for the sake of maintenance and readability."
In what way does a constriction of convention relate to readability or maintainability? The languages I'm most productive in have many ways to write readable code that accomplishes basically or exactly the same thing. I've always considered it a mark of a language's elegance and power that there would emerge multiple ways of expressing the same problem. But maybe we're thinking about different scopes here. Can you give an example?
That's an interesting and very defensible PoV. However, even considered as such, it has some serious warts:
* It has no clearly-defined semantics: it's an accretion of rewriting tricks, and as such, it's often very hard to predict how two tricks will interact together, especially when they involve indentation and line-breaks.
* It tries to support too many cute idioms, which leads to too many ways to do things. There ought to be one obviously best way to do each thing, for the sake of maintenance and readability.
Now, if we consider CS as a presentation layer for JS, then its proper place is in an IDE, not as a compiler. Ideally, files should be stored as JS and converted back to CS transparently when editing. Mixes of real JS and CS->JS code should mesh together gracefully. When a piece of CS is highlighted, the corresponding JS should be shown as a tooltip. And of course, when a backtrace is produced, it should be translated from JS lines to CS lines transparently.
Today, CS fancies itself as a compiler, i.e. something which produces object code which should never be dealt with by the programmer. As such, it fails. If it presented itself as a representation/refactoring abstraction, it would be much easier to embrace. Of course, the implementation/integration with an IDE would be an order of magnitude harder than a text->text processor, and would make the language^Wtool liable to editor wars.