The technology that "gets the job done" isn't fine if your competitors get it done in half the time, or it's easier to add features, or it's supported on more platforms, and so on

Bah! That's just semantics. Of course you have to meaningfully define "job"... If the "job" entails beating your competitors to market, then so be it. If the "job" entails making feature creep easy, then so be it. If the job entails portability, then so be it. And whatever technology gets the "job" done is just fine.

These things can all be objectively analyzed, it just takes a very large amount of effort, time, and expertise.

Bah again! No one is arguing that you should pick the tools you use arbitrarily. But, in the real world, after all that "objective" analysis, it comes down to educated guesswork; and you won't know whether you guessed right until the job is either done or it isn't. In fact, the speed with which a choice is made is often more important than the choice itself. While you are expending all that "effort", taking all that "time", and paying for all that "expertise", your competitor is getting it done in half the time. And by the time you get to market, he's already covered his investment... which was only half yours to begin with. Sure, your product is better (maybe) but no one is using it and your profitable competitor is sinking tons of cash into his marketing campaign to make sure it stays that way.

This is why you won't see many good comparisons posted online - they take a lot of effort, a wide area of expertise, become out of date quickly, and there's very, very little positive feedback for these things (read: you'll piss a lot of people off).

Since when did the risk of pissing someone off become a barrier to web publishing? In fact, there are some good comparisons online. And they do piss people off, which is only an indicator of the real reason there aren't more good comparisons online. That is, people don't need comparisons because they already have their minds made up.¹ For instance, I'm not going to bother wasting a lot of "effort, time, and expertise" the next time I'm faced with choosing between Java and Perl. I'm just going to pick Perl. I'm more comfortable with it and I believe it is the better language whether I'm right or not. On the other hand, I might choose C for a project over Perl because I'm comfortable with it as well and I believe it is better for some things. That choice would be made from experience though; I wouldn't be doing additional research.

Note that I'm not saying research is never necessary. What I am saying is that you can research and analyze your findings for the next ten quarters and you will never get a definitive answer that this language is better than that one. All you'll get is a slightly better educated guess. The good news is that after the project is done, your next guess is likely to be much better than could ever be accounted for by research.

1. Generally they make their minds up in one of two ways. Either they learn through experience or they make a choice based on marketing material. Imagine how the world would be if Perl had the marketing support that Java does...

-sauoq
"My two cents aren't worth a dime.";

I'll just reply to the first part, everything else seems to be along the same lines.

And whatever technology gets the "job" done is just fine.

The problem is only partially defining "the job." The other part is defining "done." It's not a black and white issue. Every minute counts, every lines of code counts, every supported system counts, every microsecond of execution time and bit of memory counts. The statement seems to imply that two languages can be equal for a task - they cannot.

Keep in mind that you and your staff's knowledge of a language is a major factor in the decision. If you already know one language, and don't know the other major alternatives you would have to spend time learning them sufficiently to evaluate them, then learning them to a satisfactory level to complete the project. This all takes a lot of time, sometimes more than the project would take, so your compulsion to use Perl may make perfect sense in the vast majority of cases. Standardizing on one language does have many benefits.

Now it seems we are in agreement. A couple of clarifications...

The problem is only partially defining "the job." The other part is defining "done."

If you are having a hard time defining "done" that's probably because the job in question is a proverbial "job that's never done" or it was poorly defined in the first place.

The statement seems to imply that two languages can be equal for a task - they cannot.

I didn't mean to imply that. But the choice should not be made through "objective analysis" of the languages alone. The decision should be made within the context of the "job" that must be "done".

To bring this full circle and back to the original questions posed by pg, it comes down to this: if someone tells you that you picked the wrong language without being intimately familiar with the "job" you picked it for, he is talking out his ass even if he can argue the technical advantages and defend the disadvantages of his language of choice better than you can yours.

-sauoq
"My two cents aren't worth a dime.";