> Lists, dictionaries, strings (none of which is of any use to scientific computing) Disagree on this one. In my experience, the computational kernels of our n

> Lists, dictionaries, strings (none of which is of any use to scientific computing) Disagree on this one. In my experience, the computational kernels of our newer scientific & engineering codes (Fortran or C++) are almost never invoked as standalone applications, and are instead embedded within much more complex workflows that are orchestrated with a Python API or Java application. The string handling, data containers, and support for standard file formats in these higher level languages are indispensable at this level, and add negligible overhead compared to the computational expense of the main solvers. Yes, these things are more ephemeral, but they are also more interchangeable. Confining them to a higher abstraction layer lets you more cleanly decouple this stuff from the essential numerical parts of the code. The historical lack of support for these basic amenities in Fortran (and the C-family to a lesser extent) has resulted in the need to maintain innumerable ad-hoc I/O formats, home-rolled nonstandard parsers, and other bizarre, Rube Goldberg-like abuses of the language. Since the original developers of these legacy codes were scientists and engineers first, and developers second, these constructs inevitably wind up being tightly coupled to a larger, organization-spanning workflow whose input-output mapping has remained bitwise identical for three decades, and must continue to do so for just as many more. Higher-level languages like Python have greatly alleviated this nightmare, at least on a go-forward basis.