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

[Chris Scheers]

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 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.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074