3 ms·

The most common belief is that python is intrinsically very hard to execute efficiently. Which seems valid. However there's a conclusion drawn that it must ther

The most common belief is that python is intrinsically very hard to execute efficiently. Which seems valid. However there's a conclusion drawn that it must therefore always be slow. Your link has some of the usual points but seems to miss the global interpreter lock which usually attracts blame. Nevertheless, I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation hard. Basically that stuff changes on you at runtime and the type system can express things that static ones cannot. So you have to do the assume + jit + rollback game for either of them, at which point python might have a longer list of stuff that is assumed constant in the prelude. But then I'm not going to write a proof of this - I'm not confident I have enough life left to clone v8 for python, nor do I have motivation to do so. I expect mojo will end up serving that role. It doesn't have the same semantics yet, but that's the stated goal and I think they'll get there.

chubot 3y ago
I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation With respect, this attitude goes back at least 15 years, and usually comes from compiler people who don't understand Python very well, and the way people use it to solve problems in context. The problem is very well studied, and your comments indicate that you haven't studied the prior art -- PyPy, Unladen Swallow, Jython/IronPython, Pyston, more recently Cinder and Skybison -- which are DIRECTLY from the v8 lineage. --- To be clear, what I'm saying is that it's certainly possible to make a v8-like implementation for a Python-like language. But the "like" is doing a lot of work there, and is the difference between the language being practical, and not practical. So I think you're a compiler person who has an image of "Python" in his head, which is not Python. That's not really a knock, because everybody who has tried to optimize Python starts from that position. I think even the Mojo team is, and they know way more about compilers than me -- but less about Python. My guess is that they will succeed at producing something very interesting and useful in 5-10 years, but either renege on the Python compatibility promises, rewrite NumPy/Pandas themselves, or maintain a bridge to stock CPython forever. Although I also think your comments indicate a fairly big misunderstanding of what Mojo is.
- JonChesterfield 3y ago
  One of the flaws of the comment format is brevity mixed with a tendency to write conclusions without the reasoning behind them. Mojo is an extension of python. In addition to the existing syntax, there are new keywords to opt into a more static set of semantics, chosen to compile directly to efficient code. You can have a machine integer instead of an arbitrary size python one, but they have different names. This gives you a path to writing code which doesn't opt into pythons compilation challenges. Or you can compile raw python as-is, but you get whatever type inference it manages, and some things aren't implemented yet. It also has calls into cpython for some stuff, but that's not inherent to the implementation strategy and I hope will not last forever. This is personally interesting because it takes the python + C extension model, and the adjacent C++ that shows up nearby, and reassembles the semantics under a single compiler stack which has a credible path to optimising across the combination. This is perilously close to what I want a programming language to be, possibly to the extent that I'm assuming they're going to do the obviously correct things in the future, so I would be interested to hear if any of the above is disjoint from your understanding. It may mean I need to recheck that they've built what I think they have.

chubot 3y ago

I maintain that python and javascript are semantically the same thing in terms of the properties that make ahead of time compilation With respect, this attitude goes back at least 15 years, and usually comes from compiler people who don't understand Python very well, and the way people use it to solve problems in context. The problem is very well studied, and your comments indicate that you haven't studied the prior art -- PyPy, Unladen Swallow, Jython/IronPython, Pyston, more recently Cinder and Skybison -- which are DIRECTLY from the v8 lineage. --- To be clear, what I'm saying is that it's certainly possible to make a v8-like implementation for a Python-like language. But the "like" is doing a lot of work there, and is the difference between the language being practical, and not practical. So I think you're a compiler person who has an image of "Python" in his head, which is not Python. That's not really a knock, because everybody who has tried to optimize Python starts from that position. I think even the Mojo team is, and they know way more about compilers than me -- but less about Python. My guess is that they will succeed at producing something very interesting and useful in 5-10 years, but either renege on the Python compatibility promises, rewrite NumPy/Pandas themselves, or maintain a bridge to stock CPython forever. Although I also think your comments indicate a fairly big misunderstanding of what Mojo is.

JonChesterfield 3y ago
One of the flaws of the comment format is brevity mixed with a tendency to write conclusions without the reasoning behind them. Mojo is an extension of python. In addition to the existing syntax, there are new keywords to opt into a more static set of semantics, chosen to compile directly to efficient code. You can have a machine integer instead of an arbitrary size python one, but they have different names. This gives you a path to writing code which doesn't opt into pythons compilation challenges. Or you can compile raw python as-is, but you get whatever type inference it manages, and some things aren't implemented yet. It also has calls into cpython for some stuff, but that's not inherent to the implementation strategy and I hope will not last forever. This is personally interesting because it takes the python + C extension model, and the adjacent C++ that shows up nearby, and reassembles the semantics under a single compiler stack which has a credible path to optimising across the combination. This is perilously close to what I want a programming language to be, possibly to the extent that I'm assuming they're going to do the obviously correct things in the future, so I would be interested to hear if any of the above is disjoint from your understanding. It may mean I need to recheck that they've built what I think they have.