4 ms·

Forgive me for being skeptical, but it seems to me that CoffeeScript is going the way of Lisp: a language by hackers for hackers, with way too many incompatible

Forgive me for being skeptical, but it seems to me that CoffeeScript is going the way of Lisp: a language by hackers for hackers, with way too many incompatible implementations because each implementer has their own pet features that must be included.

yuchi 14y ago
There's already a production ready transpiler, and a big bunch of production code to test against every new transpiler. Why do you think this is going to be a reason for fragmentation? And, by the way, coffeescript is not intended to be a language for hackers (I mean, only for hackers) but for Ruby programmers moving to javascript, JS programmers looking for a more terse syntax and programmers with an eye for terseness. In my opinion it has only two big flaws that need to be targeted by new transpilers: 1) for --> each 2) parens free chainable syntax.
- mistercow 14y ago
  Well, one reason that it could go that way is that the attitude that the maintainers has had toward feature-creep is "just make your own fork!" That's why we now have more dialects than we can shake a stick at, but it has kept the main branch from becoming PHP.
- charliesome 14y ago
  Please stop saying 'transpiler'. The CoffeeScript compiler is no less deserving of the term than any other compiler.
  - mistercow 14y ago
    "Transpiler" is a subset of "compiler", so it can hardly be a demeaning term. A transpiler is simply a compiler that translates code from language A to language B where A and B have roughly the same abstraction level. It is true that CoffeeScript is slightly more abstract than JavaScript in a few features (although JavaScript's inheritance model is more abstract than CoffeeScript's classes, for example), but any difference in abstraction level is tiny compared to the difference between, say, C and assembly.
    - yuchi 14y ago
      Exactly what I wanted to reply.
jashkenas 14y ago
Whoops -- I think you're missing a big part of the point of compiling into "standard" JavaScript. Not only is CoffeeScript code fully compatible with any JS library ... it's also compatible with code generated by any version of the compiler, and with code generated by alterna-compilers like Coco, and eventually this project as well. The semantic compatibility exists at the "plain 'ol" JS level.
- deleted 14y ago
  [deleted]
- streptomycin 14y ago
  That only solves part of the problem. It's still a big pain to have different syntax dialects and different tools that have to be used for different projects that are ostensibly written with the same language, even if they are compatible after you compile them to JS.

yuchi 14y ago

There's already a production ready transpiler, and a big bunch of production code to test against every new transpiler. Why do you think this is going to be a reason for fragmentation? And, by the way, coffeescript is not intended to be a language for hackers (I mean, only for hackers) but for Ruby programmers moving to javascript, JS programmers looking for a more terse syntax and programmers with an eye for terseness. In my opinion it has only two big flaws that need to be targeted by new transpilers: 1) for --> each 2) parens free chainable syntax.

mistercow 14y ago
Well, one reason that it could go that way is that the attitude that the maintainers has had toward feature-creep is "just make your own fork!" That's why we now have more dialects than we can shake a stick at, but it has kept the main branch from becoming PHP.
charliesome 14y ago
Please stop saying 'transpiler'. The CoffeeScript compiler is no less deserving of the term than any other compiler.
- mistercow 14y ago
  "Transpiler" is a subset of "compiler", so it can hardly be a demeaning term. A transpiler is simply a compiler that translates code from language A to language B where A and B have roughly the same abstraction level. It is true that CoffeeScript is slightly more abstract than JavaScript in a few features (although JavaScript's inheritance model is more abstract than CoffeeScript's classes, for example), but any difference in abstraction level is tiny compared to the difference between, say, C and assembly.
  - yuchi 14y ago
    Exactly what I wanted to reply.

jashkenas 14y ago

Whoops -- I think you're missing a big part of the point of compiling into "standard" JavaScript. Not only is CoffeeScript code fully compatible with any JS library ... it's also compatible with code generated by any version of the compiler, and with code generated by alterna-compilers like Coco, and eventually this project as well. The semantic compatibility exists at the "plain 'ol" JS level.

deleted 14y ago
[deleted]
streptomycin 14y ago
That only solves part of the problem. It's still a big pain to have different syntax dialects and different tools that have to be used for different projects that are ostensibly written with the same language, even if they are compatible after you compile them to JS.