🚀 go-pugleaf

In article <12689@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
<No vendor should provide a routine named "pnmatch."  Vendors are
<not supposed to pollute the namespace with "convenient" (but
<invariably unportable and system-specific) routines.  ("Then why
<do so may vendors do so?" you ask.)

I'll tell you why: because customers want them. Here's a transcript of a
not uncommon telephone call:

Customer:	Compiler X has 427 library functions. Your compiler has
		only 387 library functions. When are you going to fix that?
Me:		Which library functions does X have that we don't that you
		need?
Customer:	But there are more library functions with X, therefore
		X is better.

Some people tend to rate a compiler by:
1.	The number of library functions (What they are is irrelevant).
2.	The number of pages in the manual (Content is irrelevant).

If you disagree with this, pick up some magazine reviews of C compilers.
Though, to their credit, the reviews *have* improved on these points in
the last 2 years, though some are still impressed by the *heft* of the
package!

Compiler vendors have responded to this pressure by creating vast quantities
of library functions. A surprisingly large percentage of these are totally
trivial (< 10 instructions). For example, routines that merely interface
with BIOS functions. What's wrong with these functions are that:
1. They clutter up the library.
2. They clutter up the manual with descriptions that are essentially
   duplicated from the BIOS manual.
3. They foster an illusion of writing portable code.

Manual writers (and reviewers) ought to read Strunk and White. A good
reference manual should contain exactly sufficient words to describe it,
no more, no less. The bloat properly belongs in a physically separate tutorial.