So, the OP is an actual educator whereas I've only really advised grad students or undergrads. I'm surprised being exposed to any new language doesn't come with it's "whys" for students. Like why should we care about type safety anyway? Or why not loop over all indices, why use (:) for some of them? May be I'm not really convinced that the whys from students in a python class are worse than the whys in fortran. Honestly, if there is some compiler option for turning on implicit none by default, I'd just do that too just to get people in the door as that too feels like more confusion than it's worth keeping, although they do need to learn what it means before they leave.
Also, the downside is fortran does not have nice plotting capabilities without an external tool. At least I know of no nice libraries like matplotlib, which again is a point in just teaching them a more general purpose language from the get go to get used to it so they can plot and code in the same language...or perhaps, matlab/octave et al as others suggested. I feel like the niceness of fortran (namely, well defined type safe function/subroutine interfaces and easy path to writing performant code) that isn't offered by python is only useful after the first threshold of learning to put algorithm to paper. The literally second (and arguably for some fields, even more important) task of actually plotting results doesn't have the same convenience as the intrinsic procedures in fortran, whereas if they had learned julia or python, these tools would be at the very least be at the same convenience level of the array facilities, essentially behind a rather easy[^] to use library. In fact, in julia, you're already mostly there although it's not my cup of tea. Perhaps the answer is julia after all.
Does OP's courses just use an external program (like gnuplot) or a black box to plot?
[^] easy to use once you know how to program a little, of course.
I did a cursory scan and some of these seem not my cup of tea, but honestly ogpf looks rather pleasant for quick plots. Thanks! I might use this.
That said, the point of these being external libraries and thus making them a bit less convenient still sort of stands, as being external libraries means you need to link them which exposes more CS tier stuff (installing libraries, make files, etc) that distracts from just learning codes, which again just motivates using a tool that abstracts some of that behind a managed package and library system.
I'm assuming you could use things like lfortran in jupyter which I imagine might allow these things to be bundled, although I haven't followed that effort as of late.
It depends on how you define "built-in" exactly. I would argue that in this context, if the end user isn't aware that an external library is used under the hood, it still qualifies as built-in. In which case, R has plot() in its stdlib.
The post dismisses Julia quite quickly, especially since it is a language essentially purpose built to teach numerical linear algebra. Numerical methods is taught in Julia in at least a dozen universities I'm aware of, including MIT.
Unicode support and a few other syntax niceties make translation from the blackboard to the editor nice and clean. Fortran is great but legibility and easy tooling like (reproducible) package managers are paramount in teaching
Saying fortran is not legible is not an argument that holds water against fortran 90. I don't want to be uncharitable but I don't know how anyone can have this opinion unless they just don't have much familiarity with it.
I didn’t say it was illegible. I said legibility is paramount, and I don’t think it makes the right trade offs in that regard to be a great teaching language
It’s far more legible for numerics than a lot of languages, maybe except Julia and Chapel. Julia was just driven in large part by teaching mathematics at mit and I think that shows
I would go and say Fortran is pretty legible because it only has a handful of builtin keywords and none of the fancy stuff alot of other languages have.
Julia has the fancy stuff aswell as being very legible and also having a nice REPL for instant feedback which is usefull for people learning (as well as multiple notebook implementations Pluto.jl or Jupyter)
Chapel has even more of the fancy stuff like multiple loop types for different kinds of parallelism which is just wildly cool.
I second this. When I worked on some older Fortran codes, I had to keep a cheat sheet for the variable names and what they meant or controlled. It definitely made the code hard to read.
Regrettably, any discussion of Fortran will be quickly filled with people who once had to write a couple of F77 programs in college and never got over it, never used a really nice Fortran compiler, and of the very few who actually knew the language has evolved in the last 50 years the vast majority of that minority couldn't name a single significant thing that changed in F90/F95 through Fortran 2018.
But they all have Opinions, which they are compelled to share.
Julia's choice to encourage people naming their variables greek letters is bad though. There's a whole group of students who struggle with the symbols, but understand the concepts (a residual). Julia, when used to its full capabilities, gains an enormous amount of its power from a huge amount of clever abstractions. But in the 1st-course-in-numerical-methods class context, this can be more offputting than the "why np?" stuff this article mentions.
For teaching linear algebra, MATLAB is unironically the best choice - as the language was originally designed for that exact purpose. The problem is that outside of a numerical methods class, MATLAB is a profound step backwards.
If students struggle with the use of Greek letters as symbols, it'll be difficult for them to deal with lots of math and physics where this is the standard notation. Intuitively it feels that the best thing that the language can do here is to enable notation that is the closest to the underlying math.
> If students struggle with the use of Greek letters as symbols
After using Character map or other "user friendly" methods to enter Greek letters as symbols on a computer, i would say, yes, people struggle with the use of Greek letters. Unless, of course, one has a Greek keyboard.
Whatever language you choose, you are only going to be teaching a subset of it anyway, so just ignore the Unicode identifier support. I code in Julia professionally, and never use it.
Fortran is not a better choice unless you are only thinking about the immediate needs of the course. In the wider world, Python is going to be a lot more useful to the students.
Today, sure. But you could have made the same argument with Pascal being more practical in the 1980s. And yet here we are 40 years later with Pascal having become obscure and Fortran still with us. While ultimately any programming learning should be language independent, there's an argument to be made to stick to languages like Fortran which have a track record of being around a long time over whatever is currently popular.
Fortran is with us in a technical sense, but its use is tiny. I’ve done about six Fortran to python rewrite projects during my academic career. No-one has seriously suggested going the other way.
I will bet you any amount of money you like Python will be more popular than Fortran in 5,10,20 and 30 years.
if you're smart enough to learn fortran and learn to impliment and undersatnd numerical methods in it, I would argue that learning python will be an afterthought. You can learn python along with numpy in a week tops if you already understand the theory. I believe a lot of numpy libs are written in fortran code anyway though I could certainly be wrong there.
Why learn Fortran? If you want nice things stop propping up dinosaurs. Let it die already.
Teach them numerical algorithms and have the students contribute to a better language's BLAS, LAPACK, or numerical library like numpy, jax, scipy, etc. Be part of the solution.
fortran is still very much the GOAT when it comes to numerical methods. to the point where all the modern fancy numerical methods libraries still squeeze out performance by calling out to libraries implemented in fortran. Its far from dying. its very good at its niche.
This isn't true. Openblas and MKL are both C/C++ with assembly hardcoded microkernels. SciPy is in the process of removing the last of their Fortran because no one wants to maintain it, and newer methods in other languages are faster. Fortran hasn't been in the core of everything for decades.
Julia is starting to pick up steam here. It's a lot easier to write mixed precision algorithms in since the type system is pretty much designed for efficiently writing generic algorithms (and it doesn't hurt that Julia's ODE solvers are SOTA)
- Matlab in the first few science lab courses + first CS course.
- C++ in second CS course
- Fortran for the scientific computing course
I found Fortran worse than matlab. The error messages were difficult to parse, and it was much more difficult to do step through debugging like in matlab.
But later I learned Python, and now use it professionally to do scientific computing, and I would give anything to go back to Fortran. Or use Rust or Julia. Or if Wolfram/Mathematica if that was possible. Anything but Python.
The fundamental problem with Python is that all the math is hacked into it, unlike Julia/Matlab/Mathematica where the math takes first priority and other values are secondary.
May be you learned all of these extremely recently before for decades I would definitely say C++ error messages were far worse than anything a fortran compiler has ever barked at me for. The bad days are definitely over but I still think C++ template errors can still be the thing of horrors even today. I know you compared matlab to fortran but you even said you took C++ just prior to this and I'm amazed that didn't harden you for anything gfortran/ifort would throw at you.
Many other researchers I work with have almost no programming experience outside of Python or other high-level languages. Switching to Fortran or Rust will significantly slow down our work for at least an year or two while people catch up.
Julia would be easier to switch, but it's still months of work to port over existing libraries.
I’d suggest Octave over Matlab, because current Matlab has tons of distracting AI and autocomplete front and center. Probably really helpful for getting a plot just right or implementing an algorithm from a paper, but not so good for learning the basics.
Step 1) Write the function using high level abstractions
Step 2) Glance over the generated assembly and make sure that it vectorized the way you wanted.
> Glance over the generated assembly and make sure that it vectorized the way you wanted.
Isn't that sth you would also need to do in Fortran? IMO Julia makes this so easy with its `@code_*` macros and is one of the main reasons why I use it.
If you write Julia similar to Fortran, with explicit argument types and for loops and avoiding allocations it shouldn’t be too far off. Fortran IIRC has a few semantics which might make it more optimal in a few cases like aliasing
But indeed there are almost certainly less performance surprises in Fortran
people like to complain about matlab as a programming language but if you're using it that way you're doing it wrong.
matlab (the core language) is awesome for expressing matrices and vectors and their operations as well as visualizing the results. matrix expressions in matlab look almost identical to how they look in mathematical notation (or how one might write them in an email). you shouldn't be using programming language flow control (or any of the other programming language features), you should be learning how to write for loops as vector and matrix operations and learning from the excellent toolboxes.
> While you have to use np.linalg.norm in Python to compute the norm of a vector, Fortran natively has the norm2 function for that. No
That's what sucks in python as a newbie. Wanted to play with random, which python docs says it's a builtin. Obscure error message. Search the internet, no fix in sight. After more searching i found out that i actually have to "import random" (builtin ??) and use a method ? Wtf.
So definitely python is not for newbies. Fortran code is much easier to underestand.
I don't see what's wrong with Python for a first course. In fact, you can go very far with Python alone (in terms of performance) if you learn to use Numba well. If that isn't enough, I would go straight to C (opportunistically augmented by C++98 when needed), and learn how to use the GNU Scientific Library and Eigen (the linear algebra library).
Not true. C++ is great for scientific computing. There is a huge number of mature libraries like Eigen. You can also painlessly use Fortran/C libraries like LAPACK, SLICOT and many others. Performance is top notch. It's multiparadigm so you can use OOP where it makes sense. It's a very complex language, but for scientific computing the C++98 subset is enough and IMO it's far cleaner than modern C++ or Rust.
C++ also has by far the best support for graphics (OpenGL/Vulkan) and GUI toolkits like Qt.
I think fortran would be cool if they program it by hand on punch card and the teacher then executes these to check the programs. Like in the very early days of programming where you had to submit these punch chards and wait until they get executed on the mainframe by an operator.
It seems pretty clear to me that the best language to use for numerical linear algebra is the language you know and a good curriculum would be structured in a way where your first encounter with a language is not a course where the choice of language is nearly irrelevant.
You would think. I was a TA for numerical methods for undergrad engineers. Saw lots of bright students who understood the material but could debug their code. Several grad students started a 1credit seminar course on Fortran fundamentals. We worked those students like dogs, but when they took the numerical methods course they came back and thanked us because they knew how to get their code to compile and how to use the admin graphics package.
So, the OP is an actual educator whereas I've only really advised grad students or undergrads. I'm surprised being exposed to any new language doesn't come with it's "whys" for students. Like why should we care about type safety anyway? Or why not loop over all indices, why use (:) for some of them? May be I'm not really convinced that the whys from students in a python class are worse than the whys in fortran. Honestly, if there is some compiler option for turning on implicit none by default, I'd just do that too just to get people in the door as that too feels like more confusion than it's worth keeping, although they do need to learn what it means before they leave.
Also, the downside is fortran does not have nice plotting capabilities without an external tool. At least I know of no nice libraries like matplotlib, which again is a point in just teaching them a more general purpose language from the get go to get used to it so they can plot and code in the same language...or perhaps, matlab/octave et al as others suggested. I feel like the niceness of fortran (namely, well defined type safe function/subroutine interfaces and easy path to writing performant code) that isn't offered by python is only useful after the first threshold of learning to put algorithm to paper. The literally second (and arguably for some fields, even more important) task of actually plotting results doesn't have the same convenience as the intrinsic procedures in fortran, whereas if they had learned julia or python, these tools would be at the very least be at the same convenience level of the array facilities, essentially behind a rather easy[^] to use library. In fact, in julia, you're already mostly there although it's not my cup of tea. Perhaps the answer is julia after all.
Does OP's courses just use an external program (like gnuplot) or a black box to plot?
[^] easy to use once you know how to program a little, of course.
Fortran has a few nice plotting libraries. [0] Including matplotlib.
Personally, I've only used ogpf, which is a single-file library, making it easier to run for beginners.
[0] https://fortran-lang.org/packages/graphics/
I did a cursory scan and some of these seem not my cup of tea, but honestly ogpf looks rather pleasant for quick plots. Thanks! I might use this.
That said, the point of these being external libraries and thus making them a bit less convenient still sort of stands, as being external libraries means you need to link them which exposes more CS tier stuff (installing libraries, make files, etc) that distracts from just learning codes, which again just motivates using a tool that abstracts some of that behind a managed package and library system.
I'm assuming you could use things like lfortran in jupyter which I imagine might allow these things to be bundled, although I haven't followed that effort as of late.
What language does have built-in plotting capabilities that don't depend on external libraries?
It depends on how you define "built-in" exactly. I would argue that in this context, if the end user isn't aware that an external library is used under the hood, it still qualifies as built-in. In which case, R has plot() in its stdlib.
Language vs system with a language?
Mathematica, matlab, maple, octave, etc.
The post dismisses Julia quite quickly, especially since it is a language essentially purpose built to teach numerical linear algebra. Numerical methods is taught in Julia in at least a dozen universities I'm aware of, including MIT.
Unicode support and a few other syntax niceties make translation from the blackboard to the editor nice and clean. Fortran is great but legibility and easy tooling like (reproducible) package managers are paramount in teaching
Saying fortran is not legible is not an argument that holds water against fortran 90. I don't want to be uncharitable but I don't know how anyone can have this opinion unless they just don't have much familiarity with it.
I didn’t say it was illegible. I said legibility is paramount, and I don’t think it makes the right trade offs in that regard to be a great teaching language
It’s far more legible for numerics than a lot of languages, maybe except Julia and Chapel. Julia was just driven in large part by teaching mathematics at mit and I think that shows
I would go and say Fortran is pretty legible because it only has a handful of builtin keywords and none of the fancy stuff alot of other languages have.
Julia has the fancy stuff aswell as being very legible and also having a nice REPL for instant feedback which is usefull for people learning (as well as multiple notebook implementations Pluto.jl or Jupyter) Chapel has even more of the fancy stuff like multiple loop types for different kinds of parallelism which is just wildly cool.
A large share of the illegibility of Fortran code is actually just the aversion of numerics code to having meaningful variable names.
I second this. When I worked on some older Fortran codes, I had to keep a cheat sheet for the variable names and what they meant or controlled. It definitely made the code hard to read.
Regrettably, any discussion of Fortran will be quickly filled with people who once had to write a couple of F77 programs in college and never got over it, never used a really nice Fortran compiler, and of the very few who actually knew the language has evolved in the last 50 years the vast majority of that minority couldn't name a single significant thing that changed in F90/F95 through Fortran 2018.
But they all have Opinions, which they are compelled to share.
C++ has evolved immensely in that same time. I still would NEVER use C++ for anything new, now that Rust exists.
Why should I use Fortran, for anything that isn't maintaining legacy code?
Julia's choice to encourage people naming their variables greek letters is bad though. There's a whole group of students who struggle with the symbols, but understand the concepts (a residual). Julia, when used to its full capabilities, gains an enormous amount of its power from a huge amount of clever abstractions. But in the 1st-course-in-numerical-methods class context, this can be more offputting than the "why np?" stuff this article mentions.
For teaching linear algebra, MATLAB is unironically the best choice - as the language was originally designed for that exact purpose. The problem is that outside of a numerical methods class, MATLAB is a profound step backwards.
If students struggle with the use of Greek letters as symbols, it'll be difficult for them to deal with lots of math and physics where this is the standard notation. Intuitively it feels that the best thing that the language can do here is to enable notation that is the closest to the underlying math.
> If students struggle with the use of Greek letters as symbols
After using Character map or other "user friendly" methods to enter Greek letters as symbols on a computer, i would say, yes, people struggle with the use of Greek letters. Unless, of course, one has a Greek keyboard.
Whatever language you choose, you are only going to be teaching a subset of it anyway, so just ignore the Unicode identifier support. I code in Julia professionally, and never use it.
Fortran is not a better choice unless you are only thinking about the immediate needs of the course. In the wider world, Python is going to be a lot more useful to the students.
That's not the goal of learning the basics of numerical programming. Plus, anyone doing such a course should already know how to write code.
Today, sure. But you could have made the same argument with Pascal being more practical in the 1980s. And yet here we are 40 years later with Pascal having become obscure and Fortran still with us. While ultimately any programming learning should be language independent, there's an argument to be made to stick to languages like Fortran which have a track record of being around a long time over whatever is currently popular.
Fortran is with us in a technical sense, but its use is tiny. I’ve done about six Fortran to python rewrite projects during my academic career. No-one has seriously suggested going the other way.
I will bet you any amount of money you like Python will be more popular than Fortran in 5,10,20 and 30 years.
You are defintely not risk averse. Try to look back 30 years and see how much popularity has changed since then.
if you're smart enough to learn fortran and learn to impliment and undersatnd numerical methods in it, I would argue that learning python will be an afterthought. You can learn python along with numpy in a week tops if you already understand the theory. I believe a lot of numpy libs are written in fortran code anyway though I could certainly be wrong there.
Why learn Fortran? If you want nice things stop propping up dinosaurs. Let it die already.
Teach them numerical algorithms and have the students contribute to a better language's BLAS, LAPACK, or numerical library like numpy, jax, scipy, etc. Be part of the solution.
fortran is still very much the GOAT when it comes to numerical methods. to the point where all the modern fancy numerical methods libraries still squeeze out performance by calling out to libraries implemented in fortran. Its far from dying. its very good at its niche.
This isn't true. Openblas and MKL are both C/C++ with assembly hardcoded microkernels. SciPy is in the process of removing the last of their Fortran because no one wants to maintain it, and newer methods in other languages are faster. Fortran hasn't been in the core of everything for decades.
For better or worse, Fortran is still a popular language to write clever PDE schemes in, as it maximizes "time to first, fast-enough-running code".
But for anything with a userbase of more than ~15 people, C/C++ are widely preferred.
Julia is starting to pick up steam here. It's a lot easier to write mixed precision algorithms in since the type system is pretty much designed for efficiently writing generic algorithms (and it doesn't hurt that Julia's ODE solvers are SOTA)
> Julia is starting to pick up steam here
First time I saw this claim was over 9 years ago.
Fortran has modern versions and is much nicer for writing numerical code than C, C++, Rust, etc...
Fortran, Octave, or Julia are excellent for learning linear algebra.
This was the path I took, before going to Python, Go, and Rust.
APL is better, obviously. There are even dozens of textbooks for teaching math with its notation.
APL has its own bag of surprises.
I was going to mention APL, then decided to scroll through the discussion.
Ada is also excellent for linear algebra and other numerical programming.
I personally think R and Julia are much better at this.
My scientific computing journey was
- Matlab in the first few science lab courses + first CS course.
- C++ in second CS course
- Fortran for the scientific computing course
I found Fortran worse than matlab. The error messages were difficult to parse, and it was much more difficult to do step through debugging like in matlab.
But later I learned Python, and now use it professionally to do scientific computing, and I would give anything to go back to Fortran. Or use Rust or Julia. Or if Wolfram/Mathematica if that was possible. Anything but Python.
The fundamental problem with Python is that all the math is hacked into it, unlike Julia/Matlab/Mathematica where the math takes first priority and other values are secondary.
May be you learned all of these extremely recently before for decades I would definitely say C++ error messages were far worse than anything a fortran compiler has ever barked at me for. The bad days are definitely over but I still think C++ template errors can still be the thing of horrors even today. I know you compared matlab to fortran but you even said you took C++ just prior to this and I'm amazed that didn't harden you for anything gfortran/ifort would throw at you.
What are the obstacles in your using Fortran (or Rust or Julia) in place of Python?
Many other researchers I work with have almost no programming experience outside of Python or other high-level languages. Switching to Fortran or Rust will significantly slow down our work for at least an year or two while people catch up.
Julia would be easier to switch, but it's still months of work to port over existing libraries.
correct. Python is a general purpose language pretending to speak math.
If you are unwilling to teach through python's warts you should use Matlab, not fortran.
I’d suggest Octave over Matlab, because current Matlab has tons of distracting AI and autocomplete front and center. Probably really helpful for getting a plot just right or implementing an algorithm from a paper, but not so good for learning the basics.
Even better: Julia (although Fortran is pretty good!)
I translated the jacobi example to julia, and it does seem to address every one of his gripes with Python.
I love julia, but the default workflow is
Step 1) Write the function using high level abstractions Step 2) Glance over the generated assembly and make sure that it vectorized the way you wanted.
> Glance over the generated assembly and make sure that it vectorized the way you wanted.
Isn't that sth you would also need to do in Fortran? IMO Julia makes this so easy with its `@code_*` macros and is one of the main reasons why I use it.
In my experience, Fortran compiler is heavily optimized. It competes head to head with C.
Julia’s on the other hand, many times puts out very unoptimized code.
Mind you, last time I looked at Julia was 2-3 years ago, maybe things have changed.
If you write Julia similar to Fortran, with explicit argument types and for loops and avoiding allocations it shouldn’t be too far off. Fortran IIRC has a few semantics which might make it more optimal in a few cases like aliasing
But indeed there are almost certainly less performance surprises in Fortran
this is the way. octave or matlab.
people like to complain about matlab as a programming language but if you're using it that way you're doing it wrong.
matlab (the core language) is awesome for expressing matrices and vectors and their operations as well as visualizing the results. matrix expressions in matlab look almost identical to how they look in mathematical notation (or how one might write them in an email). you shouldn't be using programming language flow control (or any of the other programming language features), you should be learning how to write for loops as vector and matrix operations and learning from the excellent toolboxes.
IMO, the issue is that "Scientific computing" covers several disparate use cases.
When you care about the math, Mathematica. It's a replacement for several pages of hand-written math, or a chalkboard.
When you care about the result, MatLab. It's a replacement for your calculator, and maybe Excel.
When you care about the resulting software? Python/Julia/Fortran.
Fortran is much more approachable and more regular than Matlab. Really, there’s no contest.
> While you have to use np.linalg.norm in Python to compute the norm of a vector, Fortran natively has the norm2 function for that. No
That's what sucks in python as a newbie. Wanted to play with random, which python docs says it's a builtin. Obscure error message. Search the internet, no fix in sight. After more searching i found out that i actually have to "import random" (builtin ??) and use a method ? Wtf.
So definitely python is not for newbies. Fortran code is much easier to underestand.
I don't see what's wrong with Python for a first course. In fact, you can go very far with Python alone (in terms of performance) if you learn to use Numba well. If that isn't enough, I would go straight to C (opportunistically augmented by C++98 when needed), and learn how to use the GNU Scientific Library and Eigen (the linear algebra library).
Nobody should be using C/C++ for anything new, much less using it as a teaching vehicle. That's just irresponsible at this point.
Not true. C++ is great for scientific computing. There is a huge number of mature libraries like Eigen. You can also painlessly use Fortran/C libraries like LAPACK, SLICOT and many others. Performance is top notch. It's multiparadigm so you can use OOP where it makes sense. It's a very complex language, but for scientific computing the C++98 subset is enough and IMO it's far cleaner than modern C++ or Rust.
C++ also has by far the best support for graphics (OpenGL/Vulkan) and GUI toolkits like Qt.
Am I crazy or is the Jacobi iteration flipping the sign of u every iteration?
Also the swapping of u and tmp doesn't work like that in python. Might in fortran.
I think fortran would be cool if they program it by hand on punch card and the teacher then executes these to check the programs. Like in the very early days of programming where you had to submit these punch chards and wait until they get executed on the mainframe by an operator.
Fun times, my frist job but I messed it up.
I should get back to Fortran but it has changed a lot over the years.
This kind of professor must disappear.
They always want to teach the more elegant and divine method that, in reality, nobody uses.
I studied Pascal and Fortran when they could have taught me more widely used languages. Shame on them.
If Fortran is so useful and clear, just offer some lessons on it. Surely students will be enlightened and captivated by it.
A follow-up post is https://loiseaujc.github.io/posts/blog-title/jacobi_experime... "Jacobi method: From a naïve implementation to a modern Fortran multithreaded one".
It seems pretty clear to me that the best language to use for numerical linear algebra is the language you know and a good curriculum would be structured in a way where your first encounter with a language is not a course where the choice of language is nearly irrelevant.
You would think. I was a TA for numerical methods for undergrad engineers. Saw lots of bright students who understood the material but could debug their code. Several grad students started a 1credit seminar course on Fortran fundamentals. We worked those students like dogs, but when they took the numerical methods course they came back and thanked us because they knew how to get their code to compile and how to use the admin graphics package.
> No off-by-one error – By default, Fortran uses a 1-based indexing. No off-by-one errors, period.
I'm with Dijkstra on this one. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...