TrevorBurnham

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.

Best of luck!

They said it couldn't be done, but CoffeeScript bumped Objective-C down to #11.

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.

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

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

That's a good idea. Michael, you should look into doing a run of CoffeeScript coffee mugs. These ones were much-loved and are no longer available: http://www.etsy.com/listing/93595042/coffeescript-mug

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.

Looks like the REPL is still affected, though: https://github.com/jashkenas/coffee-script/issues/1829#issue...

I'm the author, ask me anything.

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

Not a very good deal, given Codeschool's $25/month unlimited access membership plan.

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?

SEEKING WORK – Boston or Remote

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.

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.

May I mention that I have an entire book on this subject coming out in March? http://leanpub.com/asyncjs/

I'm the author, ask me anything.

A sample chapter on Promises, focusing on their implementation in jQuery (1.5+), is available now: http://www.kickstarter.com/projects/869786663/async-javascri...

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.

Thanks! I'm planning to add syntax highlighting in the next update.

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.

SEEKING WORK - Boston/Cambridge, MA or Remote

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.

Ryan Dahl (creator of Node) tweeted that "this looks pretty awesome": http://twitter.com/ryah/status/148659426897825792

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.

SEEKING WORK - Boston/Remote

Web dev. Wrote the PragProg book on CoffeeScript. Proficient in jQuery and Node.js.

I also enjoy random networking, so if you're in the Harvard/MIT vicinity and you want to talk tech, let's grab coffee. One person got into Y Combinator after asking me for interview tips, so I may be a good luck charm. ;)

Page design feedback: You should make the "Free Trial" link more prominent (make it a button with a bright background). Bump up the line-height on all the text; it looks too crowded.

Features list needs to give more specifics about RAM, disk space, bandwidth, etc., not just a list of pre-installed software (especially things like Express and Backbone that are trivial for me to bundle with my app when I upload it).

The bullet point about "We don't make you go through a proxy" is useful. You could also brag that WebSockets work—last I checked, this is a big drawback on Heroku.

Is there a reason you refer to Node as "n*d." on the front page, and "nod." on the features page?

It's a false choice that's been presented many times: Learn CoffeeScript, or learn to do JavaScript right.

When I wrote the PragProg book on CoffeeScript (http://pragprog.com/book/tbcoffee/coffeescript), my aim from the start was to fill common gaps in JavaScripters' knowledge while introducing them to the new language. Brendan Eich himself said in his blurb for the book: "It helps readers become better JavaScripters in the process of learning CoffeeScript."

Far from distracting people from learning JavaScript properly, CoffeeScript is a terrific learning tool.

There is a Justin.tv iPhone app that would allow you to watch it, but it's $4.99: http://itunes.apple.com/us/app/justin.tv/id358612216

The thesis of this piece is that Steve Jobs was less controlling after he returned to Apple than before, and that the iPhone "is far more open than the Mac ever was..."

I am guessing that James Surowiecki does not read Hacker News. Would anyone here care to make the case that iOS is more "open" than the Mac, in any sense?

I appreciated this generous interpretation of a blackboard reading "1+1=2":

> This is clearly an extremely advanced level mathematical course, focusing on the Peano axioms for the natural numbers which formalised mathematics in the late 19th century. This course would culminate with Gödel's second incompleteness theorem which shows that the consitency of the Peano axioms cannot be formalised within Peano arithmetic itself.

What the hell? Since when is posting a pull request telling someone they should kill themselves funny or cool? Why is this being upvoted on HN? Shameful.

Zappa is an excellent web framework that builds on Express to provide a more Rails-like "convention over configuration" experience for Node.js. And this is its fancy new website.

> Save yourself the headache and make a <script> tag with an id

That's not always efficient. Suppose you want the same lengthy template to be available across several pages which share the same JavaScript. Then it makes a lot more sense to put the template in the JS and serve it once than to put it in the DOM and serve it repeatedly. Also, with the DOM approach, you have to insert data into the template using regex rather than simple str1 + data + str2.

If syntax highlighting is really your major concern, write a simple script that compiles your .html to .coffee (sandwiched with """). Best of both worlds.

It looks weird at first, but it's great when used like so:

    return x unless err
    return y if condition
    ...
    return z

Keeping all of your "return"s at the start of the line makes it much easier to see, at a glance, what the possible return values of your function are. (And, of course, when you see a "return" in the middle of your function, you know there must be a condition attached.)