Very well put. Also a subset of Python: https://lpython.org/, and it shares the internals with https://lfortran.org/, both run at the same speed. If you have any feedback, please let us know.

I’ve done computational physics and used Fortran. There are some warts, like line length requirements. But for actual math, Fortran takes the cake

And the line length limit will soon (with Fortran 2023 later this year) practically go away--a hard limit of 10,000 characters.

Changes to the standard don't instantly, or even eventually, cause corresponding changes in implementations. Code that needs to be portable to many implementations will need to worry about line length limits for a long time into the future.

The Venn diagram of Fortran feature availability in the various actively maintained Fortran compilers is very messy, and the ISO standard is definitely not a subset of any of them. Standard-conforming code is not necessarily portable, and highly portable code is not necessarily standard-conforming, especially since Fortran '95.

The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.

You're correct about the compiler flags. 10K will be the line length limit; the 1M limit is for a statement length that can span any number of lines.

having used both FORTRAN and Julia, Julia generally had less friction and comparable speed. JIT is great for having a very short programming loop. I definitely prefer Fortran to Python though for math programming.

The insistence of using dot operators for nonsensical purity ruined julia for me. A good example of computer scientists ruining things.

Can you give an example? I haven’t used Julia and I’m curious to hear what you mean by that.

Normally, languages implement SIMD compilation for a specific set of data types/structures and even then you have to really make sure to ask the compiler nicely. Julia is able to vectorize any generic, user-defined data types/operators/functions. This comes at the cost of pretty horrid syntax. It needs extra syntax to give the compiler the information, for sure, but you can argue that it could have been chosen better.

  X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))

Or just use @.

julia> X = [1.,2.,3.]; f=sin;

julia> @. X = f(2 * X^2 + 6 * X^3 - sqrt(X))

In fortran 90, an example I have sitting around:

   c_y   = (qmr*ey_sub*dtsq + c_y*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1*gminv

ey_sub, c_y, c_ym1 are N long arrays with the same shape, and in this case, the operation is elementwise, so indexing isn't needed, and I do not need an explicit do-loop (for loop in C languages) so it fits on a single line that is readable to a scientist in the field. The julia equivalent, I think is the same with a period on every operator

   c_y   .= (qmr.*ey_sub.*dtsq .+ c_y.*(2 .- omsq_b.*dtsq))./gmdto2p1 .- c_ym1.*gminv

The assignment was already verbose as it is, and I at the time tried to make it terser but still marginally readable by using variables that are named for...scientists I guess (e.g., gmdto2p1 means "gamma * dt / 2 + 1" dto2 thoughout the codes I read and use is "dt over 2") and adding 10 characters makes a little more cumbersome. While I think the visuals can be acclimated to, it is tedious to write, especially when you translate a formula from vectorised form to non vectorised or vice-versa and have to insert or delete periods. Mind you this is one of the simpler formulae in the code in question. You can imagine it quickly gets worse when the number of terms exceeds 6 or so.

If you can't rely on implicit-do or terse assignment statements, then the good alternative in terms of readability then for the formula is just to do an explicit do-loop (for loop for julia).

   ! fortran 90, `integer i` above
   do i=1,size(c_y)
     c_y(i) = (qmr*ey_sub(i)*dtsq + c_y(i)*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1(i)*gminv
   end do

   # julia
   for i=1:length(c_y)
     c_y[i] = (qmr*ey_sub[i]*dtsq + c_y[i]*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1[i]*gminv
   end

The problem is then I have made more extraneous bits to worry about. This gets even more hard to parse when the shape of the arrays exceeds more than 3 dimensions. I've read C style codes that are 7 levels deep with different indices, god is it painfully unclear and easy to get lost reading that, it's best to hide extraneous loops with syntactical sugar where possible such as to keep the algorithm as clear as possible, especially when it's a simple elementwise operation. It isn't like you can hide complexity all the time (or that it's even a good idea to do so), but this was a code for just two figures in a paper that needed a bit more oomf than numpy could, so given the time constraint for me, the size of the problem and everything, fortran fit much better.

If you want to know more about the dot macro in julia, here is a nice blogpost about them[0]. The line above is from work I did for a paper that I initially thought "hey, it's been a few years, why not see if julia has stabilised by now" only to find out this was a decisive change they made. I mean they might deserve praise having made this macro a very general thing and apply widely to things that aren't just syntactical sugar for broadcasting, but after being frustrated trying to write my code, googling, and then finding this post, I basically dropped the julia learning effort and got the code written in fortran and made my figures. I can learn things in my spare time to a limit but at the end of the day I have a job to do.

I still want to give julia a chance because the idea does seem cool. I complain about computer scientists a little tongue-in-cheek but really I find the metaprogramming in julia pretty interesting. I'm just not sure I can use it in my day job as a scientist without some effort in learning and time on my part which is at a premium right now.

[0] https://julialang.org/blog/2017/01/moredots/

It took me awhile to get used to the dot operator, but what convinced me that it was a good choice is that also your own function can be broadcasted with function_names.(args). For example is you have a function process_a_file(in_filename,out_filename,parameter_value), then you can easily process also a list of files with process_a_file.(in_filenames,out_filenames,parameter_value) (if parameter_value is a scalar it gets broadcasted). I think that it is similar to numpy ufunc's but every function have this possibility.

A useful macro is @. which allows you to write "@. A * B * C" instead of "A .* B .* C". Also the macro avoid the creation of an intermediate vector with A times B.

I'm far from a computer scientist, and used to be a fan of "Do What I Mean" (DWIM) magic like automatic elementwise broadcasting. But have come to highly favour consistency and predictability over that with experience.

I've certainly had moments where I've gone "just do that elementwise already, it's obvious!" and been mildly annoyed, but I'll take that any day over silent misbehaviour, hard to detect bugs, and being unable to tell at a glance what exact operations are going on in a line of code.

But I I would argue that for mathematical operations doing elementwise by default is much more consistent than doing matrix multiplication everywhere. Now the multiplication operator works differently (and importantly changes the shape of your result) based on what your arguments are. While elementwise behaves essentially like it was scalars everywhere. But the worst part of the elementwise operator is that they followed matlab and chose the freaking dot, the most easy to overlook character they could find. The issue is that missing the dot often does not result in errors but in bugs where somehow the code is not giving sensible results. Back in the days when I was still teaching matlab to students, the main source of bugs were missing dots which were always painful to find.

do you mean f.(x) for broadcasting?

What? That isn't at all about computer scientists. One of the most fundamental reasons for it is actually mathematical.

Functions like exp and sin can be defined on numbers, but are also well defined on square matrices. In languages that have automatic broadcasting of functions across arrays, if you write exp(x) and x happens to be a matrix, you won't get the mathematically correct answer. You actually get [exp(xi) for xi in x] which is nonsense.

Having the dot operators make it very easy to tell if a function should be operating on entire arrays or on elements of those arrays. It also enables performance enhancements, because if I write

    exp.(x) .+ 1

that will do [exp(xi) + 1 for xi in x] instead of [y + 1 for y in [exp(xi) for xi in x]] which wastes and allocation

I once noticed the thing is people balk at the line length in fortran as if it is some archaic hold off (which it is somewhat) that proves its obsolescence but in the next breath berate everyone for not using a formatter that will chunk lines into 100 characters in their favorite "modern" language. I guess the problem is fortran chose 80 as the line length and not 100.

> as if it is some archaic hold off (which it is somewhat)

Indeed it is! The standard IBM punch card had 80 columns.

> and not 100

The standard IBM printer models had 120 print positions.

It is 80 for "fixed form" (card image) source files. It is 132 for free form modern source, but adjustable on the compiler command line. LLVM Flang uses the line length only for emitting optional portability warnings.

100?? Obviously 132 is the correct line length.

But mah punch cards!

As weird as it may sound, I prefer the old fixed-form source with continuation characters and mandated 7-character indent. Like Python, it made for consistent code formatting across people and libraries.

Fortran-lang's role (as an open-source org) has been 4-pronged: Tooling (build system and package manager, testing, eventually compilers etc.), modernized and maintained libraries (stdlib, minpack, fftpack, etc.), community space (Discourse), and evangelism/marketing (website, Twitter, blog posts etc.). Some members participate in the standardization process of the language, but the groups and processes are separate and complementary.

It's true that one goal may be to pick an important race and try to win it.

Another goal, in my view more important, is to make Fortran more pleasant to use for people/Orgs who need it (there are many) and for people who love it (there are many).

I've found that more often than not, people/teams first like working with a technology, and then come up with technical arguments for why that technology is the best choice. Often the arguments are valid, sometimes they're made up, but ultimately underneath it all you either like it or not and that's all that matters. My goal with Fortran-lang has been to slowly and continuously increase the surface area of Fortran's likability. Fortran is not for everyone, but for people who think it may be, we can work to make it better and more pleasant to use.

As one example, we just released a small library to make high-level HTTP requests from Fortran applications: https://github.com/fortran-lang/http-client. This was a product of one of our Google Summer of Code contributors.

> people/teams first like working with a technology, and then come up with technical arguments for why that technology is the best choice.

Words of wisdom (:

Maybe it's not the way things should be, but it's common and very human. Sometimes I'll even catch myself retconning explanations for my choices in my own head, despite myself.

Thanks for writing Modern Fortran!

Looking forward to mojo. Right now it’s not production ready but it’ll great for some of my ML-adjacent code. For other HPC work I’ve used Rust which has some annoying syntax and lacks some of the simplicity of python.

Check out LPython as well (also in alpha): https://lpython.org/