2 ms·
This is both true and false. LoC is a volume metric. More volume = more things to comprehend. A great example of imperative vs. less-imperative is looping vs m
by pnathan 14y ago
This is both true and false. LoC is a volume metric. More volume = more things to comprehend.
A great example of imperative vs. less-imperative is looping vs mapping.
Mapping in Python:
foo = map(function, list)
vs looping in C++:
for(int i = 0; i < list.size(); i++)
{
foo[i] = function(list[i];
}
Note that the C++ version has about 6 choice points where errors can be made (or customized too - it's more flexible than a map)- initialization, comparison, upper bound, increment, lval index, and the rval index. So to grasp the entirety of the loop, you have to examine all 6 things, whereas the map is far simpler. After a while, this simplicity starts to add up.
However, LoC is a truly bad metric (other measures are, imo, just as bad), and doesn't really capture what I just said at all. What LoC does capture (as I said above) is volume - the extrinsic complexity of the solution. If you can hone your code so that it simply expresses the intrinsic complexity of the solution, your LoC will decrease to that point. And language helps a great deal.
Your point is really well made though: for industrial use you have to have a head to head of expert teams over a reasonable time frame for a reasonably sized system, in reasonably comparable conditions. And yeah, that's the big joke in SW engineering research. It's never really been done and published in any meaningful way. Some companies did do work in that area in the '80s, as I recall - but they didn't publish meaningful datasets as far as my reading shows. Most SW engineering research in this area is very much "small problems" and "students in a class".
- vineet 14y ago> More volume = more things to comprehend I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different styles of coding then you have a lot of other things to consider. On top of this, if you have a language that has very few underlying primitive (such as parentheses in lisp as opposed to [,;.] in other languages) then you actually have a higher comprehension barrier as the reader will need have to examine the role of the primitive as well. Basically, the terser the language the harder it is comprehend a LOC in that language. On the research note, I do agree that most SW engineering research has focused on 'small problems'.
- pnathan 14y agoI disagree. :-) It is that simple, at base! More stuff = more things to wrap your head around. I posit that a well-written terse solution should say exactly the intrinsic needs of the problem at hand, and no more. The ideal language abstraction would explain exactly what needs to happen and no more. The key forms of the language (macros, functions, etc) should be built up to that point so that it is clear what is going on. There is - in my mind - little difference between (with-open-file (file-stream filename) (do-stuff (read file-stream))) and stuffDoer(fileObject(filename).read()); Both say (to me) exactly the same thing at approximately the same level of abstraction; one does it with Lisp syntax and one in traditional C++ syntax. The question starts to arise after a while - what abstraction tools does the language make available. At what point do you need functions, classes, closures, m4 macros, lisp macros? Well, at the point when you need them. :-) These are all just tools to say exactly what you mean in as much code as you need. If you have a social problem of a bunch of cowboys all whooping it up in your codebase, I don't think any technical solution is going to help you. :-)
- masklinn 14y ago> Both say (to me) exactly the same thing at approximately the same level of abstraction They don't, though: depending on the exact C-style language, you may have leaked a filehandle.