[Info-vax] Dependencies and Calling Standards (was: Re: Opportunity for VSI?)

[Stephen Hoffman]

On 2018-12-15 18:29:01 +0000, Dave Froble said:

> On 12/15/2018 1:14 PM, Stephen Hoffman wrote:
>> On 2018-12-15 17:08:48 +0000, John Reagan said:
>> 
>>> The spread of OpenVMS languages is not what the rest of the world
>>> expects.
>> 
>> There's no small difference between the expectations and experiences of
>> the current OpenVMS installed base and those of others.
> 
> Probably rather true.  VMS users demand better.

And are willing to accept much worse, in some areas.  The developer 
tools are a bit of a mess, around the lack of a modern IDE, and around 
having to integrate other development tools.  And missing frameworks 
and libraries.  But these tools do matter for folks looking to allow 
OpenVMS to coexist with or to add support for OpenVMS.  Some of the 
motivation for developers to use clustering as part of a software 
source code platform migration effort is reduced when git or mercurial 
is in use, for instance; a different approach to the problem.

>> Also part of why porting off of OpenVMS is often expensive.
> 
> Because other systems don't provide reasonable capabilities?

More than a little of the OpenVMS code was not written with portability 
in mind, and tends to be filled with RMS calls, with system services 
and itemlists and RTL calls, with extensive DCL, and with other 
less-than-portable constructs.

I am well aware of some very large OpenVMS projects that were ported 
off to Linux and quickly, though those projects had worked to isolate 
the system dependencies.

>> And why porting onto OpenVMS is often expensive.
> 
> Because other systems use unreasonable capabilities?

Finding and porting over dependencies and prerequisites, and—prior to 
the arrival of the work that VSI has undertaken—with downgrading source 
code to older compiler standards, among other details.

Dependencies on PostgreSQL or SQLite, too.  These tools and these 
frameworks matter matter less for the traditional and existing apps 
found on OpenVMS.

>> OpenVMS is weird.  And at times, not in a good way.
> 
> Why, because it hasn't (at least totally) accepted that C is everything?
> 
> Why, because of those who say "we want standards", and then declare 
> "Unix is the standard"?
> 
> I'm curious, how many other systems are you aware of that have a common 
> calling standard, such that routines in different languages can easily 
> be used together?
> 
> Hmmm...  perhaps not even VMS, since C doesn't really conform.

The Microsoft Common Language Runtime (CLR) is what the OpenVMS calling 
standard looks like twenty years on, and after substantial improvements 
in its features and capabilities, and after evolving descriptors into 
objects and other changes.

https://docs.microsoft.com/en-us/dotnet/standard/clr
https://en.wikipedia.org/wiki/.NET_Framework

Though there's little reason for VSI to chase this particular set of 
ECMA standards, that is an option.  And .NET Core and CoreCLR source 
code is available with reasonable licensing, as has been mentioned 
around here before.

Biggest issue with C and C++ on OpenVMS and the calling standard was 
arguably that the languages were never extended to integrate 
OpenVMS-isms such as string descriptors and itemlists and other -isms.  
Which is how we ended up with $DESCRIPTOR() and descrip.h and iledef.h 
and ilk, and how C sprouted as much or more glue code than some of the 
existing programming languages such as BASIC and Fortran.  That C and 
C++ enhancement work is less interesting now, but it would have been 
beneficial many years ago.   New OpenVMS work for developers is likely 
best happening elsewhere.  Not in retrofitting current C and C++ into 
OpenVMS.  I certainly don't expect to encounter ObjC or ObjC++ on 
OpenVMS.


The opportunities for VSI here involve understanding what is available 
and used on and necessary on other platforms, and around providing 
options and alternatives if not explicit support for that.  This effort 
differs substantially from working on what will help existing OpenVMS 
folks keep using the OpenVMS platform.  Clustering and RMS and the DLM 
and HBVS aren't going to particularly attract new interest going 
forward.  Not much more than what those same longstanding features have 
attracted over the past decades. And features and changes intended to 
attract new users variously won't be interesting to existing users.   A 
few might even disrupt existing users.



-- 
Pure Personal Opinion | HoffmanLabs LLC