[rcirka]

Although it is impressive that an app like this can be created in such few lines of code, I think it is a bad precedent as a programmer to have a goal to write as least as many lines as possible. It leads to hacks and unmaintainable code. I would rather have a method that has 10 lines of code that can be easily understood, then a method with one line of code that is only understood by the creator. That is not to say that one shouldn't focus as code reduction via re-usability, but one should always write code the can be understood by others.

[mistercow]

This code isn't particularly hard to understand, and that's one of the things I was impressed with about it. If it were more than a demo, it would need comments to explain its cleverer bits, but on the whole, it's pretty cleanly written.

But I disagree that writing short programs for the sake of writing short programs is a bad thing. Sure, you need to recognize that you can't take all of the habits you get from it with you when doing stuff for production, but it can be a good goal when creating prototypes. One big advantage is that it prevents feature creep.

I wrote a library a while back called DelayedOp for wrangling async calls in JS. Originally it was 5 lines of CoffeeScript, and I actually used it in that form for a while. It's much bigger now and full of features to aid in debugging. The key is that by writing it minimally to begin with, I got something I could use and see what features I actually wanted to add. And while I mourn the elegance of those original five lines, I also realize that what it is now is far more useful and reliable.