4 ms·

To me the last sentence nullifies the entire argument. People doing a lot of numeric computations aren't (typically) doing it all in Python. They write critical

by jakear 9y ago

To me the last sentence nullifies the entire argument. People doing a lot of numeric computations aren't (typically) doing it all in Python. They write critical sections in C (or some other "fast" language), or use existing libraries that already have done so. If they aren't writing those sections in C already, perhaps because they don't know how, or it would take too long to do right, then why would they ever choose to do the whole thing in C?

Chris2048 9y ago
Maybe C-devs are easier to find than Python devs with competence in C?
apendleton 9y ago
Firstly, not everyone doing performance-sensitive work is doing numeric work (that seems to have been a motivator for writing this article), so numpy isn't always practical. Secondly, I think the "if it's slow just rewrite the hard parts in C" is generally out of step with more modern options. Python gets you a really nice environment that's super pleasant to work with... until suddenly it doesn't and you're backed into a performance corner, and then you potentially need to conquer a major learning curve, take a huge usability hit, sacrifice memory safety, etc. There are increasingly common options now that let you get near-C performance for many applications while also totally avoiding that cliff. For applications that have even a decent chance of eventually needing that kind of work, I think it's reasonable to ask why you'd want to chance it when you could just write it in something both reasonably fast and much more pleasant than C from the get-go.
- dragonwriter 9y ago
  > Secondly, I think the "if it's slow just rewrite the hard parts in C" is generally out of step with more modern options. Right, including modern options like “use Cython”, which opens up C-like power and performance within the Python ecosystem and while maintaining Python ergonomics (because Cython is both a Python language superset and had tooling integrated with Python's distutils, etc., tooling.)

by jakear 9y ago

Chris2048 9y ago

Maybe C-devs are easier to find than Python devs with competence in C?

apendleton 9y ago

Firstly, not everyone doing performance-sensitive work is doing numeric work (that seems to have been a motivator for writing this article), so numpy isn't always practical. Secondly, I think the "if it's slow just rewrite the hard parts in C" is generally out of step with more modern options. Python gets you a really nice environment that's super pleasant to work with... until suddenly it doesn't and you're backed into a performance corner, and then you potentially need to conquer a major learning curve, take a huge usability hit, sacrifice memory safety, etc. There are increasingly common options now that let you get near-C performance for many applications while also totally avoiding that cliff. For applications that have even a decent chance of eventually needing that kind of work, I think it's reasonable to ask why you'd want to chance it when you could just write it in something both reasonably fast and much more pleasant than C from the get-go.

dragonwriter 9y ago
> Secondly, I think the "if it's slow just rewrite the hard parts in C" is generally out of step with more modern options. Right, including modern options like “use Cython”, which opens up C-like power and performance within the Python ecosystem and while maintaining Python ergonomics (because Cython is both a Python language superset and had tooling integrated with Python's distutils, etc., tooling.)