3 ms·

> Unfortunately, there is a performance penalty with dynamic langues, which wont go away. You'd be amazed at the sorts of aggressive optimizations that can be

by icky 19y ago

> Unfortunately, there is a performance penalty with dynamic langues, which wont go away. You'd be amazed at the sorts of aggressive optimizations that can be done at compile-time.

Tichy 19y ago
Still, how do you get around the fundamental problem of symbol lookup? Maybe sometimes you can infer the type, but I doubt that it is possible in general. If the symbols are "hard linked", it is not dynamic anymore. I wonder what strategy the LISP dialects out there typically use? I was impressed how easy it is to create an object system in a LISP, but somewhat dismayed because all examples just used (cond) for symbol lookup. Maybe because they were just academic examples, or perhaps they really don't care about performance at all?
- icky 19y ago
  > If the symbols are "hard linked", it is not dynamic anymore. Lies, slander! ;-) Anything that happens within a function can be treated as a black box, and compiled down to the metal, if you like. The language can be as dynamic as you like; that doesn't preclude the output format from being tightly optimized machine code.
  - Tichy 19y ago
    What about the things you pass into the function? You can't know their properties in advance, in general, or can you?
    - icky 19y ago
      > What about the things you pass into the function? You can't know their properties in advance, in general, or can you? You can know that, e.g. a function passed in as an argument can be dereferenced as a pointer stored in a specific offset on the stack. If your typechecks are compiler-generated statements inserted before a function call, then if you know at compile-time (via declarations or type inference, or type propagation) that a certain variable (to be passed as an argument) will always be of the correct type T, then you can omit the typecheck, as well as boxing/tagging. You can get really close to the metal this way, and still have your language be as dynamic as can be.

by icky 19y ago

> Unfortunately, there is a performance penalty with dynamic langues, which wont go away. You'd be amazed at the sorts of aggressive optimizations that can be done at compile-time.

Tichy 19y ago

Still, how do you get around the fundamental problem of symbol lookup? Maybe sometimes you can infer the type, but I doubt that it is possible in general. If the symbols are "hard linked", it is not dynamic anymore. I wonder what strategy the LISP dialects out there typically use? I was impressed how easy it is to create an object system in a LISP, but somewhat dismayed because all examples just used (cond) for symbol lookup. Maybe because they were just academic examples, or perhaps they really don't care about performance at all?

icky 19y ago
> If the symbols are "hard linked", it is not dynamic anymore. Lies, slander! ;-) Anything that happens within a function can be treated as a black box, and compiled down to the metal, if you like. The language can be as dynamic as you like; that doesn't preclude the output format from being tightly optimized machine code.
- Tichy 19y ago
  What about the things you pass into the function? You can't know their properties in advance, in general, or can you?
  - icky 19y ago
    > What about the things you pass into the function? You can't know their properties in advance, in general, or can you? You can know that, e.g. a function passed in as an argument can be dereferenced as a pointer stored in a specific offset on the stack. If your typechecks are compiler-generated statements inserted before a function call, then if you know at compile-time (via declarations or type inference, or type propagation) that a certain variable (to be passed as an argument) will always be of the correct type T, then you can omit the typecheck, as well as boxing/tagging. You can get really close to the metal this way, and still have your language be as dynamic as can be.