Couldn't you technically just concatenate everything into 1 line and call in "X software in 1 line of code"?
Isn't it a better benchmark to have better code structure even if the project is composed of more lines of code or more files for that matter.
> Isn't it a better benchmark to have better code structure even if the project is composed of more lines of code or more files for that matter.
It isn't about benchmarks, it's about understanding a concept enough to cut junk out and providing clear concise code that does as expected.
You could also measure the compressed size of the code, since compression eliminates redundancies like long identifiers being repeated. But they’ll also sort of “cyclomatically optimize” your code as well—effectively re-rolling any hand-written unrolled loops, and shortening repetitions of a(b(x)) into the same result as a_b(x). You might say compression shows the optimal lexical size of the code. :)
That said, it's novelty and working within set restrictions that makes it impressive.
Not the line count of the code, but the fact that it works within the set restrictions of making an n64 software renderer (novelty) with that line count of code. (also a novelty)
It's not important at all, it's novel. We have had hacky, and even gimped for quick hacks n64 emulation (compare Project 64 to say, Dolphin) since the late 90's-early 00's, but we haven't had a 512 line object software renderer. A novelty for those who like novel programming exercises!
In my programs, I never took lines of code as a restriction. Since if you have a compiled program, the binary size tends to depend mostly on the compiler. I'm more focused on other restrictions, such as memory usage, etc.