Complexity of reallocating storage (was users command crap)

[Dan Bernstein]

In article <1991Feb04.161829.9385 at convex.com> tchrist at convex.COM (Tom Christiansen) writes:
> From the keyboard of dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi):
> :In <5883:Feb102:05:4991 at kramden.acf.nyu.edu>
> :brnstnd at 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.