[Info-vax] DCL and scripting

[Stephen Hoffman]

On 2018-12-13 01:07:11 +0000, Arne Vajhj said:

> On 12/12/2018 9:47 AM, John E. Malmberg wrote:
>> My vote would be to keep DCL the way it is, but to provide a good 
>> interactive Python shell for scripting that needs to be 64+ bit aware, 
>> with applications designed to handle serialized objects.
> 
> I think many agrees with that.

As would I.  DCL is a mess as it is currently implemented, and it's not 
feasible to extend it without corresponding increases to the miasma of 
compromise and compatibility.

>> You keep mentioning PowerShell.
>> 
>> Have you done any significant coding in PowerShell?

And as I seem to have to repeat myself here, around my making 
references to different approaches and different designs, and not to 
specific solutions...  If working with students as Jairo is—or working 
with folks that might know only DCL, for that matter—exposure to 
different environments is a very good way to learn about the values and 
the limitations of the more familiar environments.  Those examples 
might well be bash, zsh, fish or one of the other available Unix shells 
for Unix scripting, Python and IPython for scripting, and PowerShell is 
an example of adding OO into the environment.  Some folks use generated 
scripts for automation and these can be written in various languages 
including JavaScript.  On Unix, psh one of the few shells that does OO, 
and it's not all that common AFAIK.  Why do I keep mentioning 
PowerShell?  because OO can nicely abstract and encapsulate data and 
APIs.  It's not so good for gonzo-scale data processing where scripts 
written in SQL or NoSQL (RMS or otherwise) or possibly wrapped SQL via 
something akin to FMDB would likely provide better performance.

Why do I keep mentioning PowerShell?  Because—in various and very 
central details—I don't want any hypothetical replacement DCL to be 
anything close to DCL.  If the hypothetical replacement is much closer 
to PowerShell or to a newer bespoke design influenced by what's now 
available elsewhere, all the better.  Any home-grown replacement can 
and should move forward ~40 years.  If the replacement happens to be 
interactive Python, well, that'll work.  And it'll solve various of the 
immediate limitations of DCL.

The OpenVMS platform and community has historically been insular.  The 
boxes have been in back rooms running quietly for decades, and other 
stories.  That insularity can cause developers working on OpenVMS to 
miss out on useful tools and abstractions and APIs and ideas from those 
other platforms.  The effects of that insularity also applies to 
marketing OpenVMS, too.  Folks that might be considering using or folks 
new to OpenVMS will have very different experiences from longstanding 
OpenVMS users and developers, and can perceive OpenVMS as being 
somewhere out past arcane, or as being outdated.  Which is what DCL is, 
pragmatically.  OpenVMS marketing could learn a few things, too.







-- 
Pure Personal Opinion | HoffmanLabs LLC