5 ms·

no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.

by nsonha 4y ago

camgunz 4y ago
Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
- nsonha 4y ago
  The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
  - camgunz 4y ago
    > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
    - nsonha 4y ago
      No one says you have to stop writing tests when you have types. You can have less tests when you have more types. There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that. You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation, rather than a decorative one. Im just too tired at this point to address the comment that having more types is somehow a burden on eng velocity while having more tests isn’t. In reality, you never have nearly as many tests as you ideally need, but you can add more types more easily and it will help people reason about your system much easier. Speaking of which, tests are often way too verbose it hurts readability aka the ability to reason about your system
      - camgunz 4y ago
        > No one says you have to stop writing tests when you have types. My point is that if you have tests, you probably don't need types, and since you really oughta have tests, the benefits of mainstream type systems are overstated. A lot of arguments in this thread are essentially "types have benefits you can't get anywhere else", but you can get them with tests. When it comes to verifying program correctness, tests are a super set of types' functionality. > You can have less tests when you have more types. Can you? In my dynamic language work the tests aren't doing type checks, usually there's some kind of validation library doing that. Generally the tests are doing work that types can't. > There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that. I guess we can disagree about "overhaul", but IMO adding a compiler, new dependencies (types) and entirely new syntax to your toolchain qualifies. If that doesn't, what does? > You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation A few things foil this: - using `any` - using untyped libraries - taking advantage of gradual typing - unhelpful type soup "Type soup" really bears expanding: subscribeToMore( options: { document: DocumentNode, variables?: TVariables, updateQuery?: Function, onError?: Function } ) => () => void I like Apollo and use it a lot, but I would say this signature from their docs [0] tells you almost nothing. There are some nice things, in particular the "pass an object blob as args" persists in JS despite having default and optional parameter support for a long time now, so TS adds nice description there (of course it would be better to just use optional parameters). But like, surprise surprise `document` is a DocumentNode, `variables` is... `TVariables` (whatever "T" might mean here), and it returns a function that does... well who knows (docs say it terminates the subscription, which I never would have guessed). It could be called "deleteDocument", and the types don't contradict that in any way. Further, these types don't verify any behavior. They can't prove to you that `onError` is called when an error occurs. They can't prove to you that you will continue to receive data when it's updated. They can't prove to you that you subscribed to the specified document. On and on. There's a reason that high-reliability environments use tests, even though they're using strongly typed languages like Ada and Eiffel, and that's because type systems cannot fully specify a program's behavior. [0]: https://www.apollographql.com/docs/react/api/react/hooks/#subscribetomore https://www.apollographql.com/docs/react/api/react/hooks/#su...

no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.

by nsonha 4y ago

no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.

camgunz 4y ago

Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.

nsonha 4y ago
The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
- camgunz 4y ago
  > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
  - nsonha 4y ago
    No one says you have to stop writing tests when you have types. You can have less tests when you have more types. There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that. You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation, rather than a decorative one. Im just too tired at this point to address the comment that having more types is somehow a burden on eng velocity while having more tests isn’t. In reality, you never have nearly as many tests as you ideally need, but you can add more types more easily and it will help people reason about your system much easier. Speaking of which, tests are often way too verbose it hurts readability aka the ability to reason about your system
    - camgunz 4y ago
      > No one says you have to stop writing tests when you have types. My point is that if you have tests, you probably don't need types, and since you really oughta have tests, the benefits of mainstream type systems are overstated. A lot of arguments in this thread are essentially "types have benefits you can't get anywhere else", but you can get them with tests. When it comes to verifying program correctness, tests are a super set of types' functionality. > You can have less tests when you have more types. Can you? In my dynamic language work the tests aren't doing type checks, usually there's some kind of validation library doing that. Generally the tests are doing work that types can't. > There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that. I guess we can disagree about "overhaul", but IMO adding a compiler, new dependencies (types) and entirely new syntax to your toolchain qualifies. If that doesn't, what does? > You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation A few things foil this: - using `any` - using untyped libraries - taking advantage of gradual typing - unhelpful type soup "Type soup" really bears expanding: subscribeToMore( options: { document: DocumentNode, variables?: TVariables, updateQuery?: Function, onError?: Function } ) => () => void I like Apollo and use it a lot, but I would say this signature from their docs [0] tells you almost nothing. There are some nice things, in particular the "pass an object blob as args" persists in JS despite having default and optional parameter support for a long time now, so TS adds nice description there (of course it would be better to just use optional parameters). But like, surprise surprise `document` is a DocumentNode, `variables` is... `TVariables` (whatever "T" might mean here), and it returns a function that does... well who knows (docs say it terminates the subscription, which I never would have guessed). It could be called "deleteDocument", and the types don't contradict that in any way. Further, these types don't verify any behavior. They can't prove to you that `onError` is called when an error occurs. They can't prove to you that you will continue to receive data when it's updated. They can't prove to you that you subscribed to the specified document. On and on. There's a reason that high-reliability environments use tests, even though they're using strongly typed languages like Ada and Eiffel, and that's because type systems cannot fully specify a program's behavior. [0]: https://www.apollographql.com/docs/react/api/react/hooks/#subscribetomore https://www.apollographql.com/docs/react/api/react/hooks/#su...