[Info-vax] DCL's flaws (both scripting and UI)

[Jan-Erik Soderholm]

Chris Scheers skrev den 2015-01-22 01:11:
> John Reagan wrote:
>> On Wednesday, January 21, 2015 at 3:21:36 PM UTC-5, Chris Scheers wrote:
>>> John Reagan wrote:
>>>> On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>>>>
>>>>> You would keep f$parse for compatibility with existing DCL code and
>>>>> it would continue to return individual strings, but you could also
>>>>> have a (say) sys package with a differently named f$parse returning an
>>>>> object containing all the parsed fields in one go.
>>>> You mean like SYS$FILESCAN?  What's your issue with multiple calls to
>>>> F$PARSE?  The overhead?  You are writing in DCL after all...
>>>>
>>>> And you want the lexical to populate all the fields even if you aren't
>>>> going to use them?  Isn't that more expensive?  Imagine the overhead
>>>> of collecting ALL the GETJPI fields or ALL the GETQUI fields?  Ugh.
>>> That doesn't follow.  One of the advantages of OO is that the
>>> implementation is hidden.
>>>
>>> There is no requirement to collect the values before they are used.
>>>
>>> Some values may be collected when they are returned, some when the
>>> object is created, some may even be collected before the object is created.
>>
>> Absolutely, that is why I objected (pardon the pun) to the use of the word
>> 'object' in the original discussion.  For the DCL extension, it felt more
>> like a structured return.  Not smart at all.  Quite different from the
>> Python/Perl examples provided later in the thread.
>>
>> And I'm certainly not going to add real objects & methods to DCL.  You'll
>> see object oriented COBOL before that. (and yes, the COBOL standard
>> did add object-oriented).  And to be clear, you won't see OO COBOL either.
>> I wouldn't mind some things beyond COBOL85 but that isn't one.  [I just
>> spent
>> the last 1.5 years working on NonStop COBOL among other things.]
>
> I agree that it wouldn't make sense to add objects and methods to DCL.
>
> Having a different OO scripting language, however, could be very useful.
>
> Personally, I am rather fond of VBA as a scripting language.
>
> This is probably no different than using Python or something else as your
> scripting language.
>
> The big thing is having many libraries available to do a greater variety of
> things than current DCL allows...

You can check the current pre-installed modules in the current
Python port for OpenVMS here:
http://www.vmspython.org/doku.php?id=downloadandinstallationpython
Scroll down to "What is included..." Tools to handle such things as
SOAP, XML, PDF, Rdb, RMS, SYS$, LIB$, AMF, JSON, AMQP and more.

> and allowing for the (possibly site
> specific) addition to these libraries.  This gives you your user defined
> lexicals.
>
> I feel very strongly that this should be OO in design.
>
> I have no problem with using "classic" DCL to invoke the scripting language.
>
> But any such scripting language should be included as part of VMS.
>