3 ms·

> why isn’t Python as fast as modern JS implementations, for example? Because the project has explicitly targeted implementation simplicity, largely successful

by baobob 4y ago

> why isn’t Python as fast as modern JS implementations, for example? Because the project has explicitly targeted implementation simplicity, largely successfully, for almost 30 years. The internals are a joy to work on, and unsurprisingly the CPython Git repository has 4x as many contributors as v8, despite CPython contribution being largely voluntary and v8 contribution being largely commercial. Even if performance were an explicit goal, it's important to remember v8 required absolutely massive funding and top tier engineering support to make it happen at all. The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds. V8 only has 2x as many contributors as PyPy. I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it. There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer

throwaway894345 4y ago
You're setting up a dichotomy between a small C-extension interface and code simplicity, but this doesn't make sense. A smaller interface is inherently simpler--it's less for developers to work around, and they can deliver more user value (whether performance or otherwise) per unit complexity. > The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds "incredible odds" refers to compatibility with the CPython C-extension interface, which is exactly what I'm talking about. > There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer No, they failed because they had to work within the considerable constraints imposed by historically bad decisions (such as the C-extension interface). The proposals need to be complex because they can't break compatibility. > I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it. Not at all! A narrower C-extension interface doesn't imply that C-extensions would be more difficult to write. There are no downsides to a narrower interface (apart from breaking compatibility, but we're positing a world in which this decision was made in 2008 or earlier). The real theme here is that historical bad decisions + compatibility guarantees add significant complexity to every single improvement if they don't preclude them altogether.

by baobob 4y ago

throwaway894345 4y ago

You're setting up a dichotomy between a small C-extension interface and code simplicity, but this doesn't make sense. A smaller interface is inherently simpler--it's less for developers to work around, and they can deliver more user value (whether performance or otherwise) per unit complexity. > The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds "incredible odds" refers to compatibility with the CPython C-extension interface, which is exactly what I'm talking about. > There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer No, they failed because they had to work within the considerable constraints imposed by historically bad decisions (such as the C-extension interface). The proposals need to be complex because they can't break compatibility. > I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it. Not at all! A narrower C-extension interface doesn't imply that C-extensions would be more difficult to write. There are no downsides to a narrower interface (apart from breaking compatibility, but we're positing a world in which this decision was made in 2008 or earlier). The real theme here is that historical bad decisions + compatibility guarantees add significant complexity to every single improvement if they don't preclude them altogether.