4 ms·

> Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program

> Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics. _________ > I don't see why a lot of packages would break. At best some of them would be not thread safe and it's probably a good idea to mark the ones that are thread safe as such in some way. Some nice package management challenge there. And probably you'd want to know which packages you can safely use. They're not thread safe because it was semantically guaranteed to them that it was okay to write code that's not thread safe.

adamc 2y ago
There are different definitions of slow, though. You might want arbitrary precision numbers but want it to be reasonable fast in that context. I don't agree that it is "insane stuff", but I agree that Python is not where you go if you need super fast execution. It can be a great solution for "hack together something in a day that is correct, but maybe not fast", though. There are a lot of situations where that is, by far, the preferred solution.
- eigenspace 2y ago
  There are ways to design languages to be dynamic while still being friendly to optimizing compilers. Typically what you want to do is promise that various things are dynamic, but then static within a single compilation context. julia is a great example of a highly dynamic language which is still able to compile complicated programs to C-equivalent machine code. An older (and less performant but still quite fast) example of such a language is Common Lisp. Python makes certain choices though that make this stuff pretty much impossible.
  - adamc 2y ago
    Not disputing it, but people don't pick Python because they need the fastest language, they pick it for friendly syntax and extensive and well-supported libraries. I loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network of humans you can ask questions of, etc.
    - eigenspace 2y ago
      > loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. None of the lisps have anything close to julia's ecology in numerical computing at least. Can't really speak to other niches though. > People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network of humans you can ask questions of, etc. Sure. And that's why Python is both popular and slow.
    - JodieBenitez 2y ago
      I think that to a certain extent the quality of libraries can depend on language features.
    - gilch 2y ago
      > I loved Lisp, but none of the lisps have anything like Python's ecology. Try Hissp (https://github.com/gilch https://github.com/gilch). Lisp programming and Python's ecosystem.
  - Jtsummers 2y ago
    Common Lisp is probably not a good point of comparison. It offers comparable (if not more) dynamism to Python and still remains fast (for most implementations). You can redefine class definitions and function definitions on the fly in a Common Lisp program and other than the obvious overhead of invoking those things the whole system remains fast.
    - 2y ago
- qaq 2y ago
  "hack together something in a day" JPM Athena trading platform had 35 million lines of code in 2019 with about 20k commits a week
lmm 2y ago
> Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. > The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics. People said the same thing about JavaScript, where object prototypes can change at any time, dramatically changing everything. But it turned out JavaScript can run fast if you try hard enough. I suspect the same would be true for Python if a similar amount of resources was poured into it (probably with a similar "try the fast path, abort and fall back to a slow path in the extremely rare case that someone actually is doing funky metaprogramming" approach).
pjmlp 2y ago
SELF, Smalltalk, Common Lisp are even crazier and have good performance, that has always been a common excuse, which is being proven false as proper resources are now being addressed into CPython. And that while ignoring all the engineering that has gone into PyPy, largely ignored by the community.

adamc 2y ago

There are different definitions of slow, though. You might want arbitrary precision numbers but want it to be reasonable fast in that context. I don't agree that it is "insane stuff", but I agree that Python is not where you go if you need super fast execution. It can be a great solution for "hack together something in a day that is correct, but maybe not fast", though. There are a lot of situations where that is, by far, the preferred solution.

eigenspace 2y ago
There are ways to design languages to be dynamic while still being friendly to optimizing compilers. Typically what you want to do is promise that various things are dynamic, but then static within a single compilation context. julia is a great example of a highly dynamic language which is still able to compile complicated programs to C-equivalent machine code. An older (and less performant but still quite fast) example of such a language is Common Lisp. Python makes certain choices though that make this stuff pretty much impossible.
- adamc 2y ago
  Not disputing it, but people don't pick Python because they need the fastest language, they pick it for friendly syntax and extensive and well-supported libraries. I loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network of humans you can ask questions of, etc.
  - eigenspace 2y ago
    > loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. None of the lisps have anything close to julia's ecology in numerical computing at least. Can't really speak to other niches though. > People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network of humans you can ask questions of, etc. Sure. And that's why Python is both popular and slow.
  - JodieBenitez 2y ago
    I think that to a certain extent the quality of libraries can depend on language features.
  - gilch 2y ago
    > I loved Lisp, but none of the lisps have anything like Python's ecology. Try Hissp (https://github.com/gilch https://github.com/gilch). Lisp programming and Python's ecosystem.
- Jtsummers 2y ago
  Common Lisp is probably not a good point of comparison. It offers comparable (if not more) dynamism to Python and still remains fast (for most implementations). You can redefine class definitions and function definitions on the fly in a Common Lisp program and other than the obvious overhead of invoking those things the whole system remains fast.
  - 2y ago
qaq 2y ago
"hack together something in a day" JPM Athena trading platform had 35 million lines of code in 2019 with about 20k commits a week

lmm 2y ago

> Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. > The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics. People said the same thing about JavaScript, where object prototypes can change at any time, dramatically changing everything. But it turned out JavaScript can run fast if you try hard enough. I suspect the same would be true for Python if a similar amount of resources was poured into it (probably with a similar "try the fast path, abort and fall back to a slow path in the extremely rare case that someone actually is doing funky metaprogramming" approach).

pjmlp 2y ago

SELF, Smalltalk, Common Lisp are even crazier and have good performance, that has always been a common excuse, which is being proven false as proper resources are now being addressed into CPython. And that while ignoring all the engineering that has gone into PyPy, largely ignored by the community.