TrevorBurnham
Joined 18 years ago
Joined 18 years ago
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.
Best of luck!
Of course, I think it's fair to say that there's more Obj-C code than CoffeeScript being written, but less of it is being open-sourced.
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...
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."
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.
This is my second book; the first was http://pragprog.com/book/tbcoffee/coffeescript.
I ran a Kickstarter in February to try to attract advance buzz: http://www.kickstarter.com/projects/869786663/async-javascri...
Buzzwords: JavaScript, CoffeeScript, jQuery, Backbone.js, Node.js.
Author of the PragProg book on CoffeeScript and a forthcoming book on Async JavaScript. Interested in solving JavaScript problems and architecting client-side applications.
And, recently, Async JavaScript: http://leanpub.com/asyncjs
I'm available for freelance work on exceptionally interesting projects. I live in Cambridge, MA.
Website: http://trevorburnham.com/
Email: [email protected]