Numpy actually explicitly doesn't need fortran. It will use some fortran lapack libraries for optimizations if they're present, but it doesn't depend on fortran at all.
Scipy is a different story.
The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fledged environment. (I think numpy was even scipy-min, or scipy-core, or something along those lines for a bit.) A key differentiator for what when into numpy vs scipy was whether or not it needed a fortran compiler. That's still true today -- numpy explicitly doesn't depend on anything fortran related, and anything that uses it is optional.
(I'm not authortative on any of this, I'm just someone who's been doing scientific computing in python (and fortran) since the numeric days.)
On a different note, modern fortran (e.g. F90 and above) is actually a really nice scientific software language. It's _still_ really hard to beat, and modern fortran is pretty maintainable and easy to read in addition to being performant. I've dealt with highly optimized fortran codebases and highly optimized C codebases for the same scientific tasks. The fortran ones were usually a lot easier to read, more maintainable, and were still faster. Fortran is not really a general purpose language, but if you're doing lots of number crunching on large arrays, it's damned nice.
Yep! Seconding what you said: A key aspect is that it’s very easy to write fast matrix math in Fortran. Vectorized operations are downright pythonic!
I was amazed how much more complex things were when moving to C++ (as opposed to C or C written in cpp files which you’ll find in academia and some books).
Of course, that ease is a hazard when all the modern (i.e. fun) sci-eng software development is in C++.
Do not grow complacent in school, ye numerical methods researchers! Write your stuff in C++. The job market awaits.
Sure - I am speaking broadly of the job market for computational programmers outside of academia and national labs, and I'd better say that I am in the USA. So if you did a masters or PhD in CFD, or the finite element for structures, (and I wager also, E&M/Maxwell, computational physics, and numerical simulation generally (a catch all because the boundaries are fuzzy), but I think "as it goes in CFD and FEA for structures, so it goes in other numerical domains...?"), then it's quite possible you came from a school where your professor(s) wrote in old style C++ (or maybe straight up procedural C), or maybe used only the most basic features of Fortran 90 or worse (F77). The main thing is that while you did something noteworthy in your field to get your degree in engineering simulation or computational physics, you used a language, or language variant, that is not common anymore in _actively_ developed projects commercially. So, outside of academia and national labs, which are hard to get into if you are coming in from say, a state school with fewer connections (and did not intern somewhere as you had research obligations at school, say), in commercial code bases, as far as I have seen, hiring "from without" looks generally for lots of C++ computational/numerical experience.
Not such a big deal if you are a pure-researcher in, say, CFD, and not such a big deal in a national lab, where the big codebase may be FORTRAN anyway (caps to denote old school code bases). But it really limits your mobility not to be "C++ first". Lastly, if you land a job at a big numerical analysis company, you may be looking after legacy products forever if you are "just a Fortran person".
Well, this is obviously anecdotal. Sorry to state such bald opinions. But it's what I've seen, and really would have been helpful to know as I was going through school. I wrote a lot of Fortran and Python. It's left me playing catch up and it could have been avoided with comparative ease compared to my time budget now.
I'll second all of that. It's well worth actually learning C++ (and not C masquerading as C++) if you want to go into the broader scientific computing job market.
I certainly wish I had focused more on "real" C++. I have maintained some very large C++ codebases, but I still don't really know C++, just "C with classes". Thankfully, C++ is not my day-job anymore.
I'd also give a quiet nod to trying to get familiar with modern dev-ops tooling. E.g. docker, kubernetes, and interacting with at least some forms of cloud storage. Get used to the idea that a bucket is not actually a directory, it's a hierarchy of prefixes and learn how to use that. Think of a dockerfile as learning how to write a makefile. It's worth learning the basics of, and it's not hard for simple things. HPC work has traditionally been a lot of fairly custom clusters (Condor, anyone?) or problems that are best solved with a lot of RAM on one machine. However, things are moving towards commodity solutions (i.e. "the cloud") or at the very least, common software layers. You don't need to understand the the ins and outs of managing a kubernetes cluster, but it's helpful to have used kubectl to spin up and debug a pod or two at some point.
However, I will say that there seem to be more Python-based jobs than C++ or Fortran jobs in the industry-based scientific computing world these days. Perhaps less so for fluid dynamics or finite element methods or other "simulation on a grid" problems, but there are a lot of python codebases out there in industry right now. I think it's very important to be comfortable working in higher level languages as well, and python is kinda becoming the lingua franca of a lot of sub-fields. For better or worse (I'm in the "better" camp), a lot of users are going to want a python library for what you're writing. It's best if you're used to "thinking in python" and can design a pythonic api.
Thanks, and it's nice to hear that about Python! I don't know why I am surprised, as the more forward thinking folks at (even such a place as) my work are having a Python api built for the stuff they look after presently (their bit does structural analysis). That should make design generation/variation/optimization a lot more fun.
I guess my fear was that all Python jobs (that I'll find) are going to be "machine learning" -- but really that would just mean data munging to feed Tensor Flow (or similar lib) and post process. Total snooze fest unless "post process" means something more like design generation/variation/optimization - and we are back to the api.
Scipy is a different story.
The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fledged environment. (I think numpy was even scipy-min, or scipy-core, or something along those lines for a bit.) A key differentiator for what when into numpy vs scipy was whether or not it needed a fortran compiler. That's still true today -- numpy explicitly doesn't depend on anything fortran related, and anything that uses it is optional.
(I'm not authortative on any of this, I'm just someone who's been doing scientific computing in python (and fortran) since the numeric days.)
On a different note, modern fortran (e.g. F90 and above) is actually a really nice scientific software language. It's _still_ really hard to beat, and modern fortran is pretty maintainable and easy to read in addition to being performant. I've dealt with highly optimized fortran codebases and highly optimized C codebases for the same scientific tasks. The fortran ones were usually a lot easier to read, more maintainable, and were still faster. Fortran is not really a general purpose language, but if you're doing lots of number crunching on large arrays, it's damned nice.