Congratulations on launching! I applied to YC a few years ago with a similar concept. Your site looks gorgeous, and I'm excited to see it develop. I hope you succeed in disrupting a space that's been neglected for far too long.
I believe the company talbina's thinking of is mine: We applied as Theoryville, got interviewed, got rejected, applied to Betaspring (http://betaspring.com/), got accepted, changed our name to DataBraid, and proceeded to fall apart over the course of a summer.
I do think the idea has a lot of potential, and what StatWing has built is already more complete than what my team managed to build in 3 months. A few suggestions I'd offer based on that experience:
1. Parsing CSVs is easy in theory, but painful in practice, because CSVs in the wild tend to be full of junk. I would provide a JSON API that makes it easy for developers to put data in your system directly, allowing people to build their own CSV parsers for you.
2. Use GitHub as your model. You want people to collaborate around data the same way that developers collaborate around code. Just about every day when I was doing DataBraid, we'd discuss a use case and then say "Oh, GitHub already figured out the right way to do this." The most compelling use case here is that researchers can run different sets of tests on the same data and discuss which approach is the most valid/insightful.
3. Getting to revenue will be hard, but having paying customers will make it much, much easier to attract investment. So find the MVP that people will pay for and put everything else on a "nice-to-have" list.
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.
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."
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.
More CoffeeScript consoles are always welcome, but this one isn't very intuitive. The minimalism goes too far; you have to mouse over the logo just to see the instructions. Also, isn't CTRL+X spoken for (as "cut") on non-Mac systems?
Author of the PragProg book on CoffeeScript and a forthcoming book on Async JavaScript. Interested in solving JavaScript problems and architecting client-side applications.
Intermediate. It would work well as the second book you read on JavaScript (or, given the way most devs come to JavaScript, the book you read after reading a book on jQuery). But there's stuff in there that even experienced devs might not know about, like Promises and control flow libs like Async.js.
Apple provides very little documentation when it comes to embedding HTML in an iBook, so I hit a lot of walls when trying to get the examples running for CoffeeScript: An Interactive Reference (http://itunes.apple.com/us/book/coffeescript/id498532763?mt=...). Hopefully this project will save other developers time and effort as they use iBooks Author to create interactive book-apps.
I'm the author of both this and the PragProg book (http://pragprog.com/book/tbcoffee/coffeescript). I wanted to offer a more succinct guide to the language that would quickly address common points of confusion. My hope is that CoffeeScripters who hit some unexpected behavior will be able to open the iBook to the right page, tweak a code sample, and say "Aha!"
Caveat emptor: This is a first edition, and updates (both technical and content-wise) are planned for the near future. Feedback is very welcome.
Looking to solve interesting JavaScript (or CoffeeScript) problems.
* I wrote the CoffeeScript book for PragProg.
* I'm avid about Node.js and jQuery.
I've also been getting into iBooks Author lately. My first iBook, "CoffeeScript: An Interactive Reference," is already available on iTunes (http://itunes.apple.com/us/book/coffeescript/id498532763?mt=...). If you have a fresh idea, I'd love to collaborate with you on an interactive book.
It looks very Rails-y with many sensible defaults (e.g. automatic CSRF for forms), but is quite a bit more lightweight. Making Redis a dependency is a smart choice; you need to store all session state, etc. outside of the process in order to cluster a Node app and take advantage of all cores.