[Info-vax] Fortran

[Jan-Erik Söderholm]

Den 2018-12-05 kl. 17:57, skrev Dave Froble:
> On 12/5/2018 8:25 AM, Simon Clubley wrote:
>> On 2018-12-05, abrsvc <dansabrservices at yahoo.com> wrote:
>>> On Wednesday, December 5, 2018 at 4:32:39 AM UTC-5, Dave Froble wrote:
>>>> On 12/5/2018 3:26 AM, Simon Clubley wrote:
>>>>>
>>>>> They were removed because it is a concept which results in both
>>>>> hard to read and hard to maintain code and which was replaced by
>>>>> a safer option decades ago.
>>>>>
>>>>> Fortran has had ideas which seemed good at the time but which have
>>>>> not stood the test of time. The other one which comes immediately
>>>>> to mind are common blocks whose definitions are repeated in more
>>>>> than one place.
>>>>>
>>>>
>>>> The question remains, was it necessary?
>>>>
>>
>> Yes.
>>
>>>> If the compiler could have continued to support the "hard to read and
>>>> maintain code", and there was no reason to remove the capability, then
>>>> that should not have been done.
>>>>
>>
>> And what about newly written compilers ?
>>
>> Should they continue to support an obsolete and dangerous construct
>> when there's a safer replacement ?
>>
>> This is no different from requiring /standard=vaxc to build VAX C code
>> in DEC C. Should every new compiler have a /standard=vaxc option added
>> to it or should the user's code be changed to use modern constructs ?
>>
>> If John is reading this, please, please, please tell me you are _NOT_
>> going to add a /standard=vaxc option to Clang. :-)
>>
>>>> Causing others to do some work, which would not have been necessary, is
>>>> not a good thing.  Causing others to re-write usable code, because some
>>>> don't like it, is arrogance carried to the extreme.
>>>>
>>>
>>> The one that caused the most pain was the loss of the octal constant 
>>> support.  While trivial to change, the decades old modules that continue 
>>> to provide the functions required had to be changed only to specify the 
>>> value in a different way.  Why?  It seems to me that supporting this was 
>>> not a major problem.  It is water under the bridge now of course, but 
>>> many man-hours were spent to make this change.
>>>
>>
>> Removing octal constant support was a bit strange unless there's
>> something I am not understanding. Like you, I don't really see any
>> reason why it could not have been left in place. This is different
>> from the removal of Hollerith support where the removal of Hollerith
>> support brings distinct safety benefits.
>>
>> Simon.
>>
> 
> There is a difference between making things better, and removing things 
> because someone "doesn't like it".
> 
> No, I would not implement things such as "/standard=vaxc" in new compilers, 
> however, I would not remove it from where it already exists.
> 
> Consider, Dave doesn't like C, therefore all computers will no longer 
> support this language.  Extreme, yes, but, the same concept, right?  All 
> I'm trying to say is, if it does not have to be removed, then don't do so, 
> because you might be causing someone else grief.  If it does have to be 
> removed to make needed improvements, then do so.
> 
> I seem to recall in the past some maintainer of some flavor of Linux 
> removing modem support, or something similar, because that person no longer 
> used modems, and caused grief for some who upgraded their OS.

It simple, just ask your money back!

> Same basic 
> concept.  Don't break someone else's code without very good reason.
> 
>