Hacker News Reader

The challenge should be LOC total, including the LOC of the libraries used. That is the only possible way to compare apples to apples. Otherwise, what is to stop you from wrapping the entire solution into a "library" and just making a simple call-out to said library.

What is the total LOC of the implementation, period. Remove all ambiguity.

View on HN

With respect to ambiguity: Wouldn't the LOC count have to also include the code of the interpreter or how would you compare an interpreted language where some method is "built-in" with another language where the method has to be implemented in a library?

Anyway, LOC count is a fetish that wreakes havoc in language communities like ruby. I'd be more interested in readability and clarity. Show the code to somebody who knows the language only superficially and take the time the person needs to figure out what the code does.

It would be possible to implement a processor that implemented this as a single assembly language instruction!

How low do you go before you give up? Silicon atom count?

I'd say that 'LoC using a language plus common libraries at least some developers use in real projects' is the most valid thing to measure.

Reply on news.ycombinator.com