3 ms·

Don't worry -- this is currently just a pull request and a fork that you can try out: http://search.npmjs.org/#/tamed-coffee-script http://search.npmjs.org/#/t

Don't worry -- this is currently just a pull request and a fork that you can try out: http://search.npmjs.org/#/tamed-coffee-script http://search.npmjs.org/#/tamed-coffee-script The real challenge here is to see if this branch can be made to generate the asynchronous code you would have written in the first place ... or how close we can come to approaching it.

DanielRibeiro 15y ago
I think it is a cool thing to be considered. Mostly because you can already do it with runtime AST metaprogramming (which is very doable in JS, due to Function.toString, even though is not as easy to do as Lisp/Clojure's macros), and have it as lib. What the language support adds is simply the convenience of not passing a function with the block of code that will be instrumented. In fact, with language support, you can even debug it. And the best part about this change: if you don't use it, it will not affect you at all. It is opt-in by default. Not saying we should take this change lightly, but I believe it does have many merits, and we should not be too quick to dismiss it.
- deleted 15y ago
  [deleted]
- raganwald 15y ago
  I’m a huge fan of stuff like this, however it’s not strictly true that features like this are “opt in.” If you write your code alone and in a vacuum, it’s opt-in. However, if you write your code on a team, if you use NPM packages that were compiled from this code, if you use backbone extensions compiled from this code, you’re opted in “by proxy” to the code it produces whenever you find yourself stepping through the code in a debugger or reading the compiled code in a browser environment. IMO, it could be a win by virtue of producing consistent code for the most common cases. It may seem unfamiliar at first compared to the code you would personally write, but if it becomes a standard and everybody’s code ends up looking much the same, that’s a win overall. I think this is already true for binding functions to the current ‘this’ and for comprehensions, and we could use a standard ‘pattern’ for the resulting asynchronous code for most common cases. But I grant that it isn’t purely optional in a world where very few people write their own stack in its entirety.
  - DanielRibeiro 15y ago
    Ever since I wrote this I realized that this feature, as outlined here, is not opt-in, even in a vacuum, due to the fact that will break all variables named 'await' and 'defer'. About using others' code: compile time code generation is always possible, and you can't prevent the libraries you are using from using it. It can even be worse: they can runtime code generation, or a downright obfuscator. Since more and more languages are being compiled to JS (Clojurescript being one formidable recent addition), trying to stay "pure" with respect to the libraries you use is getting harder and harder. My biggest worry is that Coffeescript starts stagnating from lack of innovation (which seems to affect most stable languages). One way Scala managed to experiment with features while still trying to be stable, was through Scala Compiler Plugins[1]. This we could be having a less theoretical conversation, by throwing it in the wild, and learning from the experiments people make with it. [1] http://www.scala-lang.org/node/140 http://www.scala-lang.org/node/140
ricardobeat 15y ago
Isn't that achievable by using a symbol that just causes the next adjoined statements to be considered an indent block? Like the inverted or tilde arrow often brought up: async.knead flour, water, (err, dough) ~> return log err if err? async.bake dough, (bread) ~> eat bread BTW, was looking back at the original announcement here at HN, and found this: CoffeeScript + node.js + V8 could produce one amazing language and implementation. Little did he know... http://news.ycombinator.com/item?id=1014080 http://news.ycombinator.com/item?id=1014080

DanielRibeiro 15y ago

I think it is a cool thing to be considered. Mostly because you can already do it with runtime AST metaprogramming (which is very doable in JS, due to Function.toString, even though is not as easy to do as Lisp/Clojure's macros), and have it as lib. What the language support adds is simply the convenience of not passing a function with the block of code that will be instrumented. In fact, with language support, you can even debug it. And the best part about this change: if you don't use it, it will not affect you at all. It is opt-in by default. Not saying we should take this change lightly, but I believe it does have many merits, and we should not be too quick to dismiss it.

deleted 15y ago
[deleted]
raganwald 15y ago
I’m a huge fan of stuff like this, however it’s not strictly true that features like this are “opt in.” If you write your code alone and in a vacuum, it’s opt-in. However, if you write your code on a team, if you use NPM packages that were compiled from this code, if you use backbone extensions compiled from this code, you’re opted in “by proxy” to the code it produces whenever you find yourself stepping through the code in a debugger or reading the compiled code in a browser environment. IMO, it could be a win by virtue of producing consistent code for the most common cases. It may seem unfamiliar at first compared to the code you would personally write, but if it becomes a standard and everybody’s code ends up looking much the same, that’s a win overall. I think this is already true for binding functions to the current ‘this’ and for comprehensions, and we could use a standard ‘pattern’ for the resulting asynchronous code for most common cases. But I grant that it isn’t purely optional in a world where very few people write their own stack in its entirety.
- DanielRibeiro 15y ago
  Ever since I wrote this I realized that this feature, as outlined here, is not opt-in, even in a vacuum, due to the fact that will break all variables named 'await' and 'defer'. About using others' code: compile time code generation is always possible, and you can't prevent the libraries you are using from using it. It can even be worse: they can runtime code generation, or a downright obfuscator. Since more and more languages are being compiled to JS (Clojurescript being one formidable recent addition), trying to stay "pure" with respect to the libraries you use is getting harder and harder. My biggest worry is that Coffeescript starts stagnating from lack of innovation (which seems to affect most stable languages). One way Scala managed to experiment with features while still trying to be stable, was through Scala Compiler Plugins[1]. This we could be having a less theoretical conversation, by throwing it in the wild, and learning from the experiments people make with it. [1] http://www.scala-lang.org/node/140 http://www.scala-lang.org/node/140

ricardobeat 15y ago

Isn't that achievable by using a symbol that just causes the next adjoined statements to be considered an indent block? Like the inverted or tilde arrow often brought up: async.knead flour, water, (err, dough) ~> return log err if err? async.bake dough, (bread) ~> eat bread BTW, was looking back at the original announcement here at HN, and found this: CoffeeScript + node.js + V8 could produce one amazing language and implementation. Little did he know... http://news.ycombinator.com/item?id=1014080 http://news.ycombinator.com/item?id=1014080