[Info-vax] Programming languages on VMS

[Bill Gunshannon]

On 01/24/2018 03:43 PM, Arne Vajhøj wrote:
> On 1/24/2018 3:31 PM, Bill Gunshannon wrote:
>> But that doesn't change the fact that none of this is what Pascal
>> was intended for and except for people (like VMS and GNU) who tried
>> to implement as many of the non-standard extensions as they could
>> manage none of it was ever portable.
> 
> Very few of the old languages are really portable.

They are very portable.  I recently took a bunch of COBOL from an
IBM Mainframe text and the only changes needed were file naming
conventions.  The rest compiled and ran just fine under GnuCOBOL.

My experience with Fortran has been similar.  As long as the code
is "Standard" the languages are portable.  But, too many vendors
used extensions as a differentiator or to make moving to another
platform more difficult in an attempt to lock people in.

> 
> Pascal programs were not portable between VMS and Borland.

Neither of them was standard.  Either Wirth or ISO. In the case of
Pascal extensions were added to make up for shortcomings. And the
shortcomings were due to using the language for things it was not
designed for.

> 
> But many Fortran programs were not portable (like betwen VMS and IBM)
> either. Unless the vendor supported "VAX extensions", which IBM did
> not but many smaller vendors did.

VAX extensions aren't Fortran.  Fortran is portable, once again, with
the exception of things like file naming conventions.  But then, early
Fortran avoided this by not dealing with file names at all and having
the files connected with Fortran Units outside the language.

> 
> Same with many C programs - C just provides the workaround that you can 
> put in a gazillion #ifdef #endif blocks to handle the specific code.

#ifdef's are not about language features (although some may use it for
that) but about things like programming for different hardware options
within the same source file (ie. #ifdef VAX, #ifdef PDP11, #ifdef TRS80)

C is very portable.  That doesn't make the program portable as C tends
to get down pretty deep in the weeds.  But, if you are talking about
writing some user level application in C, it would be very hard to
make it non-portable.  Unless you start doing bad things like pointer
arithmetic or assuming the order of bytes is the same on all machines.
But those are both things that one shouldn't do and it is unlikely
one needs to do at the application level.

> 
> A little outside my area of expertise but I have also been told that
> moving code between VMS Cobol and IBM Cobol is not just a matter of
> recompiling.

See my comments above.  I have worked with COBOL on at least a dozen
different machines.  It is very portable.

> 
> Newer languages are often more portable.

That's funny.  PHP and Perl aren't portable between different releases
of their own language.  Pretty sure Java suffered the same malady
between at least a couple of releases.

> 
> They have stricter rules for semantics with little or no implementation
> specific behavior.
> 
> They have huge standard libraries that reduce the need for platform
> specific functions.

In other words, vendors no longer modify their particular version of the
language with "extensions".  Well, except maybe for Ada which does not
guarantee the same results compiling and running the same program on two
different implementations of the language.  :-)

> 
>> The first problem is a good example of what is the biggest problem
>> with everyone here's favorite language, C.  If people hadn't worked
>> so hard to use it for tasks for which it was not designed and uses
>> for which it was not intended there would be a lot less problems
>> with it.  :-)
> 
> You mean like kept it for writing OS'es?

Yes, that's a good point.  There have always been better languages
for many of the tasks people chose C for.  Choosing the wrong language
does not make the language bad any more than using a hammer to drive
screws makes the hammer bad.

bill