[Info-vax] And another one bites the dust....

[Chris Townley]

On 17/02/2022 19:17, Arne Vajhøj wrote:
> On 2/17/2022 1:59 PM, Dave Froble wrote:
>> On 2/17/2022 11:01 AM, Arne Vajhøj wrote:
>>> On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
>>>> On 2/17/22 09:21, Arne Vajhøj wrote:
>>>>> On 2/16/2022 9:41 PM, dthi... at gmail.com wrote:
>>>>>>> On Tuesday, February 15, 2022 at 8:05:01 AM UTC-5, Bill Gunshannon
>>>>>>> wrote: National Computing Group West Mifflin, PA
>>>>>>>
>>>>>>> Document, plan and execute the modernization of Fortran
>>>>>>> applications running on OpenVMS systems to a virtualized Windows
>>>>>>> Server environment.
>>>>>>
>>>>>> I'd like to point out to everyone that this posting specifically
>>>>>> calls out modernizing FORTRAN, which CANNOT be done on OpenVMS, as
>>>>>> the OpenVMS FORTRAN compiler is over 25 years old. The commercial and
>>>>>> scientific FORTRAN code base out there is massive, as is the
>>>>>> commercial COBOL code base. I am aware of many companies modernizing
>>>>>> their FORTRAN code bases to use the new object oriented methods of
>>>>>> the later FORTRAN standards, which can be compiled with the Intel
>>>>>> Fortran compiler and the later gfortran compilers.
>>>>>
>>>>> It talks about "modernization of Fortran applications", which can 
>>>>> really
>>>>> be move Fortran code as it to newer platform, upgrade from old Fortran
>>>>> to newer Fortran or rewrite from Fortran to newer language.
>>>>
>>>> This is one of the problems with the term "modernization".
>>>> To some it means use modern capabilities of the original
>>>> language that increase the efficiency and readability of
>>>> a program while to others it means scrap the old program
>>>> and re-write it in the language du jour.  The second option
>>>> seldom being necessary or of any added value,
>>>
>>> The industry seems to think otherwise since it is happening
>>> a lot.
>>>
>>>>>> I've complained to both HPE and VSI for years that you can't attract
>>>>>> new developers to the platform, and thus grow your customer base, if
>>>>>> you don't provide modern software development tools and tool chains.
>>>>>
>>>>> Yes.
>>>>>
>>>>> Existing customers need compatibility.
>>>>>
>>>>> New customers needs modern languages, tools, libraries, frameworks
>>>>> etc. that tyhe industry expect today.
>>>>
>>>> Even if the so called "modern languages" actually bring no added
>>>> value to the table?
>>>
>>> The industry thinks they do.
> 
>> What I rarely see is practical considerations.
>>
>> Joe wiz kid comes along and tells his employer how they must "upgrade" 
>> to modern standards.  But, Joe wiz kid isn't going to pay for the 
>> effort.  That is left to the employer, who just might be rather happy 
>> with the fully functional and working current solutions.
> 
> If the CTO/CIO is worth his/her salary then the pro's and con's
> of a migration will be analyzed before a decision is made.
> 
> Sometimes the decision is to migrate. Sometimes the decision is
> not to migrate.
> 
> Not to migrate is probably the most common.
> 
> But the question comes up again and again. If the question comes
> up every 3 years and it is 20% migrate 80% keep, then after 24
> years 87% has migrated.
> 
>> I'd like to know just who and what the "industry" Arne refers to is? 
>> It's always easy to use some nebulous term.  But just what is it? 
>> Perhaps it is a "transfer", as in "transfer your money to us"?
> 
> It is all those companies using IT. And the decisions they make.
> 
> Arne
> 

Interesting interpolation!

-- 
Chris