[Info-vax] Programming languages on VMS

[Stephen Hoffman]

On 2018-01-23 13:26:37 +0000, Craig A. Berry said:

> On 1/22/18 6:52 PM, Arne Vajhøj wrote:
>> On 1/22/2018 7:50 PM, Richard Maher wrote:
>>> On 23-Jan-18 8:22 AM, Arne Vajhøj wrote:
>>>   > Languages needed for new stuff:
>>>> 
>>>> C - HP/VSI, will be ported
> 
> I believe there will also be clang for C11 and later support.

That's the language.   The associated frameworks are the other part of 
that.  We're way past needing "just" getopt_long and a few other 
well-known C calls from gcc, and deep into needing other commonly-used 
libraries integrated.  Examples include libtls, libxml2, libgtk+, 
ncurses, libcurl, etc.  The IEEE POSIX 1003 API bits are a subset and 
what is available is last-millennium.   I won't ask for libdispatch, 
but that'd be handy for writing asynchronous programming.

> How obsolete is vsi-i64vms-php-v0506-10g-1?

php 5.6.33 is the current end of that line.  7.2.1 is current.

>>>> Python - volunteer provided version is getting old, not sure if it will 
>>>> get ported

Somebody gets to pay for that.

>>>> Ruby - no idea of status
> 
> There is a vsi-i64vms-ruby-v0202-2i-1 kit available. I don't know how 
> current that is.

2.5.0 is current.

> Among those not mentioned, there is Lua (vsi-i64vms-lua-v0502-3-1 is 
> available now) and Perl. I don't expect "porting" Perl to involve much 
> more than tinkering with how the configuration script deals with 
> architecture names.

Lua 5.3.4 is current.

The Perl kit isn't current, either.

C++, Fortran, COBOL and various other "OpenVMS-traditional" languages 
are fairly far behind current standards, too.

Somebody really needs to be testing "head" for Lua, Perl and Python and 
the rest, and I don't think that's happening with any of the community 
programming language.  And I'm routinely seeing breakage.

And the SSL-related changes are tipping over various parts of the whole 
environment.

Nobody's mentioned an IDE here yet, and that's basically a requirement 
for most modern developers.   That means more than a little work in 
LSEDIT or other VSI tools, and more than a little integration support 
that the third-party IDE providers can build on.   Build-related tools, 
too.  Cmake has been ported, but is not yet available.  Work on GNV and 
its tools.  Etc.  Existing ISVs accept where OpenVMS and its tools are, 
but potential new ISVs are going to be a little more particular about 
the available tools and frameworks.

The scale of the effort required here is staggering, the updates and 
the scale of what's involved here is only going to increase, and VSI is 
only going to be able to fund and provide a small fraction of what's 
arguably needed for development.  Just picking what to provide will 
undoubtedly be contentious.  And a few APIs will have to be deprecated 
and removed to move forward, and work on that is already underway in at 
least one spot.





-- 
Pure Personal Opinion | HoffmanLabs LLC