Re: qsh from cl

On Wed, Mar 7, 2018 at 8:01 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Tue, Mar 6, 2018 at 5:21 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:

I rarely go more than 1 or 2 parameters on the command line without
specifying the option as well

One or two parameters is generally all you need for CL *programs* also.

That's not my experience; I have written a lot of CL programs and plenty of
them used more than a couple of parameters. Anything beyond trivial is
likely to wind up with at least one command with more than a couple of
parameters.

You misunderstood the prettifier suggestion (which was a little bit

tongue

in cheek) I just meant writing something to clean up and prettify your CL
code which would not be so hard.

I didn't misunderstand. I got it exactly. A prettifier takes existing
code for a given language and cleans it up... so that it's still valid
code in that same language.

And I never said it would be hard. I said it would be tedious.

Maybe you are the one who misunderstood me. When I'm writing new code
myself, I don't need a prettifier. I have written it the way I want it
to look. Where a prettifier might help (me) is where the code was
written or generated by someone else, and they either did it with
sloppy formatting or no formatting. (SEU-prompted CL or the output of
RTVCLSRC would both be the latter.) I don't think we have much
disagreement on cleaning up formatting. I called that portion of the
prettifier the "indenter". But you seemed to completely miss that I
would want a prettifier to also remove unnecessary keywords. It would
be one thing if ALL keywords could be removed. Then it might be mostly
algorithmic. Or if every command always had, say, two positional
parameters and the rest require keywords. Still mostly algorithmic.
But every command is different. So the prettifier has to have
knowledge about every command that it wants to prettify. And that's
just a database of commands and their (omittable) parameters. Tedious,
but not particularly hard.

I am really missing something here; my experience of the CL prompter is
that it adds the options you actually use into the CL source so I have no
idea why your prettifier would need to know anything about which
unnecessary options it could safely remove. By defintiion anything in the
CL program is required because it has been specified (at least in my
experience).

For what it's worth I think CL verbose as it is is fine the way it is. It
is not intended to be a programming language for writing applications, so
it doesn't the elegance of some other languages.

OK, I can understand that. I disagree that elegance isn't important
for "shell scripting" or automation languages (witness Python's
success in that role), but I acknowledge that traditionally, it's been
common for shell-scripting languages to be pretty homely. Whether they
are like that because folks who use them like them that way, or
whether they were built that way because it was easier to implement, I
don't know.

CL verboseness in my opinion derives from the design of the commands
themselves. The fact that you can guess commands for functions your
havene't used before based on the verb-noun syntax it uses makes it simple
yest powerful (but verbose); same thing with the parameters - it is
exceptionally consistent.

I get that you find it
ugly but I think the alternative - for example cryptic, confusing
inconsistent unix command lines - is worth the small amount of visual

pain.

That's a completely false dichotomy. Unix commands are inconsistent
and largely cryptic, that's true. It's because of their history as
separate, often independently developed utilities, and the Unix
culture. But CL and Unix commands are far from the only two choices.
There is room for something that's not overly verbose but also not
overly cryptic. (Indeed, CL with judicious omission of obvious
keywords, and with decent formatting, isn't too bad.)

I didn't say there werer no other alternatives - I used shell commands as
an example of an opposite extreme. I suppose I could use Rexx or Python,
but CL has the advantage that it is pretty much the lingua franca of anyone
who has worked on the box.

I still don't understand what obvious keywords need to be omitted - my CL
programs are not full of paramaters I have not specified or used. Could you
provide an example of what your mean ?

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD