My Modern Fortran book is now published

@certik I have a similar view of the place of OOP in scientific programming. There
are places that it is useful but I think that an object-based approach that favors
composition and aggregation over pure inheritance is just as effective and doesn’t
force you into what I like to call “select type Hell”. When I first started trying to use
Fortran 2K+ OOP it didn’t take me long to learn to hate the select type construct. Again
I’ll use OOP where I deem it appropriate but I share some of the contrarian views about
OOP outlined in the following lengthy post from a few years
back.Object-Oriented Cult: A Slightly Skeptical View on the Object-Oriented Programming


Since this thread is escalating into a discussion about the merits of OOP, I’d just like to point out that my book doesn’t even mention the word extends. :rofl:


And returning this thread to @milancurcic’s book, Manning Publications has dropped the
price on their website for the print+ebook combo to $38.99. To good a deal to pass up.
At this price I’m sure they are selling like hot-cakes :smile:

1 Like

When we started, Manning was upfront with me: “A Fortran book won’t sell in high numbers. But it will probably sell for many years.” This is in contrast to books that cover “JavaScript frameworks of the week”, which can sell in tens of thousands of copies, but stop selling in about a year because the material soon becomes obsolete.


Yes, it’s a preference style, not a “mistake” to easily fix. I consider it important though, but it’s subjective, and I like to backup my claims with code that people can criticize, and if it withstands public criticism/scrutiny, then I can say here is an alternative. Until then it’s just my personal subjective opinion.

With this caveat in mind, I think the book is great, and I would like to see more books like that. Once LFortran works well, I would like to create some tutorials/book like that with Jupyter notebooks, that can be executed online, showing how to use modern Fortran to solve numerical problems. That would be a great section at our fortran-lang website.


My remarks:

  1. error_unit definitely brings a new possibilities (unbuffered stderr output)
  2. mentioning read * and print * is quite misleading, especially print * as the asterisk here does not have anything to do with the unit, being the specification of list-directed format. I guess it should rather be read(*,...) and write(*,...)
  3. the xxxx_unit constants allow to avoid accidentally redirecting stdout/stdin to a disk file. I have always been encouraging students to use units>=10 for external files (assuming non-standardly that the special units are always <10). Now the user have the possibility to check the numbers and deliberately avoid them or use them, thus redirecting the standard units to a file

This was a pragmatic choice. The meaning of * is explained a few paragraphs before, and the read() and write() forms have not been yet introduced. We mulled over this for quite a bit during editing, and this was the optimal form to use here.

The explanation should be improved though, thanks to great suggestions in this thread.

I got the book, and it is fantastic and feels really modern. I wish for the next version, this book could add some chapters about OpenMP, OpenACC, and MPI.


Thanks a lot for writing this, I’m happy that you enjoy it. Consider writing an Amazon or Manning review, it really helps drive the sales and promote the language.

Regarding other parallel programming models, a few peer reviewers of the book (while it was being written) requested covering OpenMP and OpenACC. We couldn’t fit it in, like some Fortran features that had to be left out. I was especially disappointed to not cover the scaling aspects of parallel programming, like minimizing communication over computation, how to measure parallel scalability and similar. For a future edition, I would like to have at least have 4 new chapters:

  1. Fortran-lang tooling (stdlib, fpm, etc.); and not just add it, but center the book around it.
  2. Running Fortran on GPUs (this would cover OpenMP and/or OpenACC)
  3. Running Fortran interactively with LFortran
  4. Fortran 2023 features.

For anybody interested, here are the sales to date by quarter:

Quarter Quarterly sales Total sales to date
2020 Q3 1092 1092
2020 Q4 731 1823
2021 Q1 36 1859
2021 Q2 75 1934
2021 Q3 107 2041
2021 Q4 77 2118

Have you an idea of the proportions of persons and organizations (universities…) amongst the buyers?

1 Like

Absolutely no clue.

1 Like

The sales data you quote are for printed version? I bought eBook/liveBook in December 2019 (privately, though I also teach Fortran at the university, so it is a sort of dual usage :slight_smile: )
It’s a great book, @milancurcic

1 Like

Congrats !!

1 Like

Thank you, @msz59 and @Aurelius_Nero!

These numbers are for all sales (both ebook-only and ebook+print). Ebook-only sales are 39% of all sales (829 copies).

66% of all sales are by Manning, 34% was retail. Of the retail sales, 63% is domestic (US) and 37% is international.

Now I recall. At the time of my purchase it was not in final version yet. Then there were 1 or 2 updates.

Did not know about your book. I will take a look at it

Doing a title search of “fortran” in the Massachusetts public library system gives the following. Thanks to Milan the first book listed is not from 40-50 years ago. I own his book but have found (as a non-academic) that if you email a librarian about a technical book not in the public library system that a loan from a university library can sometimes be arranged.

Go to details page

Modern Fortran : building efficient parallel applications / Milan Curcic ; foreword by Damian Rouson

Curcic, Milan,

BOOK | [2020]

Computing for engineers and scientists with Fortran 77 / Daniel D. McCracken

McCracken, Daniel D.

BOOK | c1984.

Fortran IV in chemistry : an introduction to computer-assisted methods / G. Beech

Beech, Graham.

BOOK | c1975.

Fortran codes for mathematical programming: linear, quadratic and discrete / [by] A. H. Land [and] S. Powell. –

Land, A. H. (Ailsa H.)

BOOK | [1973]

Numerical methods with Fortran IV case studies / [by] William S. Dorn [and] Daniel D. McCracken

Dorn, William S.

BOOK | [1972]

High performance computing / Kevin Dowd

Dowd, Kevin, 1959-

BOOK | ©1993.

1 Like

What they bring is (a) ability to cope when the numbers are not what you might have expected e.g.
output_unit is usually 6 but compilers are free to make it some other number, and (b) ability to treat those units like any other unit numbers, in cases where you can’t use * as in the following little program.

program twofiles
use, intrinsic:: iso_fortran_env, only: output_unit
implicit none
integer:: n,units(2) = [66,output_unit]
do n = 1,size(units)
write(units(n),*)‘Hello world from unit’,units(n)
end do
end program twofiles


As noted, units 5,6, and usually 0 are defacto Fortran, not standard Fortran. Using LUNs instead of asterisk makes it far easier to add options to your program to write to regular files instead of stdout, by setting your LUN to some file you have opened or to that pointed to by the standard names; albeit most OSes allow you to use redirection for the same function. I used to think you could not change attributes like padding and such with an OPEN or do INQUIRE on an asterisk, but I think I was wrong or it changed but I never do it and use unit numbers in almost all cases. I know it is not quite kosher but just about any program I write anymore has

use,intrinsic :: iso_fortran_env, only : stdin=>input_unit, stdout=>output_unit, stderr=>error_unit

in it. Just a personal quirk, but I really prefer using the names stdin, stdout, stderr even though that implies a few things that are not technically guaranteed to be true.