1) Is the inherent performance adequate for your forseeable needs?
2) Is the platform stable?
3) Can you find suitable libraries for what you want to do without re-inventing the wheel?
4) Have you addressed relevant portability issues?
5) Are the available development environments suitable for your needs/preferences?
Really, that's about it. Everything else is just kind of annoying dithering. Sure, with real human languages people have a lot of vested interests, plus there are aesthetic concerns. But programming languages have only been around for decades. Do we really need to have a balkanized landscape in the programming language world to mimic that of regular languages in the real world? Apparently so! As for aesthetics, I suppose poetry written in French can never be perfectly translated into English, or Chinese, or Swahili, and so on. But we're talking about computer programs here. The aesthetics should, in my opinion, be limited to expressing things clearly and economically. Computer programming is much more like technical writing than poetry. If there are real aesthetics to it, then I would say any poetry in programming lives in the realm of algorithms, which are language-agnostic anyway. Then there are the endless debates about changes to programming languages. I had an email discussion recently with a fellow about checked exceptions in Java and how terrible they were. My goodness. If you don't like them, then don't use them. It's easy to dispense with them. It's not a problem. Frankly it's a waste of mental energy to discuss things like this. But that's what people are into these days. Endless onanizing with the latest and coolest language features. Should the language be more dynamic? Less dynamic? Can we write our own specialized Domain Specific Languages? Sigh...
Finally there's the methodology cesspool. I have my own views. The problem is that this issue tends to be at the forefront all the time. Is XP good? Are all XP practices good? Is agile a religion or a con? What's the difference between agile and lean? The simple reality is having competent and motivated programmers is good. Having unmotivated and incompetent programmers is bad. If you have competent and motivated programmers, then a really bad methodology may cripple them, but nothing short of the insanity of the CMM stuff is likely to do that.
CMM level 5, denotes complete paralysis. Levels 2 to 4 indicate various intermediate stages where paralysis is spreading, but you can still ship.The norm is simply chaos without any form at all: The hack and fix grind. Outside the realm of complete insanity, there are practices that most reasonable people would agree on: Automated tests for regression and quality; using a revision control system; integrating the tests into the revision control system as part of an automated build; planning and designing in some kind of iterative fashion; communicating - you know, like, talking to one another in some way that doesn't involve exchanging 200 page documents. Cooperation - people involved genuinely wanting to help one another reach the goal.
Ok, you get the idea. Beyond that, it's all about refinement. Don't like pair-programming? Fine. Prefer writing automated tests after you write the code for a particular feature? Well, I disagree, but ok, go for it. Find occasions in which some detailed planning and design is necessary? Hey, do it - just don't lose it and end up in in(s)anity land again.
What's my point? Well, it's that the real problem with programming is that developers aren't competent enough. There is not enough understanding of core programming ideas - either that or there isn't enough self-discipline to appy them: Reduce duplication; encapsulate; reduce coupling; increase cohesion; emphasize clarity; resist the urge to obfuscate; no matter how tempting it might be, choose the plain way to do something rather than the really fancy: Avoid the way that uses some new fangled language feature unless you can demonstrate the plain way is going to be a serious problem.Whatever you do, avoid falling in love with object-oriented design for its own sake (or functional programming for its own sake). You should be able to show how everything you do emphasize clarity and reduces duplication and coupling. At the end of the day, a good program written in Python should look almost identical to the same thing written in Java. What are your objects? What are their functions? How have you removed duplication? It's not a sexy problem. Switching to a new programming language or a new methodology won't help. It's just the slow grind of educating people, educating ourselves, and keeping things as simple as possible.
Think about it.