Language for the ages

Jules> Or better still, do both. I think that often gets lost by Jules> programmers - that in nearly all cases it's possible to write Jules> highly efficient code that's also simple to understand. Jules> Mind you, I always gauge efficiency in terms of what the Jules> compiler turns out. I'm not a fan of the "efficiency" allowed Jules> in some languages (C being one of the biggest culprits!) which Jules> reduce the amount of typing but result in ten possible ways Jules> for the programmer to write the same thing - which ultimately Jules> gets compiled to the exact same binary anyway! Excellent point. Many of the bizarre syntactic hacks in C (like foo++ or foo += bar) exist only because it allowed a primitive non-optimizing compiler to generate tolerably decent PDP-11 machine code. Then again, it's important to remember that no compiler can ever do as good a job as a skilled programmer taking advantage of *all* the relevant information for a particular problem. The reason is that there are always a number of bits of information that cannot be expressed in the programming language. Cases where this matters are not common, and don't appear at all in many applications, but they do appear in some. For example, the very simple problem statement "compute the byte by byte XOR across a set of input buffers and return that to the output buffer" (which is what RAID-5 storage arrays have to do very efficiently) has to be done in assembly language. You may be able to express "and by the way, the buffers are aligned to 512 byte boundaries and don't overlap" (in GCC at least, by using GCC-specific extensions) but no C compiler that I know of will let you express "and by the way, assume that none of the input buffers is currently in the processor cache, and furthermore assume that I don't care they are in the cache afterwards". paul