Language tutorial topics

[milancurcic]

We discussed website tutorials on our June 19 call and we tentatively agreed to organize the mini-books that teach the language itself around topics, rather than skill level. Each mini-book would then cover the topic with increasing skill level, starting from the most basic concepts and building toward more advanced.

This is specific to the mini-books that teach the language itself. We'd still have other mini-books that cover other topics like building programs, best practices, Rosetta code and similar.

On the call a few people suggested that we discuss what should be the topics to cover. I think we should aim to define topics that are mostly complementary, have little overlap between each other (but it's impossible to completely avoid overlap). Here are the topics that I think would work well:

• Built-in types and operators
• Control flow
• Procedures
• Modules
• Arrays
• Strings
• Derived types
• I/O
• OOP
• Parallel programming
• C-interop

As an example of building skill level within a topic, mini-book on parallel programming would cover all parallel concepts, from basic to advanced: Images, synchronization, coarrays, collectives, teams, events, and perhaps even some example parallel algorithms.

In this approach, a user of any skill level who wants to learn or refresh memory on any aspect of the language, knows where to look for it because the mini-books are organized by topic. Once in the mini-book, they can skip forward to more advanced aspects of a topic if needed.

How this all evolves exactly in practice, I don't know. Perhaps @LKedward will have some ideas. Perhaps we just expand the sections in the existing Quickstart until they become complete enough to warrant transitioning them into a dedicated mini-book.

What do you think?

[LKedward]

This sounds good @milancurcic! I like your topic breakdown - this gives us a good starting point!

Where there is overlap between topics, will we be referring the reader to the corresponding mini-book (as a recommended prerequisite) or will we be repeating the content in both mini-books? The obvious examples I can think of are Procedures/Interfaces being prerequisite for Modules/C-interop and Derived types being prerequisite to OOP.

The problem with repeated content is increased maintainer workload and potential confusion for readers as to where best to go for a topic. The former problem can probably be solved by sharing pages between mini-books in the yaml file but I feel this exacerbates the latter issue of confusing readers.

IMO, I think for these situations it is best not to repeat content and to recommend pre-requisite mini-books in the introduction of the dependent mini-book. The disadvantage of this approach is that the mini-books are not perfectly self-contained but partially interdependent.

There is a question about the future of the Quickstart mini-book - I would prefer to keep the mini-book as a brief overview of the main language features but with links to the other mini-books for each topic in detail. The Quickstart mini-book would not be part of the core language mini-books but the 'Other' mini-books.

Finally, your proposed Parallel Programming book is a Coarray Parallel Programming book - I want to ask whether we are going to additionally cover MPI, OpenMP, and OpenACC as well. IMO we should include these, each in a separate mini-book, because they are well-established standards and I don't see any reason to arbitrarily limit the tutorial content to just the Fortran standard.

[ivan-pi]

Finally, your proposed Parallel Programming book is a Coarray Parallel Programming book - I want to ask whether we are going to additionally cover MPI, OpenMP, and OpenACC as well. IMO we should include these, each in a separate mini-book, because they are well-established standards and I don't see any reason to arbitrarily limit the tutorial content to just the Fortran standard.

+1. Recently I was at an OpenMP training course where I discovered they have a lot of nice training material also for Fortran. The book by Dragos B. Chirila also contains an OpenMP chapter in the context of Fortran.

An overview of solutions for GPU programming including CUDA, OpenCL, OpenMP, and OpenACC from the Fortran perspective would also be nice. I understand however, that the goal of coarrays was exactly to remove the burden of having to learn all of these standards and focus instead on the actual problem. There is a recent paper where they attempted to use coarrays on GPUs.

We could also ask the developers of these standards if they are willing to contribute a mini-book.

[LKedward]

An overview of solutions for GPU programming including CUDA, OpenCL, OpenMP, and OpenACC from the Fortran perspective would also be nice.

Yes this is what I would like, though I am also aware that there is a lot of good preexisting material on these topics already.

I understand however, that the goal of coarrays was exactly to remove the burden of having to learn all of these standards and focus instead on the actual problem.

It's great to have coarrays in the standard and I'm hopeful about their future, but unfortunately I'm not currently convinced of their maturity and portability (I can't yet find a native Windows version* except for ifort). Thanks for the paper link!

We could also ask the developers of these standards if they are willing to contribute a mini-book.

Good idea!

(edit: *I have not tried building OpenCoarrays from source on Windows.)

[milancurcic]

Where there is overlap between topics, will we be referring the reader to the corresponding mini-book (as a recommended prerequisite) or will we be repeating the content in both mini-books? The obvious examples I can think of are Procedures/Interfaces being prerequisite for Modules/C-interop and Derived types being prerequisite to OOP.

I also think referring the reader to other mini-books, rather than repetition, is better. One technique I learned from Manning is that if a mini-book (chapter) strongly depends on another, for example the way OOP depends on derived types, then at the beginning of the mini-book we can state clearly:

This tutorial assumes that you have a good grasp of the derived types. If you don't, please work through the derived types mini-book first.

or similar. Another technique is to add a reference to a definition whenever we first bring up a term that we won't define here. For example, in OOP, when we first show a listing with a derived type in it, we can say something like:

This is a derived type, which is described in <link to derived type mini-book>.

Finally, your proposed Parallel Programming book is a Coarray Parallel Programming book - I want to ask whether we are going to additionally cover MPI, OpenMP, and OpenACC as well. IMO we should include these, each in a separate mini-book, because they are well-established standards and I don't see any reason to arbitrarily limit the tutorial content to just the Fortran standard.

Yes, I meant it to cover only concepts that are part of the language, and I'd also like us to have separate mini-books on MPI, OpenMP, and OpenACC each.

[milancurcic]

It's great to have coarrays in the standard and I'm hopeful about their future, but unfortunately I'm not currently convinced of their maturity and portability (I can't yet find a native Windows version* except for ifort).

I can confirm OpenCoarrays build and work well in WSL. I didn't try other Windows approaches.

[certik]

I second that a tutorial how to use Fortran on GPUs efficiently would be key to help users around me stay in Fortran instead of moving to C++.