Earlier quoted context omitted.
> I chalk that up to the higher pain threshold for doing really obnoxious metaprogramming in Python If you're going to quote it, don't you think you should quote the whole thing? The whole point of making the pain threshold higher for certain kinds of metaprogramming painful and obvious. I think that is a good thing. You can use it when you need to, but when it comes up in a code review, it's extremely obvious that y…
The important thing for me is that the pain is by design. That someone thinks it’s good for me doesn’t justify the deliberate application of pain to me. I don’t mind that “it works on your machine.” My distaste for Python’s philosophy is my distaste. I simply think my life is richer without aspirations to be Pythonic. And now I can put my finger on why. Thanks.
In the former case, I think that having a "distaste for it[Python]'s philosophy" where one's life is "richer without aspirations to be Pythonic" is pretty reasonable.
In the latter case, there isn't as much room for that. Instead, the more practical considerations I mentioned predominate: the question is how to get the most mileage out of language in a large organization to accomplish large, complex business goals with technology in a durable way.
It's not to say that one or the other is more important (I think there is plenty of space in this world for both), but I would say that the vast majority of ecosystem space around programming languages is and very likely always will be taken up by the latter use case. If you're curious about why things are the way they are (which you may not be, or which you may simply not care about, or which may simply not apply to you), then I think it's worth considering.