[9fans] efficient programs as distinct from humble programmers

[Richard Uhtenwoldt <ru@ohio.river.org>]

in the late 70s, Edsger Dijkstra and Tony Hoare advocated the
"humble-programmer" philosophy, which says that humans tend to
overestimate their ability to handle complexity in software and
consequently one should strive (in addition to one's other objectives)
to pessimize the complexity (measured in lines of code) of the software
one relies on.  often, this is achieved by finding a novel way of
viewing or conceptualizing the problem (like per-process namespaces).
they pointed out the programmer who can meet a set of requirements with
fewer lines of code is the better programmer because a smaller program
will usually be easier for the user to control, more likely to behave
the way the programmer thinks it will behave and easier for future
programmers to modify to do something the original programmer did not
provide for.

in summary, a "humbly-written" program will not unnecessarily waste the
time and the attention of the programmer trying to modify it or the user
trying to control it.

large (ie, rich, generally useful) humbly-written programs are rare. the
Plan 9 papers make it clear that the core designers of Plan 9 are humble
programmers: 3 or 4 times, I saw words to the effect "we were able to
provide this functionality in only XX,000 lines of code" (and yet Plan 9
appears to provide a rich, generally useful software environment).

it is important to distinguish between the aforementioned conserving of
human attentional resources and conserving memory, disk, bandwidth and
cpu resources.  memory size, disk size, bandwidth and cpu speed
double every few years.  the speed at which a person can learn or the
number of things a person can keep track of does not grow like that.

that is why I do not like the term "code bloat".  most Linuxers who use
that term are deploring the wasting of cpu or memory resources.  it would
be more clear if those people refer to "inefficiency".

some people --like dhog@plan9.bell-labs.com in the following quote-- use
the term "code bloat" to mean what I would rather call "gratuitous
complexity":

> > hate to see gnome ported and get 20meg staticaly linked
> > simple CD player
>
> So basically you want shared libraries to mitigate the effects
> of code bloat?  Why not do away with the code bloat instead?
> This is Plan 9's approach.

this use of "code bloat" managed to confuse at least one person,
who thought it referred to wasting memory:

>huh !?!
>
>i thought statically linking each and every application in the system
>IS code bloat

(note that I have not taken a position on shared libraries.)
--
Richard Uhtenwoldt