@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
5 Likes
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. 
4 Likes
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 
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.
2 Likes
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.
3 Likes
My remarks:
- error_unit definitely brings a new possibilities (unbuffered stderr output)
- mentioning
read * and print *is quite misleading, especiallyprint *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 beread(*,...) and write(*,...) - 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
2 Likes
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.
2 Likes
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:
- Fortran-lang tooling (stdlib, fpm, etc.); and not just add it, but center the book around it.
- Running Fortran on GPUs (this would cover OpenMP and/or OpenACC)
- Running Fortran interactively with LFortran
- Fortran 2023 features.
10 Likes
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 |
7 Likes
Great!
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 
)
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.
Modern Fortran : building efficient parallel applications / Milan Curcic ; foreword by Damian Rouson
BOOK | [2020]
Computing for engineers and scientists with Fortran 77 / Daniel D. McCracken
BOOK | c1984.
Fortran IV in chemistry : an introduction to computer-assisted methods / G. Beech
BOOK | c1975.
Fortran codes for mathematical programming: linear, quadratic and discrete / [by] A. H. Land [and] S. Powell. –
BOOK | [1973]
Numerical methods with Fortran IV case studies / [by] William S. Dorn [and] Daniel D. McCracken
BOOK | [1972]
High performance computing / Kevin Dowd
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]
open(66,file=‘twofiles.output’)
do n = 1,size(units)
write(units(n),*)‘Hello world from unit’,units(n)
end do
end program twofiles
2 Likes
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.