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.
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.
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.
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 ). How about only if unsatisfied otherwise?
Trust me, this was the first thing I thought about when I started LFortran. 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
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.
). How about only if unsatisfied otherwise?
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.