4 ms·
I'm actually kind of surprised that programmers, of all people, would oppose guard-rails. At university, it was a meme that no one's C program ever compiled th
by Zarel 8y ago
I'm actually kind of surprised that programmers, of all people, would oppose guard-rails.
At university, it was a meme that no one's C program ever compiled the first time they tried.
I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on AoC was closer to 50%, and I was like #30 or so on the leaderboard [1]). But to do it perfectly, in real-world code? That I don't believe.
The nice thing about static typing is about catching mistakes earlier, and making it easier to figure out what your mistake was. Without the type annotation on the function, when you get a crash a few days later, it's harder to figure out "is the function wrong, or is the code calling the function wrong?" With it, those questions are automatically answered.
The best I've heard is that for short scripts, static typing doesn't help _enough_ to be worth the extra time it takes. But with modern type inference, it takes very little extra time at all.
And the extra time it does take, to write out interfaces and stuff, you can avoid in TypeScript with type assertions and `any` assertions. But honestly, it's usually worth it: It's not like you _don't_ plan out the interface; you just used to keep them memorized instead of writing them down, and then regret it a few weeks later when you want to make a change.
[1] To be fair, it was 50% because I was optimizing for programming speed for the leaderboard rather than accuracy; I'm sure I could have gotten closer to 90% if I were optimizing for accuracy. But anyone who argues that avoiding static types saves time has to accept that you make a lot more mistakes if you're trying to save time.
- _bxg1 8y ago> it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.log(foo.bar1); console.log(foo.bar2); // example 2 for(let i = 0; i < 3; i++) { console.log(foo['bar' + i]) } Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. There are advantages of being able to do the second thing - more code reuse, possibly less refactoring needed. But it's impossible to verify that those properties exist on that object without running the code. The argument is that oftentimes, the type checking is more valuable than the loss of "creative" freedom. But it does mean limiting the kinds of things you can do.
- Zarel 8y ago> Ah but see, the compiler is a guard-rail. Yes, I agree. It's a guard-rail which is missing in scripting languages like JavaScript and Ruby, and which some people are resisting adding. > Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. With type assertions, it's not really limiting at all. For instance, I'd write example 2 as: for (let i = 0; i < 3; i++) { console.log(foo['bar' + i as keyof typeof foo]); } If you weren't as experienced with TypeScript, you can also just throw around `any` assertions until the problem goes away: let foo: any = { bar0: 12, bar1: 14, bar2: 16 }; Or if you wanted to be tricky, you could even just assert a specific key: for (let i = 0; i < 3; i++) { console.log(foo['bar' + i as 'bar0']); } It's true that there are a lot of things typecheckers can't check. But that's no reason to give up on the things they _can_ check.
- recursive 8y agoIn case anyone missed it, example 2 is allowed in typescript.
- Zarel 8y agoIt's not, not without an assertion: https://i.imgur.com/DJjzPDF.png https://i.imgur.com/DJjzPDF.png Well, it's allowed in that it will still compile the code (because TypeScript is a superset of JavaScript), but it'll still yell at you.
- recursive 8y agoYes, without an assertion. Just change your compiler options. https://www.typescriptlang.org/play/#src=%20%20let%20foo%20%3D%20%7B%0D%0A%20%20%20%20bar0%3A%2012%2C%0D%0A%20%20%20%20bar1%3A%2014%2C%0D%0A%20%20%20%20bar2%3A%2016%0D%0A%20%20%7D%0D%0A%0D%0A%20%20%2F%2F%20example%201%0D%0A%20%20console.log(foo.bar0)%3B%0D%0A%20%20console.log(foo.bar1)%3B%0D%0A%20%20console.log(foo.bar2)%3B%0D%0A%0D%0A%20%20%2F%2F%20example%202%0D%0A%20%20for(let%20i%20%3D%200%3B%20i%20%3C%203%3B%20i%2B%2B)%20%7B%0D%0A%20%20%20%20console.log(foo%5B'bar'%20%2B%20i%5D)%0D%0A%20%20%7D%0D%0A%20%20 https://www.typescriptlang.org/play/#src=%20%20let%20foo%20%...