5 ms·

> Those languages, the lisps, schemes, smalltalks, etc. The main reason those languages got fast despite being highly dynamic is because of very complex JIT VM

> Those languages, the lisps, schemes, smalltalks, etc. The main reason those languages got fast despite being highly dynamic is because of very complex JIT VM implementations. (See also: JavaScript.) The cost of that is that a complex VM is much less hackable and makes it harder to evolve the language. (See also: JavaScript.) Python and Ruby have, I think, reasonably chosen to have slower simpler implementations so that they are able to nimbly respond to user needs and evolve the language without needing massive funding from giant corporations in order to support an implementation. (See also: JavaScript.) There are other effects at play, too, of course. Once your implementation's strategy for speed is "drop to C and use FFI", then it gets much harder to optimize the core language with stuff like a JIT and inlining because the FFI system itself gets in the way. Not having an FFI for JS on the web essentially forced JavaScript users to push to make the core language itself faster.

peatmoss 5y ago
Spending a weekend or two writing a Scheme that beats Python in performance has been a pastime for computer science students for at least a couple decades now. I'm not sure that I believe that a performant Scheme implementation has more complexity than e.g. PyPy. In fact, I'd wager the converse.
- mrtranscendence 5y ago
  You're either exaggerating or the computer science students you're familiar with are wizards. I've never known the student who could write a Scheme implementation, from scratch, in one weekend that is both complete and which beats Python from a performance perspective.
  - peatmoss 5y ago
    If it's an exaggeration, it's not much of one. Two parts to your argument: - Writing a Scheme implementation quickly: Google "Write a Scheme in 48 hours" and "Scheme from scratch." 48 hours to a functioning Scheme implementation seems to be a feat replicated in multiple programming languages. - Performance: I haven't benchmarked every hobby scheme, but given the proliferation of Scheme implementations that, despite limited developer resources, beat (pure) Python with it's massive pool of developers (CPython, PyPy), I still don't buy the idea that optimizing Scheme is a harder task than optimizing Python. Again, I'd strongly suggest that optimizing Scheme is a much easier task than optimizing Python simply by virtue of how often the feat has been accomplished.
    - mrtranscendence 5y ago
      If you can give me an implementation that implements almost all of R5RS, in 48 hours, beating Python in performance, and all by a single developer, I’ll tip my hat to that guy or gal. But I can’t imagine it’s too commonly done.
      - eatonphil 5y ago
        Nobody said you can implement a full Scheme implementation in 48 hours or two weeks. That's very much besides the point about how poor CPython performance is.
        mrtranscendence 5y ago
        > Nobody said you can implement a full Scheme implementation in 48 hours or two weeks. Fair enough, you're right. But if we're only talking about incomplete Scheme implementations it's not a very interesting claim. As I pointed out in another comment, even I could write a fast Scheme implementation in 48 hours if I kept my scope very limited. That doesn't say much about Scheme performance overall or how it relates to Python.
        eatonphil 5y ago
        What is it that you think makes a full Scheme implementation as slow as CPython?
        mrtranscendence 5y ago
        I don’t think a full Scheme implementation is as slow as Python in general. What I’m hung up on is the claim that it’s so absolutely trivial to write a language implementation faster than Python that basically anybody at any skill level could do it in a weekend, and still have time for Sunday afternoon bocce.
        pjmlp 5y ago
  - eatonphil 5y ago
    Substitute computer science student with "developer" and it holds for me. Definitely some CS students can do it too. Actually at my school we did have to implement a Scheme compiler. So yeah it's not too big of a stretch to say. I think people who haven't implemented a language underestimate how slow CPython is. And overestimate how hard it is to build a compiler for a dynamic language. I think every professional developer or CS student can and should build a compiler for a dynamic language!
    - mrtranscendence 5y ago
      But the claim was that a student could write a conformant Scheme implementation in 48 hours that beats Python. Clearly it’s possible for a student to write a Scheme that’s faster than Python, but is it a reasonably complete Scheme done in a single weekend? Even I, very much a non-computer scientist, could write a fast Scheme quickly if I could keep myself to a very small subset, so that’s not interesting to me.
      - eatonphil 5y ago
        Conformant is a word you introduced, they didn't say that.
  - pjmlp 5y ago
    Only if they aren't attending degrees where compiler design is part of the curriculum, which if that is the case kind of speaks for the quality of the institution.
    - mrtranscendence 5y ago
      A reasonably complete, fast language implementation, from scratch, in one weekend, though? By someone who was only introduced to compilers within the last few months? I don’t believe most students would be capable of that, but I’m not a computer scientist so what do I know.
      - pjmlp 5y ago
        Yes, Scheme is quite simple, no one is speaking about doing R7RS. Compared with current state of affairs in CPython, even with basic code generation algorithms, the machine code would be fast enough. Introducing to compilers means also writing one in the process, unless it is a lousy degree.
- munificent 5y ago
  Sure, but that's because Python has objects. If your write an object system on top of your performant hobby Scheme implementation, you'll likely find that the performance of its method dispatch is about as slow as it is in Python. Probably even slower. Purely procedural Python code isn't as slow as object-oriented Python code.
  - peatmoss 5y ago
    That's fair, but also the fact that we're comparing hobby scheme implementations to two mainstream extremely popular implementations of Python and setting up conditions that forces (hobby) Scheme to play to Python's relative strengths is telling. :-) The Python ecosystem has certainly received a lot of developer resources and attention the past couple of decades. Shall we compare the performance of CLOS on SBCL, which again has seen comparatively little developer resources, to Python's performance in dealing with objects? I'd take that performance wager.
    - Spivak 5y ago
      This isn’t as much of a gotcha as you think. Python is slow because the language is so dynamic and simply has to do more behind the scenes work on each line. It’s not impressive that a language that does less is faster. What’s impressive is that a language that does more, like JS on V8, is faster.
      - CraigJPerry 5y ago
        Is CLOS doing less than Python? I'm thinking CLOS has more dynamism than Python - they're both dynamically typed, they're both doing a lookup then dispatch, but then CLOS adds dynamism on top of that, it's also looking in the metadata thingy (i'm not a lisp developer, do they call it the hash? I'm meaning the key value store on every "atom" - i'm so out of my depth here, is atom the right word?) plus if i remember right the way CLOS works you use multiple dispatch not just single dispatch like python.
      - ByteJockey 5y ago
        The CLOS is more dynamic than python. You can do things like specialize a method on multiple types based on the runtime types (that is to say, the method conceptually belongs to the intersection of the classes, not any single class). I like python (especially things like comprehensions), but to say it's more dynamic than common lisp is a little insane.
igouy 5y ago
> Python and Ruby have, I think, reasonably chosen to have slower simpler implementations… ? https://shopify.engineering/yjit-just-in-time-compiler-cruby https://shopify.engineering/yjit-just-in-time-compiler-cruby
- munificent 5y ago
  Yes, CRuby is slowly moving towards a JIT now because performance is a major blocker for user adoption. The larger Python ecosystem has tried that a number of times too (Unladen Swallow, PyPy, etc.) It's quite difficult since both of those languages already lean heavily on C FFI and having frequent hops in and out of FFI code tends to make it harder to get the JIT fast. JITs work best when all of the code is in the host language and can be optimized and inlined together.
eatonphil 5y ago
Javascript the language seems to have evolved much more than Python despite CPython's very simple implementation.
- munificent 5y ago
  Hence my point about "massive funding from giant corporations in order to support an implementation". :)
  - eatonphil 5y ago
    Well almost all the JavaScript language innovation was syntax sugar and was implemented as transforms before the browsers implemented it. I think JavaScript devs mostly were fine to keep using transforms indefinitely and it's just been more convenient that the browsers have moved to implement it. Python could have done this easily too but evolving as a language just isn't as big a priority (not that I'm saying it should be) and that's completely (or mostly) disconnected from their backend implementation decisions.
saghm 5y ago
> Python and Ruby have, I think, reasonably chosen to have slower simpler implementations so that they are able to nimbly respond to user needs and evolve the language without needing massive funding from giant corporations in order to support an implementation. (See also: JavaScript) I'm not really sure I buy that argument for why JavaScript evolved slowly for a while. It seems more likely to me that it was due to the combination of basically being required to be 100% backwards compatible (no one making a browser wants to be the only one who doesn't work for a certain website), having no single canonical implementation (which means that all the common browsers would have to agree on a spec for something to be added or changed), and not really being used in the server context widely before Node. Python and Ruby both sacrificed backwards compatibility at times in their history, and both had one central implementation which others tended to draw from, so it was easier to get changes made.
- munificent 5y ago
  Agreed, that isn't the reason JavaScript in particular was essentially motionless for about a decade. As you note, that was largely due to political factors and disagreement about language direction among the various competing implementers. But compared to say Smalltalk, Scheme, and Lisp, I think Ruby and Python have been able to evolve incrementally in part because of their simpler more hackable implementations.
  - igouy 5y ago
    Similarly why shouldn't we think that business reasons left Smalltalk motionless after release from ParcPlace? So traits for Squeak but not the commercial Smalltalks.

peatmoss 5y ago

Spending a weekend or two writing a Scheme that beats Python in performance has been a pastime for computer science students for at least a couple decades now. I'm not sure that I believe that a performant Scheme implementation has more complexity than e.g. PyPy. In fact, I'd wager the converse.

mrtranscendence 5y ago
You're either exaggerating or the computer science students you're familiar with are wizards. I've never known the student who could write a Scheme implementation, from scratch, in one weekend that is both complete and which beats Python from a performance perspective.
- peatmoss 5y ago
  If it's an exaggeration, it's not much of one. Two parts to your argument: - Writing a Scheme implementation quickly: Google "Write a Scheme in 48 hours" and "Scheme from scratch." 48 hours to a functioning Scheme implementation seems to be a feat replicated in multiple programming languages. - Performance: I haven't benchmarked every hobby scheme, but given the proliferation of Scheme implementations that, despite limited developer resources, beat (pure) Python with it's massive pool of developers (CPython, PyPy), I still don't buy the idea that optimizing Scheme is a harder task than optimizing Python. Again, I'd strongly suggest that optimizing Scheme is a much easier task than optimizing Python simply by virtue of how often the feat has been accomplished.
  - mrtranscendence 5y ago
    If you can give me an implementation that implements almost all of R5RS, in 48 hours, beating Python in performance, and all by a single developer, I’ll tip my hat to that guy or gal. But I can’t imagine it’s too commonly done.
    - eatonphil 5y ago
      Nobody said you can implement a full Scheme implementation in 48 hours or two weeks. That's very much besides the point about how poor CPython performance is.
      - mrtranscendence 5y ago
        > Nobody said you can implement a full Scheme implementation in 48 hours or two weeks. Fair enough, you're right. But if we're only talking about incomplete Scheme implementations it's not a very interesting claim. As I pointed out in another comment, even I could write a fast Scheme implementation in 48 hours if I kept my scope very limited. That doesn't say much about Scheme performance overall or how it relates to Python.
        eatonphil 5y ago
        What is it that you think makes a full Scheme implementation as slow as CPython?
        mrtranscendence 5y ago
        I don’t think a full Scheme implementation is as slow as Python in general. What I’m hung up on is the claim that it’s so absolutely trivial to write a language implementation faster than Python that basically anybody at any skill level could do it in a weekend, and still have time for Sunday afternoon bocce.
        pjmlp 5y ago
- eatonphil 5y ago
  Substitute computer science student with "developer" and it holds for me. Definitely some CS students can do it too. Actually at my school we did have to implement a Scheme compiler. So yeah it's not too big of a stretch to say. I think people who haven't implemented a language underestimate how slow CPython is. And overestimate how hard it is to build a compiler for a dynamic language. I think every professional developer or CS student can and should build a compiler for a dynamic language!
  - mrtranscendence 5y ago
    But the claim was that a student could write a conformant Scheme implementation in 48 hours that beats Python. Clearly it’s possible for a student to write a Scheme that’s faster than Python, but is it a reasonably complete Scheme done in a single weekend? Even I, very much a non-computer scientist, could write a fast Scheme quickly if I could keep myself to a very small subset, so that’s not interesting to me.
    - eatonphil 5y ago
      Conformant is a word you introduced, they didn't say that.
- pjmlp 5y ago
  Only if they aren't attending degrees where compiler design is part of the curriculum, which if that is the case kind of speaks for the quality of the institution.
  - mrtranscendence 5y ago
    A reasonably complete, fast language implementation, from scratch, in one weekend, though? By someone who was only introduced to compilers within the last few months? I don’t believe most students would be capable of that, but I’m not a computer scientist so what do I know.
    - pjmlp 5y ago
      Yes, Scheme is quite simple, no one is speaking about doing R7RS. Compared with current state of affairs in CPython, even with basic code generation algorithms, the machine code would be fast enough. Introducing to compilers means also writing one in the process, unless it is a lousy degree.
munificent 5y ago
Sure, but that's because Python has objects. If your write an object system on top of your performant hobby Scheme implementation, you'll likely find that the performance of its method dispatch is about as slow as it is in Python. Probably even slower. Purely procedural Python code isn't as slow as object-oriented Python code.
- peatmoss 5y ago
  That's fair, but also the fact that we're comparing hobby scheme implementations to two mainstream extremely popular implementations of Python and setting up conditions that forces (hobby) Scheme to play to Python's relative strengths is telling. :-) The Python ecosystem has certainly received a lot of developer resources and attention the past couple of decades. Shall we compare the performance of CLOS on SBCL, which again has seen comparatively little developer resources, to Python's performance in dealing with objects? I'd take that performance wager.
  - Spivak 5y ago
    This isn’t as much of a gotcha as you think. Python is slow because the language is so dynamic and simply has to do more behind the scenes work on each line. It’s not impressive that a language that does less is faster. What’s impressive is that a language that does more, like JS on V8, is faster.
    - CraigJPerry 5y ago
      Is CLOS doing less than Python? I'm thinking CLOS has more dynamism than Python - they're both dynamically typed, they're both doing a lookup then dispatch, but then CLOS adds dynamism on top of that, it's also looking in the metadata thingy (i'm not a lisp developer, do they call it the hash? I'm meaning the key value store on every "atom" - i'm so out of my depth here, is atom the right word?) plus if i remember right the way CLOS works you use multiple dispatch not just single dispatch like python.
    - ByteJockey 5y ago
      The CLOS is more dynamic than python. You can do things like specialize a method on multiple types based on the runtime types (that is to say, the method conceptually belongs to the intersection of the classes, not any single class). I like python (especially things like comprehensions), but to say it's more dynamic than common lisp is a little insane.

igouy 5y ago

> Python and Ruby have, I think, reasonably chosen to have slower simpler implementations… ? https://shopify.engineering/yjit-just-in-time-compiler-cruby https://shopify.engineering/yjit-just-in-time-compiler-cruby

munificent 5y ago
Yes, CRuby is slowly moving towards a JIT now because performance is a major blocker for user adoption. The larger Python ecosystem has tried that a number of times too (Unladen Swallow, PyPy, etc.) It's quite difficult since both of those languages already lean heavily on C FFI and having frequent hops in and out of FFI code tends to make it harder to get the JIT fast. JITs work best when all of the code is in the host language and can be optimized and inlined together.

eatonphil 5y ago

Javascript the language seems to have evolved much more than Python despite CPython's very simple implementation.

munificent 5y ago
Hence my point about "massive funding from giant corporations in order to support an implementation". :)
- eatonphil 5y ago
  Well almost all the JavaScript language innovation was syntax sugar and was implemented as transforms before the browsers implemented it. I think JavaScript devs mostly were fine to keep using transforms indefinitely and it's just been more convenient that the browsers have moved to implement it. Python could have done this easily too but evolving as a language just isn't as big a priority (not that I'm saying it should be) and that's completely (or mostly) disconnected from their backend implementation decisions.

saghm 5y ago

> Python and Ruby have, I think, reasonably chosen to have slower simpler implementations so that they are able to nimbly respond to user needs and evolve the language without needing massive funding from giant corporations in order to support an implementation. (See also: JavaScript) I'm not really sure I buy that argument for why JavaScript evolved slowly for a while. It seems more likely to me that it was due to the combination of basically being required to be 100% backwards compatible (no one making a browser wants to be the only one who doesn't work for a certain website), having no single canonical implementation (which means that all the common browsers would have to agree on a spec for something to be added or changed), and not really being used in the server context widely before Node. Python and Ruby both sacrificed backwards compatibility at times in their history, and both had one central implementation which others tended to draw from, so it was easier to get changes made.

munificent 5y ago
Agreed, that isn't the reason JavaScript in particular was essentially motionless for about a decade. As you note, that was largely due to political factors and disagreement about language direction among the various competing implementers. But compared to say Smalltalk, Scheme, and Lisp, I think Ruby and Python have been able to evolve incrementally in part because of their simpler more hackable implementations.
- igouy 5y ago
  Similarly why shouldn't we think that business reasons left Smalltalk motionless after release from ParcPlace? So traits for Squeak but not the commercial Smalltalks.