Aaargh! C++ drives me round the bend (again)

I'm mentally exhausted, and I blame C++. I've spent a good chunk of my work time and mental energy for the last couple of weeks trying to rewrite the CLHEP physics vectors, matrices and Lorentz boosts, and it seems like I've been fighting the language every step of the way. Here's a selection of the C++ joys I've encountered:

• since my vectors and matrices are templated, I have to put the code in header files (cos that's the mark of a really good generics implementation). And so I have to recompile every class in the package every time I make a minor change to the vectors. * it's nice/good practice to have vector and matrix functions defined as external functions and implement the class methods in terms of them - hence I need a vast selection of fiddly, templated forward declarations and friend statements before every class. * I also want to use templated constructors, but C++ templates are so dumb that I have to go through some "traits" nonsense to stop my Matrix<N> operator<< from thinking that it should try to copy construct itself as a four-vector. * Since this is just about the most canonical application where operator overloading is relevant rather than just syntactic sugar, I need to implement the whole slew of operator<, operator==, operator+, operator*=... even though each group of four or so of these things is really just derived from one operation.

The really painful thing is that I'm aware of the D language and I know that it solves all of these problems. In fact, C++ is the only OO language that I might use which has all of these wrinkles, but I really have no choice: this painful procedure has to be done in C++, because that's the language that the HEP community has decided upon. We might as well have decided to poke ourselves in the eye once every 5 minutes for the next ten years.

I know that I'll keep painfully grinding along for the duration of this mini-project until I've got what I think will be the nicest set of physics vector classes on the market, which will be some consolation. But in the back of my mind, I'll be trying to work out how our community can possibly steer itself (or be steered) towards a more modern, less masochistic language. Usually, the people who make the decisions are the ones who don't write the code: as a very code- centric, and generally computing-aware physicist, I want to know if there is any way that I can change things, in at least this one case.

While I really like the look of D, I'm not sure it offers much, if anything, over Java: but the elimination of a VM and hence the overhyped stigma of slowness might be the psychological kick up the arse needed by our community. Yes, I know about native Java compilation with gcj; yes, I know that the benchmarks for Java's speed really aren't that bad; and yes, I don't think physicists can be convinced that it's fast enough. The language shootout results for D vs. Java and D vs C++ are of interest here and any HEPers with an interest in improving analysis frameworks and simulation code should have a look. Since I think this, and a few other selected aspects of HEP computing are worth a longer discussion, I promise (threaten?) to return to the breach when I'm a bit less knackered.

But why leave on a negative note? Get a load of the work Sergei has been doing on his brilliant jHepWork Java analysis framework. Given that one guy, in a year, has produced a more compelling package than 15 years of C++ development on ROOT, I think it can be safely said that the language argument is more substantial than just syntactic sugar. If only it had a catchier name...