John J., just this one because it immediately caught my eye:
"..the speed difference between an IDENTICAL C++ and Python program.."
Writing an IDENTICAL program in Python and C++ already implies that you a) did not take real advantage of either programming language and therefor b) wrote extremely poor code. You can solve one and the same problem in both languages, but to optimally solve it in each language, you would have to write two completely different programs. Therefor, you just cannot compare an identical implementation; one language would automatically lose.
Why do so many programs converted to Python just suck at their performance? Because they are no real Python programs, but programs written by Java or C++ or whatever-language programmers who still think in their old language. With a highly dynamic language like Python, that simply won't work (well).
On the other hand, if you'd program in C++ like you would program in Python (provided that you implemented your own dynamic runtime that works similar to what Python does), you would soon discover that C++ wouldn't be one bit faster than Python is. Probably slower, because your code wouldn't be as mature and optimized as the Python interpreter.
You cannot treat all languages in the same way. You need to adjust your coding style to the philosphy and the features of the language that you are using when you want to write optimal code.
If you'd ask a very good C++ programmer and a very good Python programmer to solve the same issue, you would discover that the Python programmer would be ready MUCH sooner than the C++ programmer (and therefor be MUCH cheaper) and you would also discover that his program would be more than fast enough for every user out there. Naturally, you have stay in domains that both languages can technically solve; nobody would write a 3D engine Python, but obviously Python is used in robotics, the "one laptop per child" project and also as a scripting language in Civilization IV.
For most applications, the highest possible performance just does not matter at all. And FlameDuck was right: It -is- cheaper to spend a few more bucks on a fast workstation or server than pay the programmers to make the software faster. I don't think he was talking about games here, but probably rather about enterprise grade software.
Another important issue is readability and maintainability of code, especially when we are talking about software that will be used for a couple of decades, like most enterprise software: What do you think how readable your optimized C++ code will be for a new developer in 20 years from now? Even the most verbose C++ code is not half as readable as ANY Python or COBOL code.
Concerning the bugs: Most C++ bugs actually come from memory management problems. Does buffer overflow ring a bell and the myriad of security problems in Windows and web browsers resulting from exactly those memory management problems?
Anyway. The reality out there is that it usually is cheaper to just aim for a faster target system than to pay the programmers to profile their code. Memory and CPU cycles are cheap, man hours aren't.
"..the speed difference between an IDENTICAL C++ and Python program.."
Writing an IDENTICAL program in Python and C++ already implies that you a) did not take real advantage of either programming language and therefor b) wrote extremely poor code. You can solve one and the same problem in both languages, but to optimally solve it in each language, you would have to write two completely different programs. Therefor, you just cannot compare an identical implementation; one language would automatically lose.
Why do so many programs converted to Python just suck at their performance? Because they are no real Python programs, but programs written by Java or C++ or whatever-language programmers who still think in their old language. With a highly dynamic language like Python, that simply won't work (well).
On the other hand, if you'd program in C++ like you would program in Python (provided that you implemented your own dynamic runtime that works similar to what Python does), you would soon discover that C++ wouldn't be one bit faster than Python is. Probably slower, because your code wouldn't be as mature and optimized as the Python interpreter.
You cannot treat all languages in the same way. You need to adjust your coding style to the philosphy and the features of the language that you are using when you want to write optimal code.
If you'd ask a very good C++ programmer and a very good Python programmer to solve the same issue, you would discover that the Python programmer would be ready MUCH sooner than the C++ programmer (and therefor be MUCH cheaper) and you would also discover that his program would be more than fast enough for every user out there. Naturally, you have stay in domains that both languages can technically solve; nobody would write a 3D engine Python, but obviously Python is used in robotics, the "one laptop per child" project and also as a scripting language in Civilization IV.
For most applications, the highest possible performance just does not matter at all. And FlameDuck was right: It -is- cheaper to spend a few more bucks on a fast workstation or server than pay the programmers to make the software faster. I don't think he was talking about games here, but probably rather about enterprise grade software.
Another important issue is readability and maintainability of code, especially when we are talking about software that will be used for a couple of decades, like most enterprise software: What do you think how readable your optimized C++ code will be for a new developer in 20 years from now? Even the most verbose C++ code is not half as readable as ANY Python or COBOL code.
Concerning the bugs: Most C++ bugs actually come from memory management problems. Does buffer overflow ring a bell and the myriad of security problems in Windows and web browsers resulting from exactly those memory management problems?
Anyway. The reality out there is that it usually is cheaper to just aim for a faster target system than to pay the programmers to profile their code. Memory and CPU cycles are cheap, man hours aren't.