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.
I think those numbers also reflect something other than the obvious.
There's a huge contingent of…uh…let's just say "differently educated" developers who previously were making some delicious pasta in PHP and now want to build iPhone apps because they heard there's gold in them thar hills.
Objective-C is also a lower-level language than CoffeeScript and thus harder to use, especially if you're not used to working in a language where it's possible to free memory early or smash the stack.
So CoffeeScript is a very easy language that tends to be used by developers who are experienced in its domain, while Objective-C is a relatively hard language that has gotten a huge influx of rank amateurs in Stack Overflow's lifetime. Thus, the latter gets a disproportionate number of questions.
(For credibility's sake: I'm one of the top contributors to the Objective-C tag on Stack Overflow.)
Other factors probably at play: Obj-C MUCH older. CoffeeScript designed to be simple and have fewer "bad parts" thus fewer questions. Many problems faced while coding CoffeeScript are actually javascript or DOM or Web questions so you don't tag them with CoffeeScript. StackOverflow isn't overly loving of CoffeeScript, so I often ask my questions using JavaScript even if my source is really CoffeeScript (and again the questions aren't really about CoffeeScript but usually about JavaScript).
Objective C has been in heavy use for a lot longer then CoffeeScript though. CoffeeScript has only been stable for over a year. Objective C has been in use since before the creation of StackOverflow.
You have to factor in all the newbies that here all this doom and gloom about the job market in the media, and the last tidbit in the news story usually mentions "but there is a lot of growth in iPhone and Android apps". This is probably causing a lot of people new to programming to learn Objective-C, thus many more questions.
That could also say something about the languages and the platforms rather than the number of people using them, especially since all of Apple's libraries fall under the category of Obj-C. You're probably right, just wanted to point that's not necessarily a good measure either.
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."
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.
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.
