3 ms·

The post isn't about dynamic validation; it's about static type checking of APIs, which is impossible in JavaScript.

cryptica 7y ago
My point is that static type checking of APIs does not solve any new problem which static type checking in general does not already solve - That's why I don't agree that it solves API woes specifically. My argument is that it adds no value in that area. If a developer already does input validation correctly with JavaScript, then switching to TypeScript will not add any value for them in that area. Furthermore, my first argument (about TS giving false confidence) is that TypeScript does not make it any more likely that an unskilled developer would be able to identify and solve the problem of schema validation when compared to JavaScript... From the unskilled developer's point of view, false confidence (which TypeScript can sometimes provide) is worse than having no confidence at all (which is what JavaScript always provides). Type checking is 100% about confidence; it gives more confidence. Confidence and correctness are two completely different things and I wanted to point out that there is such a thing as false confidence.
- gary_bernhardt 7y ago
  I rename the "email" key in our register endpoint to "emailAddress" and all code that touches that key turns red less than 1s later, whether it's in the client or server. Edit: All of these edits to your posts after I've already replied are very confusing.
  - cryptica 7y ago
    What you're describing applies to static type checking in general. I don't argue this point. Sorry about the edits. It's very difficult to express such things unambiguously. I'm more concerned about the effects of the post's title on people's programming practices than the actual content of it. HN does tend to have this effect unfortunately.
    - cryptica 7y ago
      Also, I should point out that in terms of achieving correctness, it's possible to get similar value as what you're describing simply by having good tests. I don't want to get into this argument now though because it could last forever but hopefully it highlights why it's important to keep arguments tightly bounded and not make blanket statements when the domain is so large and complex and we can go off on a tangent in an infinite number of directions. Ultimately, I enjoy JavaScript and I don't want future employers to force me to use TypeScript because of articles like yours (with those kinds of titles)... I was already forced to use TypeScript at my last company, it went well but it would have been even better if founders had let me and my team use JavaScript... For one, I might not have quit the company. I was tired of debugging mangled JavaScript (compiled from TS) using vim over SSH whenever there was a problem (it was a large decentralized P2P project so often that was the only way to debug it). The drawbacks of TS were definitely not worth its benefits for that specific project.
      - gary_bernhardt 7y ago
        You may enjoy this talk: https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology
        daotoad 7y ago
        Great video. If you want to play with a powerful type system check out Raku. It offers gradual types that are a hybrid of dynamic and statically checked. Basically, you can define a `subset` of a type with a validation predicate. Subsets can be named or anonymous and inline in function signatures. Another thing that made me think of Raku was your discussion of NULLs. Any type container can be defined or undefined, an undefined Array container `isa` Array. But you can specify whether your annotation means to be specifically only defined or undefined members of the type. So `Int:D` is a defined integer, whereas `Int:U` is undefined, and `Int` is either. The type specifications combined with multiple dispatch cam make for pretty code. It's a really interesting language and, in my opinion, worth checking out. It would be great to hear your thoughts on it.
        6y ago

My point is that static type checking of APIs does not solve any new problem which static type checking in general does not already solve - That's why I don't agree that it solves API woes specifically. My argument is that it adds no value in that area. If a developer already does input validation correctly with JavaScript, then switching to TypeScript will not add any value for them in that area. Furthermore, my first argument (about TS giving false confidence) is that TypeScript does not make it any more likely that an unskilled developer would be able to identify and solve the problem of schema validation when compared to JavaScript... From the unskilled developer's point of view, false confidence (which TypeScript can sometimes provide) is worse than having no confidence at all (which is what JavaScript always provides). Type checking is 100% about confidence; it gives more confidence. Confidence and correctness are two completely different things and I wanted to point out that there is such a thing as false confidence.

gary_bernhardt 7y ago
I rename the "email" key in our register endpoint to "emailAddress" and all code that touches that key turns red less than 1s later, whether it's in the client or server. Edit: All of these edits to your posts after I've already replied are very confusing.
- cryptica 7y ago
  What you're describing applies to static type checking in general. I don't argue this point. Sorry about the edits. It's very difficult to express such things unambiguously. I'm more concerned about the effects of the post's title on people's programming practices than the actual content of it. HN does tend to have this effect unfortunately.
  - cryptica 7y ago
    Also, I should point out that in terms of achieving correctness, it's possible to get similar value as what you're describing simply by having good tests. I don't want to get into this argument now though because it could last forever but hopefully it highlights why it's important to keep arguments tightly bounded and not make blanket statements when the domain is so large and complex and we can go off on a tangent in an infinite number of directions. Ultimately, I enjoy JavaScript and I don't want future employers to force me to use TypeScript because of articles like yours (with those kinds of titles)... I was already forced to use TypeScript at my last company, it went well but it would have been even better if founders had let me and my team use JavaScript... For one, I might not have quit the company. I was tired of debugging mangled JavaScript (compiled from TS) using vim over SSH whenever there was a problem (it was a large decentralized P2P project so often that was the only way to debug it). The drawbacks of TS were definitely not worth its benefits for that specific project.
    - gary_bernhardt 7y ago
      You may enjoy this talk: https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology
      - daotoad 7y ago
        Great video. If you want to play with a powerful type system check out Raku. It offers gradual types that are a hybrid of dynamic and statically checked. Basically, you can define a `subset` of a type with a validation predicate. Subsets can be named or anonymous and inline in function signatures. Another thing that made me think of Raku was your discussion of NULLs. Any type container can be defined or undefined, an undefined Array container `isa` Array. But you can specify whether your annotation means to be specifically only defined or undefined members of the type. So `Int:D` is a defined integer, whereas `Int:U` is undefined, and `Int` is either. The type specifications combined with multiple dispatch cam make for pretty code. It's a really interesting language and, in my opinion, worth checking out. It would be great to hear your thoughts on it.
      - 6y ago