But even in such cases, there is often no unambiguous X is better than Y argument, because the question isn't exactly clear (There are many dimensions to this.

But even in such cases, there is often no unambiguous X is better than Y argument, because the question isn't exactly clear (There are many dimensions to this. How large is the project, which people are available to work on it, what is the maintainance schedule, which players are involved and will have to look at it, what kind of things do you intend to do, and do you envision hiring people in the future who will work on this?). These then add the a bunch of possibly conflicting dimensions to the right answer, and many of these can be better for X than for Y, even if Y is, from a language design standpoint, 'unambiguously better': * Dev stacks * # of developers you have or can reliably hire for it * The general 'vibe' of the community. Some amazing languages have communities that are nasty, or tend to like overly verbose catering-to-ridiculous-generality libraries, just have way too many conflicting libraries for the same thing, don't have ANY libraries, prefer writing academic 'look at how fancy I can make this code look!' over just getting things done, and so many more unfortunate habits. A great many things that need doing are so simple, the benefit of a strictly better designed language often just don't weigh up to burdening yourself with the nasty habits of the community. You can try and go against the community, but now every time you search, the examples won't 'feel' right, most libraries will clash with your programming styles, when hiring new folks you need to retrain them significantly, and so on and so forth. Even PHP has benefits. I admit the language is badly designed, extremely inconsistent, dev tooling sucks and the language by design isn't helping in that department either, and the community has an unbelievably nasty habit of mixing up a complete disdain and cluelessness about even basic security and a love of 'hey, it works for me' mentality. But.. PHP's deploy stack is easy to understand, very widespread, the model pretty much forces you into writing your apps in a way that throwing money at the problem will pretty often work to solve scaling issues, there are a bajillion examples out there, programmers are easy to find, and that 'hey it works for me' attitude can actually come in handy if you're developing in-house. I love to get on my high horse and shout trite things such as '... but PHP rots the brains of your programmers!', and I do, but if I have to be perfectly honest, I can foresee scenarios where it makes sense for a company to go with PHP. And, hey, if PHP can sometimes be the right answer, clearly there is no room for the concept of 'X is unambiguously better than Y'.