This sounds like a load of pseudo-mathematical bullshit to me.<p>I agree with the principle behind it, which I believe to be "all else being equal, fewer lines of code is better than more lines of code," but I'd argue that all else is rarely equal. Sometimes, spelling things out in a slightly more verbose way is better than using some slick one-liner.<p>When I was in grad school, I was that guy who would strive to get his proofs as short as possible, but no shorter. Since my audience consisted of fellow students (who could be expected to be at least as capable as me), and PhD mathematicians, a short, clever proof had much higher value than a long, plodding argument. (But, even the short proof needed to be understandable: I recall reading a paper co-authored by several famous mathematicians that included a diagram to show the structure of the proof, not the mathematical objects that were the subject of the proof!)<p>Software is not mathematics and it shouldn't be treated as such. Remember that code is read many more times than it is written; and that the audience is the people who will come behind you and read the code, not the compiler.
I think your conclusion might be vacuous, or at least oversimplified. What is "value"? If we don't assume that it takes a programmer a set amount of time to write any line of code (and I know it takes me much longer to do linear algebra in Haskell than bung out a bunch of arithmetic in Python), any manager would be just as happy with B. B might even be more maintainable- it might be so long because its done in Knuthian-style literate programming, say- or have other virtues above A, increasing its "value," by most peoples' estimation.<p>What in particular do you mean when you say A is "greater"?
I'm no expert but it seems to me that the relative value of two programs (or functions or classes or whatevers) can be determined by only their LOC count only in the most trivial cases - e.g., a class that uses a single construtor/parameter signature and performs a single task under a single set of conditions.<p>If the logic has to handle multiple, possibly overlapping parameters and branching conditions in order to "do the same thing", then the longer code may well "outperform" the shorter one by whatever metric is most relevant to the use case (e.g., perform faster, use less energy, use less memory, be more readable, maintainable, portable, secure, or any weighted or unweighted combination of such metrics).<p>Does this make sense or am I missing something??
<i>"Given any two unobfuscated source codes, the one that produces more value in average per line of code is greater."</i><p>For some software, higher performance is more valuable than fewer lines of code. For example, if you re-wrote the Linux kernel in Lisp, it might have many fewer lines of code than the current C version, but would deliver less value because it would run much slower and might stop for garbage collection in the middle of an interrupt handler. Concerns about real-time performance and memory-usage would also apply to lots of embedded software, like the code that controls the engine in your car.<p>I'm not sure that I'd call something a "fundamental theorem of software development" if there are large classes of software that it doesn't apply to.
Not to nitpick, but you might want to check your grammar and spelling. It's "lemma", not "lemme", for one thing, and "produce" should be "produces"
There's definitely some linear algebra which should be happening in the head of any programmer as s/he writes code, some combination and balance of functionality, conciseness, performance, readability / maintainability, extensibility, etc.<p>I'd suggest that this lemma doesn't quite take into account that software quality isn't just about what it is able to do today, but how efficiently it's able to adapt or be repaired in the future.
I wonder what PG would think of his given his notion of "power" as exemplified by his language arc: <a href="http://www.paulgraham.com/arcchallenge.html" rel="nofollow">http://www.paulgraham.com/arcchallenge.html</a>