Date:         Mon, 17 Nov 1997 21:45:41 GMT
Reply-To:     REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
Sender:       REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
From:         "Bill Turner, WB4ALM" <wb4alm@GTE.NET>
Organization: Amateur Radio Station WB4ALM
Subject:      Re: Why REXX is not my favorite scripting language (was Re:
Content-Type: text/plain; charset=us-ascii

I have found this thread interesting, and my hat is off to Doug for starting
the discussion. It is somethimes very hard to start a discussion like this,
because there is "one of me", and "millions of thee" and many are out there
ready to prove you wrong. With that, I say my piece on a couple of items "where
I disagree"...
 
> Really?  I find it surprising that you consider that a single argument.
> When I do something like
>
> rm file1 file2 file3
>
> I expect the rm program to receive 3 arguments, not one..
 
I guess it is all symantics, but the example above delivers me "3
arguements"when I:       Parse arg   item_1  item_2  item_3
 
Yes, there is a problem when you expect one parameter to contain multiple
words,
and you also expect to receive multiple parms, but this is generally a special
case, and frequently also has a problem in "how to tell a user" how to specify
the command and what it's options are.
 
I find that the "best" method of specifing options and parameters frequently
depends on the exact application and the knowledge level of the user expected
to use it. You must also take into consideration that "the principal of least
astonishment" has a different answer for each operating system, and general
classifaction of user using that system...
 
What is considered "good" technique for "MVS" is frequently "bad" for UNIX and
vice-versa. "System Support" Programmers like it a little different, than do
"Application Support" programmers, and neither speaks the language of the
end-user.
 
I find that the mechanism used by REXX is easier to use than the parsing
mechanisms used by many other languages, and it's simplicity generally allows
me ways to emulate the way commands are generally specified on the local host
machine. ...and yes, some are easy to do, and others are very difficult. But
you can code for most exceptions..
 
 
>   Double quoted arguments in Unix shells are literals, but they are subject
> to variable
> interpolation (mostly environment variables, but sometimes also history
> substitution and others).  Single quoted strings are literals with no
> substitution.  If you mean that you expect the program to see the double
> quotes, that's simple too
>
> example '"Why would anyone"' '"want to do this?"'
>
 
If you can define it,  I can code it. REXX does not prevent me from processing
the ARG's in a "user friendly" way - but some systems do, because they
pre-process everything before it is handed off to the "command".
 
> ...simply wrap all your arguments to the shell inside a pair of single
> quotes and you're there.
>
> rm 'file1 file2 file3'
>
> You lose file globbing (wildcard expansion), but presumably you don't
> want to do that in the shell anyway if you're doing all the argument
> parsing in the script.
>
 
I would rather have callable functions that do the wildcarding, because I can
then handle the error cases. In fact that is what I have done, I have my own
personal set of functions that are designed to work in the environments that I
support, or are interested in. When coding cross-system applications, I do not
assume that either system will "work FOR me", and I sometimes provide my own
routines.
 
 
> > >... the point is that the behavior of the short versions is poorly chosen.
> Instead ARG and PULL should not do case translation, and
> PARSE ARG UPPER and PARSE PULL UPPER should be used if you want to smash
> case.
>
> > Why does that behaviour seem better to you?
> > Personally I would like to see a keyword like IGNORE added to the
> > PARSE instruction, and/or to add IGNORECASE to the OPTION
> > instruction.  But then in "The Revised REXX Language"...
 
> 1) The shorter alternative should be the more useful.
 
"More useful" in what environment? and in whose opinion?  MVS/CMS uses upper
case, and the language was designed "for" CMS. It is a real tribute to Mike C.
and gang that a work designed for a very specfici environment was designed well
enough to be ported to other environments and still be useful..
 
For "UNIX" the definition is not necessarily the best... agreed?
 
 
> 2) There is nothing in a simple ARG or PULL statement that gives the
> slightest
> indication that it would smash case.
 
Nor is there one that hints that it won't.
 
>  If I want my arguments to be worked over, I should have to ask for it.
 
Except that it does what is expectyed for the design environment. They are
translated to upper case.
 
> The REXX ARG and PULL instructions violate the essential programming language
> design principle of least astonishment.
>
 
I have worked in many environments that "defaulted" to lower case support  as
well as those that "defaulted" to upper case support. Some supported both.
 
And all had exactly the same kind of problem, and are confusing to a new user.
"What is supposed to be upper cased, and what is lower cased, and what is
capitalized, and what is..." Some operating systems only translated the command
name to the perferred case before lookup and execution, others translated the
entire command line, and every system did it just a little differently.
 
MVS, which has its roots in 1964 (actually before, but nobody knew it existed
yet) was designed in an environment that did not have lower case devices, and
tends therefore to perfer upper case.
 
 UNIX, which is based in the late 60's and early 70's had lower case equipment
- the Model 35 Teletype comes to mind as a very common one. Lower case
keyboards tend to default to lower case, and in the best interests of the "lazy
programmer/typist" that UNIX uses as a design goal - everything was designed
from the ground up to be lower case. INCLUDING THE IMPLICATION OF UPPERCASE
BEING SHOUTING.
 
So I am not surprised that MVS does most stuff in "UPPER CASE" and UNIX does
things in "LOWER CASE" by default.
 
You have to be careful though, with case "perceptions" - many people think that
URL's are "lower case", but they are really "mixed case".  Some people can't
access things like
"www.Post227.org" and others can. (No, that site doesn't exist - yet.)  People
get confused with the uppercase "P". Is it required? was it typed in error? Did
he capitalize it according to the rules of English.  Or was it Capitalized
according ToTheRulesOf varable naming techniques in C?.
 
You apparently learned ARG and PULL first. My "second" lesson to REXX newbies
is the PARSE statement and all of its variations. After they learn the
difference between PARSE UPPER ARG and PARSE ARG - I introduce them to the
short form "ARG". and they don't seem to have a problem with understanding or
coding.
 
Teaching "PULL"  is a lot harder, since they expect "ASK" after seeing "SAY",
but that is a different problem.
 
All languages have their idosynchroncies - I think REXX just has a smaller set
of them in general. It was designed as a Scripting language, but is capable of
being an applications language. (and can be compiled in some environments.) But
I do wish that a function for retreiving the suffixies from STEMed varables had
been part of the language...along with a bunch of other neat features.
 
On the other hand, if it did all of the things that I would have liked, it
would have been the size of PL/I and had the execution speed of  winers_95
running on a 16K trash-80 with one 100K 8" floppy disk....  Or maybe a Bendix
GP-30 running MVS, or ...
..never mind, you got the picture.
 
/s/ Bill Turner, wb4alm