[Info-vax] Free Pascal for VMS ?

[Stephen Hoffman]

On 2018-05-08 16:35:08 +0000, Arne Vajhj said:

> On 5/8/2018 12:06 PM, Stephen Hoffman wrote:
>> On 2018-05-08 15:34:16 +0000, Arne Vajhj said:
>> 
>>> On 5/8/2018 11:09 AM, Stephen Hoffman wrote:
>>>> As for those wondering why Free Pascal might be more interesting than 
>>>> the existing OpenVMS implementation, have a look at the difference in 
>>>> features: https://freepascal.org/docs-html/ref/ref.html  Among other 
>>>> differences, OpenVMS Pascal hasn't yet added object-oriented 
>>>> programming support.   Wouldn't surprise me to find that some future 
>>>> version of Pascal for OpenVMS either incorporates some of the features 
>>>> from Free Pascal, Delphi and ilk, though that's some years into the 
>>>> future and long after the completion of the OpenVMS x86-64 port.  Or 
>>>> maybe Free Pascal gets ported to OpenVMS x86-64.  Most of the 
>>>> "traditional" OpenVMS programming languages and the associated and 
>>>> underlying OpenVMS APIs and the vendors' development tools haven't 
>>>> moved forward substantially in ~twenty years.  Yes, VSI does aim to 
>>>> change that.
>>> 
>>> Software development on VMS definitely need to move to OO.
>> 
>> The underlying operating system bits and the development tools in 
>> support of OO are likely as big an effort as would be the work on the 
>> compilers.  If not larger.  Message-passing implementation work, 
>> endemic Unicode support, modifications to the system calls to return 
>> the the requested data, debugging tool updates and process dump 
>> updates, all the design and documentation and testing work, more than a 
>> little work optimizing of the results, etc.
> 
> Lots of work.
> 
> But I believe business applications could move to OO before all the OS 
> interface is OOified.

In the case of C++ and Java (and a few other choices), they can move now.

It's a package deal, for any apps that are making system calls.  Mixing 
procedural APIs as ugly as itemlists with OO gets old.  Quickly.   
It'll inevitably involve various local and third-party wrappers around 
the calls, with all that entails.  Also for the updates to the vendor 
development tools, which are very weak by current standards.  LSEDIT 
and third-party IDE tools, and none of the tools are particularly 
integrated with the debugger or related OpenVMS tools when last I 
checked.

>>   It'd be interesting to see how willing existing OpenVMS developers 
>> working in each of the existing languages would be to move forward, but 
>> I'm not hopeful folks heavily invested in procedural designs and tools 
>> would be looking to change their approaches.
> 
> You may very well be right.
> 
> :-(

VSI has some interesting choices here, whether it's around moving the 
installed base forward, or moving the VSI developers forward.  New 
languages take time and effort to develop skills, and that's directly 
contrary to development schedules and other short-term (and also very 
fundamental to the continuation of the VSI business) requirements.

Prising OpenVMS developers off of EDT is enough of a project, when the 
comparatively-weak LSEDIT tool is EDT-compatible and faster and offers 
features for application development far beyond what EDT offers 
developers.

>>   Which would probably mean focusing on languages interesting to new 
>> folks and to the existing OpenVMS folks in the installed base that are 
>> interested in moving forward and adapting and adopting, while 
>> maintaining the existing environments and with an incremental migration 
>> likely eventually occurring for those apps.
> 
> It is not that difficult to identify languages with traction.

It's less easy to identify which languages are being used by OpenVMS 
folks, and less easy to identify which of those to add or improve and 
that might then be adopted by OpenVMS folks.  And the whole OpenVMS OO 
(akin to Cocoa or the .NET framework) would be by definition new to 
OpenVMS developers, and unfamiliar to many.   Who can keep doing 
classic BASIC or Fortran or otherwise; that's entirely fine.

In general, yes, there are surveys and related.  TIOBE index et al.  C, 
Java, and C++, long-term.  SQL, Rust and Go are some of the more 
obvious additions, aiming at applications somewhat lower and somewhat 
higher respectively.  Server-side JavaScript, too.  Yes, SQL means 
putting a SQL database in the base distro.  SQLite and PostgreSQL being 
the most obvious choices, there.  Existing php, Perl, C, C++, Java (LTS 
or bleeding-edge current, pick your poison) being more fully integrated 
and brought and kept current, etc.  But DEC BASIC isn't on that TIOBE 
index and Fortran is far down that list, and I keep running into source 
code written in those on OpenVMS.  Lua would be very handy for OpenVMS 
folks, but few are interested.    TIOBE has Ada on a not-great 
long-term trend, and has Pascal falling off the proverbial cliff.

There's a whole huge area here, ranging from the obvious tools such as 
compilers, to work on the debugger and the dump tools, to updates and 
telemetry and crash data collection, git and mercurial and svn, to 
making common text editors such as vim and emacs more readily 
available.  Stuff like IDEs and collaborative tools are a while out.

For whoever taht was grumble-struggling else-thread with JSON and COBOL 
and node.js and the rest...
http://www.coboloncogs.org/INDEX.HTM
https://github.com/IonicaBizau/node-cobol


-- 
Pure Personal Opinion | HoffmanLabs LLC