[Info-vax] Fortran

[Dave Froble]

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

The key thing here is not to prolong poor (subjective) programming 
techniques, but rather to not destroy existing and working and useful code.

So, I think I have a solution to the problem.  It seems to me that some 
aren't too worried about such breakage, and the resultant re-writing of 
the applications, perhaps because they are going to get paid to do the 
work.  Now, not picking on Simon, but, he is one who seemed to think 
that that it was right and proper to break the old code, so, perhaps 
those like Simon can rewrite the old code to fix the problem, but NOT 
GET PAID TO DO SO.

Think that might change some perspectives?


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486