Joel Spolsky, one of the ablest commentors on the industry, recently made the mistake of combining advice and self-promotion without realizing that what he was writing combined "do what I say, not what I do," with a flame-baiting slap at non-mainstream languages. He's been hammered in the blogosphere, but the incident was driven by something commendable: when you walk the walk, sometimes it doesn't accord with the talk you talk.
The original post begins as advice to someone wondering ".NET or J2EE...Which Web Server?...Which language?" and, as part of that final question, mentioned Ruby and Ruby on Rails. Joel's response begins with the observation that lots of people build lots of systems with .NET, Java, and PHP and "none of them are failing because of the choice of technology." That's not a bad answer, given the implicit context of the question. While there's a slight possibility that the questioner is so experienced that they feel they can adopt "the best" solution without stumbling, it's vastly more likely that the question reveals "Neither I nor my team have experience with the mainstream dominant platforms."
Giving a beginner advice that narrows risk -- "Java or .NET" -- is not foolish. There is a vast array of resources for programmers and teams using Java and .NET. There are lots of libraries, lots of tools, lots of books, lots of consultants ready to come in and lend a hand. It's the software development equivalent of the old "no one was ever fired for buying IBM," phrase of the pre-PC era.
Re-reading the post with this perspective shows that this is Joel's main point: ecosystem and personal/team experience. However, instead of emphasizing the "positive space" of the benefits, he attacks the "negative space," and questions whether non-dominant languages are capable of success. This reminds me of the people who, boosting their own language, invariably make some crack about how C/C++ is "hideously complex" and "error-prone," to which a reasonable person thinks "Yet there are one or two successful programs written in these languages; if he exaggerates the difficulties of C/C++, is he not likely to be exaggerating the benefits of X?"
Just this aspect of the post would have been enough to troll up responses, but Joel then reveals that at his company, they use a domain-specific language that's some derivative of Basic, but that's a functional programming language, and it has closures and lambdas and different initialization syntax and it's "only two months work for a talented person who's read the dragon book" and assorted other things impossible-to-reconcile with risk-minimizing advice to beginners. (Closures "and" lambdas? "Functional programming"? As in, non-mutable assignment? Really? Or did Joel slip into hyperbolic mode?) (The "dragon book" reference is another giveaway that Joel's switched gears. This is the book from which my generation learned compiler theory and implementation. I think it's been out of print for a decade and, if I recall correctly, all the code was in hard-core C. There's not a more low-hanging signifier of programming studliness than a well-worn copy on your shelf.)
So Joel set himself up for a comparison of the risk exposure of Ruby versus that of a proprietary functional derivative of Basic with embedded SQL. No matter how good a debater Joel is, he's gonna' lose that fight. William F. Buckley couldn't finesse his way through that argument.
But the bigger issue is this: many, probably most, people who advise others on software development are not in the business of developing software. They're in the business of advising how to develop software, either as architectural consultants who soar blissfully above the details or as trainers who face the same limited range of problems time-and-time again. In the development business, talent manifests in the use of powerful techniques -- domain-specific languages, meta-programming facilities, rolling up your sleeves and writing assembly language, etc. In the advice business, talent manifests as increasing client's productivity while lowering their risk exposure. Joel accidentally crossed these wires, but in general, he's still one of the best on software development advice because he stays so close actual development.