Kickstarter: Make a Better CoffeeScript Compiler
kickstarter.com
kickstarter.com
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.
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 <- macros in a non-lisp langauge
* 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.
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.
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.
+ 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.
You can blog about your progress, you can offer adspace on your page which might sell better than a name/company in the readme.
Also, you're offering a mention in the README as a bonus - which is a good idea. But IMHO you should consider also having a separate DONORS file (or similar) which will list the names of anyone who donated and still be part of the project. Even such a small gesture will help people bond to the project and feel like they're a part of it, beyond the Kickstarter. I bet there are people who would even donate $5 just to get into such a file on what might be a popular project :-) (sad but true!)
My real thinking behind this is because I might be including this in JavaScript Weekly next week. And if I do, I think it would be awesome if people felt motivated enough to throw you some money.
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.
They call them Rewards: http://www.kickstarter.com/help/faq/creating%20a%20project#W...
no offense but IMHO, we should focus on releasing the next Javascript and make it possible instead of writing better CoffeeScript compilers.
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...
It's more worthwhile future facing project.
I was wondering why Rails.app need $25,000 while this is like half the price.
With that said, I don't mind Rails.app targeting $25k. Let the masses decide if that kind of budget is realistic.
... also also a student's cost of living as opposed to a seasoned software engineer's is probably pretty disparate (for better or worse).
PEG didn't quite cut it for left-recursion so I created a new parser.
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_gram...
Michael, we can collaborate on this. Send me a msg on github or email `jkwon.work` at gmail.
example: 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
$output.html('a'.prepend(renderedHtml));
$output.html('a'.prepend(renderedHtml));
$output.html('a').prepend(renderedHtml);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.
Thanks for posting
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.
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.
I think you might be selling yourself a bit low. The market value of someone at your level of skill is at least $8,000 per month, and I don't think you should be going down by 62.5% (as opposed to 20-30) just because it's a fun, open-source project. If it's genuinely commercially useful, you should be shooting for market salary.
I would set the same price but make the promise 2 months, if it were me.
Because he would have to work on something that wouldn't interest him as much as his own project, and because he would have to show up regularly. When you gather funds to work on an open source project, all you have to do is hang out at home and work on your pet project when you're in the mood. That's good work even when you're not getting paid.
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."
I know I'm in a tiny minority of HN readers, but I have to deal with a pretty wide variety of UNIX platforms.. my code needs to run on SPARC, Itanium, etc. Sure most of these have a foot-and-a-half in the grave but one still is hanging in there: I still see a decent number of AIX customers; it'll be with me for the next few years at least. If something can't be made to run on a POWER CPU I can't touch it.
In the past, the widely used scripting languages (perl/lua/python/ruby/...) always treated CPU portability as sacrosanct. In time, there have been CPU-specific optimizations work done (LuaJIT, etc) but there is always a way to run the underlying language anywhere.
In the JS world, all of the modern work seems to carry an assumption that node.js is available, which in turn relies on the V8 JIT engine. V8 supports Intel, ARM, and (to some extent) MIPS CPUs -- IIRC node itself only supports the first two of those.
I'm all for optimizing for the 99%-case CPUs, but it's frustrating that I can't use these JS-based tools even at a large performance penalty.
I was heartened by the existence of the "SpiderNode" project since it would provide some engine diversity to the node.js world. From what I can tell it doesn't seem to be getting much traction in the wider community though, so I don't know if that's going anywhere.
Last I heard, the V8 team's opinion on portability was "ARM is our bytecode, just emulate that".. which is a fine answer as far as it goes. However, I haven't seen anything that actually implements this advice though (short of emulating an entire linux kernel in qemu) I keep hoping that V8 will add a fallback non-JIT mode for greater portability but I'm sure it's not a priority for Chrome.
So JavaScript portability has ended up in an unfortunate predicament: the language itself should be portable to "any OS" but in reality all of the non-browser projects have tied their wagon to a single engine.. and that engine doesn't have wide portability as a goal.