OT: lines of code (was Re: [dwm] jr-patchset up to date)

| 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.

<asbestos underwear>

One difficulty I have with emphasising minimising the lines of
code is that it tempts people to design functions which `work
given that we know other functions f1() and f2() happen to
produce certain things in a certain way', with these important
relations only implicit in the code. This creates strongly-coupled
components where it's difficult to change one thing in isolation.
I much prefer programs that have more lines, but create
sufficient abstractions that modifying individual pieces is possible
most of the time. (Clearly any non-trivial program will have some
fundamental assumptions that you can't change without changing everything.)
If you like, this is the `non-expertisation of programming': if I
have to understand every nuance of a program in order to modify it
then having the source code is relatively useless to me. If it's
structured so that I can bumble around trying understand and
change just one bit, then it's actually useful. (Think people who
are reasonably intelligent but don't want to be full-time programmers
such as scientists, etc. Eg, I've modified part of dwm yet I know almost nothing
about X and its conventions and protocols.)

That's why I'm more interested in programs that do one well-defined
thing rather than lots of vaguely related things. To be fair, I think
this is the sort of thing Anselm is getting at with `shortest program'.
</asbestos underwear>

cheers, dave tweed
Received on Wed Aug 30 2006 - 14:35:26 UTC