>No, it entirely depends on the skill and experience level of the programmer. We're comparing programming languages. You control for the other variables - othe

>No, it entirely depends on the skill and experience level of the programmer. We're comparing programming languages. You control for the other variables - otherwise the comparison is meaningless. My argument is equally skilled programmers will generally be more productive in Python than C++. >No, a good programmer with equally good knowledge of both languages will code equally fast in both. Care to explain how? Huge amounts of the features in these higher level languages are explicitly to increase productivity, and it's generally pretty well accepted they're successful. In this very comment section there's multiple sets of people talking about having to implement their own reference counting systems, and all sorts of other things. Implementing those systems takes up productivity. If any one language was the best at everything, we would only have one language. There's trade offs made, and that's why there frequently is a right language (or set of languages) for one job vs. another. >You failed to see the point. Large teams of clueless programmers doing things slowly and badly is a feature of the system, not a bug. KPI's for managers don't include lowering headcount and cost cutting as an incentive. (And trust me, you really wouldn't like it if they did.) This simply hasn't been the case anywhere I've worked at for a meaningful amount of time. Empire building was plenty discouraged at all of the places I have been employed long term and there were KPIs for reducing headcount, or maintaining it while taking on additional responsibility, and accounting was always happy to step in if costs were increasing without solid justification. Reducing headcount doesn't even have to mean firing people or managing them out - it can be not backfilling spots, helping people find teams with open headcount and transferring, etc. It's never bothered me any - if we have too many people for the amount of work, I'm more likely to get bored. >Yet that's effectively what you just did in your specious 'productivity' argument. You started this whole tangential discussion by taking shots at Python developers for no apparent reason. I'm not calling anyone names, or anything even remotely similar - different languages are frequently differently suited. There's obviously places where C++ makes a lot of sense. I don't really have a horse in this race - right this moment, I'd do basically any serious project in rust, and cargo-script has me even doing small scripts in rust as well. Maybe Erlang or Elixir if OTP makes a lot of sense for the project.