

Kickstarter: Make a Better CoffeeScript Compiler - rainysunday
http://www.kickstarter.com/projects/1182995593/make-a-better-coffeescript-compiler

======
TrevorBurnham
I'm pledging $1,000 to this. As the author of the PragProg book on
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.

------
grayrest
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> <\- 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.

------
drcode
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
CoffeeScript doesn't have a built in minifier does it? You can still run
Closure against the js output.

~~~
jurre
Yeah but it would be nice if it was just a matter of setting a flag.

------
petercooper
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
Kickstarter allows me to add rewards after the project has started. What kind
of rewards would you like to see?

~~~
GuiA
\+ 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.

~~~
TamDenholm
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.

~~~
kennywinker
Along these lines, for Kickstarters where both individuals and companies are
probably going to donate in you're going to want different rewards. Companies
want recognition... their name in lights. Individuals want participation and
swag. Set rewards up accordingly.

------
evincarofautumn
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
_“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#W...](http://www.kickstarter.com/help/faq/creating%20a%20project#WhatCanBeOffeAsARewa)

~~~
evincarofautumn
Thanks. Couldn’t remember and missed it when I went looking. These things
happen.

------
gren
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
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.

~~~
strager
What prevents "new" JavaScript from being compiled like CS is being compiled
now?

~~~
TrevorBurnham
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/>

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...](http://stackoverflow.com/questions/6506519/ecmascriptharmony-
es6-to-javascript-compiler)

~~~
Raynos
Why don't we spend effort on building an ES:Harmony -> ES3 compiler rather
then a CoffeeScript -> ES3 compiler.

It's more worthwhile future facing project.

------
ksec
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
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.

------
jaekwon
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>

The grammar for CoffeeScript is getting there -- enough to parse the project
files at least.

[https://github.com/jaekwon/joeson/blob/master/joescript_gram...](https://github.com/jaekwon/joeson/blob/master/joescript_grammar.joe)

Michael, we can collaborate on this. Send me a msg on github or email
`jkwon.work` at gmail.

------
tomaskafka
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> (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);

------
hzy
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.

~~~
evincarofautumn
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
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.

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

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

Thanks for posting

------
krelian
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.

~~~
ScottBurson
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.

~~~
michaelficarra
Thank you, you are exactly right. Working on CoffeeScript is my passion. I
don't need any financial incentive to do it, I just need food, a place to
live, and some cash to hold off my student loan creditors.

~~~
michaelochurch
Kudos to you for having the stones to do this. I don't know much about
CoffeeScript, but what you're doing is cool.

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.

------
tkahn6
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
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."

~~~
alexis-d
Isn't Less written in JS now?

~~~
andrewflnr
Yes. I think he meant: _I'd advocate (Jade over Haml) and ((Stylus or Less)
over Sass)_

~~~
alexis-d
Oh totally, you're right, I misread his comment.

