10 ms·

Kickstarter: Make a Better CoffeeScript Compiler

133 points by rainysunday 15y ago

hzy 15y ago
I don't really see the benefits of this over the existing compiler. The changes sounds like they could be merged into the existing compiler as command line arguments with relative ease.
- warmwaffles 15y ago
  or a config file sitting somewhere.
- evincarofautumn 15y ago
  The author seems to believe that a complete rewrite is necessary to address fundamental design issues with the existing compiler. I don’t know much about CoffeeScript or its internals, but since he’s worked significantly on it, I’m inclined to trust his judgement.
  - beala 15y ago
    Right. To elaborate, the benefits he enumerates are really things that he thinks will be easier after a complete rewrite into a more modular design. Based on his description of the current CS compiler, it looks like the meat of the compilation from CS to JS is done in one step. After it's parsed into a CS AST, the AST is walked, and each node knows what JS it corresponds to. It prints it out as a string, and voila, you have JS. A more orthodox and more robust design would parse the CS into an AST, and then push that AST through a series of stages. Each stage would transform the AST and have a narrowly defined purpose (flattening, uniqueification, etc), which should bring the AST closer and closer to a JS AST. The last step would be walking the AST and outputting strings. So, one benefit he mentioned is that you can "define multiple sets of (CS)AST -> (JS)AST transformation rules for multiple compilation targets." What this means is that since the entire transformation won't be done in one step, this will allow the modularization of stages. So, suppose there's some stage that's making the JS more IE friendly, but you don't care about IE. No problem. Remove that stage, swap in something else. Having multiple stages will also decouple parts of the design, and lessen the need for special casing. So, hopefully less bugs and more extensibility. He also wants the JS AST to conform to some Mozilla standard, so existing tools will be able to operate on it. In fact, it sounds like his strategy for printing the JS AST into JS concrete syntax is to use an existing project that operates on these mozilla ASTs.
gren 15y ago
I like CoffeeScript but I see it as a temporary language providing cool syntax features on top of Javascript. no offense but IMHO, we should focus on releasing the next Javascript and make it possible instead of writing better CoffeeScript compilers.
- roryokane 15y ago
  The problem is that making a better JavaScript you can actually use is a lot harder than making a better CoffeeScript. If you make a better CoffeeScript, you just have to write one compiler for it, written in JavaScript. If you make a better JavaScript, you have to lobby all of the major browser vendors to accept it. And then you have to wait for the browser teams to write the compiler. And even if you write the compilers yourself really fast for all of the open-source projects, you still have to wait for the Internet Explorer team to upgrade their compiler - you can't speed that up, because IE is closed-source. And finally, you can't safely use that new JavaScript on most sites until a few years later, when most people have upgraded their browsers. Whereas compiled CoffeeScript runs on even old browsers.
  - hartror 15y ago
    Of course compiling to JS as CoffeeScript does is itself the answer to the IE issue. If and when there is a new JS one could conceivably compile the new JS to old JS for IE users. It adds an extra burden on dev teams but IE special cases aren't anything new to web devs and it allows the standard to move more quickly.
  - strager 15y ago
    What prevents "new" JavaScript from being compiled like CS is being compiled now?
    - TrevorBurnham 15y ago
      This is an excellent idea, and is the goal of a project that Google announced at JSConf 2011 with much fanfare (some of it from Brendan Eich himself), Traceur: http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/ However, Traceur has gained little traction. With the announcement of Dart, it's clear that Google's heart isn't really into the project. See also: http://stackoverflow.com/questions/6506519/ecmascriptharmony-es6-to-javascript-compiler http://stackoverflow.com/questions/6506519/ecmascriptharmony...
drcode 15y ago
One feature that would be helpful is support for the Google Closure Compiler's "Advanced Mode" in the generated javascript (coffeescript right now stumbles with the property renaming, especially when destructuring is used) I wish I could run this powerful "whole program optimizer" against my coffeescript code.
- MatthewPhillips 15y ago
  CoffeeScript doesn't have a built in minifier does it? You can still run Closure against the js output.
  - jurre 15y ago
    Yeah but it would be nice if it was just a matter of setting a flag.
- xal 15y ago
  I agree with this. I chipped in 1k. I know it's not the goal of the project but I hope it lays the groundwork for an optional production mode compile run for coffee script that yields optimized and / or google closure compatible code.
- pestaa 15y ago
  Compressed property naming would be huge improvement, but then how would you really export to outer namespaces? I recall Closure Compiler has custom syntax in multiline comments for that, but you can't (or shouldn't) expect Coffee to support it natively with custom sugar. I found closures (as opposed to classes with properties/methods) to be much more compression-friendly and it made "Advanced Mode" not worth pursuing for me.
- lynaghk 15y ago
  I have a CoffeeScript fork (based on Michael Bolin's work) targeting Google Closure's Advanced mode here: https://github.com/lynaghk/coffee-script https://github.com/lynaghk/coffee-script The motivating use case for me is that ClojureScript (the Clojure->JS compiler) is built on Closure, and when I've wanted to integrate third party JS into my ClojureScript projects I've found it easier to port JS to CoffeeScript than to annotate the existing JS for use with advanced mode.
evincarofautumn 15y ago
I have this hope, however irrational, that compilers and similar projects become more common on Kickstarter. This is currently the only search result for “compiler”, which feels…wrong, somehow. If I’m not doing anything else this summer, I might just put up a language project and see if I don’t get laughed off the stage. Of course, it’s hard to offer good “prizes” (or whatever—Kickstarter doesn’t seem to have a term for them) for a project that of right ought to be free and open. This guy had the good sense to offer services, but I could see an “enterprise” edition working out as well.
- icebraining 15y ago
  “prizes” (or whatever—Kickstarter doesn’t seem to have a term for them) They call them Rewards: http://www.kickstarter.com/help/faq/creating%20a%20project#WhatCanBeOffeAsARewa http://www.kickstarter.com/help/faq/creating%20a%20project#W...
  - evincarofautumn 15y ago
    Thanks. Couldn’t remember and missed it when I went looking. These things happen.
TrevorBurnham 15y ago
I'm pledging $1,000 to this. As the author of the PragProg book on CoffeeScript (http://pragprog.com/book/tbcoffee/coffeescript http://pragprog.com/book/tbcoffee/coffeescript), I have a stake in making CoffeeScript a more mainstream tool, and I believe that Michael's project will greatly advance this cause. The use of CoffeeScript has become fairly widespread at startups (GitHub, 37signals, many YC alums...) but not in larger enterprises. One reason for this is that debugging CoffeeScript requires a "hacker mentality": compile-time errors are often reported with minimal or misleading explanations (e.g. "Unexpected ," when there is no comma on the line, but rather an implicit comma from whitespace); run-time errors have to be manually traced from the compiled JS to the original CoffeeScript. These flaws are likely to be ameliorated gradually (Jeremy has stated that Source Map support is the primary goal for CoffeeScript 1.4), but this project could improve the debugging situation dramatically in a matter of months. I hope the CoffeeScript community will lend Michael their support.
- flywheel 15y ago
  You're spending so much effort to distance yourself from javascript, when javascript isn't difficult, and coffeescript doesn't solve many problems while introducing its own problems. You must be a masochist if you support coffeescript so much and just refuse to code javascript. It's just such a backwards way to develop. Coffeescript is not becoming "widespread", and it doesn't require a "hacker mentality", it is simply a syntax fetish that dithers modern web development. It is a "made-up" language that has been way over-hyped to the point that people start believing that it's a good thing to stick yet another abstraction layer between the DOM and the code. Updates to coffeescript have broken existing code, how is this a good thing? Good luck with that.
ksec 15y ago
Is making those compiler features simple and easy? I was wondering why Rails.app need $25,000 while this is like half the price.
- pestaa 15y ago
  Not sure why you've been downvoted, because I somewhat agree with you. $12k is not bad for a few months if you happen to live in my country (Hungary, Middle Europe), but the expertise required by a full compiler rewrite is supposed to... cost more. With that said, I don't mind Rails.app targeting $25k. Let the masses decide if that kind of budget is realistic.
- rbxbx 15y ago
  Also bear in mind that the community behind Rails is more mature, and a lot more companies have stake in it being an effective solution than do CoffeeScript, not to mention the fact that Yehuda Katz probably has a bit more reach than Michael Ficarra. ... also also a student's cost of living as opposed to a seasoned software engineer's is probably pretty disparate (for better or worse).
krelian 15y ago
Someone capable of writing this kind of software will earn much more than $3000 per month at a full time job. I understand that this is probably not a for-profit project but if the guy can dedicate 4 full time months to this than he: 1) Can work full time 2) Needs the money Why not find a regular programming job that will pay you much more?He is obviously skilled enough to be hired.
- ashconnor 15y ago
  Fun fact: Money doesn't motivate everyone.
  - speg 15y ago
    Maybe not, though if this project is successfull it will certainly increase his value. Eventually allowing him to earn more money!
- hartror 15y ago
  He is a masters student, so he is likely looking at a relatively entry level job assuming he hasn't had any other experience. Also it is most likely he is passionate about the project and wants to work on it and this way he can work on his passion and still pay rent and eat. Beyond that this makes him more valuable, and will likely land him a well paying job working on CoffeeScript. He has been sensible about it as well, on his KS profile page: I am a research assistant at Worcester Polytechnic Institute, soon to receive my MS in computer science. In my free time (of which there hasn't been too much lately as I finish up my degree), I like to work on CoffeeScript and other open source projects, particularly those related to JavaScript. If you'd like to offer me a job either after the culmination of this project, or if this project does not get funded, feel free to contact me.
- ScottBurson 15y ago
  You're completely missing the point. He's not proposing to write a compiler as a way to make money; he's trying to get his living expenses covered so he can write this compiler that he wants to write, and which he believes will be useful to others.
petercooper 15y ago
Separate to the idea itself, this KS made me realise there's an art to choosing the right rewards and levels. Some KS are just irrestible to donate to partly because they get the rewards just right. Others, like this one IMHO, don't make the most of it.
- michaelficarra 15y ago
  Kickstarter allows me to add rewards after the project has started. What kind of rewards would you like to see?
  - GuiA 15y ago
    + You want to have rewards in lower donation brackets. Right now there's nothing between $25 and $200 — if I were to donate, I'd likely donate more than 25, but less than 200. You probably want rewards at the 50, 75, 150 levels. + Most projects offer tangible rewards (posters, booklets, figurines, keychains, tees-shirts etc.) that are just cool to have for any self-respecting geek. Unfortunately you're a software enterprise so it's not that evident for you, but I'm sure you can be creative in that space.
    - TrevorBurnham 15y ago
      That's a good idea. Michael, you should look into doing a run of CoffeeScript coffee mugs. These ones were much-loved and are no longer available: http://www.etsy.com/listing/93595042/coffeescript-mug http://www.etsy.com/listing/93595042/coffeescript-mug
    - TamDenholm 15y ago
      Perhaps you could find a sponsor to offer some free give away items like t-shirts etc to donors, in return they get mentioned in the kickstarter, the email list and throughout the project. I imagine any startup would happily back this, if you managed to get one that used coffeescript that'd be even better.
      - 15y ago
tkahn6 15y ago
Is there any reason the compiler should be written in Javascript? I know it's pretty cool to have a language's compiler written in itself, but what if Javascript isn't the best environment to write a compiler?
- TrevorBurnham 15y ago
  What's really nice about the compiler being in JavaScript is that you can run JavaScript anywhere: in the browser, on any OS, embedded in any major web framework. If the compiler were written in any other language, you'd have to worry about dependencies. This applies to HTML and CSS preprocessors as well: I'd advocate Jade over Haml and Stylus or Less over Sass, simply because Jade and Stylus/Less aren't tied to the Ruby ecosystem. JS is the real deal for "Write Once, Run Anywhere."
  - flywheel 15y ago
    "What's really nice about the compiler being in JavaScript is that you can run JavaScript anywhere: in the browser, on any OS, embedded in any major web framework. If the compiler were written in any other language, you'd have to worry about dependencies." You really can't see the irony of this statement, can you.
  - alexis-d 15y ago
    Isn't Less written in JS now?
    - andrewflnr 15y ago
      Yes. I think he meant: I'd advocate (Jade over Haml) and ((Stylus or Less) over Sass)
      - alexis-d 15y ago
        Oh totally, you're right, I misread his comment.
  - bodyfour 15y ago
impeachgod 15y ago
I wonder what are the advantages/disadvantages between a PEG and say, a Pratt parser (http://javascript.crockford.com/tdop/tdop.html http://javascript.crockford.com/tdop/tdop.html)?
grayrest 15y ago
Having poked around with Jeremy's compiler (I forget if I've sent in patches or not), I'm curious about some of the technical details behind the project. I've thought about this topic for a while and this is a rather disorganized brain dump Feel free to respond to as much or as little as you like. The main complaint I have with the current compiler is the inability to control output either via compile time macros or compiler hooks. I would like to map Coffeescript's class construct onto the class system of a variety of frameworks. I understand most of Jeremy's rationale but I still have to patch my install to change the superclass name in order to map coffeescript classes onto yui3 (same pattern, different superclass names) and I'd really like to see the class syntax map to Ember's classes. Any particular reason for PEGs over Parser Combinators? From reading, looks like you plan to skip the rewriter pass. I started a PEG parser implementation in the 0.3 timeframe but ran into problems with the `x = a: 1, b, c` -> `x = {a: 1, b:'b', c:'c'}` and similar ambiguities. Do you have a plan for handling this? Will you drop language features if you can't do them without rewriting? What sort of compile time hooks are you planning? Just (C)AST->(J)AST passes? In the time since I've messed with coffeescript internals, I've run across two potentially useful things that I haven't really investigated: * http://www.mirah.org/wiki/Macros http://www.mirah.org/wiki/Macros <- macros in a non-lisp langauge * https://github.com/cgrand/parsley https://github.com/cgrand/parsley <- fully incremental parser generator The latter is interesting because it'd potentially allow the actual compiler to be used as the starting point for language IDE support. Good luck, I'll be following your progress with interest.
jaekwon 15y ago
I've made a some progress in this. PEG didn't quite cut it for left-recursion so I created a new parser. https://github.com/jaekwon/joeson https://github.com/jaekwon/joeson The grammar for CoffeeScript is getting there -- enough to parse the project files at least. https://github.com/jaekwon/joeson/blob/master/joescript_grammar.joe https://github.com/jaekwon/joeson/blob/master/joescript_gram... Michael, we can collaborate on this. Send me a msg on github or email `jkwon.work` at gmail.
platform 15y ago
I donated 25. CoffeeScript and derivates is the right approach to improve compile-time problem detection with the typeless javascript Thanks for posting
tomaskafka 15y ago
How about improving coffeescript language? I tested in on a small project recently and run into lot of ugly edge cases, where I had to read the generated code to find out that coffeescript compiled code differently than my expectations were? example: http://t.co/omIdeNGA http://t.co/omIdeNGA (jQuery chaining) # I'd expect these two blocks ... $output .html 'a' .prepend renderedHtml $output .html ('a') .prepend renderedHtml # ... to generate exactly same code as this: $output .html('a') # you cannot put whitespace or omit parentheses here - but in other places, you are guided to remove them and use spaces .prepend renderedHtml Coffeescript: $output.html('a'.prepend(renderedHtml)); $output.html('a'.prepend(renderedHtml)); $output.html('a').prepend(renderedHtml);
deleted 15y ago
[deleted]

133 points by rainysunday 15y ago

hzy 15y ago

I don't really see the benefits of this over the existing compiler. The changes sounds like they could be merged into the existing compiler as command line arguments with relative ease.

warmwaffles 15y ago
or a config file sitting somewhere.
evincarofautumn 15y ago
The author seems to believe that a complete rewrite is necessary to address fundamental design issues with the existing compiler. I don’t know much about CoffeeScript or its internals, but since he’s worked significantly on it, I’m inclined to trust his judgement.
- beala 15y ago
  Right. To elaborate, the benefits he enumerates are really things that he thinks will be easier after a complete rewrite into a more modular design. Based on his description of the current CS compiler, it looks like the meat of the compilation from CS to JS is done in one step. After it's parsed into a CS AST, the AST is walked, and each node knows what JS it corresponds to. It prints it out as a string, and voila, you have JS. A more orthodox and more robust design would parse the CS into an AST, and then push that AST through a series of stages. Each stage would transform the AST and have a narrowly defined purpose (flattening, uniqueification, etc), which should bring the AST closer and closer to a JS AST. The last step would be walking the AST and outputting strings. So, one benefit he mentioned is that you can "define multiple sets of (CS)AST -> (JS)AST transformation rules for multiple compilation targets." What this means is that since the entire transformation won't be done in one step, this will allow the modularization of stages. So, suppose there's some stage that's making the JS more IE friendly, but you don't care about IE. No problem. Remove that stage, swap in something else. Having multiple stages will also decouple parts of the design, and lessen the need for special casing. So, hopefully less bugs and more extensibility. He also wants the JS AST to conform to some Mozilla standard, so existing tools will be able to operate on it. In fact, it sounds like his strategy for printing the JS AST into JS concrete syntax is to use an existing project that operates on these mozilla ASTs.

gren 15y ago

I like CoffeeScript but I see it as a temporary language providing cool syntax features on top of Javascript. no offense but IMHO, we should focus on releasing the next Javascript and make it possible instead of writing better CoffeeScript compilers.

roryokane 15y ago
The problem is that making a better JavaScript you can actually use is a lot harder than making a better CoffeeScript. If you make a better CoffeeScript, you just have to write one compiler for it, written in JavaScript. If you make a better JavaScript, you have to lobby all of the major browser vendors to accept it. And then you have to wait for the browser teams to write the compiler. And even if you write the compilers yourself really fast for all of the open-source projects, you still have to wait for the Internet Explorer team to upgrade their compiler - you can't speed that up, because IE is closed-source. And finally, you can't safely use that new JavaScript on most sites until a few years later, when most people have upgraded their browsers. Whereas compiled CoffeeScript runs on even old browsers.
- hartror 15y ago
  Of course compiling to JS as CoffeeScript does is itself the answer to the IE issue. If and when there is a new JS one could conceivably compile the new JS to old JS for IE users. It adds an extra burden on dev teams but IE special cases aren't anything new to web devs and it allows the standard to move more quickly.
- strager 15y ago
  What prevents "new" JavaScript from being compiled like CS is being compiled now?
  - TrevorBurnham 15y ago
    This is an excellent idea, and is the goal of a project that Google announced at JSConf 2011 with much fanfare (some of it from Brendan Eich himself), Traceur: http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/ However, Traceur has gained little traction. With the announcement of Dart, it's clear that Google's heart isn't really into the project. See also: http://stackoverflow.com/questions/6506519/ecmascriptharmony-es6-to-javascript-compiler http://stackoverflow.com/questions/6506519/ecmascriptharmony...

drcode 15y ago

One feature that would be helpful is support for the Google Closure Compiler's "Advanced Mode" in the generated javascript (coffeescript right now stumbles with the property renaming, especially when destructuring is used) I wish I could run this powerful "whole program optimizer" against my coffeescript code.

MatthewPhillips 15y ago
CoffeeScript doesn't have a built in minifier does it? You can still run Closure against the js output.
- jurre 15y ago
  Yeah but it would be nice if it was just a matter of setting a flag.
xal 15y ago
I agree with this. I chipped in 1k. I know it's not the goal of the project but I hope it lays the groundwork for an optional production mode compile run for coffee script that yields optimized and / or google closure compatible code.
pestaa 15y ago
Compressed property naming would be huge improvement, but then how would you really export to outer namespaces? I recall Closure Compiler has custom syntax in multiline comments for that, but you can't (or shouldn't) expect Coffee to support it natively with custom sugar. I found closures (as opposed to classes with properties/methods) to be much more compression-friendly and it made "Advanced Mode" not worth pursuing for me.
lynaghk 15y ago
I have a CoffeeScript fork (based on Michael Bolin's work) targeting Google Closure's Advanced mode here: https://github.com/lynaghk/coffee-script https://github.com/lynaghk/coffee-script The motivating use case for me is that ClojureScript (the Clojure->JS compiler) is built on Closure, and when I've wanted to integrate third party JS into my ClojureScript projects I've found it easier to port JS to CoffeeScript than to annotate the existing JS for use with advanced mode.

evincarofautumn 15y ago

I have this hope, however irrational, that compilers and similar projects become more common on Kickstarter. This is currently the only search result for “compiler”, which feels…wrong, somehow. If I’m not doing anything else this summer, I might just put up a language project and see if I don’t get laughed off the stage. Of course, it’s hard to offer good “prizes” (or whatever—Kickstarter doesn’t seem to have a term for them) for a project that of right ought to be free and open. This guy had the good sense to offer services, but I could see an “enterprise” edition working out as well.

icebraining 15y ago
“prizes” (or whatever—Kickstarter doesn’t seem to have a term for them) They call them Rewards: http://www.kickstarter.com/help/faq/creating%20a%20project#WhatCanBeOffeAsARewa http://www.kickstarter.com/help/faq/creating%20a%20project#W...
- evincarofautumn 15y ago
  Thanks. Couldn’t remember and missed it when I went looking. These things happen.

TrevorBurnham 15y ago

I'm pledging $1,000 to this. As the author of the PragProg book on CoffeeScript (http://pragprog.com/book/tbcoffee/coffeescript http://pragprog.com/book/tbcoffee/coffeescript), I have a stake in making CoffeeScript a more mainstream tool, and I believe that Michael's project will greatly advance this cause. The use of CoffeeScript has become fairly widespread at startups (GitHub, 37signals, many YC alums...) but not in larger enterprises. One reason for this is that debugging CoffeeScript requires a "hacker mentality": compile-time errors are often reported with minimal or misleading explanations (e.g. "Unexpected ," when there is no comma on the line, but rather an implicit comma from whitespace); run-time errors have to be manually traced from the compiled JS to the original CoffeeScript. These flaws are likely to be ameliorated gradually (Jeremy has stated that Source Map support is the primary goal for CoffeeScript 1.4), but this project could improve the debugging situation dramatically in a matter of months. I hope the CoffeeScript community will lend Michael their support.

flywheel 15y ago
You're spending so much effort to distance yourself from javascript, when javascript isn't difficult, and coffeescript doesn't solve many problems while introducing its own problems. You must be a masochist if you support coffeescript so much and just refuse to code javascript. It's just such a backwards way to develop. Coffeescript is not becoming "widespread", and it doesn't require a "hacker mentality", it is simply a syntax fetish that dithers modern web development. It is a "made-up" language that has been way over-hyped to the point that people start believing that it's a good thing to stick yet another abstraction layer between the DOM and the code. Updates to coffeescript have broken existing code, how is this a good thing? Good luck with that.

ksec 15y ago

Is making those compiler features simple and easy? I was wondering why Rails.app need $25,000 while this is like half the price.

pestaa 15y ago
Not sure why you've been downvoted, because I somewhat agree with you. $12k is not bad for a few months if you happen to live in my country (Hungary, Middle Europe), but the expertise required by a full compiler rewrite is supposed to... cost more. With that said, I don't mind Rails.app targeting $25k. Let the masses decide if that kind of budget is realistic.
rbxbx 15y ago
Also bear in mind that the community behind Rails is more mature, and a lot more companies have stake in it being an effective solution than do CoffeeScript, not to mention the fact that Yehuda Katz probably has a bit more reach than Michael Ficarra. ... also also a student's cost of living as opposed to a seasoned software engineer's is probably pretty disparate (for better or worse).

krelian 15y ago

Someone capable of writing this kind of software will earn much more than $3000 per month at a full time job. I understand that this is probably not a for-profit project but if the guy can dedicate 4 full time months to this than he: 1) Can work full time 2) Needs the money Why not find a regular programming job that will pay you much more?He is obviously skilled enough to be hired.

ashconnor 15y ago
Fun fact: Money doesn't motivate everyone.
- speg 15y ago
  Maybe not, though if this project is successfull it will certainly increase his value. Eventually allowing him to earn more money!
hartror 15y ago
He is a masters student, so he is likely looking at a relatively entry level job assuming he hasn't had any other experience. Also it is most likely he is passionate about the project and wants to work on it and this way he can work on his passion and still pay rent and eat. Beyond that this makes him more valuable, and will likely land him a well paying job working on CoffeeScript. He has been sensible about it as well, on his KS profile page: I am a research assistant at Worcester Polytechnic Institute, soon to receive my MS in computer science. In my free time (of which there hasn't been too much lately as I finish up my degree), I like to work on CoffeeScript and other open source projects, particularly those related to JavaScript. If you'd like to offer me a job either after the culmination of this project, or if this project does not get funded, feel free to contact me.
ScottBurson 15y ago
You're completely missing the point. He's not proposing to write a compiler as a way to make money; he's trying to get his living expenses covered so he can write this compiler that he wants to write, and which he believes will be useful to others.

petercooper 15y ago

Separate to the idea itself, this KS made me realise there's an art to choosing the right rewards and levels. Some KS are just irrestible to donate to partly because they get the rewards just right. Others, like this one IMHO, don't make the most of it.

michaelficarra 15y ago
Kickstarter allows me to add rewards after the project has started. What kind of rewards would you like to see?
- GuiA 15y ago
  + You want to have rewards in lower donation brackets. Right now there's nothing between $25 and $200 — if I were to donate, I'd likely donate more than 25, but less than 200. You probably want rewards at the 50, 75, 150 levels. + Most projects offer tangible rewards (posters, booklets, figurines, keychains, tees-shirts etc.) that are just cool to have for any self-respecting geek. Unfortunately you're a software enterprise so it's not that evident for you, but I'm sure you can be creative in that space.
  - TrevorBurnham 15y ago
    That's a good idea. Michael, you should look into doing a run of CoffeeScript coffee mugs. These ones were much-loved and are no longer available: http://www.etsy.com/listing/93595042/coffeescript-mug http://www.etsy.com/listing/93595042/coffeescript-mug
  - TamDenholm 15y ago
    Perhaps you could find a sponsor to offer some free give away items like t-shirts etc to donors, in return they get mentioned in the kickstarter, the email list and throughout the project. I imagine any startup would happily back this, if you managed to get one that used coffeescript that'd be even better.
    - 15y ago

tkahn6 15y ago

Is there any reason the compiler should be written in Javascript? I know it's pretty cool to have a language's compiler written in itself, but what if Javascript isn't the best environment to write a compiler?

TrevorBurnham 15y ago
What's really nice about the compiler being in JavaScript is that you can run JavaScript anywhere: in the browser, on any OS, embedded in any major web framework. If the compiler were written in any other language, you'd have to worry about dependencies. This applies to HTML and CSS preprocessors as well: I'd advocate Jade over Haml and Stylus or Less over Sass, simply because Jade and Stylus/Less aren't tied to the Ruby ecosystem. JS is the real deal for "Write Once, Run Anywhere."
- flywheel 15y ago
  "What's really nice about the compiler being in JavaScript is that you can run JavaScript anywhere: in the browser, on any OS, embedded in any major web framework. If the compiler were written in any other language, you'd have to worry about dependencies." You really can't see the irony of this statement, can you.
- alexis-d 15y ago
  Isn't Less written in JS now?
  - andrewflnr 15y ago
    Yes. I think he meant: I'd advocate (Jade over Haml) and ((Stylus or Less) over Sass)
    - alexis-d 15y ago
      Oh totally, you're right, I misread his comment.
- bodyfour 15y ago

impeachgod 15y ago

I wonder what are the advantages/disadvantages between a PEG and say, a Pratt parser (http://javascript.crockford.com/tdop/tdop.html http://javascript.crockford.com/tdop/tdop.html)?

grayrest 15y ago

Having poked around with Jeremy's compiler (I forget if I've sent in patches or not), I'm curious about some of the technical details behind the project. I've thought about this topic for a while and this is a rather disorganized brain dump Feel free to respond to as much or as little as you like. The main complaint I have with the current compiler is the inability to control output either via compile time macros or compiler hooks. I would like to map Coffeescript's class construct onto the class system of a variety of frameworks. I understand most of Jeremy's rationale but I still have to patch my install to change the superclass name in order to map coffeescript classes onto yui3 (same pattern, different superclass names) and I'd really like to see the class syntax map to Ember's classes. Any particular reason for PEGs over Parser Combinators? From reading, looks like you plan to skip the rewriter pass. I started a PEG parser implementation in the 0.3 timeframe but ran into problems with the `x = a: 1, b, c` -> `x = {a: 1, b:'b', c:'c'}` and similar ambiguities. Do you have a plan for handling this? Will you drop language features if you can't do them without rewriting? What sort of compile time hooks are you planning? Just (C)AST->(J)AST passes? In the time since I've messed with coffeescript internals, I've run across two potentially useful things that I haven't really investigated: * http://www.mirah.org/wiki/Macros http://www.mirah.org/wiki/Macros <- macros in a non-lisp langauge * https://github.com/cgrand/parsley https://github.com/cgrand/parsley <- fully incremental parser generator The latter is interesting because it'd potentially allow the actual compiler to be used as the starting point for language IDE support. Good luck, I'll be following your progress with interest.

jaekwon 15y ago

I've made a some progress in this. PEG didn't quite cut it for left-recursion so I created a new parser. https://github.com/jaekwon/joeson https://github.com/jaekwon/joeson The grammar for CoffeeScript is getting there -- enough to parse the project files at least. https://github.com/jaekwon/joeson/blob/master/joescript_grammar.joe https://github.com/jaekwon/joeson/blob/master/joescript_gram... Michael, we can collaborate on this. Send me a msg on github or email `jkwon.work` at gmail.

platform 15y ago

I donated 25. CoffeeScript and derivates is the right approach to improve compile-time problem detection with the typeless javascript Thanks for posting

tomaskafka 15y ago

How about improving coffeescript language? I tested in on a small project recently and run into lot of ugly edge cases, where I had to read the generated code to find out that coffeescript compiled code differently than my expectations were? example: http://t.co/omIdeNGA http://t.co/omIdeNGA (jQuery chaining) # I'd expect these two blocks ... $output .html 'a' .prepend renderedHtml $output .html ('a') .prepend renderedHtml # ... to generate exactly same code as this: $output .html('a') # you cannot put whitespace or omit parentheses here - but in other places, you are guided to remove them and use spaces .prepend renderedHtml Coffeescript: $output.html('a'.prepend(renderedHtml)); $output.html('a'.prepend(renderedHtml)); $output.html('a').prepend(renderedHtml);

deleted 15y ago

[deleted]