Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.os.vms
Subject: Re: Help us defend against VMS!
Message-ID: <344@wsccs.UUCP>
Date: 22 Mar 88 03:01:36 GMT
References: <2814@enea.se> <20597@bu-cs.BU.EDU> <341@wsccs.UUCP>
Lines: 143
Summary: Sorry Dave, but I attend both "churches" and am agnostic...

In article <341@wsccs.UUCP>, val@wsccs.UUCP (Val Kartchner) writes:
> In article <20597@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> > >And this brings us on to another issue which Barry does not mention:
> > >Unix may have some clever tricks, but it's user interface is really
> > >arcane. One-letter options is certainly not state-of-the-art.
> > 
> > I don't mention it because I believe it's a chocolate/vanilla issue I
> > specifically said I would avoid. Or would you like to give us all a
> > good definition "arcane", with units preferably, perhaps something
> > like measured learning curves etc. Can you spell bullshit, I knew you
> > could.
> 
>     Any Eunuchs programmer could easily: bllsht.  Anyone else could spell it
>     correctly.

Actually, Val, it would be blsht.  Doubled consonants are usually eliminated,
too :-).

>     Shall we compare learning curves?  A new user on VMS can learn more in
>     less time because the options make sense.  For instance, what does "-s"
>     mean as opposed to "-S" as opposed to "/system" or "/security"?  Which
>     would make more sense to a new user?

It would depend on several factors:

	1) The user's previous experience

		For instance, MS-DOS, CP/M, MP/M, and most older DEC user
		interfaces all used single character options.

	2) How the user "remembers"

		Does the user perceive things visually, or does he/she
		perceive tactorily or dimensionally?  Does the user
		remember commands via analogy?  Or auditorily (remembers
		only the commands he/she was told verbally or that he/she
		verbalized themselves (many programmers talk to themselves,
		for instance repeating variable names to themselves while
		switching edit sessions, etc).

	3) Can the user spell

		I have caught myself spelling keywords wrong a number of
		times on many systems (I'm dyslexic).  Longer commands are
		harder for me to get correct (Although, interestingly enough,
		I can feel my fingers mispelling something and correct using
		the backspace immediately, accounting for my 80 WPM average
		typing spped).

>     And what about consistency?

I won't flame your example except to say it was inconsitant with UNIX
parameterization.  Generally, your consistancy argument is basically one of
user interface preferences... I won't say chocolate vs. vanilla, as that is
a rather misguided analogy.

> 
>     In the VMS environment, the command would be parsed (and verified
>     syntactically correct) in a consistent manner before the program (image)
>     was even loaded.

	Only if the command was defined prior to invoking it; this is not true
of "external" commands.  While I believe CLD's to be, in general, a good idea,
there are a number of drawbacks, making them more difficult to impliment than
external commands:

	1) No non-error inducing way to check programatically if a CLD is
	   defined.  I can't tell, from within the program, whether or not
	   I should try to parse the command line as a CLD or as an external
	   command without setting up an error trap; something which is not
	   shown as a source-code example in the manuals.

	2) One must resort to non-portable calls to get CLD information, as
	   opposed to main( ac, av) parsing.

>     In the Eunuchs evironment, the command parsing is left totally up to
>     the programmer.

	I agree, that while there are some merits to this approach (faster
	testing of quick-and-dirty programs and less source code and less
	debugging of external files), it does lead to the non-uniform
	implimentation of command lines by bad programmers.  A CLD or BTOS
	style command interface would probably lend a great deal to UNIX.
	Note, however, that CLD's are a feature of DCL, the command
	interpreter, not of VMS.  A *very* VMS-style interface, down to the
	implimentation of VMS-compatable library routines has been done under
	UNIX by the Celerity corporation.

>  This means a wide variety (and inconsistent) method of parsing between
>  programmers.  (Sometimes the options to the "-" command must follow
>  immediately, other times a space, and other times an equals.)

	I agree that this has been a problem in the past; one of the goals of
	the proposed POSIX standard is to rectify this, however. Where did
	you find the '='?  The only place that comes to mind is the 'dd'
	command, an originally student-written utility adopted from Berkely.
	I could, as easily, expect all DECUS software to be consistant.  Agreed
	that it should not have been adopted without cleanup.  But it is the
	fault of the development environment, NOT UNIX itself.

>     This was a problem in the AmigaDOS environment before ARP (AmigaDOS
>     Replacement Project) came along.  AmigaDOS parses the commands just like
>     Eunuchs (inconsistencies included) and with cryptic "-" commands.  ARP
>     provides a standard library of routines to parse the command line
>     arguements in a consistent manner.  These libraries are available for
>     use of all Amiga programmers to provide this consistency.  Something
>     like this is _*DESPERATELY*_ needed in all Eunuchs like environments.

	Obviously, you have not explored _all_ ARP commands! ;-).

>     P.S.: If the Eunuchs programmer really wants to, he(/she/it) can parse
>     the command line totally him(/her/it)self.  This is to provide Eunuchs
>     compatability for those who want it.  Could Eunuchs (and like
>     environments) provide optional and consistent command line parsing.

	Obviously, according to your first sentence, this is possible, but
	it is up to the programmer (that's you!) to do so.  And again, this
	is a feature of the programs under UNIX, not UNIX itself.

>     Another thought on Eunuchs: Get an editor.

	Not UNIX; a program under UNIX.


I think that what Val and everyone else have been bandying about with such a
show of hormone-induced religious mania are *NOT* UNIX and VMS, per se, but
in reality, the developement environments provided by each.  Nowhere has it
been argued the relative merits of a message passing architecture vs. a pure
turing architecture, or any other features of the operating systems themselves.

Do you have _any_ idea how VMS or UNIX does page allocation or timeslicing for
task switches?

By the way, Val, you spelled "UNIX" incorrectly... perhaps you are in need of
a developement operating environment which is not so demanding on spelling ;-).


| Terry Lambert           UUCP: ...{ decvax, ihnp4 }                          |
| @ Century Software          : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |