Zen of Fortran

Over 11 years ago my collaborators and I have created the following Zen of Fortran:


Fast is better than slow
Slow is better than unmaintainable
Array-oriented is better than object-oriented
Make everything as simple as possible – but no simpler (Einstein)
Simplicity is robustness.
Make it look like the math.
All inputs and outputs explicit.
All inputs and outputs carefully named and clearly defined – the
closer to the point of declaration the better.
Vector is better than loop
Matrix is better than vector
Unless it’s complicated
Strided is better than scattered
Contiguous is better than strided
Broadcasting is a great idea – use where possible


Inspired by Zen of Python and Zen of NumPy. Later, Stefano Zaghi created his own version for Fortran, inspired by some of the above also. I personally like our original better. :slight_smile:

Based on my experience on this forum, I don’t think we will agree. But I figured I’ll post what I have and you are welcome to post other versions that you like better.

12 Likes

Nice. More controversial, but I might add a few personal preferences
(and then snitch this very nice list; what would be a preferred
attribution?) …

  • self-descriptive code is best, but if you do not add comments and
    references someone will wish you had (probably you)

  • small functions are clearer than monolithic procedures (which are
    sometimes justifiable for performance, but should be avoided)

  • Use every debug flag you can while developing

  • The more compilers you use the better

  • Write everything as general as you can and as if it was going to be reused (and share it)

  • profile your #*?! code (mostly an HPC thing, but you would not believe
    the things I find).

  • test your input and output values whenever the overhead
    is tolerable (make your routines paranoid!).

  • make tests

    • then test at the scale your users will use your code at x 10
    • next, test at the scale your users will use your code at x 100
    • and then test to failure.
  • package your code and supporting files like you were going to have to
    give it to a friend.

Yours beautifully cover optimizations, but a will add these more mundane items and put this on a few desks, I think.

3 Likes

Probably:

Ondřej Čertík, John Pask, Travis Oliphant, Tim Peters

John and I did the Fortran version, Travis did the NumPy version which inspired us and Tim did the Python version which inspired Travis and us. I hope I didn’t forget about anybody.

FWIW Tim Peters worked on a Fortran compiler for Kendall Square Research in the lab 80s, before he became involved with Python.

Well, you did leave off Einstein. Thanks; the names will be on some simile of this on some desks Monday.

So in LFortran is I have the line “use this” in my code what will get printed? :wink:

1 Like

Definitely in the interactive mode, maybe not in regular mode. :slight_smile: I don’t know if it is a good idea, but Python still has that.

Yeah, the purist in me almost stopped me from typing that, but it is just too good. Maybe you have to use a switch like --easter-egg or only in the development version but I would hate to adulterate it. (Folks – launch python interactively and enter “import this” to see why I cannot resist hoping for this against my better judgement :smile: ). How about only if unsatisfied otherwise?

1 Like

Fortran uses keywords where other languages use symbols.

matmul(transpose(A),A)

is in Julia I believe

A'*A

A Fortranner accepts the verbosity of a declaration such as

real(kind=real64), intent(out), allocatable, dimension(:,:) :: x,y

in return for its informativeness, safety, and possible performance boost.

2 Likes

Trust me, this was the first thing I thought about when I started LFortran. :slight_smile: In Python, “this” behaves as if it was an intrinsic module, so we can do the same in Fortran. If a project has a module of this name, it would get precedence, so there is probably very little harm. In Python I don’t think you can even disable it. In Fortran we can follow the tradition to be fully configurable and add an option to disable this behavior.

Btw, I agree with your additions to the Zen. The additions are longer than the original poem, so if there is a way to shorten it, that would be useful.

Mine probably need to percolate for a while (you had 11 years!). Apparently, Poets have a hard job. So far the best I think I did is

Grokking Fortran

Fast is better than slow
Slow is better than unmaintainable

Small functions are clearer than monolithic procedures
Simplicity is robustness
“Make everything as simple as possible – but no simpler” (Einstein)

Self-descriptive code is best
but comment

Make it look like the math

All inputs and outputs explicit
All inputs and outputs carefully named and clearly defined
the closer to the point of declaration the better
Be paranoid about parameters and check their validity coming and going

Array-oriented is better than object-oriented
Vector is better than loop
Matrix is better than vector
unless it’s complicated
Strided is better than scattered
Contiguous is better than strided
Broadcasting is a great idea
use where possible

Create tests large and small
and use them
Use every debug flag you have been given when developing

Write everything as if it was going to be reused
and share it
Package code and supporting files
like you were going to give them to a friend

“Rules are meant to be broken” (MacArthur, not Einstein)

     Based on:   "The Zen of Fortran", by Ondřej Čertík, John Pask
                 with poetic license taken by John S. Urban
     Date:       2021-10-30

     Inspired by Zen of Python 2 and Zen of NumPy 3,
     by Travis Oliphant and Tim Peters
2 Likes

Will this eventually go to fortran-lang.org? :slight_smile:

1 Like

sounds too complicated. just say:
fast and simple.

When I was using fpm, I found that the full precision setting of stdlib increased the pressure of fpm compilation in some ways.
I think of talking directly about the Zen of Fortran, or maybe we can start from the projects we have come into contact with, such as the Zen of fpm, stdlib and LFortran.

  • fpm package:
    • Reasonably small
    • real(real64), integer(int32) are preferred.
  • stdlib:
    • Implement functions with existing syntax.