5 ms·

How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it.

How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.

cm2187 8y ago
Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.
- core-questions 8y ago
  I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help enough to be worth it?
  - dunefox 8y ago
    Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
    - dictum 8y ago
      The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
      - mannykannot 8y ago
        If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.
  - SatvikBeri 8y ago
    I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.
    - cm2187 8y ago
      In fact with the right IDE, static typing makes refactoring much easier. Right click on a parameter, rename, and it will rename anywhere where it is relevant (as opposed to a replace all).
      - SatvikBeri 8y ago
        To be fair, you can do that with dynamically typed Python and a good IDE too. I've used PyCharm on Python 2.7 for years and never really had any issues with refactoring.
  - hectormalot 8y ago
    I’ve been programming in Ruby for years (as a hobby / small passive income project), and about a year ago decided to reimplement a small part of it in Go. Both for learning and because it was a bottleneck in the application. Recently I needed to fix some things in the original Ruby code, and it felt like freeclimbing after getting used to ropes... I called a function and started wondering how I could have any guarantees that it returned something useful. Benefits of static typing really ‘clicked’ for me at that moment. I still love ruby though
  - mannykannot 8y ago
    You could probably become a better developer if you did more thinking ahead (or 'planning', as you put it.) If you are writing a bunch of variables, and you don't have a good idea of precisely what data they hold, there is very little chance that your program will work properly first time (not that thinking ahead guarantees it, of course, but it improves your odds.) For every programmer, there comes a point where you cannot effectively track how everything needs to fit together to work, unless you are doing some sort of planning. Duck typing only works when it works, which is not as trivial a statement as it might first seem.
    - core-questions 8y ago
      Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.
      - ecnahc515 8y ago
        If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems? Numerically speaking, if the first 9 attempts didn't work, then 90% of the time you ran it after coding, it was still broken. The fact that the program was broken a majority of the time you developed it should make you skeptical if it's even "correct' after you've determined it to be "finished". I understand you picked random examples, but this is still relevant. It seems to me like you're arguing a common argument about picking tools which is "I've always done it this way, and it works for me, so why look for anything better?"
        adrianhel 8y ago
        I agree with the sentiment, but types don't guarantee correctness. I would put such a developer on "TDD-duty", be thorough about code reviews and do some pair programming.
  - 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.
- recursive 8y ago
  `let val = 3;` This statement can be statically analyzed using the inferred static types that are already present. There is a lot of idiomatic javascript code that already has inferr-able static types in it. In fact, if you turn on the "implicit any" option in the typescript compiler, then you never need to add any types.
- marcosdumay 8y ago
  Static types are one kind of static analysis, but there is a lot more that can be done. A linter can look at anything from micro-quality like "don't use more than one ++ operator at the same line" or "there's an = at this if test, this is probably wrong" to macro ones like "I couldn't prove your program terminates", "I couldn't prove that memory does not leak", or "a deadlock can happen here".
_bxg1 8y ago
Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns. Complex JavaScript codebases used to mostly be this way, but in recent years the JavaScript community has seen a huge influx of new, inexperienced programmers. There are obvious downsides to this, but one upside is that they don't have the pretense of being able to do everything perfectly without help, making them less resistant to things like TypeScript.
- AdeptusAquinas 8y ago
  Being very careful not to start a flamewar, my armchair analysis is the opposite: JS has seen a large influx of serious backend developers, who generally have no time for silly arguments against static typing.
  - geoelectric 8y ago
    My guess is it's some of both, really. There's the old saw about levels of SWE expertise: * Beginner: doesn't know much and knows it * Intermediate: knows a lot, hasn't lived with the consequences * Expert: knows a lot, including when not to use what they know The two comments here seem to be articulating the community shifting between I->B and I->E respectively. I think it's safe to say we have both a maturing developer base and a huge influx of newbies. That intermediate "look what I can do!" stage still exists, probably as much as ever, but is being professionally tempered by the caution inherent in the other two cohorts. The Intermediate stage is the most fun to watch, though, and probably a lot of what drives innovation. The coolest projects come from people who ostensibly should've known better than to try that thing.

cm2187 8y ago

Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.

core-questions 8y ago
I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help enough to be worth it?
- dunefox 8y ago
  Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
  - dictum 8y ago
    The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
    - mannykannot 8y ago
      If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.
- SatvikBeri 8y ago
  I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.
  - cm2187 8y ago
    In fact with the right IDE, static typing makes refactoring much easier. Right click on a parameter, rename, and it will rename anywhere where it is relevant (as opposed to a replace all).
    - SatvikBeri 8y ago
      To be fair, you can do that with dynamically typed Python and a good IDE too. I've used PyCharm on Python 2.7 for years and never really had any issues with refactoring.
- hectormalot 8y ago
  I’ve been programming in Ruby for years (as a hobby / small passive income project), and about a year ago decided to reimplement a small part of it in Go. Both for learning and because it was a bottleneck in the application. Recently I needed to fix some things in the original Ruby code, and it felt like freeclimbing after getting used to ropes... I called a function and started wondering how I could have any guarantees that it returned something useful. Benefits of static typing really ‘clicked’ for me at that moment. I still love ruby though
- mannykannot 8y ago
  You could probably become a better developer if you did more thinking ahead (or 'planning', as you put it.) If you are writing a bunch of variables, and you don't have a good idea of precisely what data they hold, there is very little chance that your program will work properly first time (not that thinking ahead guarantees it, of course, but it improves your odds.) For every programmer, there comes a point where you cannot effectively track how everything needs to fit together to work, unless you are doing some sort of planning. Duck typing only works when it works, which is not as trivial a statement as it might first seem.
  - core-questions 8y ago
    Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.
    - ecnahc515 8y ago
      If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems? Numerically speaking, if the first 9 attempts didn't work, then 90% of the time you ran it after coding, it was still broken. The fact that the program was broken a majority of the time you developed it should make you skeptical if it's even "correct' after you've determined it to be "finished". I understand you picked random examples, but this is still relevant. It seems to me like you're arguing a common argument about picking tools which is "I've always done it this way, and it works for me, so why look for anything better?"
      - adrianhel 8y ago
        I agree with the sentiment, but types don't guarantee correctness. I would put such a developer on "TDD-duty", be thorough about code reviews and do some pair programming.
- 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.
recursive 8y ago
`let val = 3;` This statement can be statically analyzed using the inferred static types that are already present. There is a lot of idiomatic javascript code that already has inferr-able static types in it. In fact, if you turn on the "implicit any" option in the typescript compiler, then you never need to add any types.
marcosdumay 8y ago
Static types are one kind of static analysis, but there is a lot more that can be done. A linter can look at anything from micro-quality like "don't use more than one ++ operator at the same line" or "there's an = at this if test, this is probably wrong" to macro ones like "I couldn't prove your program terminates", "I couldn't prove that memory does not leak", or "a deadlock can happen here".

_bxg1 8y ago

Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns. Complex JavaScript codebases used to mostly be this way, but in recent years the JavaScript community has seen a huge influx of new, inexperienced programmers. There are obvious downsides to this, but one upside is that they don't have the pretense of being able to do everything perfectly without help, making them less resistant to things like TypeScript.

AdeptusAquinas 8y ago
Being very careful not to start a flamewar, my armchair analysis is the opposite: JS has seen a large influx of serious backend developers, who generally have no time for silly arguments against static typing.
- geoelectric 8y ago
  My guess is it's some of both, really. There's the old saw about levels of SWE expertise: * Beginner: doesn't know much and knows it * Intermediate: knows a lot, hasn't lived with the consequences * Expert: knows a lot, including when not to use what they know The two comments here seem to be articulating the community shifting between I->B and I->E respectively. I think it's safe to say we have both a maturing developer base and a huge influx of newbies. That intermediate "look what I can do!" stage still exists, probably as much as ever, but is being professionally tempered by the caution inherent in the other two cohorts. The Intermediate stage is the most fun to watch, though, and probably a lot of what drives innovation. The coolest projects come from people who ostensibly should've known better than to try that thing.