Re: [dwm] jr-patchset up to date

From: Anselm R. Garbe <>
Date: Wed, 30 Aug 2006 12:59:13 +0200

On Wed, Aug 30, 2006 at 01:41:38PM +0300, Ville Koskinen wrote:
> On Wed, 30 Aug 2006 11:34:05 +0200
> "Anselm R. Garbe" <> wrote:
> > I'm also going to generalize the 10kloc project into 'shortest code
> > project' - which will only accept software <10kloc, but with somewhat
> > more liberal statements.
> I've been meaning to comment on that...
> I wholeheartedly agree that the less loc a program has the less errors
> it has, and that people should try to write less and not more. 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 most elegant and the most 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 the opposite 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]

Actually I agree on what you wrote, especially your concerns
about a fixed LOC boundary. This is especially the reason why I
want to generalize the philosophy into the shortest code
direction. However, there must be some criteria of a boundary to
separate this project from the mainstream. I choosed 10kloc
because of my own experience with existing software, even if
this is quite random.

I've seen much crap software exceeding this maximum, and rarely
crap software under-running this boundary.


 Anselm R. Garbe  ><><  ><><  GPG key: 0D73F361
Received on Wed Aug 30 2006 - 12:59:14 UTC

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