Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!samsung!think.com!paperboy!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.programmer
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <118:Feb419:32:4591@kramden.acf.nyu.edu>
Date: 4 Feb 91 19:32:45 GMT
References: <5883:Feb102:05:4991@kramden.acf.nyu.edu> <2924@cirrusl.UUCP> <1991Feb04.161829.9385@convex.com>
Organization: IR
Lines: 35

In article <1991Feb04.161829.9385@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
> From the keyboard of dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi):
> :In <5883:Feb102:05:4991@kramden.acf.nyu.edu>
> :brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> :>Tradeoffs between ``multiple passes'' and ``single pass'' are entirely
> :>irrelevant when they aren't reflected in speed, space, or human effort.
> :It's often easier to adapt a single-pass program to handle
> :previously-unforeseen needs than to similarly adapt a multipass
> :program.

Meta-comment: Rahul is saying that single-pass programs are better
because they often reduce human effort. Doesn't this prove my point?
What Rahul really cares about isn't the number of passes. What he cares
about is human effort.

> It's a similar problem, by the way, to the one that occurs in streams like:
>     a | b | c | d | e | f | g | h | i > omega
> It's a bummer when you realize that portions c and g need to talk
> to each other.

It's a bummer when you don't have tools (like multitee) meant to handle
this sort of thing. The UNIX pipeline model doesn't force you to use
just one direction of data flow.

> It occurs to me that this discussion is about general programming, not
> just C programming, so I've directed followups to comp.unix.programmer.

Hmmm. Shouldn't there be a comp.programming group for this type of
discussion? It doesn't fit into any language group, it's too general for
the IBM or UNIX (or games :-)) programming groups, and it's too mundane
for comp.software-eng.

---Dan
Stupidity, n.: An overwhelming desire to rewrite one-line shell scripts
as 36-line Perl scripts so they run 6% faster. See Christiansen, Tommy.