[rmcclellan]

I think the point he was trying to make is that a good language allows a library to be a "domain specific embedded language", in which an expert in some domain who is not an expert in the host language can do meaningful work. The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.

[jedbrown]

The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.

And it either (a) creates and destroys many intermediate structures or (b) templates everything by exposing the entire implementation to the user, resulting in slow compilation time and error messages that the domain expert couldn't hope to decipher.

[mattgreenrocks]

It's almost as if everything has tradeoffs, and engineers have to make them consciously!

Optimize when necessary. Until then, no need to mutilate expressiveness if the language allows it.

[rmcclellan]

Yeah, I'm not a big fan of C++, really. That said, (a) is mostly solved in 11 with rvalue references, isn't it?

[cdavid]

I think the matrix example is particularly unflattering, and highlights the fundamental issues with the language. For once, there is no agreed-upon matrix library in C++, but many different ones. They are only "compatible" at a very low-level (a contiguous memory buffer), and the promises of performances often broken. The only one I know of that has been delivering on the performance front is eigen3, but I think the difficulty of the approach to become slightly ridiculous. When you need some "dynamic" optimization as done by eigen, C++ and templates are rather crude tools IMO.