I'm certain that on any modern hardware, any reasonable choice of programming language will provide a responsive user interface -- assuming that the developers are competent on the platform;-CWuestefeld
I personally find that most JAVA applications have somewhat sloppy user interfaces, even on fast CPUs... but I'm
very sensitive to issues like that, most users might not be bothered by that.
It's an oversimplification because modern compilers and JITters (e.g., the .Net CLI and Java) are very smart. It's common now for high-level languages to demonstrate higher performance than hand-coded assembler or C.-CWuestefeld
I still haven't seen this in practice. Theoretically, JITers with hotspot recognition and profiling could do
very well, but they'll still be following heuristics - and statically compiled languages also have profilers available (just how often does varying data input
massively change hotspots?).
The reality is, however, that for 99% of the software out there, you aren't going to be very CPU bound, so it doesn't matter much if you're coding in Ruby, C++, VB or Assembly. And for the serious number crunching, on x86 anyway, there's still nothing that beats hand-tuned assembly... especially when you have the chance to use SSE instructions. Compiler intrinsics, unfortunately, suck.
But also, allowing developers to use higher-level abstractions frees them to address the overall architecture more fully. Even if you could code something in C++ that would be 5x faster, if there were an alternative approach that only needs to execute 10% as often, that alternative would be better.-CWuestefeld
And what would stop you from doing this approach in C++?
Stuff like garbage collection can have benefits, but you can gain some benefits through the use of RAII and smart pointers, it's possible to do full garbage collection if you really want to, and for speed-critical stuff you can do pool allocators. You get
choice instead of being forced to use GC, which you might not have much control over. True, this requires more work than automagic GC, but you can tune to your needs.
But again, for most software, you don't
need this kind of control and fine-tuning, and it requires decent experienced coders to get substantial improvement over some of the JITed languages.
dotNET and JAVA do take their toll on the system, though - it takes quite a while to load the runtimes from a cold boot, and not everybody keeps their systems on 24/7.
Anyway, I agree with a lot of your points, I just had to bicker a bit
. And I fully agree that the developers should choose the language after doing project analysis... although they should probably be constrained to open platforms since this is going to be an opensource project.
