[Info-vax] Python on VMS

[Stephen Hoffman]

On 2019-01-16 17:30:56 +0000, g	rard Calliet said:

> Le 16/01/2019 à 15:10, Stephen Hoffman a écrit :
>> On 2019-01-16 12:55:24 +0000, Neil Rieck said:
>> 
>>> Comment-1: I have been installing run-time libraries into VAX, Alpha 
>>> and Itanium for 31-years and have never experienced any breakage with 
>>> compiled programs. Many of these systems just continue to run forever.
>> 
>> I have. Some of the more famous examples are Adobe Display Postscript 
>> support (removed), the EV6 load-locked mess (bad GEM code generation), 
>> OpenSSL (API and encryption changes), and callable BACKUP (changed 
>> itemcodes).
>> 
>> The changes necessary for the password hash support will be another example.
>> 
>> There _will_ be more of these incompatibilities, if VSI is going to 
>> continue bringing OpenVMS forward.
> We know your opinion about that. But it seems you are saying:
> - VSI has to do a lot of things to be competitive, and so they'll have 
> to forget compatibiliy,

In specific areas, the choice is either forward progress and modern 
security, or it's continued compatibility.   There's no way to have 
both.  You cannot fit 32 bytes in an eight byte field, and—with the 
old-style APIs that OpenVMS is so fond of—there's no way to 
transparently re-size static buffers in apps.

In other areas, there's either an increasing amount of work from VSI 
around compatibility and around bugs that'll never go away, or an 
expectation that the ISVs and developers are going to have to 
contribute to the progress, or that there'll be little or no progress.  
Were it to have been integrated, VSI could not fix Python 2 source code 
to be compatible with Python 3.

These incompatibilities and breaking changes are only going to become 
more prevalent, too.

> - VSI will not be competitive for a very long time.

OpenVMS will not be competitive for some years, yes.   Probably a 
decade to get there, and that's assuming an increasing hoard of cash 
and very substantial increases in staff, and a whole lot of effort.

VSI may well be viable long before that, based on how much of the 
existing installed base that they can capture and maintain.

> So "you have to do that" & "it will not be a success".

It'll be a while before OpenVMS attracts new users and new 
installations outside the installed base, and if an operating system 
isn't attracting new users then it's on the wrong long-term trend, as 
existing apps can and do get retired and replaced.

VSI has funding from the installed base.    Where the folks at VSI can 
get to with that funding?  How fast they can get there?  OpenVMS hasn't 
really moved forward in ~twenty years.

It's a balance.   Keep the installed base happy, or add stuff that new 
folks and new ISVs will expect?   The former was what was tried with 
OpenVMS.

Breaking APIs is a balance, too.  You don't want to do that very often, 
you want to have a good reason for doing so, and you do want to fix 
everything (else) in the area when you do break an API.  Not breaking 
anything was what was tried with OpenVMS.

The balances that were struck have led OpenVMS to its present position 
in the computing market, too.







-- 
Pure Personal Opinion | HoffmanLabs LLC