Comment by jashkenas | Hacker News Reader

Comment by jashkenas | Hacker News Reader

I usually try not to weigh in on these debates -- I imagine https://groups.google.com/forum/#!topic/nodejs/a7yVzBw1sJk is what triggered this post. But...

Mr. Schlueter is right on -- C++ is a much more accurate comparison, and especially so because it was originally implemented as a cross-compiler into C source code (circa 1983-1990).

That said, saying that the desire to compile into JavaScript is (to paraphrase the post) pathological language-wank craziness, is a bit extreme.

I'd like to think that the reason why CoffeeScript has caught on like wildfire, when there are so many other AltJS languages out there (https://github.com/jashkenas/coffee-script/wiki/List-of-lang...) is that we're trying to take the deeply pragmatic approach.

Mr. Schlueter writes "you don’t compile it to target a given platform," as if this would be an advantage or a justification for existing ... when it's really quite the opposite. JavaScript is plagued with libraries that will only ever run on certain platforms because they opt-in to platform specific features. I can't use your simple pluralization library to turn "bit" into "bits", because it was only written to run on Node.js, and is riddled with `forEach` and `require`, or because it was only written for the browser, and hides data in the DOM.

CoffeeScript tries very hard to compile into efficient, lowest-common-denominator JavaScript (read avoid Internet Explorer bugs) because that's how your library can be used widely across devices and runtimes, while being reasonably future proof.

I don't know when "order of magnitude difference" became a synonym for "worthwhile difference", but ... how much easier does a program have to be to read and write before it becomes a worthwhile choice to make the change? 2x? 1.3x?

In any case, CoffeeScript is a little thought experiment -- not a corporate project, or a Dart-like browser takeover. If it suits your fancy, use it, and if it itches you the wrong way, by all means leave it out.

The desire to compile into JavaScript is not what's being criticized here; it's the "blah is to JS as C is to Assembly" analogy: "That’s not to say that any of these systems are bad, just that the “blah is to JS as C is to Assembly” analogy is wildly wrongheaded."

Trying to treat JavaScript as assembly is silly because it doesn't vary too much between browsers- it is palatable to write, by hand, cross-browser JS programs, whereas it is literally impossible to do so in assembly because different assembly languages, as human-readable machine code, have virtually nothing in common at that level.

Treating JavaScript as C is the reality, because JavaScript is what gets run in different browsers (the analogy to compiling C to different platforms).

CoffeeScript is more like C++ than C because the language it's replacing/augmenting/etc. is very similar semantics-wise- it's just trying to make the same basic idea nicer to work with. The 10x difference thing is pointing out that C->assembly is a massive translation, whereas C++->C, while still a worthwhile difference, is much smaller.

Again, this is not a value judgement of CoffeeScript or GWT or anything. It's pointing out a flawed analogy. This is useful because when we think of JS as C rather than Assembly, it becomes clear that it shouldn't be the only option. It would be an improvement if, in the future, more mature language compilers could bypass JS to some form of bytecode (be it browser-specific, which would be a much bigger problem in the browser world, or a standardized one like the JVM does for the non-browser world... this is where the analogy breaks down a little).

A compiler that did an 'identity compilation' on a strict subset of real JavaScript, and rejected any problematic or confusing constructs would have value.

CoffeeScript goes further than that and provides different syntax.

One of the things that complicates C++ is the requirement for source code compatibility with C. This necessarily requires preservation of confusing quirks.

CoffeeScript is not source code compatible with JavaScript.

Correct. That doesn't make CoffeeScript->JavaScript like C->assembly. In fact, it supports the idea that it's like C++->C. C++ provides stronger type checking than C and provides different syntax for things like constructors, heap allocation, etc.

CoffeeScript->JavaScript is a little like C++->C but it is more like Eiffel->C because CoffeeScript makes no attempt to compile any valid JavaScript.

This is important because C++ is damaged by the attempts to provide C source compatibility.

    A compiler that did an 'identity compilation' on a strict 
    subset of real JavaScript, and rejected any problematic 
    or confusing constructs would have value.

It would. But it would be a linter, not a compiler.

It would only be a linter if it weren't a compiler. If it compiles language X to language X, it's a compiler. Because it compiles. Rule of thumb: if it compiles, it's a compiler, not a linter. Simple. Like ducks.

What if it compiles language X to language Y, where Y is the union of all the valid programs in X with a set of possible descriptive error strings?

I'm bothered by these bits:

Mr. Schlueter writes "you don’t compile it to target a given platform," as if this would be an advantage or a justification for existing ... when it's really quite the opposite.

I don't know when "order of magnitude difference" became a synonym for "worthwhile difference"

I didn't see Schlueter arguing either of these things, but we may have read the post differently. Both points, in my view, seemed only to illustrate that the JS-Assembly analogy is wrong, not to argue against to-JS languages.

Regarding #1, you may very well be right, and I've just been reading through "language-wank" goggles. But regarding #2:

https://twitter.com/#!/izs/status/114089739908415488

And to be extra clear, I appreciate the post, and agree with most of it.

Okay, I'll give you #2 after that. And I'll point out that asking for a 10:1 difference in expressiveness from JS is, let's face it, ridiculous. (Except in specialized domain applications perhaps.)

If I recall correctly, Scott Hanselman raised the Assembly analogy in a post linked from this thread: http://news.ycombinator.com/item?id=2783060 . While discussing the unreadable JavaScript behind Google+ and similarly large-scale sites, Erik Meijer said

"JavaScript is an assembly language. The JavaScript + HTML generated is like a .NET assembly. The browser can execute it, but no human should really care what's there."

JavaScript generated by CoffeeScript is very readable and thus does not exactly correspond to that concept of JS-as-Assembly.

edit: formatting

That's because it's optimized to hell. Programming in GWT you can turn obfuscation/optimization off and it's readable, but much larger.

Debugging with GWT hosted mode is so ridiculously easy that readability is a non-issue.

I don't think creating a new language just to compile the source to Javascript is a good move, especially when Javascript is being under heavily supervised & supported by a huge web development community. If Javascript isn't that expressive or weird, fine, why don't we just fix it or find another replacement? I find myself is comfortable to work on a language that's close to the platform than fancy languages that try to hide/fix trivial problems and take away other good aspects of the language. There are enough languages to learn already and CoffeeScript is probably fade away once these[1] kind[2] of stuffs[3] become stronger.

[1] http://www.ecmascript.org/

[2] http://www.mascaraengine.com/

[3] http://code.google.com/p/traceur-compiler/

Regarding performance, have you considered CoffeeScript that generates JavaScript with (@JSDoc) type annotations that would allow Google's "Closure" compiler to further optimize and type-check the generated JavaScript?

CoffeeScript has its own optimizations and error checking, but type annotations would allow you to also leverage Google's continuing improvements to the Closure compiler.

https://code.google.com/closure/compiler/docs/js-for-compile...

Yep. Core CoffeeScript isn't going to pick any particular horse in the JS optimizer race, but there's a great fork that does just that:

http://www.bolinfest.com/coffee/features.html

Awesome! Thanks.

you know, it's really frustrating how reasonable you always are :)

your expectations with coffeescript have always been great and in line with reality.

i think the frustration isaacs, and myself, have had with many other coffeescript users is that they expect us to take on the work of supporting it to the same degree we support development in javascript.

you have to understand that the purpose of the "javascript is assembly" mantra is to give the impression that writing applications in javascript is a waste of effort compared to using a JS-to language. it infers that there is an order of magnitude difference, which is why isaacs is calling out that it is not.

the mantra is very common when asking for others to do more work to accomodate coffeescript programmers. it gives the impression that our resistance to doing the work is because we all have grey neck beards and expect others to live in the dark ages of programming with curly braces.

C++ can be a "worthwhile difference" over C for some people. others hate it. it's a much more realistic comparison.

if everyone using coffeescript had your demeanor and expectations our world would be a much better place.

Reply on news.ycombinator.com