3 ms·

Agreed. I've spent a whole lot of time hopelessly optimizing Python so that it ran only 10% the speed of a naive Go implementation (and naturally the Python ver

Agreed. I've spent a whole lot of time hopelessly optimizing Python so that it ran only 10% the speed of a naive Go implementation (and naturally the Python version was less maintainable as it was a mess of numpy and multiprocessing). Similarly, when I write Python, I spend a lot of time trying to get accurate type information (I've never worked in a project that actually used mypy, so type annotations could be missing or incorrect). I'm sure dynamic languages were more productive than 90s-era Java, C, and C++, but I don't think those productivity claims hold today.

robertlagrant 5y ago
Please sir don't blame Python for a PhD's NumPY mess.
- emteycz 5y ago
  Well a naive Python solution would be much slower than the Numpy one, so...
  - throwaway894345 5y ago
    Sometimes this is true, and the parent's criticism is certainly unhelpful. That said, I've definitely seen people try to optimize with numpy and end up with something that's even slower (Numpy isn't a substitute for mechanical sympathy, but it's often treated as magic dust by the Python community). Basically Python performance is just a hot mess all around. :(
    - robertlagrant 5y ago
      I guess I'm the OP. Sorry my comment didn't help you; please let me know what you need.
      - deleted 5y ago
        [deleted]
    - DeathArrow 5y ago
      >Basically Python performance is just a hot mess all around. Maybe don't use Python where performance matters? Just a thought.
      - throwaway894345 5y ago
        That's the right answer, but it's not helpful for people who don't get to make the call on what language to use. Moreover, a lot of people don't think an application will have a performance problem until suddenly it does (either because of scale or shifting requirements or whatever). Even worse, a whole lot of people simplistically believe that you can just throw C/multiprocessing/numpy at any Python performance problem, which is how you make Python even slower and less maintainable.
- throwaway894345 5y ago
  I'm no great fan of Numpy, but other Python performance solutions aren't more maintainable. :(

robertlagrant 5y ago

Please sir don't blame Python for a PhD's NumPY mess.

emteycz 5y ago
Well a naive Python solution would be much slower than the Numpy one, so...
- throwaway894345 5y ago
  Sometimes this is true, and the parent's criticism is certainly unhelpful. That said, I've definitely seen people try to optimize with numpy and end up with something that's even slower (Numpy isn't a substitute for mechanical sympathy, but it's often treated as magic dust by the Python community). Basically Python performance is just a hot mess all around. :(
  - robertlagrant 5y ago
    I guess I'm the OP. Sorry my comment didn't help you; please let me know what you need.
    - deleted 5y ago
      [deleted]
  - DeathArrow 5y ago
    >Basically Python performance is just a hot mess all around. Maybe don't use Python where performance matters? Just a thought.
    - throwaway894345 5y ago
      That's the right answer, but it's not helpful for people who don't get to make the call on what language to use. Moreover, a lot of people don't think an application will have a performance problem until suddenly it does (either because of scale or shifting requirements or whatever). Even worse, a whole lot of people simplistically believe that you can just throw C/multiprocessing/numpy at any Python performance problem, which is how you make Python even slower and less maintainable.
throwaway894345 5y ago
I'm no great fan of Numpy, but other Python performance solutions aren't more maintainable. :(