I realize that this is going to be considered an abominable statement, especially to UNIX/Linux users and computer engineering types in general, but the fact is any programming language that can't directly and natively handle multidimensional arrays is a pretty silly choice for a scientific programming language. Unfortunately, the only obvious option that can produce lean, fast code is Assembler - which has the drawback that most programmers are unwilling to climb the learning curve. Complaints that code is not readable or reusable are not at all supportable since Microsoft first released the Macro Assembler in the 1980s, but the learning curve (particularly to develop reusable coding practices) complaint is perfectly true.

Portability is a great strength of C++, obviously, making it possible for Windows, Mac, and UNIX/Linux programmers to use the same reference text and code will remarkably little modification between platforms.

Assembler, of course, is the absolutely least portable language ever since it's not inherently OS specific but CPU specific.

But wait!

Aren't all new PCs, Macs, and most UNIX/Linux machines now Intel based? And aren't there in fact commercial and freeware assemblers that will produce platform specific binaries? Well, yes, in fact there are!

I realize I'm not going to convince the authors or in fact the vast majority NR users to consider Assembler seriously, but when a not unreasonable case can be made for Assembler as a portable programming language doesn't that suggest that the portability argument for C++ might not be as rock solid as it is usually assumed to be? And if that's true, aren't there in fact good reasons to consider a more science-friendly programming language for a book on the art of scientific programming?

Anyways, thanks for your time.

Merrick, thanks for your post. Speaking for the NR authors, I think I can confidently say that we will never write a book "Numerical Recipes in Assembler".

I think the living language that is "closest to the machine" these days is C. However, it is not even clear what "close to the machine" even means any more, since memory is hierarchical (invisible to the user) and instructions get re-ordered by the hardware (also invisible to the user), for example.

Merrick is going agains the tide, since computer languages have been going more and more "high level" for almost 50 years. There also has been a tendency to give them lower level control capabilities for sophisticated users. The drift from Fortran towards C, C++, and C## illustrates that, as does the popularity of Matlab and Mathematica. Parallel processing will reinforce these trends.

What does scientific computing really need? Floating point arithmetic of arbitrary precision, supported by both software and hardware, maybe a super-X87 that uses RAM when the need arises. Why? Chaos! While it is true that some problems cannot be solved with floating-point calculations of any precision, there is no number of significant bits that is always enough. Errors in numerical algorithms interact with errors and instabilities in models in very complex ways and a lot of simulations being published today should be viewed with skepticism. E.g., sometimes the failure of various errors to average out can input a significant impulse.

My title may surprise you, but it's true. Well, I'm being a bit misleading but it's on purpose, because we all tend to forget that a well-constructed compiler links library functions for all of its intrinsic functions and all external functions from a 3rd party library. It always comes down to how well the compiler can optimize code and how well the library was written by its designer.

I will not argue that well-written hand-coded assembler can or can't produce superior results in certain situations, however, the vast majority of code that's written for a fully functional application has more to do with i/o and other slow operations. Where is your program spending most of its cpu time? What part of the loop should be optimized? These points are well covered in Numerical Recipes whenever this is relevant.

CPU cache and use of registers for temporary variables has been well thought out in most numerical library code. The science of building optimizing compilers is not new. I don't think we all need to rewrite the libraries from scratch each time we need a new function. Let's let the library designers do it and then use the higher level functions they built for us.

One example in favor of hand-coded assembler is the story behind the Great Internet Mersenne Prime Search at www.mersenne.org. The FFT algorithm used was hand-coded in assembler.

Another example of assembler programming to create MS Windows apps can be seen at Gibson Research, http://www.grc.com/smgassembly.htm, for those interested in Merrick's idea.