3 ms·

Documentation will not save you the day you decide to rename a function or change its signature. Static typing will.

qwertyuiop924 10y ago
...No, it won't. It might make the refactoring a little easier, but with various tools, you can check all the call sites and see if you fixed it. Sure, your compiler won't tell you what's wrong, but your REPL and your tests will.
- FrancoDiaz 10y ago
  Yes, given enough time for enough manual work, and enough tests, and enough code review.... The whole point is not to have to do this stuff manually, which is very error prone. Ad-hoc REPL work, and tests are very likely to have missed something.
  - mercurial 10y ago
    Precisely.
- mercurial 10y ago
  It will absolutely save you, because it will complain loudly about every broken call site and prevent the broken code from making it to production (assuming you didn't use any tricks with any). Tests may or may not help (I have yet to see a codebase with perfect test coverage).
- stcredzero 10y ago
  Sure, your compiler won't tell you what's wrong, but your REPL and your tests will. If a REPL and tests make you powerful, then a type system that doesn't drag you down and good tooling around that will only make you more powerful.
Roboprog 10y ago
It depends on your tools. I refactor JS stuff in intelliJ from time to time, no big deal, at least for rename. (1) OTOH, if you don't have plugins for things like Struts or Spring (faking the desperately needed dynamicism in config files), good luck safely refactoring your "static" typed Java (2). But once have "trained" your IDE where to look, you are back in business again. 1: it's easier to refactor JS if you restrict the scope of identifiers, of course. For starters, this means NOT naively making every function and variable in the global namespace and/or scattered in inline <script> fragments. 2: many other languages dragged into these discussions since there is some general philosophy of compile time vs runtime types discussed on this page.

...No, it won't. It might make the refactoring a little easier, but with various tools, you can check all the call sites and see if you fixed it. Sure, your compiler won't tell you what's wrong, but your REPL and your tests will.

FrancoDiaz 10y ago
Yes, given enough time for enough manual work, and enough tests, and enough code review.... The whole point is not to have to do this stuff manually, which is very error prone. Ad-hoc REPL work, and tests are very likely to have missed something.
- mercurial 10y ago
  Precisely.
mercurial 10y ago
It will absolutely save you, because it will complain loudly about every broken call site and prevent the broken code from making it to production (assuming you didn't use any tricks with any). Tests may or may not help (I have yet to see a codebase with perfect test coverage).
stcredzero 10y ago
Sure, your compiler won't tell you what's wrong, but your REPL and your tests will. If a REPL and tests make you powerful, then a type system that doesn't drag you down and good tooling around that will only make you more powerful.

Roboprog 10y ago

It depends on your tools. I refactor JS stuff in intelliJ from time to time, no big deal, at least for rename. (1) OTOH, if you don't have plugins for things like Struts or Spring (faking the desperately needed dynamicism in config files), good luck safely refactoring your "static" typed Java (2). But once have "trained" your IDE where to look, you are back in business again. 1: it's easier to refactor JS if you restrict the scope of identifiers, of course. For starters, this means NOT naively making every function and variable in the global namespace and/or scattered in inline <script> fragments. 2: many other languages dragged into these discussions since there is some general philosophy of compile time vs runtime types discussed on this page.