[Info-vax] Python on VMS

[Dave Froble]

On 1/16/2019 12:30 PM, gérard Calliet wrote:
> 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,
> - VSI will not be competitive for a very long time.
> So "you have to do that" & "it will not be a success".
>
> On the other side, *if* one of the most important qualities of VMS have
> been compatibility, which explains in part why VMS is good for long time
> live cycle applications, and *if* (you say it) the most important market
> now for VSI is the ones who are still on it, why abandon one of the
> qualities which explains there are still there?
>
> As usual, the answer is: "it depends". For some segments of market
> compatibility is very important, for others it is a pain because of new
> needs. Perhaps you have the good general idea about not necessity of
> compatibility and a lot of general ideas about OS's but the renewal we
> observe with VMS is something not at all general.

Well, yes, it depends.

Consider a user who has an application running.  The application is 
fine.  The user just wants to keep using the application.

Should the OS vendor cause the application to fail on newer versions of 
the OS?  That''s not good for the user, and not good for the vendor, if 
they are receiving recurring revenue for the user's use of the OS for 
their application.

Also, the vendor can offer new features and improvements to allow the 
user to enhance and expand the application, thus justifying the 
recurring support revenue.  Win for the user, win for the vendor.

Consider a user considering acquiring an application.  For example, the 
application is implemented using Python V2.???.  With what's being 
written about Python V3.??? and lack of future support for Python 
V2.???, why would the user ever consider the application software?  No 
future to it.  Sure, the app vendor can promise to come out with a 
version using Python V3.???, but if it does not exist now, then it's a 
promise, not an application.  Perhaps not the best solution available.

Perhaps many who have moved off VMS did so because they could see no 
future for them, and not for any other reason.  No "perhaps" about it. 
It's happened, many times.  An OS vendor's commitment to the future is 
rather important.  DEC, Compaq, and HP's commitment to the future was 
sadly lacking.

I have no problems with some new features which may cause some changes 
to apps.  The password issue is one such.  However, it would be 
interesting to see how many current users will be inconvenienced.  I 
don't think it will be a problem for me or my customers.  YMMV.

> Gérard Calliet
>>
>>> Systems requiring a specific version of Python are just one careless
>>> upgrade away from failure.
>>
>> Tools and apps are tied, and always have been.  More than a few folks
>> have forgotten to check in their tooling with their source code for
>> instance, which means rebuilding their long-working apps gets difficult.
>>
>>> Comment-2: Python is "very powerful" with interfaces into almost
>>> everything including MySQL and MariaDB
>>> https://en.wikipedia.org/wiki/Python_(programming_language)
>>
>> This is hardly surprising for folks that have been working across
>> platforms.  Python, Lua, Perl and other scripting tools all feature
>> database access, as well as a wealth of other routines for common
>> tasks.  This is part of why at least some of us have been pointing at
>> the unfortunate state of DCL as an issue on OpenVMS.   DCL is not the
>> pinnacle of a CLI.  It's competitively inadequate, at best.
>>
>>> Comment-3: I started in computing by learning "interpreted BASIC" on
>>> an Apple2. Compiled languages (COBOL, FORTRAN, Pascal, BASIC, C, C++)
>>> on minicomputers changed everything for me. I am ending my career
>>> learning "interpreted Python" on udemy
>>
>> The whole business changes, and the tools are changed and updated
>> across the spectrum.  The compiled languages available on other
>> platforms—and the available frameworks, development tools, and even
>> the compilation support and diagnostics—are well past what OpenVMS
>> offers, too.  And PyPy, Jython and IronPython all support JIT'ing
>> Python code, so you can also be running compiled Python code.  This is
>> the world that OpenVMS is competing in now.
>>
>


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486