yeah.
I guess a lot depends on other factors though.
for example, is a lot of this added code because:
the programmer has little idea what he was doing, and so just wildly
copy-pasted everywhere and made a big mess?...
has lots of code which is actually beneficial, such as doing error checking
and building abstractions.
similarly, is a piece of code smaller because:
the programmer is good at getting work done in less code?
or because the code is essentially a tangled mess of hacks?
these may matter more in many cases than the total code size.
like, if the app is only 10 or 15 kloc, but most of it is composed of
"if(...) goto ..." and ugly use of bit-twiddling and pointer operations
(say, you see things like "((int *)(((void **)p)[i+5]))[16]+*(int *)(*(void
**)q)" pretty much every-other line), and the programmer couldn't be
bothered to use more than 3 or 4 characters for most of their function
names, this is not necessarily a good thing.
a similar app which is maybe 20-25 kloc, but consists of code which may be
understood (and doesn't blow up in ones' face as soon as it is fed bad
data), may be a little better.
but, then again, sometimes an app may benefit from being smaller, for simple
sake that ordinary humans can work on it (without having to go up a steep
learning curve and having to become "experts" on the thing before being able
to do much of anything).
for example, a 350 kloc app may be better, even if it does a little less,
than a 5 or 10 Mloc app, if it means that the programmers can more easily
understand the thing in its entirety.
feature bloat is also a problem. features may be good, but too many features
may not be a benefit to ones' purpose, and sometimes a piece of code which
is smaller and only does a few things well, may be better than a larger
piece of code trying to do everything adequately... (sometimes, we don't
need some unified "one true implementation").
but, a lot comes down to abstraction as well:
a much larger codebase with much better abstractions may still be much
easier to work on than a smaller codebase with few or poorly-chosen
abstractions (for example, if the codebase is relatively well organized, and
its code relatively self-explaining, then one can more easily get things
done without having to keep as much in-mind, but if changing something one
place means they have to fix something somewhere else which breaks as a
result, this is a problem...).
but, there are many factors involved.
or such...
----- Original Message -----
From: "Colin Putney" <[email protected]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Friday, July 09, 2010 12:56 AM
Subject: Re: [fonc] goals
On 2010-07-08, at 9:21 PM, Steve Dekorte wrote:
Thanks for the response. That kind of sounds like the goal is fewer lines
of code (and presumably less labor) per unit of function (increasing
productivity). Is that correct?
Well, I don't speak for Alan, but I have to think it's a bit more than that.
The biggest problem we have in computing is that we're terrible at it. Just
the other day I remarked to a colleague that the system we were working on
had about 10x too much code for what it did, and he agreed. So yes, less
code for the same functionality might (might!) be higher productivity, but
it's also a rough measure of quality. Writers seek economy of words,
athletes seek economy of motion, we seek economy of code.
Colin
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
