Earlier quoted context omitted.
> 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 i…
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.
Why physicists still use Fortran (2015)
291–300 of 300 posts
Re: Why physicists still use Fortran (2015)
#292Earlier quoted context omitted.
David Baker's Rosetta code, which made him a pile of money, is IMO a spectacular example of craptastic C++ written by people who really didn't understand C++ but didn't let that deter them from using every single feature of the language, badly. Some years back we tried to port it to CUDA but there were so many levels of indirection, dereferencing, and virtual functions that it was nearly impossible to make any progre…
Oh, you're that Scott Grand? Allow me to thank you for the work you did on pmemd.cuda, my old research group wouldn't be where they are now without you.
https://sourceforge.net/projects/folderol/
Why write the port in the first place? Because back in the days of yore, I was doing the equivalent of adversarial search to try and design a better potential function for predicting protein tertiary structure. I ultimately arrived at the result that there were too many adversaries to make linear models and single hidden layer neural networks work.
And unfortunately, my postdoctoral advisor at the time didn't consider this publishable research.
Re: Why physicists still use Fortran (2015)
#293Earlier quoted context omitted.
I am unfamiliar with the passage. But it describes two options: 1. "A staggeringly comprehensive knowledge of UNIX", three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge 2. A piece of paper just like everyone else in the department. And while the former might be more difficult to make use of, I think it could be muc…
A good point, but the text suggests there are ways to get this knowledge. >> except six hundred dollars in his bank account
>> are ways to get this knowledge.
Edit: are ways 'better' to get this knowledge.Re: Why physicists still use Fortran (2015)
#294Earlier quoted context omitted.
His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time". as someone who had contact with that codebase, do you have any insights as to why that is? Was it the sheer size of the thing? Was it some nuance that Fortran had as an advantage over other languages? was the math just d…
To do such a rewrite one needs domain knowledge much more than you need software engineering knowledge. This means you need to get research physicist to contribute major effort into such a rewrite. To get there one needs to make them see a clear benefit of translating a system (that works fine today, thank you), from language A to language B. A Ph.D. student or a young researcher might be more interested if a rewrite…
http://www.nersc.gov/systems/cori/
I completely agree on the domain knowledge statement. It is 100% required more then the CS degree.
Re: Why physicists still use Fortran (2015)
#295Earlier quoted context omitted.
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).
Re: Why physicists still use Fortran (2015)
#296Earlier quoted context omitted.
I recall that a local aerospace outfit was looking for C++ programmers to re do a metric F%^K ton of Fortran into c++. I actually rang the recruiter to query why would not be simpler to train your existing staff to use Fortran - the add stayed up for years and years I always wonder if it ever got ported.
Did you get an answer about why not just train them to use Fortran?
Re: Why physicists still use Fortran (2015)
#297Earlier quoted context omitted.
Functional languages force you to be more correct, more often. Eliminates a bunch of classes of bugs which are anathema to scientific computing, and are generally so high level that compilers can optimize extremely aggressively. Also, scientific programming is usually much more about data flow and transformation, which is FP’s wheelhouse.
Do you have examples where it is the case that FP code yielded a superior scientific result?
It should instead be compared with how long it took to engineer and build the system or program in a particular paradigm and the qualitative engineering aspects of a particular platform. FP may be amazing for certain areas, but a difficulty in basing a large-scale project or business on it would be hampered by the small supply of developers who can comfortably program in it.
Re: Why physicists still use Fortran (2015)
#298I think this just shows how scientists don't understand programming. Pretty much every 'advantage' listed for Fortran over C++ could be added to C++ in an afternoon. C++ is an extensible language, you can define your own types and operators, so all the examples can be easily implemented. For some of the examples it's just sad that they were brought up. For example, 'you have to write a loop to allocate an array' shou…
language built-ins are not fully replaceable with extensions and libraries. Most notably: (1) Compilers have more ways to optimize if given higher level abstractions, (2) built-ins are easier to use for the user because of specific syntax (e.g. highlighting), (3) built-ins have support in debuggers (e.g. you can easily print an array slice in a Fortran debugger). just a case in point: what do you think is easier to u…
Re: Why physicists still use Fortran (2015)
#299I think this just shows how scientists don't understand programming. Pretty much every 'advantage' listed for Fortran over C++ could be added to C++ in an afternoon. C++ is an extensible language, you can define your own types and operators, so all the examples can be easily implemented. For some of the examples it's just sad that they were brought up. For example, 'you have to write a loop to allocate an array' shou…
I don't think that's the case, seems a little too extreme to think that. I believe the central point of someone not directly enrolled with programming as an actual job (or as a hobby taken seriously) picking Fortran over C/C++ has to do with the features it has out-of-the-box, or at least that are more apparent from the surface of language knowledge. Even if it takes one afternoon to implement a certain feature, woul…
Lets say I wanted to write a web blog server. One language has "import blog; blog.run()" and I am up and running instantly. Another language makes me install a blog library and some other side stuff, and choose a webserver. The point is it isn't just built right in. Which language is better for writing web blog software? The answer is, you have literally no idea from what I just told you. My analysis is insanely superficial and meaningless. Presumably, if I am going to spend hundreds or thousands of hours in some coding environment, what is 'built in with no effort' matters somewhat on hour 0, but virtually not at all by hour 200. Professional scientists presumably spend thousands of hours on this stuff, it's really not too much to ask that they become somewhat competent with the tools they are using.
Re: Why physicists still use Fortran (2015)
#300Earlier quoted context omitted.
language built-ins are not fully replaceable with extensions and libraries. Most notably: (1) Compilers have more ways to optimize if given higher level abstractions, (2) built-ins are easier to use for the user because of specific syntax (e.g. highlighting), (3) built-ins have support in debuggers (e.g. you can easily print an array slice in a Fortran debugger). just a case in point: what do you think is easier to u…
Actually for C++ you are almost perfectly wrong. It's specifically a design goal of the language to not have the builtins be 'superior' to what you can implement yourself (well the builtins are built by world class experts, but the point is there is no bias in the language).