4 ms·

I never understood the importance of lines of code for projects such as this one. Couldn't you technically just concatenate everything into 1 line and call in

I never understood the importance of lines of code for projects such as this one. 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.

oxide 9y ago
Yes. 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!
- _cwolf 9y ago
  High praise. Thank you.
- westoque 9y ago
  I completely agree. You make a good point! It's definitely a novely. 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.
figgis 9y ago
They aren't just concatenating though. The code is clean and understandable with short comments explaining a few things. > 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.
derefr 9y ago
A better measure of “effort to write code” is the number of lexer tokens. So, identifiers count as one (regardless of length), operators count as one, each paren counts as one, and spaces count as zero. Code that has had more “blunt force” applied to it to get it working will end up with more lexer-token length. Code that has had most of its repetition factored away will have few (although, in turn, its cyclomatic complexity will go up, meaning that it might now be harder to read, however much easier it is to maintain once grokked.) 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. :)

oxide 9y ago

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

_cwolf 9y ago
High praise. Thank you.
westoque 9y ago
I completely agree. You make a good point! It's definitely a novely. 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.

figgis 9y ago

They aren't just concatenating though. The code is clean and understandable with short comments explaining a few things. > 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.

derefr 9y ago

A better measure of “effort to write code” is the number of lexer tokens. So, identifiers count as one (regardless of length), operators count as one, each paren counts as one, and spaces count as zero. Code that has had more “blunt force” applied to it to get it working will end up with more lexer-token length. Code that has had most of its repetition factored away will have few (although, in turn, its cyclomatic complexity will go up, meaning that it might now be harder to read, however much easier it is to maintain once grokked.) 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. :)