I think much language criticism miss the non-technical context which influences which language is the best tool for the job. We are good at providing technical

I think much language criticism miss the non-technical context which influences which language is the best tool for the job. We are good at providing technical arguments (Erlang is fun if you need concurrency, C is cool if you need to get close to the metal), but there are important non-technical issues. Things like: How many people is on the team who have to work on the code? How big is the turnover among the developers? How experienced are they? How long is the code going to live? Will some people have to jump in and fix bugs in the code on short notice? For example, I have noticed that I prefer a nice clean dynamic language like Python when I know I am only person on the project. But in cases where I had to work on and improve code of a dubious quality, I much prefer it to be in C#, since type analysis makes it a lot easier to figure things out and refactoring in a safer way. To put it another way: I like to work with nice clean code in Python or Haskell, but when I have to work with bad code, I prefer to work with bad C# code.