[Info-vax] Free Pascal for VMS ?

[Stephen Hoffman]

On 2018-05-10 00:11:59 +0000, Arne Vajhj said:

> The current VMS world is very different from the general world 
> regarding programming languages.
> 
> If VSI wanted they could also get some data:
> * count c.o.v/I-V questions last 10 years
> * count support calls at HP(E)
> * count in jobs ads requiring VMS

That's all where we were.  Where we are can't be changed.  Where we 
want to be?  That can be changed.

And there's no reason to assume that continuing with longstanding 
OpenVMS traditions and incremental changes will produce a different 
outcome.

But then this also gets to whether VSI seeks to stay with the installed 
base, or to add new apps and new customers and new ISVs.

> If I were to make a guess then I would say:
> 
> First tier: C

Also given that an ever-increasing part of OpenVMS itself is written in C.

> Second tier: Cobol, Fortran, Pascal, Basic

Reasonable and unsurprising list.

> Third tier: C++, Ada, PL/I, Macro-32

Support for clang gets both C and C++, Ada is third-party, PL/I is no 
longer offered and AFAIK didn't get ported, and Macro32 is a sizable 
hunk of OpenVMS.  There's a decent-sized hunk of Ada in the operating 
system.  And the APIs for that part of OpenVMS do need some work around 
complexity and fitness for common uses, but I digress.  I don't recall 
if there's C++ in the base distro, but it wouldn't surprise me that 
there are a few hunks of that around.  There's no PL/I in recent 
OpenVMS versions.

> (only counting traditional native compiled languages - so excluding 
> Java, PHP, Python etc.)

What's the rationale for the distinction between interpreted, JIT'd, 
and compiled?  While in practice there can be run-time performance 
differences, all three of those languages are in common and very 
widespread use.  Having at least Python in the base OpenVMS distro 
would work around some of the issues with and limitations of DCL, for 
instance.  We'd have a better choice for hacking SYSUAF data through 
unsupported RMS access or unsupported output-parsing access for 
instance, and integrated support via $getuai and $setuai within the 
vmspython bits.  Programming languages are programming languages, 
whether interpreted, JIT'd or compiled.  Much like the whole "worm or 
virus or trojan". that difference has become a distinction of little or 
no pragmatic difference.

> If I were asked 20 years ago to make a prediction, then I would have 
> expected C++ to grow wild. But I don't think it has happened - it is 
> very rare to see C++ questions.

I do see a fair number of C++ questions around, though for other 
platforms.   If you're interested in the topic of C++ and haven't 
already encountered him, John Carmack is a pretty good source.   As 
compared with other platforms, there are far fewer developers for 
OpenVMS, and the tools have largely been unmodified in a decade or two 
and down-revision, and most of the developers are either familiar with 
the tools or can run a web search and find an existing discussion.  
There's not been a whole lot of change.  Which is good and bad.    
http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php 


We'll still be dealing with C and Microsoft Windows and Unix/Linux in 
twenty years.  Other bits and baubles that we'll be dealing with?  Who 
knows?  The next five years is important to the future of VSI.  Then 
the five years after that.  And the decisions and trade-offs can and 
will change, just like the current and likely future economics mean 
that some of the more problematic parts of OpenVMS will very likely be 
replaced and deprecated and removed.

As for the discussion of getting JSON out of stuff that's going in 
parallel, an OO interface into the operating system and frameworks gets 
you whatever you want as output by formatting the objects, whether it's 
JSON or YAML or CSV or smoke signals via USB.  Either directly with a 
built-in formatter, or with the addition of a local method that formats 
the object to your needs.  Think of lib$put_output and its action 
routine on OpenVMS, but where you can pass in a data structure other 
than a descriptor and still get a good result displayed.  Getting JSON 
or YAML from everything is akin to the work needed toward creating an 
OO interface for each of the APIs, without the other benefits of OO.


-- 
Pure Personal Opinion | HoffmanLabs LLC