6 ms·

Having partial type safety is like having a no peeing section in the pool.

dguo 7y ago
To your point, I do think it depends on the team and their ability to make good judgment calls. But type safety is a spectrum anyway. One could say that not having dependent types is like having a swimming pool without a lifeguard. Should every swimming pool in the world have a lifeguard? Probably not.
- lmm 7y ago
  Lifeguards are expensive. Basic typing is damn near free. More languages should adopt dependent typing, but for the moment there are languages that lack it and offer enough advantages to make up for that. I don't think you can say the same thing for languages without a true type system (one in which unsoundness is the exception rather than the rule) - there are too many good alternatives for it to be worth compromising on that.
jjeaff 7y ago
That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.
- tristanstcyr 7y ago
  If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.
simplify 7y ago
Would you say the same about incomplete testing?
- gregkerzhner 7y ago
  no - proper unit testing mocks dependencies, so untested dependencies shouldn't affect tests. However, if there are typing issues in your dependencies, even the code that strongly typed can crash as a result if it uses those dependencies.
cdata 7y ago
A more accurate remix of this analogy (for the TypeScript case) is that it is like building a wall around the part of the pool that you actually swim in, and allowing that folks can pee all they want as long as it is outside of the boundary you built.
- lmm 7y ago
  Does Typescript actually add runtime checks, even for e.g. container types? I'd be very surprised if it did, because that would mean a lot of overhead.
  - tristanstcyr 7y ago
    It does not.
xsmasher 7y ago
It makes it really easy to add type safety to parts of a legacy project as you go along; for new projects you can enforce type safety with a linter or stricter compiler settings.

dguo 7y ago

To your point, I do think it depends on the team and their ability to make good judgment calls. But type safety is a spectrum anyway. One could say that not having dependent types is like having a swimming pool without a lifeguard. Should every swimming pool in the world have a lifeguard? Probably not.

lmm 7y ago
Lifeguards are expensive. Basic typing is damn near free. More languages should adopt dependent typing, but for the moment there are languages that lack it and offer enough advantages to make up for that. I don't think you can say the same thing for languages without a true type system (one in which unsoundness is the exception rather than the rule) - there are too many good alternatives for it to be worth compromising on that.

jjeaff 7y ago

That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.

tristanstcyr 7y ago
If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.

simplify 7y ago

Would you say the same about incomplete testing?

gregkerzhner 7y ago
no - proper unit testing mocks dependencies, so untested dependencies shouldn't affect tests. However, if there are typing issues in your dependencies, even the code that strongly typed can crash as a result if it uses those dependencies.

cdata 7y ago

A more accurate remix of this analogy (for the TypeScript case) is that it is like building a wall around the part of the pool that you actually swim in, and allowing that folks can pee all they want as long as it is outside of the boundary you built.

lmm 7y ago
Does Typescript actually add runtime checks, even for e.g. container types? I'd be very surprised if it did, because that would mean a lot of overhead.
- tristanstcyr 7y ago
  It does not.

xsmasher 7y ago

It makes it really easy to add type safety to parts of a legacy project as you go along; for new projects you can enforce type safety with a linter or stricter compiler settings.