3 ms·

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 overha

by 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...

by nsonha 4y ago

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...