3 ms·

> and are very fast and reliable. Among the most popular languages is Python. It is popular in spite of its bad performance, high memory use, and lack of CPU m

> and are very fast and reliable. Among the most popular languages is Python. It is popular in spite of its bad performance, high memory use, and lack of CPU multithreading. And it is heavily ran on servers. Why? Because running Python apps is still much cheaper than hiring humans to wait for calls or manage e-mails. Humans are valuable. They should not be working on easily automatable problems. The bottleneck is automating AT ALL, rather than automating with a low machine cost. Only at huge scale (i.e. Big Tech with billions of daily events) does it warrant to optimize the code. Of course, assuming you have a sane computational complexity. If you don't, it doesn't matter which paradigm you use.

dgb23 4y ago
I think you’re right what you said. But the gist of the video doesn’t disagree at all. In fact the resulting code was very clear, easy to write and understand. He got a 15x improvement by removing indirection and OO cruft. I don’t think he’s saying “don’t use language X” here, but rather “don’t make it harder for yourself and the computer”.
- danuker 4y ago
  But it does disagree. Python is a dynamic language where essentially everything is indirect (an object). Hardcoding types and methods (so they compile to simple/fast machine code as the video proposes) takes away flexibility (but you can do that with Cython by the way, but it is not nearly that popular).
  - dgb23 4y ago
    I don’t know/use python. But I assume that it has hasmaps and vectors that are backed by something performant and possibly JITed? The table driven, static dispatch approach Muratori isn’t necessarily “hard coded” in the general case. It’s just data driven, or table driven as he puts it. It’s not less flexible as you can easier add (append!) new cases. In fact it reminds me of how I do it in higher level languages like JS and Clojure. Of course we’re paying a substantial performance tax when using higher level, dynamic languages. We’re paying that tax in order to get very tangible benefits. But we can still program in a way that is data oriented, simple and easy to work with by the compiler and runtime (JIT).
alfalfasprout 4y ago
OK but... computationally heavy code in Python isn't generally really running in Python. Almost all of it either calls out to optimized C/C++/Fortran (eg; Numpy which in turn calls BLAS+LAPACK) or do that or some other separate compilation (eg; what ML libraries do with XLA, etc. or cython). Sure, python web servers are a thing. Heck, we use them a fair bit. But it's a deliberate decision from the start where it makes sense to use it for that purpose.
- xupybd 4y ago
  >But it's a deliberate decision from the start where it makes sense to use it for that purpose. Exactly that! There is a time and a place for performant code but it's not the only metric we need to take into consideration. Sometimes you're better off using the slower tool or algorithm as it improves things on a dimension other than performance.
  - mtrower 4y ago
    > There is a time and a place for performant code but it's not the only metric we need to take into consideration. Of course not. But then, nobody is really complaining about apps they think are fast enough. The problem is, when something is noticeably slow, you complain about it, file reports etc, and are met with stiff resistance. What's important is not that you make the machine go as fast as it can possibly go at all times. What's important is to know how fast it can go, so that you're aware of just exactly how much you're leaving on the table. The actual amount in most cases, would, I expect, surprise most people...

dgb23 4y ago

I think you’re right what you said. But the gist of the video doesn’t disagree at all. In fact the resulting code was very clear, easy to write and understand. He got a 15x improvement by removing indirection and OO cruft. I don’t think he’s saying “don’t use language X” here, but rather “don’t make it harder for yourself and the computer”.

danuker 4y ago
But it does disagree. Python is a dynamic language where essentially everything is indirect (an object). Hardcoding types and methods (so they compile to simple/fast machine code as the video proposes) takes away flexibility (but you can do that with Cython by the way, but it is not nearly that popular).
- dgb23 4y ago
  I don’t know/use python. But I assume that it has hasmaps and vectors that are backed by something performant and possibly JITed? The table driven, static dispatch approach Muratori isn’t necessarily “hard coded” in the general case. It’s just data driven, or table driven as he puts it. It’s not less flexible as you can easier add (append!) new cases. In fact it reminds me of how I do it in higher level languages like JS and Clojure. Of course we’re paying a substantial performance tax when using higher level, dynamic languages. We’re paying that tax in order to get very tangible benefits. But we can still program in a way that is data oriented, simple and easy to work with by the compiler and runtime (JIT).

alfalfasprout 4y ago

OK but... computationally heavy code in Python isn't generally really running in Python. Almost all of it either calls out to optimized C/C++/Fortran (eg; Numpy which in turn calls BLAS+LAPACK) or do that or some other separate compilation (eg; what ML libraries do with XLA, etc. or cython). Sure, python web servers are a thing. Heck, we use them a fair bit. But it's a deliberate decision from the start where it makes sense to use it for that purpose.

xupybd 4y ago
>But it's a deliberate decision from the start where it makes sense to use it for that purpose. Exactly that! There is a time and a place for performant code but it's not the only metric we need to take into consideration. Sometimes you're better off using the slower tool or algorithm as it improves things on a dimension other than performance.
- mtrower 4y ago
  > There is a time and a place for performant code but it's not the only metric we need to take into consideration. Of course not. But then, nobody is really complaining about apps they think are fast enough. The problem is, when something is noticeably slow, you complain about it, file reports etc, and are met with stiff resistance. What's important is not that you make the machine go as fast as it can possibly go at all times. What's important is to know how fast it can go, so that you're aware of just exactly how much you're leaving on the table. The actual amount in most cases, would, I expect, surprise most people...