[Info-vax] Fortran

[Bill Gunshannon]

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 (and I am sure most experienced
Fortran programmers) don't find them all that difficult.

> 
> 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.

> 
>>> 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.

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".  The bus driver
doesn't make up the route on the fly, he takes people
where they wanted to go when they got on the bus.
sadly, academia has become the rogue bus driver.

bill