I made a thread long ago to discuss this
I watched the whole of Tsoding’s video and took notes to analyse his learning experience. I did this mainly for my next Fortran lecture, but I think there are interesting points for our community. Some of my points have already been discussed here, but since the discussion has drifted apart, I’d like to ask you if I should post them here, or if we should create a new thread for them.
PS: I believe there is more to analyse on his Twitch channel, but I don’t know if I have the time for that.
I think this thread is the right place.
Learning points summarized by an educator would be quite helpful. This is the correct thread for such a topic I believe. I watched most of the first 2 hours, and believe that the majority of confusion comes from how different Fortran is from a lot of C style languages that are much more popular today. Combined with an abundance of (sometimes conflicting) information about FORTRAN 77 that comes up when you google Fortran, it can be very difficult for a newcomer to find any “modern” practices.
This is by far the #1 problem!
We need a reliable and complete language reference, with concise and executable examples.
It also needs to be SEO so that when people search for something, they will find good resources instead of the FORTRAN 77 documentation.
Additionally, we require an overview for Fortran’s high level syntax, because Tsoding many times had difficulties finding the right place for his code.
As far as documentation goes you’re absolutely right. Code examples need to be complete copy/paste and run without any hidden syntax, shortcuts, or compiler warnings/errors emitted.
A separate suggestion, likely to experience significant pushback, is that Fortran should adopt modern (common) vernacular to describe the programming language. Want to know what gfortran is? It’s a compiler. When talking about “processors” in modern computing, that is synonymous with the CPU hardware component. “Documentation” that is just snippets copied out of the language standard would be about as useless as nothing at all, so hopefully that issue can be avoided as well.
On July 10th/July 11th, Brad Richardson moderated a NERSC Beginners class for Fortran (link to the landing page). In addition to video recordings, slides & training materials retained, this time* with an additional document (link to Google Docs, open-access download is possible as e.g., as .pdf (21 pages); .odt, .docx; or .txt) to address questions which emerge e.g., while running the exercises.
To illustrate the spectrum of questions by the attendees, a few examples:
- What does
len=*
andlen=:
mean when declaringcharacter
variables in these programs? - Is the behavior of
extends
the same assuper
in Python? […] Followup: It looks likeextends
is more similar to Java’sextends
feature, doesn’t it? - How does this coarrays feature relate to the
do concurrent
construct? - How difficult is it to turn an existing package into an fpm package?
* This is in comparison to a brief 101 by him, it either was a Lynda/LinkedIn, or Udemy class.
A video pops up in my youtube recommendations and I “wasted” almost an hour to watch it… but it is really interesting to watch the frustration and later, the satisfaction from a new Fortran learner! He basically switched his attitude from “WTF is this language!” to “Who needs python!” in an hour.
Besides his attitude switch, his reaction as a non-Fortran programmer might be helpful to improve the community’s tutorial page. For example, he spotted that there exists an extra space when he tries to output a string with print *, "Hello, world!"
. As Fortran user I know it is related with the carriage control, but we might want to point out these details in the tutorial.
Also, the youtuber spent quite a while exploring the implicit typing in Fortran. OK, I really really don’t want to trigger another “implicit war”. But the youtuber’s reaction does reflect some of the issues raised and discussed in this community.
So, here is the link:
He has a whole series on his Twitch channel about Fortran. He is more and more frustrated by the syntax, the online material for learning and the compiler error messages (he uses an outdated version of GFortran). By the time, he really dislikes it.
Being calm and objective probably does not enlarge the audience on Twitch. Fortran is not going to become a curly brace language or one where indentation defines blocks. Are there gripes he has that have not already been discussed in this thread?
Rather the opposite… And this is true on all “social” media. Not to say that there is no good quality content on the social media (there definitely is!), but as a matter of fact many streamers deliberately choose to be entertaining and dividing above all, because this is what the algorithms favor to get a large audience.
I’m still collecting everything he criticises, but it takes some time, since there are hours of recordings to go through. The major points are discussed above, but I guess there are more things of interest. We have to keep in mind, that he originally was very excited and open-minded to learn Fortran, but then found more and more things he didn’t like. We have to assume that many people trying Fortran are having similar experiences.
These statements do capture the experiences of quite a few who try to code in anger using Fortran. Whether it is
- type-safe programming,
- structured and modular programming with various constructs introduced starting Fortran 90,
- functional aspects introduced particularly starting Fortran 95
- object-oriented paradigm starting Fortran 2003,
- especially concurrent and parallel execution support starting Fortran 2008
- generics since the early days of
FORTRAN
to Fortran 2023
there are commonalities where users get excited initially and as they dig further, they are soon exasperated and exhausted with so many caveats and gotchas and gaps and limitations. This is just not doing right by them.
This is why I repeatedly try to raise awareness with the too little, too late problem with the language standard evolution and the half-baked nature of so many features that make it in.
With Fortran 2023, you can see an immediate example with a most simple facility for coders in a modern language: an ENUM
type - it got entirely messed up - too many were asleep at the wheel and when they were alerted of concerns all through, the reactions were only indifference and utter contempt for the messenger (me, paying my own way and sacrificing personal time-off to attend committee meetings) and for all the present and future Fortranners who would actually be trying to use the feature for real work.
This is a serious issue for Fortran.
I’m still going through his videos right now, but this was very instructive for me.
The key problem is that despite getting very far with virtually no knowledge of Fortran, there was enough confusion due to experience with other languages, that it is easy for new people to get frustrated.
Perhaps something like a Fortran Cookbook – full examples that can be compiled that teach how to do common tasks in Fortran, would have been useful. Such a document could also provide warnings on misconceptions that someone would have coming from other languages.
A lot of these things can be fixed by a compiler. For example LFortran by default doesn’t allow implicit typing and does not put the extra space in prints. You can of course enable the old behavior with compiler options. It will also guide you with style suggestions if you use some old syntax like .gt.
or integer*4
(they can also be turned off of course). So I think this approach will deliver a very pleasant experience learning and using modern Fortran.
Just to be clear, that isn’t “old” behavior, it is standard behavior. LFortran is set up to implement nonstandard behavior by default, and the programmer must specify options in order to get standard behavior. Intel ifort and ifx do the same thing for legacy reasons, the programmer must specify several options in order to get standard behavior.
I personally don’t think that is a good idea, for either LFortran or for the intel compilers, because of the potential for confusion for new fortran programmers. And even experienced fortran programmers complain about the intel situation. LFortran isn’t a production compiler yet, so it remains to be seen how programmers will like their nonstandard choices.
All LFortran will have to do is actually tell you when some non standard behavior flag is affecting complication. Intel will tell you nothing and then just silently NOT WORK if you leave off something like “-assume realloc_lhs”
For now it is the standard behavior indeed (I think it should be changed, but that’s a different story, no need to open that debate again). The implicit typing is a great example, the absolute vast majority (if not all) Fortran programmers do not use implicit typing, they always use “implicit none”. There is a significant subset of Fortran programmers who want standard conformance by default, and since the standard says implicit typing by default, they are willing to live with it.
LFortran isn’t a production compiler yet, so it remains to be seen how programmers will like their nonstandard choices.
Indeed.
We plan to add -std=f23
option that will make everything strictly standards conforming. We can add more info into error messages if it is confusing.
I think that a (short) document named “frequent traps” (or similar) would be useful. It would focus on some points of the language that are often misleading for people coming from other langages (such as implicit typing, implied save, the .f90 extension, …). There are not so many of them, I think.
Good idea. Or short documents called “Fortran for C programmers”, “Fortran for Python programmers” etc.
But this will not solve the main problem with learning material/documentation: Searching for Fortran <feature xy>
on DuckDuckGo or Google will many times list websites for FORTRAN 77 first.
Try this:
fortran parameter - Google Search or fortran parameter at DuckDuckGo
In addition, searching for different features of Fortran leads to many websites (oracle, intel, gnu, tutorialspoint, etc.) and therefore to very inconsistent information.