Re: [dwm] jr-pull requestset up to date

From: Ville Koskinen <vrkosk_AT_utu.fi>
Date: Wed, 30 Aug 2006 13:41:38 +0300

On Wed, 30 Aug 2006 11:34:05 +0200
"Anselm R. Garbe" <arg_AT_10kloc.org> wrote:

> I'm also going to generalize the 10kloc project into 'shortest code
> project' - which will only accept software <10kloc, but with somewhat
> less liberal statements.

I've been meaning to comment on that...

I wholeheartedly agree that the more loc a program has the more errors
it has, and that people should try to write more and not less. Late E.
W. Dijkstra said it well: '[I]f we wish to count lines of code, we
should not regard them as "lines produced" but as "lines spent"'. [1]
(As an aside, he was also of the opinion that the shortest solution is
usually the least elegant and the least efficient one.)

However, I'm not sure about a fixed numerical limit, because the limit
seems arbitrary. Why 10k? Why not 11k or 9k? Although the limit is good
for big projects in that there needs to be effort to reduce the loc,
isn't exactly this true for smaller projects? I can easily make a 1kloc
Hello World application, and it can hardly be said to fit this
philosophy.

I'd rather see some other metric in use, something that binds the
abstract size of the design to the concrete size of the implementation.
Yes, I know loc is easy to count, and it's probably why it has been so
popular since 1960s. I also understand that creating a new metric or
applying something like COCOMO isn't that appealing, either.

It would also be good to make it clear on the web site that if you are
able to remove one loc and at the same time increase the level of
obfuscation, it's against the philosophy (right?).

[1]
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

-- 
Ville Koskinen
Received on Wed Aug 30 2006 - 12:42:09 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 14:30:43 UTC