# Scientists are using artificial intelligence and large language models to rewrite old code in modern languages

**URL:** <https://fortran-lang.discourse.group/t/scientists-are-using-artificial-intelligence-and-large-language-models-to-rewrite-old-code-in-modern-languages/9598>\
**Category:** Uncategorized\
**Created:** [April 20, 2025, 5:35am UTC](https://fortran-lang.discourse.group/t/scientists-are-using-artificial-intelligence-and-large-language-models-to-rewrite-old-code-in-modern-languages/9598 "2025-04-20T05:35:46Z")\
**Posts on this page:** 1\
**Showing post:** 32

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [April 21, 2025, 11:14am UTC](https://fortran-lang.discourse.group/t/scientists-are-using-artificial-intelligence-and-large-language-models-to-rewrite-old-code-in-modern-languages/9598/32 "2025-04-21T11:14:36Z")

</div>

> [@Machalot](#):
>
> Well, g++ 14.2.0 is very modern and it “runs” C++ very well, but Fortran doesn’t run on it at all!

Could you elaborate? I’m using gfortran 14.2 and it works well on CPUs.

I could agree if “modern computers” was referring specifically to GPUs and other accelerators. At least that was one of the critiques LANL had in that other report ([An evaluation of risks associated with relying on Fortran for mission critical codes for the next 15 years](https://fortran-lang.discourse.group/t/an-evaluation-of-risks-associated-with-relying-on-fortran-for-mission-critical-codes-for-the-next-15-years/5644)).

* * *

> [@AlainHebert](#):
>
> The following two statements are true: (1) old Fortran-77 code runs badly on modern computers,

I agree with @PierU, this is an over-generalization; the flip-side being that I _partially_ agree with this. Some codes indeed don’t map well to modern architectures, but I think this is true for many C and C++ codes too. One problem with F77 codes is the heavy use of common blocks and static variables (i.e. `save`), which can be a blocker for multithreading. In the past I’ve met two domain scientists/engineers (one from TUM, one from RWTH) who told me their university engineering departments had large existing codes (finite elements, tribology) which became obsolete as a result of being limited to single-threaded execution only. The younger PhD students did not have the knowledge needed to refactor these programs. Also SciPy had this problem with some of the included ODE solvers. Their solution was to rewrite them in Cython/C, also for other reasons (toolchain availability).

> [@AlainHebert](#):
>
> (2) Young programmers don’t know Fortran.

This really varies between organizations. In general I would agree that Fortran was kicked out of CS departments already decades ago. Engineering departments have replaced Fortran with Python/MATLAB/Julia and this process also started decades ago. Many students learn Fortran when confronted with existing applications.

Concerning the translation of Fortran to C++ using LLMs. It is interesting that DARPA is also funding a program to translate C to Rust:

> **[Translating All C to Rust](https://www.darpa.mil/research/programs/translating-all-c-to-rust)**

There have also been calls from the US Department of Commerce to drop C++ in new applications in favor of memory-safe languages like Rust and Go. I’m not sure how relevant these calls are to the applications at LANL, which are probably ran behind an [air gap](https://en.wikipedia.org/wiki/Air_gap_(networking)) anyway.

---

_[View the full topic](https://fortran-lang.discourse.group/t/scientists-are-using-artificial-intelligence-and-large-language-models-to-rewrite-old-code-in-modern-languages/9598)._
