C++ vs Fortran

I've been wanting to put together a blog post about Fortran for a while now, but it never made it to the top of my list of priorities. I'm happy to see that someone named eric_t went ahead and put together a really nice page:

https://bitbucket.org/eric_t/modern-fortran/wiki/Home

So, predictably, the C++ mob showed up with their pitchforks to argue against the use of Fortran. (Actually, a lot of them were arguing against FORTRAN, demonstrating their ignorance.)

As someone who has used both C++ and Fortran for numerical programming, it's hard for me to think of a good reason to use C++ for this stuff.

Let me start out by explaining my perspective, which is what rarely happens in programming language debates. I write numerical programs that do statistical analysis, simulations, and various types of numerical analysis. Most of my programs are less than 5000 lines.

I don't know or care about comparisons of C++ against Fortran for 50 developers working with a codebase of a million lines. I work together with only a few others. I have no interest at all in software development. I write programs as necessary to feed myself.

C++ comes with the mother of all learning curves. I'm not talking about the fact that there's no complexity too large to fit into a C++ program (the language is more than happy to accommodate any desired level of complexity). Though of course that is a problem.

I'm talking about the ability to do basic things like linear algebra or writing functions. A Matlab user can convert to Fortran in about 10 minutes. Obviously you won't know very much, but in the time it takes to get used to the idea of compiling a program and specifying types for your variables, you can define two matrices and do a matrix multiplication in Fortran. The language was written for scientific computations. You can take a look at the gfortran manual to see all the built-in goodies that come with a Fortran compiler.

The bare minimum for doing the same exercise in C++ is that you have to get your hands on a library that does what you want. So you have to know about the existence of Eigen or another libary. Then you have to figure out how to call it. Then you have to figure out how to link to an external library. And the documentation is probably not that helpful. There are friendly C++ users for sure. It's just that you won't have a clue what they're telling you to do. They'll be telling you to set up a makefile. They'll be recommending that you look at Boost and talking about how great it is and you'll be all WTF.

All this mess because you wanted to try out C++ to do a simple matrix multiplication. In Matlab it was just a few lines. In C++ it's a month-long project.

And before you use that C++ library, are you really sure you won't end up with a memory leak? Do you even know what a memory leak is? It probably won't matter for your simple matrix multiplication, but it's real comforting to know that you should worry about such things in order to write such a simple program, isn't it?

Now that the numerical version of "Hello, World!" is out of the way, you can get on to real work. You need to start with a tutorial. Not a complete introduction to the language, of course, just a tutorial that will give you a basic understanding of the language.

An excellent tutorial (that has taught me a great deal) is C++ Primer Plus. I just pulled the Fifth Edition off my shelf. It's okay to just read through Chapter 17. You don't even have to read the appendices. The first 1039 pages of the book is enough for now.

You will have worked through Chapter 4, including the section on "Pointers and the Free Store" and "Pointers, Arrays, and Pointer Arithmetic". You'll have learned about "Dereferencing Pointers". You'll get to work through well-designed syntax like (page 308)

int sum(int (*ar2)[4], int size);

or (page 309)

*(*(ar2 + r) + c)

You'll learn about "Memory Models and Namespaces" in chapter 9. The topics include material useful to newbies like "Automatic Variables and the Stack".

Further along (page 677) you'll learn about "Inheritance and Dynamic Memory Allocation".

Maybe you can just learn the language a little bit at a time. Here's the thing. You really can't. You have to know a lot to read code written by others and to use libraries written by others. Complexity is never hidden behind the scenes with C++. You have to understand memory management before you write your first line of code.

You might think you'll just call libraries so you'll be okay. That's not programming in C++, but let's pretend it is. An easy library (written in C) to call is the GSL. You want to solve a system of equations. Here's the function call:

int (* f) (const gsl_vector * x, void * params, gsl_vector * f)

This is an example of "easy" in C++.

Then when you're done with your tutorial, at a minimum, you need to learn about templates and the STL. And, although not strictly necessary, you should pick up some books by Scott Meyers so you can learn about pitfalls of the language.

If you think I'm just some idiot blogger who doesn't know anything about programming, and don't want to take my word that C++ is too complex to be a reasonable language choice, take a look at this blog post:

http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/

It was not a group of mediocre developers too lazy to learn a programming language that he interviewed. From my perspective, Ken Thompson's comment is the most relevant:

"It certainly has its good points. But by and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex."

If you can program in Matlab, you can program in Fortran. The same is not true for C++. The complexity is not optional: you just can't interact with the outside world without bumping into it.

The advice to use C++ goes something like this:
1. Spend ten years learning to write C++ programs.
2. Start writing all the programs that you could have been writing ten years ago using Fortran.

I understand what these C++ developers are going through. If I invested ten years of my life learning nearly 1% of the C++ language, I would be upset to find out that those ten years were wasted. I'd be looking for some way to make it feel as though I didn't flush ten years of my working life down the toilet.

There are better choices. For many things, Fortran is an excellent choice. It even has recursive functions and lets you specify that a function is pure. It's not Lisp but that does offer a bit of comfort to someone like me.

If you like the object oriented side of things, Java has closed the speed gap a lot (not that I like Java, but being a better choice than C++ is a low standard). There's also D and Objective-C. The more I use D the more I like it. You really should have your head examined if you have the choice between D and C++ and you choose C++ because you think it's a better language. There might be a different reason to use C++ (like, you're too stubborn to admit that your favorite language sucks) but it's definitely not the case that C++ is a better language.

There are languages like Scala (I've played with it a little but not done any real work, so I can't say much about it) and Clojure that have access to the JVM. You can do the performance critical parts in Java if necessary.

LuaJIT2 is really fast, and the upcoming GSL Shell will be based on LuaJIT2 (at least that's my understanding). Even the current version of GSL Shell does well for speed. PyPy is constantly improving as well. Both are excellent, if somewhat incomplete, choices.

C++? No way. There might be a few cases in which C++ is the best choice, but given the time investment required to learn C++, that is a very small set. If you factor in the time to learn the language, write/debug your program, revisit the program later to fix bugs/add features, and then compile and run programs, even pure interpreted Ruby is likely to be a better choice.

Update: I just watched an excellent presentation by Herb Sutter:

http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

He definitely makes a strong case for C++. I don't disagree with much of what he said, except that I think he overstates the speed gap for many tasks between C++ and languages like Java, though for the applications he's talking about the difference still matters. Interestingly, for those applications, developer time is almost irrelevant.

He never says C++ has replaced Fortran. In fact, at the beginning of the talk, he specifies that the three languages that can deliver the needed performance are C, C++, and Fortran. Later at that same conference, they talked about D:

http://channel9.msdn.com/posts/Scott-Meyers-Andrei-Alexandrescu-and-Herb-Sutter-C-and-Beyond