A shame to skip the IBM 029 experience. (separate issue from drum cards with a skip)

F'90 lacked allocatable derived type components, but was otherwise very well thought out, and its major contributions (modules, free form, internal procedures, generic interfaces, ELEMENTAL, array syntax, POINTER/TARGET...) have held up well. Kind of a mixed bag since then, frankly (FORALL, LEN type parameters, FINAL, ENUM, DO CONCURRENT...)

Fortran first appeared in 1957... It's probably older than most people here on HN.

The "new" Fortran for me was f77.

If you allocate a character object, then write to it with an internal write statement, F’23 now requires that the variable be reallocated to the actual length of the formatted record, instead of retaining its former length and being padded out with blanks (or truncated).

The LLVM Fortran compiler (Flang) has warnings for various usages whose semantics would change if F'23 semantics were adopted by default, which I'm not sure I want to do.

That is funny. Interesting career trajectory.

you want a one-line switch expression??

Sounds similar to computed GO TO, as in:

      GO TO (LABEL1, LABEL2, LABEL3, LABEL4) I

https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9l/inde...

If "it" is F'23, then none. GNU Fortran has had the "new" degree-unit trig functions for a while, but no compiler, FOSS or otherwise, has the newly invented features of this revision.

Fortran doesn't prototype features with real implementations (or test suites) before standardizing them, which had led to more than one problem over the years as ambiguities, contradictions, and omissions in the standard aren't discovered until years later when compiler developers eventually try to make sense of them, leading to lots of incomplete and incompatible implementations. I've written demonstrations for many examples and published them at https://github.com/klausler/fortran-wringer-tests/tree/main .

flang [1], it's part of the LLVM project.

[1] https://github.com/llvm/llvm-project/tree/main/flang

GFortran, Flang and LFortran are all open-source compilers that support modern Fortran.

You be one good Blub programmer.

pg can write Lisp in any language!

Heck, pg can write any language in Lisp!

pg can even write On Lisp!

A few more:

https://github.com/modern-fortran/neural-fortran (disclaimer, I originally created this one)

https://github.com/BerkeleyLab/inference-engine

https://git.exeter.ac.uk/hepplestone/athena

I use Fortran for some research codes (I also use Julia and C++). The main advantage of Fortran, to me, is that it is very easy to write very fast code, and has very few foot-guns. The latter property also means it can be quite difficult to do non-numerical stuff, but that's a great trade-off if you're a physicist or engineer wanting to write simulations. The name comes from "Formula Translation" for a reason. Doing the kinds of multi-dimensional array manipulation and linear algebra you can do with out-of-the-box Fortran in C or C++ feels like torture.

I generally prefer Julia, as its a more general-purpose language, but there are parts of Fortran I like better than Julia, such as

- Fortran uses static typing and is statically-compiled

- It's a lot easier to write slow Julia code than I'd like, and you generally need to think more to make code fast than you do in Fortran.

However, I think Julia beats Fortran in most everything else. My main gripe with Fortran these days is 1) lack of a decent default package manager (FPM seems great, but most Fortran codes don't use it) and 2) slow evolution due to the conservative standards committee. I don't understand why we still can't have extremely basic generics in 2023, or a simple string type.

C and C++ and most modern programming languages have very poor support for arrays in comparison even with the ancient versions of Fortran, especially for multi-dimensional arrays.

In C++ it is possible to define adequate types and operations for good support of multi-dimensional arrays, but this means that a user must choose some additional libraries to get the support that does not exist in the base language, unlike with Fortran.

C++ can be much better than Fortran for scientific computing, but only after a significant initial effort of establishing a well-specified programming style, based on selecting an appropriate non-obsolete subset of C++ and after selecting carefully a set of libraries that provide all the missing features.

For someone whose main job is not programming, using Fortran can be simpler.

One big thing I remember is that it's illegal to have multiple array arguments reference overlapping storage, so storage regions can't alias. This means functions can be optimized more aggressively.

My fingers can't type Fortran anymore, so I'm going to use C as an example.

Imagine you have this function:

    /* Add entries in arg1 to arg2, put result in result */
    void add_vec(int arg1[], int arg2[], int result[], int length) {
        for(int i = 0; i < length; i++) { 
            result[i] = arg1[i] + arg2[i];
        }
    } 

In C, it's perfectly legal to call this like so:

    int array[101];
    // ...pretend array is initialized...
    // for the first 100 elements, set a[i] = a[i] + a[i+1]
    add_vec(array, array+1, array);

The C compiler has no choice but to iterate through the array one element at a time, doing things in the exact order that the source code spells out. No loop unrrolling or vectorization can occur.

In Fortran, the compiler knows that the arrays are not aliased, so it can do much more reordering, unrolling, and vectorization to speed this code up.

In Fortran you can write high-performance array code without getting lost in a maze of pointers. As most of the code is written by academics, the talent question is pretty immaterial, there is no money to compete for top-level software engineers anyway.

Fortran can be faster than C because it has a more restrictive memory model (compiler can make more optimizations when it knows nothing else is aliasing some memory)

Partially historical inertia, partially the fact that commercial Fortran compilers have had decades to optimize numerical code to within an inch of its life.

Also, for at least the older versions of it, its a pretty small language. If you have a grad student who's already familiar with programming, they can probably teach themselves Fortran and start being able to make useful changes to your research code in a week or two. Compare, say, C++ where just learning the language enough to be useful could take most of a semester.

Fortran is closer to a highly optimized Matlab than a general purpose language like Javascript. It excels at matrix and vector calculations and is simple enough of a language that getting something working isn’t too difficult.

It's been about 30 years since I last wrote FORTRAN (77), but back then it was used in computationally intensive applications because it was (or at least felt) like working much closer to the bare-metal data and code segments of a process than a 'high-level' language like C. Certainly the compilers produced far fewer lines of assembly/line of source compared to C, pushing the burden of correctness back on the programmer. It was almost like working with an assembly macro language.

I suspect much has changed since though, so its fields of use may just be convention now.

If you’re writing a program or a library to perform fast arithmetic computation over large numeric arrays, Fortran is the optimal tool for the job.

Think of FORTRAN as of a GPU shader language, or something like numpy. It's heavily leaning towards massive vector processing, usually automatically parallelized, and the compiled code runs very fast. It gives you a lot of tools for doing numerical stuff straightforwardly and efficiently at the same time. It's not a very ergonomic general-purpose language, but in its area it shines.

In a lot of cases the libraries are developed by researchers and academics in physics, engineering, biology, and other sciences. Having a huge pool of CS graduates isn't very helpful, except for the subset getting Phds in one of those other fields.

How easy are strings and associative arrays in Fortran?

My experience working with particle physics code (which is generally C++) is that we could probably make it a lot faster if we completely banned the use of `std::map<std::string, T>`. But since it's there, and since people use it to e.g. look for files or parse configuration, you often find an API that accesses elements in an array by string rather than by index. Sure, it just made your code 20x slower, but it's only one part of much bigger framework and this wasn't on the "hot path" anyway, so you just use it.

Rinse and repeat a thousand times, you can see how things slow down a bit.

Odd that so far nobody has mentioned nuclear weapons.

There are a few other active projects porting weather, ocean, and climate models to Julia, C++, or Python.

Getting a weather or climate model from zero to production grade requires approximately 100 person-years, or $20M (personal experience). Because of extremely high scientific expertise needed to correctly implement such models, it's more difficult to leverage open source contributions from a broader community, like it is with web or ML frameworks. So most of the development in these projects is done by full-time hires, and to a lesser extent by contributions from early adopters.

The key technical arguments that I hear/read for such transition projects are ease of portability to accelerators (e.g. GPUs), and higher availability of programmers in the workforce.

My intuition is that a $20M budget, if carefully allocated to compiler and hardware accelerator teams, could solve running Fortran on any accelerator in its entirety.

With Fortran's tooling and compiler support for offloading standard Fortran to accelerators slowly but surely improving over time, the rationale for porting to other languages becomes increasingly more questionable and is being revisited.

But regardless of technical arguments, it's a good thing for large models and frameworks to be written and explored in diverse programming languages.

I did my PhD at Caltech and knew one of the grad students working on this project. I remember him telling me that Julia is a complete mess (don't recall why he disliked it). I would imagine it feels more "modern" than Fortran, but that doesn't necessarily mean it's better per se.

The best BLASes (BLIS, openBLAS, and MKL) have lots of C nowadays. IMO it is actually one of their weird cases where C makes more sense: you are mostly tuning GEMM and TRSM, so you can actually throw an unlimited amount of expert C coder effort at them.

But most of the ecosystem other than BLAS doesn’t share this property.

Other than the original reference implementation, you would not find any other fortran version of BLAS anymore. And nobody links to the reference for performance code. All written in either close to metal C with SIMD etc. or straight in assembly altogether. LAPACK is mostly fortran but there are also libraries slowly rewriting those in Rust/Julia and C.