Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!julius.cs.uiuc.edu!usc!samsung!uunet!aurs01!throop
From: throop@aurs01.UUCP (Wayne Throop)
Newsgroups: comp.os.misc
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <59462@aurs01.UUCP>
Date: 21 Jan 91 19:04:57 GMT
References: <1991Jan16.063253.2834681@locus.com> <1991Jan16.182106.1758@Think.COM> <59451@aurs01.UUCP> <1991Jan18.175917.28766@Think.COM>
Sender: news@aurs01.UUCP
Lines: 31

>,>>> barmar@think.com (Barry Margolin)
>> throop@aurs01.UUCP (Wayne Throop)

>>> None of these changes are feasible in current Unix, 
>>I mildly disagree.
> Well, I'm not a big fan of command processors where the syntax descriptions
> are separate from the commands themselves, so I often inadvertently forget
> about them when making statements like the above one.
>   [.. well-presented details of some of the design tradeoffs
>       involved,  omitted for brevity ..]
> This is why I prefer library-based approaches rather than shell-based
> approaches.

Good points, but I'd like to briefly add one tradeoff which weighs in
the opposite direction, and is perhaps the primary reason I end up
prefering.... well, not so much "shell based" but "non-library based"
approaches.

If the mechanism is a library (or a bit more precisely, if the
implementor interface to the mechanism is a library), it (IMHO)
inordinately encourages an imperative or procedural description of the
argument interface to a command.  But if one has to spell it out in
some command-description-ese, I find it encourages readability and
reusability both.  And (going along with the readability) a standard
command-description-ese can make an excelent presentation in the user
documentation, while being very precise.

I sadly admit that these criteria are somewhat more vague than the
ones Barry outlined.  Sigh.

Wayne Throop       ...!mcnc!aurgate!throop