3 ms·

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it h

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. How would you gracefully handle that without dynamic types?

Retra 9y ago
If the APIs are different, they are differently typed. You still don't need dynamic types, you need to correctly account for both APIs. Doing it gracefully requires that you say what 'graceful' means in this context. It may or may not mean doing it correctly.
- ridiculous_fish 9y ago
  Having a single static type system that captures all differences across all versions of all browsers is not realistic. But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed. You want to type check with the actual runtime environment, not just a static guess at it. I guess by "graceful," not segfaulting would be a good start.
  - sds2 9y ago
    > Having a single static type system that captures all differences across all versions of all browsers is not realistic. Why? Standards and abstractions are useful. > But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed. At that case your program's behaviour may become inconsistent > You want to type check with the actual runtime environment, not just a static guess at it. That's not typechecking and there's no guarantee that your program will work with dynamic typing if the API changes. > I guess by "graceful," not segfaulting would be a good start. Is runtime type error better? If the type of your value changes and your assumption was false about the type then it can fail anyway with an incorrect function call.
jnbiche 9y ago
> code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. If you are referring to an second API that is differently typed, what happens if you do use a dynamically-typed language there? Then you're running under the assumption of one type when you actually are getting another? Your program is in an inconsistent state. Very often, at least in languages like JavaScript and Python, that means that very strange and obscure bugs will eventually start popping up. Unfortunately, the same can happen with static typed languages receiving data from an external API unless you're doing runtime checks of external APIs (which is often a good idea). So the ideal thing to do is to runtime validate external APIs and account for any differences that turn up in the APIs. Ignoring the differences in any language is very often the start of downstream bugs, not a graceful way of handling the problem.

Retra 9y ago

If the APIs are different, they are differently typed. You still don't need dynamic types, you need to correctly account for both APIs. Doing it gracefully requires that you say what 'graceful' means in this context. It may or may not mean doing it correctly.

ridiculous_fish 9y ago
Having a single static type system that captures all differences across all versions of all browsers is not realistic. But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed. You want to type check with the actual runtime environment, not just a static guess at it. I guess by "graceful," not segfaulting would be a good start.
- sds2 9y ago
  > Having a single static type system that captures all differences across all versions of all browsers is not realistic. Why? Standards and abstractions are useful. > But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed. At that case your program's behaviour may become inconsistent > You want to type check with the actual runtime environment, not just a static guess at it. That's not typechecking and there's no guarantee that your program will work with dynamic typing if the API changes. > I guess by "graceful," not segfaulting would be a good start. Is runtime type error better? If the type of your value changes and your assumption was false about the type then it can fail anyway with an incorrect function call.

jnbiche 9y ago

> code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. If you are referring to an second API that is differently typed, what happens if you do use a dynamically-typed language there? Then you're running under the assumption of one type when you actually are getting another? Your program is in an inconsistent state. Very often, at least in languages like JavaScript and Python, that means that very strange and obscure bugs will eventually start popping up. Unfortunately, the same can happen with static typed languages receiving data from an external API unless you're doing runtime checks of external APIs (which is often a good idea). So the ideal thing to do is to runtime validate external APIs and account for any differences that turn up in the APIs. Ignoring the differences in any language is very often the start of downstream bugs, not a graceful way of handling the problem.