Reply to: On

Tue Jan 5 22:42:12 AEST 1982

I knew I was going to get in deep on this one...

The idea that `you can just write a menu hack for the naive' is EXACTLY
the kind of narrow thinking that makes UNIX difficult.  The fact is that
EVERY damn command uses its own made-up (frequently stupid) argument
conventions, and so even if you are very clever about the menu, building
it to do any kind of a reasonble job of prompting users and helping them
get the calling sequences right is a HORROR.  Not to mention that this
all has to be done on a pipepiece-by-pipepiece basis, since being able
to set up a pipe properly is pretty important.  it would probably be
easier to just rewrite the front ends of every program to be cleaner
than to try to keep track of each fool program's conventions.

In terms of specific things, like a TENEX-style `COMAND' Jsys, or making
`glob' more useful, it may well be the case that it is not necessarily a
`kernel function', but certainly one can hardly argue with perhaps
having such functions standardly available in libc.a and providing LARGE
amounts of pressure on everyone to use the thing (just as there was
pressure to gravitiate everything to `stdio' with V7 and to use
`structures' properly instead of ad hoc arrays that happened to be the
right size for something).  The lament of those of us that rue the
current situation is that the cat is long since, probably irretrievably,
out of the bag: YEARS ago there should have been some effort given to
making various user-level things uniform across the system.  Now, I fear,
there are just too many strange programs with strange conventions to
be able to make much of a dent on it all with any sensible amount of effort.

I am hard pressed to believe that you are arguing in favor of being
undisciplined and irresponsbile, all in the sake of `not getting in your
way'.
    [after all, we are not talking about Civil Liberties here: we
     are talking about the obligations of systems level folk to
     well-engineer things they foist on their users.  Part of the
     baggage of becoming a `wizard' is dealing with the
     responsibilities.  We can certainly discuss `what makes for
     standards that are both structured enough and flexible
     enough' to make sense, but my responsibility to the folk in my
     user community pretty much make me bow out of discussions on
     the virtues of doing poor engineering; they expect me to use
     my time on their behalf more wisely]
So I can only infer that you presume that the simple provision of `rules'
for various things (and standard libraries, routines and the like) will
somehow interfere with your doing something useful.  That certainly wasn't
true on TENEX (I don't know about TOPS 20).

On TENEX, we mostly had no help from the monitor, but aeons ago, when the
`EXEC' was first being writting somebody (Ray Tomlinson, I think) wrote a
wonderful little piece of code that took a table description of what your
args are allowed to be, what types they are, where to store the values,
etc. and handled all of the ESC completion and ? giving you hints about
what was expected next.  This is not too hard a routine to write, and if it
is reasonably well organized should not too badly interfere with your
ability to do anything sensible you want.  The trouble is getting it
integrated into all of the existing programs (I believe, as it was on TENEX
pretty much, that once it was thought out and made available, even the
craziest of yahoos would use it in preference to crudely hacking out
something on their own).   Similarly, I don't think that USER's much care
where `*' are expanded, except so far as the fact that doing it in the shell is
both the quickest-and-dirtiest place to do it, and very nearly the least
useful.  Ditto with damn regular expressions: there should have been a library
routine to handle that a long time ago so that at least all of the programs
that talk `RE' will talk about the same functionality.  The list of places
where a little bit of clear thought, a library routine (or a syscall)
and a little `word from on high' to encourage the use of the new stuff
would have made DRAMATIC improvements in UNIX's overall appearance and
functionality.
    [ For example, consider something that the TENEX folk
      got WRONG:  they never made rules requiring (and
      setting standards for) documentation.  Too late into
      the game, they tried to `clean up their act', and have
      mostly ended up with an incredible hodgepodge of
      places where useful bits of documentation were stuck;
      all in different, ad hoc formats ranging from a page
      of assembly code (roughly the equivalent of using
      something like /usr/include/math.h as your `manual
      page' for the math library) right through full
      phototypesetter-ready encoded files, with a liberal
      collection of UNIX-style manual pages in between.
      Lord only knows I hate being `slowed down' by the
      obligation to write reasonable manual pages for
      anything I do, but certainly we have to admit that
      life would be virtually unbearable even for us hardy
      non-naive users if every damn application and video
      editor and this and that started showing up WITHOUT a
      manual page to go with it.  You'd go nuts! ]

Just a brief scan through the UNIX manual will quickly reveal how terrible
things can get if everything is done without some rules in force.  I HATE
it that I have to always make room on my desk to keep a (bulky!) UNIX
manual available for constant reference.  How can anyone prefer or defend
having to remember whether or not a swtich for a particular program ought
to be prefixed with `-' or not, or if there are two switches if they go `-a
-b' or `-ab'; How about output file: some just use the last file name on
the line, others like a `-o' in front of it.  The list of stupidities
perpetrated for lack of a sensible standard go on and on, and to no purpose
that I can see.

In terms of being a `small I/O level multiplexor', I think you are in the
wrong game: UNIX is hardly `small' as Operating systems go and all but the
most simpleminded of I/O is mostly difficult to do: if it ain't a vanilla
`char at a time' device, it mostly won't integrate well, and you'll
probably end up with some abortion like the old V6 mag tape devices (don't
know if they fixed them up for V7 or not); doing a real-time system is
virtually impossible.  (we're not planning on even TRYING to use UNIX for
our real-time systems!) If you want a klunky, minimal system that mostly
lets you do any damnawful thing you want to any kind of strange device, you'd
be better off using something like CMOS.

  /Bernie