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