Someones going to like you... His jaw is... made of metal?

[off-topic]clue : [attach]

I read through this thread once last night, and bit my tongue, saying I'll look at it fresh in the morning. I'm back, and I'm sorry to say that I'm still infuriated.

Why in the world would someone other than the developer want to choose the language that an application is developed in? You admit yourself that you're not the expert. But even I, an expert proficient in more languages (and language families, for that matter) than I can even count anymore, wouldn't make this decision at the beginning of the project.

Do you buy software based on the language that it was coded in? I know that there are some open-source zealots who do this, but they're insane. The fact is, an application does its job or it doesn't. That's what you make the buying decision based on.

Let the developers do the analysis and high-level design first, and then let them make the decision. 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; understand well both the language chosen and the problem they're trying to help the user solve; and sufficient resources (time, tools) to complete the project.

I understand that you're looking to sponsor a project, and want to ensure that it's successful, but this is not the way to do it. You may actually be undermining its success.

It's true that some languages are better at some things than others, but there are many more factors than that oversimplification -- and they're generally more important.

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.

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. This isn't so hypothetical. Every time you find yourself frustrated with an application, it's because the developers failed in building an application that anticipated your needs. If you force developers into the wrong tool, you're diverting resources away from preventing these problems, and into the minutiae of coding.

And you've got to consider the skills of the individual developers. The failure of the Chandler project has been discussed here recently. Many observers believe that part of its problems were that an executive decision had been made to use the Python language. But most of the developers didn't have the experience to "think" in Python, and instead wrote Java code in Python (if you can see what I mean). This means that the project got the worst of both worlds: they weren't able to leverage Python's strengths, but they retained all of the limitations of the Java platform.

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;

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.

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.

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.

now, allow me to pose a question: is it truly so rare and undignified to propose a language beforehand? I have seen it as the standard procedure on sites like getacoder/rentacoder/odesk, etc.

No it's not. In most cases, professional coders will produce a substantial amount of documentation before making any decisions about their project, however hobbyists/managers/newbies need not concern themselves with such things.
To me your justification is well defined for a project that has not yet commenced, though do keep in mind some of your thought processes may change once you get a taste.

Ehtyar.

DC member by the name of tinjaw is a python enthusiast here on the forum.

Thread revival... just for fun!

I found this neat little tool:

http://www.awaretek.com/atesterea.html
...
The result is

1. C/C++
2. Java
3. Python

Fun find!

"power and expressiveness" would be a measure of how powerful and flexible the language is and how easy it is to represent different data structures and concepts.

Real fun!  Take a look at the score I was given...



I couldn't stop laughing !  I can hardly spell, "C."