🚀 go-pugleaf

In article <87774@tut.cis.ohio-state.edu> Bob Manson <manson@cis.ohio-state.edu> writes:
>I know what you're trying to say. It's a useless waste of time to
>write extra code to make a program limit-independent when we can make
>a good estimate of the maximum numbers & provide source for
>recompilation. My argument is, it really doesn't cost that much more
>to design the program properly to function without limits. The cost in
>making utilities with fixed limits in them is unhappy customers & time
>spent rewriting programs, since I seriously doubt source policies will
>change anytime soon. Your point about utilities dying on too long
>input lines is an excellent example; really, there is no much thing as
>a "too long input line". Whoever wrote sed decided that lines would
>never be longer than 4000 characters, and they were quite wrong...

I agree with this most emphatically.  The kind of software design Mr.Manson
is complaining about is rampant in the industry, and pervades Unix.  Most
programmers learn software design by example.  Sometimes this is good, when
a good programming style (e.g. programs that filter stdin to stdout) is
mimicked, but it also propogates poor programming practices.  When I talk
about the "brokenness" of Unix, it's this kind of stuff I'm thinking of.

These kinds of problems aren't even in utility programs, but in just about
every level of the system.  For instance, file descriptors are indexes into
a per-process table in the kernel; in many of the older Unix versions I
don't even think the size of this table was configurable, but I may be
mistaken.  Of course, there are often good reasons to put some limits on
per-process and per-user resources, to keep a single user or buggy program
from hogging a system, but why aren't they runtime options?  Why should I
have to rebuild a kernel because I need more ptys?

Yes, I admit that it is easier to program with fixed-size tables and
buffers, but who ever said good programming was supposed to be easy?  Of
course, I'm biased, because I do much of my programming in Lisp, which
makes it easy to write programs with few arbitrary limits.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar