[HN Gopher] Compilers for continuous integration of Fortran proj...
       ___________________________________________________________________
        
       Compilers for continuous integration of Fortran projects
        
       Author : genphy1976
       Score  : 29 points
       Date   : 2024-03-10 03:03 UTC (2 days ago)
        
 (HTM) web link (fortran-lang.discourse.group)
 (TXT) w3m dump (fortran-lang.discourse.group)
        
       | leonheld wrote:
       | > The concept of CI (Continuous Integration) and GitHub Actions
       | have been not only life-changing but also eye-opening to me. They
       | enable me to test my code with intensity and extensiveness that
       | are unimaginable otherwise.
       | 
       | That's such a surprising sentence for me to read in 2024. CI to
       | me is like a compiler: a basic, necessary tool. One of those
       | things I assume everyone else also does. I guess the Fortran
       | people move a bit slower than the rest of the industry in this
       | regard?
        
         | Brentward wrote:
         | In grad school I worked on three separate Fortran code bases
         | written as early as the 80s with tens of thousands of lines, no
         | source control or version history, no build systems or even
         | build scripts, and no tests. I think a lot of old scientific
         | software is in the same condition, with some mix of "if ain't
         | broke don't fix it" and the code being very hard to refactor.
         | 
         | This quote from the linked PRIMA page pretty much sums up my
         | experience porting the above code too: "I hope I am the last
         | one in the world to decode a maze of 244 GOTOs in 7939 lines of
         | Fortran 77 code -- I did this for three years and I do not want
         | anyone else to do it again"
        
         | jfkfif wrote:
         | HPC, or scientific computing more generally, are slow when it
         | comes to adopting modern software development practices. Most
         | researchers used to only care about results above all, rather
         | than reliability or reproducibility for other users. DOE
         | initiatives [0] in the past couple years have done a lot to
         | change this, though there are significant hurdles from a
         | security and logistical standpoint [1]. For instance, to
         | uncover issues in a PR, you might need to run the code at >64
         | nodes on a shared system.
         | 
         | [0] https://ecp-
         | ci.gitlab.io/docs/admin/jacamar/introduction.htm...
         | 
         | [1] https://arxiv.org/abs/2303.17034
        
       ___________________________________________________________________
       (page generated 2024-03-12 23:01 UTC)