3 ms·

Yes: your program fails at runtime, and you have no idea of where the problem is, because the place where the type invariants are violated is not related to whe

by devit 8y ago

Yes: your program fails at runtime, and you have no idea of where the problem is, because the place where the type invariants are violated is not related to where an exception is thrown or an incorrect result is produced. It's basically like using and debugging C/C++ code, where it looks like there is a "type system" but in fact you are just arbitrarily manipulating a big byte array that contains all your data and the call stack (except with TypeScript it's a graph of untyped arrays and dictionaries instead).

jeremyjh 8y ago
It is absolutely no different from debugging Javascript. In Javascript you have an expectation of types in your mind, that are not guaranteed. The same is true of Typescript. The difference is, Typescript will catch most exceptions to the type system at compile time. It is not sound, but is extremely useful.
- acjohnson55 8y ago
  "Most" isn't necessarily a good thing, because it can lead to a false sense of security. For example, if you start thinking, "no need to check for null here, because the types won't allow it", you're open to being surprised when a null sneaks in at run-time. So you have to deal with the overhead of both types and run-time guards.
  - RyanCavanaugh 8y ago
    It's not like it fails on a 1d20 roll. Most unsound languages will only cause runtime problems if you are proactively trying to construct things which defeat the type system.
  - jeremyjh 8y ago
    This is the sort of thought people have when they haven't actually used the language much. It is also an example of something Typescript is really good at. If you try to use an `any` value - or any nullable typed value - that hasn't been checked for null, it is a type error. Sure you could write a type definition for a Javascript function that is a lie and say that it cannot return a null when it can, and then guess what? You'll get a runtime error and debugging it is identical to Javascript. In fact I do not know of any language that is actually safe at it's FFI boundaries. Rust isn't, Haskell isn't. You could get a value back from a C function that you were told would be allocated 64-bytes and actually it was only 32, so you'll have an overflow somewhere later. The Typescript / Javascript boundary is similar, though obviously not as dangerous.
    - acjohnson55 8y ago
      The problem is in just how much boundary there tends to be, since many TypeScript programs are heavily mixed with ordinary JS. I would agree with you for programs that exclusively use TS for application code.
Too 8y ago
People assuming C is a big byte array is one of the most common source of difficult to debug bugs. People write code assuming they can manipulate bits and bytes here and there using pointer arithmetic because "they know" that this offset into an array will align with this member of that type. Then they come crying that the compiler is broken and change their optimizer setting to -O0 .... I still like your analogy, as when things are down executing it is as you say just on big byte array, you should never try to map this array to the language manually though.

by devit 8y ago

jeremyjh 8y ago

It is absolutely no different from debugging Javascript. In Javascript you have an expectation of types in your mind, that are not guaranteed. The same is true of Typescript. The difference is, Typescript will catch most exceptions to the type system at compile time. It is not sound, but is extremely useful.

acjohnson55 8y ago
"Most" isn't necessarily a good thing, because it can lead to a false sense of security. For example, if you start thinking, "no need to check for null here, because the types won't allow it", you're open to being surprised when a null sneaks in at run-time. So you have to deal with the overhead of both types and run-time guards.
- RyanCavanaugh 8y ago
  It's not like it fails on a 1d20 roll. Most unsound languages will only cause runtime problems if you are proactively trying to construct things which defeat the type system.
- jeremyjh 8y ago
  This is the sort of thought people have when they haven't actually used the language much. It is also an example of something Typescript is really good at. If you try to use an `any` value - or any nullable typed value - that hasn't been checked for null, it is a type error. Sure you could write a type definition for a Javascript function that is a lie and say that it cannot return a null when it can, and then guess what? You'll get a runtime error and debugging it is identical to Javascript. In fact I do not know of any language that is actually safe at it's FFI boundaries. Rust isn't, Haskell isn't. You could get a value back from a C function that you were told would be allocated 64-bytes and actually it was only 32, so you'll have an overflow somewhere later. The Typescript / Javascript boundary is similar, though obviously not as dangerous.
  - acjohnson55 8y ago
    The problem is in just how much boundary there tends to be, since many TypeScript programs are heavily mixed with ordinary JS. I would agree with you for programs that exclusively use TS for application code.

Too 8y ago

People assuming C is a big byte array is one of the most common source of difficult to debug bugs. People write code assuming they can manipulate bits and bytes here and there using pointer arithmetic because "they know" that this offset into an array will align with this member of that type. Then they come crying that the compiler is broken and change their optimizer setting to -O0 .... I still like your analogy, as when things are down executing it is as you say just on big byte array, you should never try to map this array to the language manually though.