I agree, the compile times are my mine problem with C++ right now, and they are not getting better.
If you listen to the C++ advocates, they all say use the STL as much as possible, use boost if there is solution for your problem there, etc.. It's true, you probably will quickly get a solution that works and looks pretty, but if you do this a hundred or a thousand times your code suddenly needs several hours to compile.
I am not against the STL, or boost, but there is a cost associated with using them that is often ignored, but IMHO is actually a productivity killer in codebases that are a bit bigger.
I never realized that Zuse is unknown in the US. I am Austrian and I am pretty sure I have learned about Zuse in school.
I assume the situation in Germany is similar.
Now I am curious what people from other countries were taught.
Did you learn anything about Zuse?
He listed some of the downsides of the OpenGL approach to shaders, but he forgot to address the (IMHO) really big advantage:
You can use OpenGL in every programming language that is able to call C functions, which is basically every programming language.
Somebody in this thread mentioned CUDA, which is great, but it also has the downside that you practically have to use C++ on the CPU side.
You also can use e.g. python, but when you do you are back to compiling CUDA code at runtime.
Sure, you could argue that we can simply create a new programming language for applications that use the graphics card (Or use C++ like CUDA).
The problem with this is that few people would use it just because its a bit easier to do CPU-GPU communication.
An there is a second much larger problem:
Different graphics API vendors would create different programming languages which makes it much harder for a application to support multiple graphics API as a lot of games do today with DirectX and OpenGL.
Perhaps there is another better solution, but I can't see it right now.
If you listen to the C++ advocates, they all say use the STL as much as possible, use boost if there is solution for your problem there, etc.. It's true, you probably will quickly get a solution that works and looks pretty, but if you do this a hundred or a thousand times your code suddenly needs several hours to compile.
I am not against the STL, or boost, but there is a cost associated with using them that is often ignored, but IMHO is actually a productivity killer in codebases that are a bit bigger.