I died till I laughed.

[JohnNichols]

I saw this set of statements this morning.  They are quite funny.  

[Arjen_Markus]

Unfortunately, that sentiment is widespread. It often makes discussions rather difficult, not to mention other aspects, like: young people do not learn Fortran anymore, so why should we not move to the language du jour?

[JohnNichols]

if 10000 lemmings stand on a cliff to decide if they jump, is the one who does not jump - insane.  

[nDS]

@Arjen_Markus : Sadly, agreed.  Its a good language for the purposes it serves, but that doesn't seem to matter much anymore.  I am currently part of some discussions related to converting 450k lines of fortran to cpp.  Hopefully cpp isn't "du jour", but who the hell knows at this point . . .

[jimdempseyatthecove]

>>converting 450k lines of fortran to cpp

To those supporting conversion, it should be mentioned that due to cpp supporting templates, operator overloads, classes and much more it becomes easier for the code to become obfuscated to the point where each source file can have its own set of rules and behavior.

From my experience (>50 years) tasking a freshly new CS graduate to support a 450k line program (be it Fortran or cpp) would be easier for them to come up to speed in supporting the program as written in Fortran. As there is less to learn. Support is not about a language preference for creating a program, rather it is about understanding the algorithms and data organization. Also, the interoperability capability of both languages permits one to merge code (e.g. cpp GUI front-end with Fortran back-end).

Jim Dempsey

[JohnNichols]

450K will take 10 human years, and will not work the same.  

[FortranFan]

The powers-that-be and decision makers are somehow rewarded ginormously for creating and perpetrating decisions that lead to situations of sunk-cost fallacy for everyone who follows, perhaps it's the "force" "dying until it starts laughing" at the hubris of the humankind!

Migration of "legacy" FORTRAN codebases to C++, etc. is a relatable example of this for the readers here.  Unfortunately so many things with modern Fortran, especially the obstinacy on certain crucial fronts with the language bearers and the commercial vendors, only catalyze such migration - we notice this and suffer from the adverse effects constantly.

The only hope is the developments among the so-called fortran-lang Community, may be that will help turn the tide?

[Mentzer__Stuart]

The misconceptions can also flow in the other direction...

As someone who does large-scale Fortran-to-C++ conversions I can assure you that:

• 450K Fortran LOC can be converted and validated within a few weeks
• The C++ can retain the look and feel of the Fortran
• Templates or other "obfuscation" can be kept out of the code

While I encourage staying with Fortran whenever that is viable there can be situations where migration to C++ is the best option. Some of these I've seen are:

• Academic projects where Fortran makes attracting grad students hard
• Commercial projects in countries/regions with few/no Fortran developers

Despite my fondness for Fortran (and other "vintage" technologies) I focus on finding the best solution rather being a cheerleader for a specific language/tool/approach.

[JohnNichols]

Our answers may not be that different, as I explained to a lot of junior engineers, there are 8 working days of time between 5 pm Friday and 8 am Monday if you need something done, you can throw people at it.  How many people hours would you say for 450 K of code?  Also, you may have existing C++ code that does a lot of things, so it is all relative.  

As a company president, I would ask can we put our capitol to better use?  If someone said, our programmers are better at C++, then I would do what I told that bunch of people in Ireland once at a meeting, hire someone who has the skills, they said, where would they find such a person, there are at least five who will read this note who have the skills, if you have to think do I have those skills you do not. 

It is also not can they code, it is do they have the math to support the coding.  

A friend said to me the other day, but they do not code the stuff we need, like you do, I thought well they are using standard libraries, just as they were taught.  

[Mentzer__Stuart]

---

@JohnNichols wrote:

Our answers may not be that different, as I explained to a lot of junior engineers, there are 8 working days of time between 5 pm Friday and 8 am Monday if you need something done, you can throw people at it.  How many people hours would you say for 450 K of code?  Also, you may have existing C++ code that does a lot of things, so it is all relative.  

John, I assure you we don't throw people at the conversion projects (or lock them in the office for the weekends!). Our tools parse and convert the code for us and our C++ library provides the support that allows the C++ to stay "clean" and similar to the Fortran. It is highly refined system that has successfully converted a number of large and high-profile applications, such as the US DOE's EnergyPlus. I do admit to locking myself away for quite a few weekends to build these tools, initially to convert my own big code base, but that was kind of a fun challenge.

You'll get no argument from me that there are lots of valid questions about whether/when it makes sense to do these conversions.

[FortranFan]

@Mentzer__Stuart writes:
.. Despite my fondness for Fortran (and other "vintage" technologies) I focus on finding the best solution rather being a cheerleader for a specific language/tool/approach.

@Mentzer__Stuart and readers,

Please note the above quoted statement is also feeding into many misconceptions that badly and needlessly hurt Fortran.  Fortran is at once both modern and classic with its enduring impact and importance for scientific and technical computing.

Ideally the "conversions" will be from FORTRAN (legacy constructs with platform-specific dependencies) to modern Fortran with standard and platform-independent codebase.  And definitely not to C++, especially because it effectively ensures a much larger fraction of scientists and engineers with domain expertise contribute less and less directly to computing development and an ever growing reliance on a burgeoning developer farm full of "animals" of various programming paradigms way beyond numerical computing, each competing to be more important than the other.  The adverse effect of all this is noticed years later at which point the managers involved have dug deep with their sunk cost fallacy and more and more resources are expended toward making C++ codes abstracted and obfuscated with complicated semantics and difficult syntax to appear like Fortran when modern Fortran itself would have achieved that at a fraction of the cost and with higher efficiency overall.

Alas - the reality is modern Fortran and its ecosystem currently has some gaps, it does not help the standard process is often "too little, too late".  Each of these gaps counts badly against Fortran with powers-that-be and the conversions in the wrong direction continue apace.

[JohnNichols]

Fortran like all technologies suffers from the issues generated by standardization.  Standards committees are humans filled with human foibles and issues.  I have served on many standards committees, none computer thankfully, but on technology products and design standards. 

A committee in 2021, will have a bunch of people in their 40, 50s, 60 and some in their later years. In the case of the 60s and later, most learned their computing in Fortran or Lisp classes if they were lucky, and the problem of that age was memory and limited output, 50's saw the mac etc, but the memory was still limited and DOS or Unix reigned.  These people are biased. 

Fortran concentrated on solving the difficult problems, and so other niche programs filled in the spaces, Fortran needs to go back and fill in the spaces, it is never too late. Fortran is not going away,  but large companies are not nimble, and there is the problem of competition, which slows innovation generally.  But no small company can solve this problem so they look for others where they can make money.

An example, one day we will have to clean up the space around the world from space junk, letting someone throw small satellites into this space is an interesting idea.  Grad students have interesting ideas, rarely useful.  

Maximum PC noted in the latest magazine that Intel is now becoming a major player in the graphics market and this will improve competition.  I laughed, the Herfindahl Index says this is not so, three is not enough, I love to work in a market of three, you split the workload and maximize profit, perfect.  It happens without breaking any rules, there is just so much info floating around the key players can make good guess as to the long term strategies that maximize profit.  Now if you had 6, this would work, but the big gorilla will buy up the little guys, law of the jungle. 

So, it would be nice if Fortran evolved, my guess is the anchor is too large and it will slowly drag across the computer space floor. 

My point in raising the different issues, is not to appear to provide random samples, but to say the whole computer space is a random jumble of humans all trying to make money from different technologies, it is a long way from an ideal system that tries to reach a Nash equilibrium point in the market space.  We want our individual freedom to make money and do as we like,  look outside and see the result.  Fortran is great, it could be better, we do not have the ecosystem to achieve this.  

The US needs to protect the factories in Taiwan the make graphics cards. Another interesting problem.  

[jimdempseyatthecove]

>>450K Fortran LOC can be converted and validated within a few weeks

While the conversion may take a few weeks, the validation is an entirely different situation. One particular problematic situation to expect is the floating point calculations may (and often) be performed with different precision and/or (more likely) the sequence/order of reductions may differ to the point where the output files drastically differ. IOW not producing the same results. (not to say either is right or wrong)

>>Academic projects where Fortran makes attracting grad students hard

They may prefer the conversion be to Python (or whatever the soup-de-jour is a few years from now).

If a grad student isn't flexible enough to adapt, I would look for a different grad student.

Jim Dempsey

[JohnNichols]

It is not the language of the day, but whether the grad student has any language at all, or an effective handle on a language.  Most professors who teach students who would use Fortan prefer to use Python or MATLAB or one of the copies, whose numerical routines are mostly Fortran in the underlying system. 

I make FEM models, in Python that which can take many hours can be done in Fortran in seconds.   

The use of release and IFX speeds up the execution, two to three fold as I see in the prime finder.  

I have programmed in LISP, Fortran, C, Python, R, MATLAB, PHP and C#.  For a pure coding viewpoint, LISP is the best, from a, I want the answer quickly and correct, I am going to use Fortran.  Being able to ask questions on the Intel Forums is a part of that decision. 

What you are taught by your Professor has a large impact on your ability to solve problems, if a Professor has spent their entire career in academe, they may not be the best person to help your future needs.  

[JohnNichols]

https://eshop.macsales.com/item/OWC/SSDACL4M232M/?utm_source=google&utm_medium=shoppingengine&utm_campaign=googlebase&gclid=EAIaIQobChMItMSkvZy09QIVUcXACh28MwcoEAEYASABEgLiRvD_BwE 

This would of course help a lot if you are recoding. 

[Mentzer__Stuart]

---

@jimdempseyatthecove wrote:

>>450K Fortran LOC can be converted and validated within a few weeks

While the conversion may take a few weeks, the validation is an entirely different situation. One particular problematic situation to expect is the floating point calculations may (and often) be performed with different precision and/or (more likely) the sequence/order of reductions may differ to the point where the output files drastically differ. IOW not producing the same results. (not to say either is right or wrong)

---

This is a good point, Jim. We generate validation case numerical solution stability ranges on the Fortran side by running various debug and release builds, sometimes with multiple compilers and sometimes with input perturbation. The C++ results are validated to fall within or near this range. If the application needs to reduce floating point sensitivity that is a separate issue -- it is very common for teams to be shocked and dismayed at the actual precision of their results.

[JohnNichols]

There are three types of people who inhabit this space.  

Highly intelligent Fortran programmers, who like to see the interesting problems and sit in the corner of the cafe, not in France, and share coffee of some sort with their friends. 

Panicked grad students, who make some people laugh and others who write terse notes of interest.  

Steve, Mary and myself.  This group is interesting.  

My English friend once said, your definition of interesting is not the OED version and I said -- interesting you thought that.  

I think Steve would belong in group 1, but anyone who answers Fortran questions on xmas day belongs in the third group.