I don’t know if it’s really right place but nevermind. I’ve just migrated my academic webpage hosted on github from Jekyll to using Quarto. If anyone in academia is pondering about the same migration, trust me, it was a bliss!
But that’s not my point here. While doing so earlier this week, I had a very interesting discussion with a colleague of mine about the merits of Fortran and Python for teaching numerical linear algebra to undergrads (think mechanical engineering, not computer science). Since Quarto makes it very easy to add a blogging section to your webpage, I figured I’ll bite the bullet and started one. The first post is about some elements of this discussion I had about using Fortran for teaching purposes. You can find it here. I’ll probably try to find the time to explain more of my research there, and obviously Fortran will have prominent place.
Hey @loiseaujc. I think this is absolutely the right place to share it. A lot of what you write also matches my experiences (as someone who’s taught coding for scientists for a similar length of time), as well as points I often raise with other educators. Thank you for putting your thoughts and experiences on this page in such an organised way - it gives me something to forward to a number of people.
What the hell is numpy and why do I need it? Also, why import it as np?
Indeed. I find it strange that implicit none is regarded as too confusing to use in coding introductions, yet import x as y (or using multiple packages generally) isn’t questioned.
Nowhere in the code snippet is it clearly specified that b needs to be a two-dimensional np.array of real numbers nor that it shouldn’t be modified by the function. It is only implicit. And that can be a big problem for students when working with marginally more complicated algorithms. Sure enough, type annotation is a thing now in Python, but it still is pretty new and comparatively few people actually use them.
I would add that even if you do add type annotations, Python will not check them. For that you can use mypy. To find other flaws in Python code, such as variable used before set, set but never used, or functions imported but never used, I use ruff and vulture. So to get the features of a good Fortran compiler with warnings enabled you need to install and run not just Python but several other tools.
@fxm : Glad to hear that the issues I’ve described are not specific to the population of students I teach to! Regarding the implicit none vs import x as y, that is a good point. There is one key difference however I believe:
import x as y : you’re actually adding new capabilities to vanilla Python.
implicit none : you’re actually disabling some default capabilities of the language.
Just like <TAB> vs SPACE, or 0-based vs 1-based indexing, having to explicitly use implicit none vs having it enabled by default in the compilers is a hot debate (even more so given the downstream impact on legacy codes this decision could have). I can understand the confusion though. After all, if someone asks me this question, the only valid answer I have is something like well, when it was created, Fortran enabled implicit typing. Since then people have realized it wasn’t necessarily such a great idea. However, because of the need for backward compatibility, it was decided to introduce this implicit none statement so that programmers could explicitly prevent implicit typing rather than releasing a new version of the language where explicit typing was the standard. Eventually it’s just one of these things you internalized and no longer question.
Really? I had no idea! I’ve never used this feature but I thought it would at least raise some warnings when the variables types are not respected. This is confusing as hell. I hadn’t heard about ruff and vulture. I’ll check these out. I’m doing fewer and fewer coding in Python these days, but these may come in handy.
I leave it at “It’s a relic kept for backward compatibility. Just make sure it’s there and then forget about it.“ Perhaps that’s not a satisfactory answer for those who want to understand it, but in practice, it doesn’t require any more engagement (unlike packages you then use in your code). That said, I do wish it would go away - also so people would not get hung up on it as they do.
Adding type hints like this has no runtime effect: they are only hints and are not enforced on their own. […] To catch this kind of error you can use a static type checker. That is, a tool that checks the types of your code without actually running it in the traditional sense.
You might already have such a type checker built into your editor. For instance PyCharm immediately gives you a warning:
[…]
The most common tool for doing type checking is mypy though.
That last word in that sentence should be default, not standard. Maybe this is just nitpicking the words, but I would say that adding implicit none to a code is the standard way to disable implicit typing. Of couse, in f77 codes (and earlier), implicit none was indeed nonstandard, but since f90, it has been standard.
There have been two types of proposals related to this discussed here (and in other fortran forums, such as comp.lang.fortran). One is to disable implicit typing all together, meaning that not only is it no longer the default, but it cannot be enabled with implicit statements. This would force programmers to explicitly type all variables, function names, and so on, and when using legacy codes, these declarations would need to be generated somehow and added in order to compile with the modern compiler. The other, perhaps less intrusive suggestion, is to still allow implicit statements, but to disable the default implicit real(a-h,o-z), integer(i-n)
implicit typing. This would require programmers using legacy codes to add that statement wherever it is needed (each subprogram, beginning of each module, and so on).
Sadly, I think the best that can be done in the near term is to regard implicitly typed variables as ‘obsolescent’. Then compilers have an easier time justifying warning about them, but still allowing older codes to compile. There is precedence for this in the C world - when there were cases of ‘implicit int’ that are no longer allowed.
implicit none is fine to force explicit declarations. One line at the beginning of all modules is not a big deal… And most (probably all?) compilers have options to force explicit declarations if one prefers.
Remember that we are not talking about what is best for experienced fortran programmers, we are talking about what is best for beginners to the language. I started using perl for scripting in the late 1990s and early 2000s, about when the language was changing some of its conventions for its libraries (.pl and .pm). I was often confused when I downloaded some package from CPAN that used the old convention and I got warnings from the parser. Should I ignore the warnings and continue, or dig through the code and fix them, or what? This is the situation that a new fortran programmer will face if default implicit typing is changed. They will download some EISPACK or LINPACK or netlib code from the 1970s or 1980s (when implicit none was not allowed, and therefore not used), get some compiler warnings, and then not know what to do. Or they will download a more recent code that uses default implicit typing in interface blocks, and then have to dig through the actual code to make sure that code matches the block. Adding explicit type statements to a program that uses default implicit typing is not trivial to do by hand, and the automatic generation of those declarations is not part of the modern fortran standard, so then the programmer must go on a tools chase on the web, looking at various tools that are available (some free, some not, some good, some not). If not planned and executed well, such a change would be a disaster for the language. It is an unfortunate coincidence that in the fortran language heyday, when fortran was the #1 language and lots of scientific and engineering codes were written in the language, not only was the default implicit typing commonly used, but implicit none was, at best, a nonstandard extension. This would be particularly bad if implicit typing were to be removed from the standard entirely, as is often proposed.
I just played around with Quarto a little (I had not come across it before). It seems like an extremely useful and versatile tool. Have you used it for purposes other than the website?
Last year I planned to use it for writing the lecture notes for one of my linear algebra class, intertwining math and code, simultaneously exporting them as pdf, html and markdown. Unfortunately I got side-tracked by other projects and hadn’t had time to finish this. Only went so far as the second lecture, but it had been a rather pleasant experience and I’ll definitely try to find time to wrap it up. I’ve also played around with it to write a paper. Having the matplotlib code directly inside the document and making sure that the figures get updated every time I post-process a simulation and compile the document is a very nice feature.
That’s what I was thinking. Given that I’ve been looking for a good way to use the same sources (with lots of maths and code) to render files for in-class presentation and html, this may be perfect … apart from the first time rewriting the notes.
[…] having to declare the type, dimension and input or output nature of every variable you use might seem cumbersome at first. But it forces students to pause and ponder to identify which is which.
I would go as far as to say this advantage is understated. The missing type declarations for Python (which would be the same for Julia, a language I had also considered for teaching and shares some of Fortran’s advantages highlighted here), always comes back to haunt students in my experience - no matter how much “watch your types” is verbalised throughout a course.
I’ve just heard about the Elan language, not to be confounded with the 1974 ELAN although they are both designed as educational programming languages. Here is an interview of its creator. Even though it is targeting high-school, many of the points he raises about Python and other programming languages used in education seem oddly similar to what we’ve discussed here (strongly typed, no global variables, functional programming, etc). I have played for a few minutes with one or two of the examples provided in the online IDE. It is a bit verbose but indeed very close to how you would present the code orally to students.
