4 ms·

Isn't CL a good counter-example to that "dynamism inherently stunts performances" mantra?

guenthert 3y ago
To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.
- Joker_vD 3y ago
  But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?
  - Ringz 3y ago
    Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x
    - jhardy54 3y ago
      This can have substantial performance implications, not to mention DX considerations.
      - Ringz 3y ago
        Of course, this is not a good example of good, high-performance code, only an answer to the specific question... the questioner certainly also knows MyPy.
        Joker_vD 3y ago
        I actually don't know anything about MyPy, only that it exists. Does it run that example correctly, that is, does it print "nopenope"? Because I think it's the correct behaviour, type hints should not actually affect evaluation (well, beyond the fact that they must be names that are visible in the scopes thay're used in, obviously), altough I could be wrong. Besides, my point was that one of the reasons why languages with (sound-ish) static types manage to have better performance because they can omit all of those run-time type checks (and the supporting machinery) because they'd never fail. And if you have to put those explicit checks, then the type hints are actually entirely redundant: e.g. Erlang's JIT ignores type specs, it instead looks at the type guards in the code to generate specialized code for the function bodies.
    - sgerenser 3y ago
      Surely this is the job for a linter or code generator (or perhaps even a hypothetical ‘checked’ mode in the interpreter itself)? Ain’t nobody got time to add manual type checks to every single function.
      - Ringz 3y ago
        Of course not. That's what MyPy is for. It was only about the answer to exactly this question in this function.
    - adhamsalama 3y ago
      Or use mypy.
  - VagabundoP 3y ago
    The Python language server in Visual Studio Code will catch this if type checking is turned on, but by default, in CPython, that code will just work.
- kazinator 3y ago
  Standard symbols being reassigned also breaks macros.
- a-french-anon 3y ago
  Of course dynamism limits performance (and as said, standard symbols and class is also an unhygienic macro thing) but I meant that you can have both high performance and high dynamism in a programming language, dynamism itself is no excuse to not even try.

To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.

Joker_vD 3y ago
But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?
- Ringz 3y ago
  Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x
  - jhardy54 3y ago
    This can have substantial performance implications, not to mention DX considerations.
    - Ringz 3y ago
      Of course, this is not a good example of good, high-performance code, only an answer to the specific question... the questioner certainly also knows MyPy.
      - Joker_vD 3y ago
        I actually don't know anything about MyPy, only that it exists. Does it run that example correctly, that is, does it print "nopenope"? Because I think it's the correct behaviour, type hints should not actually affect evaluation (well, beyond the fact that they must be names that are visible in the scopes thay're used in, obviously), altough I could be wrong. Besides, my point was that one of the reasons why languages with (sound-ish) static types manage to have better performance because they can omit all of those run-time type checks (and the supporting machinery) because they'd never fail. And if you have to put those explicit checks, then the type hints are actually entirely redundant: e.g. Erlang's JIT ignores type specs, it instead looks at the type guards in the code to generate specialized code for the function bodies.
  - sgerenser 3y ago
    Surely this is the job for a linter or code generator (or perhaps even a hypothetical ‘checked’ mode in the interpreter itself)? Ain’t nobody got time to add manual type checks to every single function.
    - Ringz 3y ago
      Of course not. That's what MyPy is for. It was only about the answer to exactly this question in this function.
  - adhamsalama 3y ago
    Or use mypy.
- VagabundoP 3y ago
  The Python language server in Visual Studio Code will catch this if type checking is turned on, but by default, in CPython, that code will just work.
kazinator 3y ago
Standard symbols being reassigned also breaks macros.
a-french-anon 3y ago
Of course dynamism limits performance (and as said, standard symbols and class is also an unhygienic macro thing) but I meant that you can have both high performance and high dynamism in a programming language, dynamism itself is no excuse to not even try.