I always find these debates entertaining to read. Not so much for the intellectual discussion about the pros and cons of the various available languages but because you can usually peg someones stance on the topic based on their job/experience/area of interest. Its right up there with the "premature optimization" arguments were the CS majors and maintenance programmers quote Knuth left and right and those who work in the real world where performance matters think they're all crazy (i'm a member of the later group to be fair).
At the end of the day, you can develop excellent software in C or C++ or insert language here. It comes down to the capabilities of the developer not the language. Being an expert in a language is usually only required if you've chosen the wrong language to begin with and now need to warp it into solving your problem, in most cases these are the only situations where you need to dive into obscure features or compiler tricks to accomplish the goal.
I often hear people start these arguments as "i'm an expert in language X and blah blah" I honestly immediately discredit these people because, in my opinion, they've already approached the problem from the wrong angle and everything after that is tainted by their desire to use their tool to solve the problem and show how 'cool' it is.
I so often watch developers choose a tool set first and attempt to bend it to their problem second, which is completely wrong and results in crap solutions.
As I mentioned in a comment to another answer, these language wars often devolve into arguing that language X allows the programmer to do more dumb things. While entertaining to read, all these statements really mean is that you have a problem hiring good developers and need to address that issue directly rather than trying to band aid the situation by continuing to hire bad developers and choosing tools such that they can do as little damage as possible.
In my opinion good developers, be it software or hardware development, research the problem, architect a solution and find the tools that allow them to express the solution in the 'best way'. It shouldn't matter if the required tool is something you've never used before, after you've used 3-4 languages/development tools for projects picking up a new one should have a minimal impact on your development time.
Of course, 'best way' is a subjective term and also needs to be defined in the research phase. One needs to consider a multitude of issues: performance, ease of expression, code density, etc based on the problem at hand. I didn't include maintainability in that list for a reason, i don't care what language you choose, if you've chosen the proper tool and taken the time to understand the problem this should come 'for free'. Difficult to maintain code is often the result of choosing the wrong tool or a poor system structure, this results in an ugly hacky mess to make it work.
Claiming any language is 'better' than any other is silly without defining a particular problem of interest. An object oriented approach is not always better than a functional approach. There are some problems that lend themselves very well to an object oriented design paradigm. There are many that do not. The same statement can be made about many language features that people seem to enjoy harping on.
If your spending more than 20% of your time on a problem actually typing code, your probably producing a very poor system, or have very poor developers(or your still learning). You should be spending the majority of your time up front diagramming the problem and determining how various pieces of the application interact. Sticking a group of talented developers in a room with a marker board and a problem to solve and telling them they are not allowed to write any code or choose any tools till they feel comfortable with the entire system will do more to improve the quality of the output and speed development than choosing any hot new tool guaranteed to improve development time. (look up scrum development as a reference for the polar opposite to my argument)
Often the unfortunate reality is that many businesses can only measure the value of a developer by the number of lines written, or by seeing 'tangible output'. They view the 3 weeks in a room with a marker board as a loss in productivity. Developers are often forced to speed through the 'thought' stage of development or are forced into using a tool set by some political issue within the company, "my boss's brother works for IBM so we can only use their tools", that kind of rubbish. Or worse, you get a constantly changing set of requirements from the company because they are not capable of doing proper market research or don't understand the impact of changes on the development cycle.
Sorry for being slightly off topic with this rant, I have quite strong opinions on this topic.