[Info-vax] Access to _all_ VMS system services and library functions from DCL ?

[Stephen Hoffman]

On 2017-07-11 23:44:34 +0000, Arne Vajhj said:

> On 7/11/2017 10:37 AM, Stephen Hoffman wrote:
>> On 2017-07-11 02:34:27 +0000, Arne Vajhj said:
>>> Yes - I agree that VMS needs a new scripting language and VMS needs new API's.
>>> 
>>> No - I don't think having the new scripting language only support the 
>>> new API's will work. Some interoperability is needed for a transition 
>>> period of 1-2 decades.
>> 
>> Invoke the new environment and pass arguments, and invoke the old and 
>> pass arguments.   Beyond that, spending a whole lot of time with DCL to 
>> try to drag it forward is... wasteful.
> 
> That is one way. But I think the result would be a mess.
> 
> The new language should support both old and new API's otherwise it 
> will be crippled by birth.
> 
> I don't think it is realistic that all new API's will be present at day 
> 1 of the new script language. They will come over time. And 
> compatibility is required.

Going OO is a big effort.   It'll be a system-wide effort on OpenVMS, 
with work around the RTLs and system services and the message 
dispatching code and the compilers and the rest, and with only a small 
hunk of that effort (initially) going to the CLI.   I'd hope that 
there'll be a way to wrap the existing calls to minimally make what DCL 
can do now accessible, as that'll be useful for VSI development efforts 
and for access and updates from existing compiled apps.

But I don't see constraining the new CLI environment to deal with what 
DCL can do now — for those cases where DCL is a choice, use it.   I'd 
hope there would be few of those cases.   I'd really not want to have 
to process UTF-8 text strings within DCL, for instance.

As for compiled environments, Objective C does this sort of thing.   
It's C and can do all of what C can do, with effective OO capabilities 
added.   It can call system services, or pass messages around.   But 
it's got all the limits of C, which has sent the folks off toward a 
wholly different solution, Swift.    But I digress.   Compiled code — 
and Python and Perl, for that matter — are going to want to access any 
new OO OpenVMS environment.  So... not a small effort for VSI to build 
all this, and many apps and various developers will never adopt these 
or other OpenVMS updates.

But then as for development efforts and capabilities, VSI looks rather 
booked up for the next several years, and I don't see the installed 
base looking for OO.   More than a few OpenVMS folks find DCL, BASIC 
and what's available now to be acceptable, and with just keeping that 
available and somewhat interoperable with the rest of the client and 
peer systems and software.   It's comfortable, familiar and not 
challenging to them and their expectations and their existing software, 
after all.

It's what happens to VSI and to OpenVMS as these legacy apps and these 
existing developers and the installed base age out.   That's not the 
path I'd want for VSI and OpenVMS, either.


-- 
Pure Personal Opinion | HoffmanLabs LLC