[Info-vax] Fortran

[Arne Vajhøj]

On 12/5/2018 10:56 AM, Bill Gunshannon wrote:
> On 12/5/18 9:28 AM, Arne Vajhøj wrote:
>> On 12/5/2018 9:06 AM, Bill Gunshannon wrote:
>>> On 12/5/18 3:26 AM, Simon Clubley wrote:
>>>> On 2018-12-04, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>> On 12/4/2018 9:25 AM, abrsvc wrote:
>>>>>> The removal of Hollerith constants is ongoing in anticipation of 
>>>>>> the loss of support for those in future compilers.
>>>>
>>>> That code must be multiple decades old. I know it's a pain, especially
>>>> when certification is involved, but sometimes code needs to be
>>>> updated in light of more modern standards and safety requirements.
>>>
>>> Is this another "Newer .EQ. Better .AND. Older .EQ. Bad" argument?
>>> Should it also be applied to VMS in general?  :-(
>>>
>>> Safety?  What is unsafe about Hollerith constants?
>>
>> They are more difficult to read than 77 character strings.
> 
> Once again, matter of opinion.

I truly believe that the vast majority consider:
     4HABCD,4HEFGH
more difficult to read than:
    'ABCDEFGH'

It is not just a matter of taste, but a real difference in whether
stuff that logical belongs together are in fact shown together.

>                             I (and I am sure most experienced
> Fortran programmers) don't find them all that difficult.

The claim was that there were a relative difference.

>> More difficult to read means more errors.
> 
> And yet, when people point out things in VMS (particularly in
> DCL lately) where this is true everyone argues to leave it alone
> so  as not to break existing code.  Go figure.

There are a lot of people that believe VMS need a new scripting
language and that it should not be 100% DCL compatible.

True - they also do not want DCL to go away soon.

But just maybe they will be willing to drop DCL after
a number of years similar to when hollerith got replaced
by characters in Fortran.

The math must be something like:

2020 + (2018 - 1977) = 2061

>>>> In some ways, it's no different than needing to update VAX C
>>>> code to work with modern C compilers. The updates are required
>>>> for a reason and the code is better as a result.
>>>
>>> See argument above.  Newer does not automatically mean better.
>>> Thus the reason UNISYS still offers and supports 1968 COBOL.
>>> The newer compiler is available, but moving to it is not forced.
>>> What happened to "If it ain't broke, don't fix it."
>>
>> There are two different models to support old code:
>> A) Remove unwanted features from language standard but
>>     either keep old compilers in parallel with the new
>>     compilers or have the new compilers have a switch /OLD
>>     that make them use old standard.
>> B) Keep unwanted features in language standard and
>>     therefore automatically supported by all compliant
>>     new compilers
> 
> Or do what UNISYS did and just keep both compilers.  New code
> can be written using the new standard and old code can continue
> to run as it has for decades.

That *is* #A above.

:-)

> The biggest problem I have seen with standards bodies
> is they write their standards  in their academic ivory
> towers caring little if at all for the people who make
> their living and keep the industry running using the
> things they choose to "standardize".

Some standards are certainly not practical
oriented.

But I don't think you should blame academia - most
standard committees are filled with industry (vendor)
people not university people.

Arne