> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does.

I would guess that a C++ codebase written by PhD students, not by seasoned C++ experts, is more complicated and much slower to debug, than a corresponding Fortran codebase.

Can verify that if you give numerical methods people C you may get wonders like (e.g.) main() functions that are 30 pages long.

No, I'm not kidding.

I shudder to think what they'd have done with C++. :-)

Don't be so assumptive that a 30 page long main function is bad code. The code still can be well organized and readable. Function is not the only method to organize code. Knuth's literate programming for example is invented to better organize code.

Function has its side effects. It's use as only once case is really questionable, justified by lack of other means.

They are both typically pretty bad - but there are many more ways to shoot yourself in the foot in c++

The very fact that the article itself, with a completely straight face, has all that malloc nonsense in there as "the way you have to do it in C++" is very telling of how easy it is to get the wrong end of the stick with C++ unless you are au fait with the history of the language and its evolution to better more modern idioms

Well, that Fortran codebase probably also was written in large parts by PhD students, not export Fortran programmers.

Fortran is a much simpler and safer language than C++. And faster to learn. Fortran is even somewhat simpler than C or Java, whereas C++ is probably the most complicated language in the known universe.

So especially in the hands of non-experts, Fortran should produce less bugs.

C++ is complex. Perl is complicated.

Funny as hell. Perl, though.

C++ is a more efficient language to write difficult to track down bugs in than Fortran.

> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

I don't know of any studies like this. But there are two aspects to consider. One is what you've pointed out, which is the long-term scientific gains and the productivity of the research group as an entity. But the other aspect is whether those students who rewrote the code into C++ were more or less successful than the students who weren't rewriting code.

Obviously, how you judge success in the latter will be tricky, since there may be differences in the interest of students who rewrote the code and their desired outcome after the PhD (e.g., stay in academia versus go into industry).

That is a good point, if the majority of the code is living in Fortran then there is definitely some value in understanding large legacy Fortran code bases.

This is true. Though I realized I wasn't specific enough in what I meant. I was more thinking about the limited available time to students and that rewriting code might mean the students do less science and so are less able to obtain a good postdoctoral position (or whatever position typically follows a PhD in the particular field).

True, but the students that re-implement these codebases also might have a much greater understanding of the underlying techniques, theory, and the interaction between them; compared to others who produce more results, but use these codebases as black boxes. I think both pathways lead to equally good academic careers, they just branch out into separate paths.

I would also really want to see a comparison of bugs and error rate, although that's probably a nightmare to try and work out.