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

[Dave Froble]

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.
>
>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>> standard, and not a complete implementation of it either). Later
>>>> FORTRAN standards (2003, 2008, 2108) have fully embraced object
>>>> oriented code practices and C interoperability.
>>>
>>> I am slightly surprised that you say Fortran shops embracing OO - I
>>> would sort of have expected most of them to keep existing code
>>> in Fortran but do new stuff not tightly integrated with old stuff
>>> in a different language likely OO.
>>
>> I was going to comment on this but didn't.  Now, however, I will
>> once again point out that OOP is not a universal panacea.  every
>> thing is not an object.  And sometimes the older paradigms are
>> actually better for the task at hand.
>
> The benefits of OO are pretty widely accepted. And almost everything
> can be considered an object.
>
> OOP is obviously not the only valuable approach, but if looking at
> the OOP languages actually used then they are usually multi-paradigm:
> - practically all support procedural programming
> - most support functional programming
> - most support generic programming
>
> So it is not like the use of one of those languages only work
> if everything is OOP centric - it makes sense if just some of it
> is OOP centric.
>
> Arne
>

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.

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"?

I'm not against progress, valuable new things and capabilities.  But change, 
just for the sake of change, maybe not.

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