4 ms·

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 co

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 4y 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 4y 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 4y 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.
  - edflsafoiewq 4y ago
    CL has many constraints that make it less dynamic to "minimize the observable differences between compiled and interpreted programs" (CLHS, 3.2.2.3 Semantic Constraints). For example, if f is defuned in a file, throughout that file you can assume (f x) refers to that f and does not have to be looked up dynamically at runtime. If I recall correctly, method calls in CLOS are also not syntactically distinguished from regular calls either (like they are in x.f() languages), so there is no motivation to write a method unless you actually want the dynamic dispatch methods provide. Methods are fairly rare compared to regular functions.
    - ByteJockey 4y ago
      > For example, if f is defuned in a file, throughout that file you can assume (f x) refers to that f and does not have to be looked up dynamically at runtime. Unless you declare them "notinline". http://www.lispworks.com/documentation/HyperSpec/Body/d_inline.htm#notinline http://www.lispworks.com/documentation/HyperSpec/Body/d_inli... > so there is no motivation to write a method unless you actually want the dynamic dispatch methods provide. Methods have some different functionality in CL than in most languages. For example, you can have the methods from the entire inheritance hierarchy (well, the classes that have had that method specialized for them) all be called as, essentially a pipeline of methods. https://lispcookbook.github.io/cl-cookbook/clos.html#method-qualifiers-before-after-around https://lispcookbook.github.io/cl-cookbook/clos.html#method-... But this is a discussion about dynamism of the object system, and most of that is defined before runtime. How about changing an object's class at runtime? https://www.cliki.net/site/HyperSpec/Body/stagenfun_change-class.html https://www.cliki.net/site/HyperSpec/Body/stagenfun_change-c...
- pjmlp 4y ago
  Smalltalk, a become: b Now all references of a and b across the complete image are changed, invalidating all assumptions done at every call site sending messages to each of them.

Spivak 4y 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 4y 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 4y 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.
- edflsafoiewq 4y ago
  CL has many constraints that make it less dynamic to "minimize the observable differences between compiled and interpreted programs" (CLHS, 3.2.2.3 Semantic Constraints). For example, if f is defuned in a file, throughout that file you can assume (f x) refers to that f and does not have to be looked up dynamically at runtime. If I recall correctly, method calls in CLOS are also not syntactically distinguished from regular calls either (like they are in x.f() languages), so there is no motivation to write a method unless you actually want the dynamic dispatch methods provide. Methods are fairly rare compared to regular functions.
  - ByteJockey 4y ago
    > For example, if f is defuned in a file, throughout that file you can assume (f x) refers to that f and does not have to be looked up dynamically at runtime. Unless you declare them "notinline". http://www.lispworks.com/documentation/HyperSpec/Body/d_inline.htm#notinline http://www.lispworks.com/documentation/HyperSpec/Body/d_inli... > so there is no motivation to write a method unless you actually want the dynamic dispatch methods provide. Methods have some different functionality in CL than in most languages. For example, you can have the methods from the entire inheritance hierarchy (well, the classes that have had that method specialized for them) all be called as, essentially a pipeline of methods. https://lispcookbook.github.io/cl-cookbook/clos.html#method-qualifiers-before-after-around https://lispcookbook.github.io/cl-cookbook/clos.html#method-... But this is a discussion about dynamism of the object system, and most of that is defined before runtime. How about changing an object's class at runtime? https://www.cliki.net/site/HyperSpec/Body/stagenfun_change-class.html https://www.cliki.net/site/HyperSpec/Body/stagenfun_change-c...
pjmlp 4y ago
Smalltalk, a become: b Now all references of a and b across the complete image are changed, invalidating all assumptions done at every call site sending messages to each of them.