Jane and I use John’s test suite to evaulate the compilers we use. The latest version is available from our web site.
here is an extract
Revision 5 is an update that targets NAG 7.1, Intel ifort 2021.6.0, Intel ifx
2022.21.0, Nvidia nvfortran 22.5 and gfortran 12.1.0.
We’ll be doing an update in the near future.
I forgot that we also included the Cray 10.0.4 compiler in this release.
I am following a C++ course this week.
Until now I thought C++ was a kind of mess, but probably because I had only an ultra-basic/approximate/self-learning knowledge of it…
I must say that this course changed my mind: now I think C++ is an absolute mess.
The only things I really like compared to Fortran are the various containers (vectors, maps, lists…).
I think C++ is very powerful when used correctly, but it takes time to develop a good sense of how to use it (not claiming to be there myself) and some of the advanced things (template meta-programming) are simply off-limits for the casual scientific programmer.
The containers are nice but can also used be incorrectly. For example I’ve seen codes where they would use vector<vector<vector<double>>> as a makeshift array a[i][j][k] instead of a proper array/tensor class (e.g. from a library such as Eigen or Armadillo).
Maybe I am just not smart enough. I simply cannot handle the mental burden when using C++. My nightmare is its iterators. The std vector is a nice container, but its associated functions like insert are based on iterators, which really kill my brain cells. To make things even worse, the std algorithms are also based on iterators. Check out inner_product. I can’t believe that someone actually came up with this abomination. Now the C++ community is introducing ranges to replace iterators, but the syntax is no better…
Although hidden by some technobabble, iterators are after all just the old good pointers to the elements. Not that modern… They actually make sense for containers like list, but as you notice, basing everything on them is just awful and a regression compared to simple indices.
There is a useful abstraction there though. It works for containers that don’t have a meaningful indexing scheme. Trees for example. There’s a paper (or at least blog post) that will illustrate what I think the API/pattern will be for iterators once we have Fortran templates.
I’m inclined to agree, but @certik has done pretty amazing things with C++, along with many others. That compels me to keep an open mind. I’d also hate to throw away the billions spent on compiler optimizations. I’m looking for a palatable subset of C++ that builds upon modern C, and won’t make C++ programmers complain (too much). Even if you have a Fortran preference, knowing just enough C++ to write bindings so Fortran can use the code, is valuable. I think any productive scientific programmer needs to know all 3 languages to some degree (C, C++, and Fortran).
RE: Memory Safety – this is more of an issue for languages accepting untrusted input on strings, but memory management algorithms remains an active area of research. The classic reference on this was updated in 2023: The Garbage Collection Handbook: Second Edition
You might like our subset of C++ frontend then: GitHub - lcompilers/lc: C++ compiler, the subset that we compile is equivalent to Fortran, same performance, same safety guarantees.
I agree, and that’s why I eventually followed the course (which was pretty bad by the way, but that’s another story). Also, I do not doubt that C++ is a powerful language… which is not incompatible with being a “huge mess” 
.
It certainly requires more learning than many other languages before being able to use it correctly, and the few C++ codes that I can see around me just confirm that: they are as messy as permitted by the language (they are not written by software engineers, but by scientists who think they are good at programming just because they use C++).
You should add Python to your list. A lot of projects are moving to a hybrid model that use Python for IO and other parts of an app that don’t do number crunching with C++ handling the rest. A lot of job announcements are also listing Python experience as one of the desirables for the job.
If you already know C, C++, and/or Fortran, there is nothing in Python that can’t be figured out simply by looking at reference manuals. As a programming philosophy, it brings nothing new.
No but if you want a job that requires programming particularly in AI/Machine Learning you better know Python. Yes Python is simple for experienced programmers to learn on their own but that’s how most people these days learn any language. Many engineering schools in the U.S. stopped requiring a programming class of some kind as part of their curricula several years ago.
This is somewhat industry specific: in quantitative finance, C++ is nearly mandatory for the important positions. In the insurance/actuarial realm, Excel is (unfortunately) considered the lingua franca, with R and then Python making some gains in certain areas. In pharma/biomedical areas, SAS is considered mandatory.
Anyone who has demonstrable competence in C and or C++ via open source projects will have enough exposure to Python, simply via looking at the build scripts. Isn’t it supposedly designed to be “executable pseudocode?”
Most people are wasting their time getting “certifications” in things like “data science” or ML, without a good math background and relevant connections.
From Dan Luu: Programmer Moneyball circa 2016.
When I asked why he [a clearly experienced programmer] was getting rejected, the typical response I got was:
- Tech experience is in irrelevant tech
- “Experience is too random, with payments, mobile, data analytics, and UX.”
- Contractors are generally not the strongest technically
TrendCo’s real complaint with Mike is. He’s not their type. TrendCo’s median employee is a recent graduate from one of maybe five “top” schools with 0-2 years of experience. They have a few experienced hires, but not many, and most of their experienced hires have something trendy on their resume, not a boring old company like Microsoft.
I think Mark Twain once said: “Don’t let your schooling interere with your education.” That is the philosophy of my recommendations in light of a completely broken job market. In terms of time spent, very little should be spent on Python, but put it on the CV if necessary.
If you are a “derivatives pricing quant”, yes, but a growing number of quants are data scientists rather than developers of pricing models, and many of them are using Python or R. Nowadays many traders are expected to do some coding to automate their strategies, and they may be more likely to use Python or even Matlab than C++. C++ is harder than Python or Matlab and is less suited for the relatively small programs traders would write. My son is a programmer at a trading firm. Part of his job is to translate quants’ sloppy C++ to good C++.
Bringing this discussion back to Fortran, once LFortran is sufficiently mature, maybe it could play a role in quant finance for users who find Python, Matlab, and Excel too slow but find C++ too difficult.
Again, the point boils down to “learn how to program.” I’m concerned with what is valuable for an individual to spend time on. I am not concerned with what employers say they want. There are rapidly diminishing returns to study of multiple languages within the same paradigm. If you want to work at Jane St. for example, you would be advised to learn OCaml, F#, Haskell, or Scheme last time I checked.
What you seriously study to improve your problem solving skills is not necessarily equal to what you put on the CV. The requirements are often arbitrary, irrelevant, and should have no bearing on what is valuable from an educational POV.
On X, Jeff @science_dot wrote
The STL is the only indispensable part of C++ and you should not feel bad about using it in C code via an extern “C” wrapper. Reimplementing standard containers and algorithms is often a terrible use of time.
Once there is a C wrapper, Fortran programmers can similarly use the C++ Standard Template Library via C interoperability.