3 ms·

But with the benefit of static types, and without the drawbacks of static types.

insanitybit 3y ago
No. "Types only known at runtime" are dynamic types. "And also you can optimize by examining the types at runtime" is just dynamic types. And it does not have the benefit of static types because it is dynamic types.
- 3cats-in-a-coat 3y ago
  This is devolving into a "word definition war" so I'll leave aside what you call static types and dynamic types and get down to specifics. Type info is available in these flavors, relative to runtime: 1. Type info which is available before runtime, but not at runtime (compiled away). 2. Type info which is available at runtime, but not at compile time (input, statistics, etc.). 3. Type info which is available both at compile time and runtime (say like a Java class). When you have a JIT optimizer that can turn [3] and [2] into [1], there's no longer a reason to have [1], except if you're micro-optimizing embedded code for some device with 64kb RAM or whatever. We've carried through legacy practices, and we don't even question them, and try to push them way out of their league into large-scale distributed software. When I say we don't need [1], this doesn't mean I deny [3], which is still statically analyzable type information. It's static types, but without throwing away flexibility and data at runtime, that doesn't need to be thrown away.
  - insanitybit 3y ago
    Short of time travel one can not turn (3) or (2) into (1). I'm not sure where the confusion here is or what you're advocating for because this isn't making sense to me. > there's no longer a reason to have [1] I guess if you're assuming the value of static types is just performance? But it's not, not by a long shot - hence 'mypy', a static typechecker that in no way impacts runtime. I think this conversation is a bit too confusing for me so I'm gonna respectfully walk away :)
    - 3cats-in-a-coat 3y ago
      The confusion is to assume "runtime" is statically defined. JIT generates code which omits type information that's determined not to be needed in the context of the compiled method/trace/class/module. That code still "runs" it's "runtime".
      - insanitybit 3y ago
        Yes, the types that JIT omits are dynamic types.
- deleted 3y ago
  [deleted]

No. "Types only known at runtime" are dynamic types. "And also you can optimize by examining the types at runtime" is just dynamic types. And it does not have the benefit of static types because it is dynamic types.

3cats-in-a-coat 3y ago
This is devolving into a "word definition war" so I'll leave aside what you call static types and dynamic types and get down to specifics. Type info is available in these flavors, relative to runtime: 1. Type info which is available before runtime, but not at runtime (compiled away). 2. Type info which is available at runtime, but not at compile time (input, statistics, etc.). 3. Type info which is available both at compile time and runtime (say like a Java class). When you have a JIT optimizer that can turn [3] and [2] into [1], there's no longer a reason to have [1], except if you're micro-optimizing embedded code for some device with 64kb RAM or whatever. We've carried through legacy practices, and we don't even question them, and try to push them way out of their league into large-scale distributed software. When I say we don't need [1], this doesn't mean I deny [3], which is still statically analyzable type information. It's static types, but without throwing away flexibility and data at runtime, that doesn't need to be thrown away.
- insanitybit 3y ago
  Short of time travel one can not turn (3) or (2) into (1). I'm not sure where the confusion here is or what you're advocating for because this isn't making sense to me. > there's no longer a reason to have [1] I guess if you're assuming the value of static types is just performance? But it's not, not by a long shot - hence 'mypy', a static typechecker that in no way impacts runtime. I think this conversation is a bit too confusing for me so I'm gonna respectfully walk away :)
  - 3cats-in-a-coat 3y ago
    The confusion is to assume "runtime" is statically defined. JIT generates code which omits type information that's determined not to be needed in the context of the compiled method/trace/class/module. That code still "runs" it's "runtime".
    - insanitybit 3y ago
      Yes, the types that JIT omits are dynamic types.
deleted 3y ago
[deleted]