LOC is not a bogus metric, it just depends on what one is measuring. If you're trying to measure code review and maintenance cost then LOC is definitely a valid metric. More lines equals more effort.
Agreed: varied comments, personal style, and syntax can affect LOC without increasing complexity, so it's silly to make a big deal about tiny differences in program length. A 400-line program probably has the same complexity a 300-line alternative, so saving a few lines probably isn't worth making a program illegible (I'm glaring at you, RegEx). At some point, however, a big difference in size indicates a big increase in complexity. For example, a 1,000,000-line program is definitely more complex than a 100-line one.
relative complexity = round (program A LOC / program B LOC)
Measuring complexity reminds me of Fermi Problems. It's really hard to quantify accurately, so I have to make squishy comparisons based on educated guesses. My rule of thumb: if a program is more than twice as big as another, then it's significantly more complex.
Thus, if switching to a new language would cut my program in half (or more), then it's worth considering.
Yes, I even think so comparing across a language. If given the same functionaly equivalent solution in two languages, including error processing, then I would say the one with lower LOC* is of higher value.
Readability is an issue, but I find syntax redundancy is the biggest problem in readability. Less code is simply less to understand, even if it involves more complex operations.
Definitely for Leaf I'll be optimizing for succinctness, but I'm not in favour of complex syntactic structures. I also have inferred and implicit typing, which removes a lot of syntax (it can look like a dynamic language without being one)
(*We might need to be a bit careful in defining LOC though, perhaps just total functional code-size is better, to avoid packed lines somehow getting an undeserved higher score)
LOC is not a bogus metric, it just depends on what one is measuring. If you're trying to measure code review and maintenance cost then LOC is definitely a valid metric. More lines equals more effort.
Ah! Not necessarily always true.
Code is written for other people to read, so it needs to be expressive, which may mean more lines sometimes.
Agreed: varied comments, personal style, and syntax can affect LOC without increasing complexity, so it's silly to make a big deal about tiny differences in program length. A 400-line program probably has the same complexity a 300-line alternative, so saving a few lines probably isn't worth making a program illegible (I'm glaring at you, RegEx). At some point, however, a big difference in size indicates a big increase in complexity. For example, a 1,000,000-line program is definitely more complex than a 100-line one.
relative complexity = round (program A LOC / program B LOC)Measuring complexity reminds me of Fermi Problems. It's really hard to quantify accurately, so I have to make squishy comparisons based on educated guesses. My rule of thumb: if a program is more than twice as big as another, then it's significantly more complex.
Thus, if switching to a new language would cut my program in half (or more), then it's worth considering.
Even between different languages?
My Java-wired-brain has said hundreds of times that it was not.
I have changed my mind.
What about you?
Do you optimize Leaf for succinctness? Does that impact readability?
Yes, I even think so comparing across a language. If given the same functionaly equivalent solution in two languages, including error processing, then I would say the one with lower LOC* is of higher value.
Readability is an issue, but I find syntax redundancy is the biggest problem in readability. Less code is simply less to understand, even if it involves more complex operations.
Definitely for Leaf I'll be optimizing for succinctness, but I'm not in favour of complex syntactic structures. I also have inferred and implicit typing, which removes a lot of syntax (it can look like a dynamic language without being one)
(*We might need to be a bit careful in defining LOC though, perhaps just total functional code-size is better, to avoid packed lines somehow getting an undeserved higher score)
Very good point about LOC.
Best of luck with Leaf!