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.
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:
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.
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.
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.
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.
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.
I think GuiA gave a good response. Psychologically, I think the $1 level is a bad anchor but then you're also missing a lot between the $10-$100 range where I'd suspect most donations would come (by quantity, not $ total).
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.
+ 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.
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.
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.
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.
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.
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.
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.
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.
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).
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?
# 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
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.
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.
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.
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.
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.
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.
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.
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.
Why not find a regular programming job that will pay you much more?He is obviously skilled enough to be hired.
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.
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?
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."
Actually this is the opposite of my experience. It's actually "Run Anywhere, as long as you're on an Intel or ARM CPU".
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.
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.