If a program needs to be up and running yesterday, then the fact that it's not as fast as C/C++ may not actually matter.
I think this issue should be mentioned more often in discussions of execution speed -- the time required to write the code in the first place. For that, Python excels.
- programmer productivity
- hardware costs
- ease of maintenance
- barrier of entry
- interop with other software
How easy will it be to maintain the software in ten years? Wrt to Python, it's a fantastic language, but I've become scared of large codebases in dynamic languages.
Fair enough. It seems to me that if an application has high performance demands and is expected to be in service for years, it should eventually be rewritten in a faster language. I find myself designing/developing programs in Python because development is so fast, then rewriting the result in a faster language after the design phase is over.
The rewriting phase is basically a translation, not a redesign. In most cases I know exactly how the program should behave, so there's no design taking place.
The system serves a massive number of users in real time, so I don't think that the speed is necessarily an issue. Of course, it can be different in other cases...
But all in all, it's more the safety you get from static typing I'm interested in than a pure speed boost. Though pylint is not too bad, it's still not the same.
Yes, you are absolutely right that this is a very valid metric to use when dealing with development. I'm not sure that it is not discussed, though. Usually people talks about "language productivity"
And yes, Python exceeds at that ;-)