I fail to see the down-side.
The downside is that at some point someone I'm working with is going to think it's a bright idea to use some god awful C++ code on the GPU which pulls far more resources than it should and makes my life as a rendering programmer harder because I'll either have to a) get them to change it (ahahahaha, most people write bad CPU C++, good luck getting them to write good GPU code) or b) do it myself/have some other renderer/some one versed in this style of code do it.
This costs time, resources and money.
C++ allows very low-level access, and also has higher-level constructs that are very easy to abuse, leading to poor performance. What's the down-side to this? Someone who isn't "performance-aware" doesn't end up with an application with high performance. This is as it should be, is it not?
Similarly with C++ on a shader. Someone who doesn't know how to get performance out of the language simply won't. Why does it bother you guys if others have performance-poor applications? Maybe they don't need the performance.
I 'care' because a) poor code running on my machine costs me money directly (more run time = draw more power = cost more money) and b) I want other devs to produce good stuff or I wouldn't be on gd.net helping out.
At the same time I don't care because if you want to write code which murders the GPUs performance than feel free. Of course the moment people can do that and they start turning up here unable to understand why their virtual infested C++ code running on the GPU runs poorly, well assuming I can stop screaming at the code I reserve the right to tell them to educate themselves about the hardware and why what they have done is a bad idea.
What you're saying is tantamount to saying, "Keep the interpreted languages off the CPU!" Why, because they aren't performance-friendly? Why should anyone care aside from the person who chose to use the interpreted language for his own reasons?
No, what I am saying is 'use the right tool for the job' and 'learn how to use those tools correctly'.
Firstly, I said that in some cases the loss of performance could be offset by ease of production so I have said there is an upside (I'm assuming you did read that paragraph?). Secondly I went on to say that I hope education will get pushed out to stop people using it wrong.
This is the same as using Lua for game play parts and hoping to hell someone doesn't decide to use it in the middle of their high performance rendering loop of a game.
Should automatic transmissions not exist? Racecar drivers, who are performance-aware, demand manual transmissions. They don't seem to care, however, that others choose automatics. Why should they?
Poor example is poor.
For starters they will be using the right tool for the job or as required by the specs fo their sport. For example I'm willing to bet that a semi-automatic paddle gear box where they indicate the direction of change but a computer performs the clutch-shift process is going to be far better than a fully manual system. As for others, well an automatic is the right tool for the job for some people, for others it isn't, same thing here.
Why not simply choose to write your own performance-aware C++ on the shader (or not use C++ at all) and let others do what they want?
I wasn't aware I was some authority from on high who could forbid people do what they want?
You ask why people felt this way and I gave you a run down of the problems from a game programming point of view, with some evidence to back it up based on current SPU misuse and my experiance with others writing code on a general CPU.
End of the day I think it's a bad idea in many cases, although I did also conceed there is some good for certain cases as well.
I hope that as and when this hits the console market that tech leads on teams will be sharp enough to say people can't use this until their use case has been cleared and even then are only given a subset of the language (depending on what the GPU can do hardware wise). I say this not so much becase as a rendering programmer I fear for my GPU cycles, I say this because I've seen the state of code people write today in C++ with no thought to the underlaying hardware and the performance problems this causes and for games this IS important stuff.
An example as an aside; some code was written to render vehicles before I joined the current company. I guess it had started of general and then people added 'if' statements to specialise it. Upon profiling on the PS3 this was frankly a nightmare; cache misses and branch stalls all over the damned place. I took 8h to rewrite it and the loader to enforce some assumptions and took 30% off the run time (0.5ms real time) and also made the code easier to follow by removing all the branches and reordering the loops so they were sane.
This is what I mean about 'coding sins' and being unaware of the target hardware. I dare say if I looked else where in the code I could find other instance of pointer chasing and reloading which also would have hurt performance like crazy.
I'm not trying to say that every piece of code should extract the most from the hardware but at the same time the lack of knowledge is damning at times; it's not even that performance code needs to be complicated either as my rewrite showed by making it easier to follow.