5 ms·

> 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 quo

> 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 you are reaching for a powerful tool which can (and in my experience, almost always) impedes ease of code readability and reasoning about behavior. These things are toxic to growing organizations with growing teams. It sounds a reach to misconstrue that the design "includes inducing pain deliberately with the rational that I deserve it" -- it's not that you deserve it, per sé, but you may not be using it for the use case it was intended for. My use cases have spanned decades of experience across dozens of organizations serving billions of dollars of industrial strength pressure. Having used other languages (including Ruby, Java, Go, Scala, Cxx), accounting for tradeoffs between ecosystem maturity and language flexibility, it remains my overall top choice for getting work done and building durable, maintainable codebases.

brudgers 4y ago
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.
- deleted 4y ago
  [deleted]
- yowlingcat 4y ago
  It sounds like we're talking past each other. It appears to me (and I may be wrong here) that for you, writing code is an activity that you partake in for pleasure, or otherwise aesthetic or artistic reasons. For me, while there are elements of writing code that are pleasurable, I predominantly engage in it in a professional setting, to get business goals accomplished. 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.

brudgers 4y ago

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.

deleted 4y ago
[deleted]
yowlingcat 4y ago
It sounds like we're talking past each other. It appears to me (and I may be wrong here) that for you, writing code is an activity that you partake in for pleasure, or otherwise aesthetic or artistic reasons. For me, while there are elements of writing code that are pleasurable, I predominantly engage in it in a professional setting, to get business goals accomplished. 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.