instability in Berkeley versus AT&T releases (absurdly long)

[Eric Carroll]

In article <5852 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>
> For an explanation of why "one program, one function, done well" is a good
> way to build a system, see almost any discussion of the "Unix philosophy".
> Try Kernighan & Pike.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,linus,decvax}!utzoo!henry

_Software Tools_, pg. 84 (Kernighan & Pike):

	Efficiency is hardly of importance for a temporary hookup
	meant only to be used a few times. Should a particular
	organization of tools prove so useful that it begins to
	consume significant resources, then you can consider
	replacing it with a more efficient version. And you are
	way ahead at this point, for you are writing a program
	that has precise specifications and that has been shown
	to be useful.

I think columnar ls is a case in point, though perhaps a bit trivial to
really worry about. From the human perspective, it is much more
pleasant, and doesn't waste my time scrolling the listing off the
screen. And if it is used heavily, why not incorporate it? I agree with
modular, single function boxes, but there should be some quarter given
to practicality here; if it is used heavily, that is your license to
incorporate it into the code. I won't argue the more esoteric features
of ls. The point is, I think, that there are several levels of use:
One-function boxes strung together with pipes, shell scripts, and for
the most heavily used features that have made it to the level of
'heavily used shell scripts', C coding, or inclusion into an existing
binary program.  I see no justification for the religious statement
"Thou shalt code in sh." It is a relative, sliding scale that leaves
room for things like Berkley ls. Not to say that they have never
over-done it, mind you...

-- 
----
Regards,
	Eric Carroll

	Univ of Toronto, Computer Systems Research Institute
	{allegra, decvax, decwrl, floyd, ihnp4, linus}!utcsri!carroll