I must formally disagree: 500 lines is about how you can read and comprehend a program. 500 lines fits in a single file in virtually any programming language (yes, you can put multiple classes in a single *.java file). And if you make use of libraries which allow to write 500 lines of high order instructions steering a vastly complex machinery, even better! This allows the 500 lines to be very expressive. I really like the idea because it puts emphasis onto a well written documentation which explains concepts while the code is very breve. Shorter code can increase the probability that bugs are found because it is probably more frequently read by other people.

> 500 lines is about how you can read and comprehend a program.

(With the exception of languages that are idiomatically horizontal, such as Forth or APL, where a 500-line program sounds about as reassuring as a 500-line mathematics paper, and is probably about as dense. But none of the programs in that book use one of those.)

Remembering that a line of code is a price you pay, and not an accomplishment in and of itself, is a valuable mindset to maintain. And I think that 500 lines is a comparable volume of code to digest across many languages. It may accomplish varying amounts of useful work, but that's beside the point. The purpose of this work is not to engage in an inter-language, inter-domain pissing match; it's to meditate on the human economics of software design. It says as much in the introduction: "500 Lines or Less focuses on the design decisions that programmers make in the small."

Thinking about these things does matter. This past week I refactored a somewhat challenging piece of code my team had been maintaining from several hundred lines of code to about 30, without playing code golf. And I found and removed bugs (and even a little bit of code golf) in the process. Similar to what the book's introduction suggests, a lot of this change was down to rethinking the abstractions and decomposition of the code. The original version apparently tried to force the problem to fit a preselected design pattern. Doing that instead of decomposing the problem according to its own natural structure really does seem to have resulted in a ~10X code bloat factor.

That's literally the point of the book. Showing how you can use 500 lines of codes to do a whole lot of things, if you know what you're doing and use the appropriate language, in a way that others can still understand what's going on.

Pick the tool based on your requirements, not the other way around =)

Yeah, working in C and python you definitely have to reinvent the wheel less in Python ;-)

I recently wrote an 8bit style CPU simulator (with it's own simple but perfectly usable instruction set) and assembler, together they fit into 1000 lines of C... To be fair that's a fairly specific case where C works really well though!

The OCR example uses the full capabilities of the browser environment. A quick scan shows html, canvas, events, XmlHTTPRequest, and JSON.parse on the client side. What the python "server" exactly uses isn't completely clear, but it includes numpy, and probably some ANN library. So yeah, it's a bit of a stretch to compare that to 500 lines of stdlib-only C.

The seemingly arbitrary limit also helps to guide the choice of language: if it's too verbose in one language, it's probably the wrong one for the job! (I.e., reinventing too many wheels, un-ergonomic language patterns vs domain logic, etc.)