4 ms·

If the code is well written... In a good environment like you have in many Smalltalks... No one who really knows how to write in a dynamic language puts stuff

If the code is well written... In a good environment like you have in many Smalltalks... No one who really knows how to write in a dynamic language puts stuff like that in typical code That's the problem. You're talking about some hypothetical, Smalltalk environment, where some expert dynamic language programmers always do "the right thing".

qwertyuiop924 10y ago
Okay then, but if you're not documenting your functions, which is the most important thing, you shouldn't be working on a large project with other people in any case.
- mercurial 10y ago
  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.
stcredzero 10y ago
That's the problem. You're talking about some hypothetical, Smalltalk environment, where some expert dynamic language programmers always do "the right thing". No, I'm talking about a place I've worked, certain subsets of code in other places I've worked, code at customer's shops, and most of the standard library of Smalltalk. True, I've also seen what can go wrong in Smalltalk. But in my experience, this isn't worse than what can go wrong in other languages, dynamic and static.
- anko 10y ago
  I think the argument is not "You can't write something maintainable in a dynamic language" - it's more like "Given the majority of projects, static typing would have helped readability". Since in SDLC maintenance is like 80%, and most of the time code isn't written amazingly, it seems pragmatic to have static typing. I love Dynamic languages as much as the next guy (Ruby and clojure are pretty great in my book) but in my career, I get my guys to write in statically typed languages.
  - stcredzero 10y ago
    it's more like "Given the majority of projects, static typing would have helped readability". Not so much readability. That comes mostly from good naming in Smalltalk, and thinking about, "What if I had to understand this through senders/implementors searches?" However, in my experience, it helps maintainability. In general, I didn't need type annotations to help me understand the system. Good Smalltalk is about message passing, so you understood the system through who sends what to whom. What I did experience a lack of, were 100% ironclad guarantees in a couple of instances where we needed to be 100% sure about something. And yes, it is pragmatic to have static typing for the long term!

qwertyuiop924 10y ago

Okay then, but if you're not documenting your functions, which is the most important thing, you shouldn't be working on a large project with other people in any case.

mercurial 10y ago
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.

stcredzero 10y ago

That's the problem. You're talking about some hypothetical, Smalltalk environment, where some expert dynamic language programmers always do "the right thing". No, I'm talking about a place I've worked, certain subsets of code in other places I've worked, code at customer's shops, and most of the standard library of Smalltalk. True, I've also seen what can go wrong in Smalltalk. But in my experience, this isn't worse than what can go wrong in other languages, dynamic and static.

anko 10y ago
I think the argument is not "You can't write something maintainable in a dynamic language" - it's more like "Given the majority of projects, static typing would have helped readability". Since in SDLC maintenance is like 80%, and most of the time code isn't written amazingly, it seems pragmatic to have static typing. I love Dynamic languages as much as the next guy (Ruby and clojure are pretty great in my book) but in my career, I get my guys to write in statically typed languages.
- stcredzero 10y ago
  it's more like "Given the majority of projects, static typing would have helped readability". Not so much readability. That comes mostly from good naming in Smalltalk, and thinking about, "What if I had to understand this through senders/implementors searches?" However, in my experience, it helps maintainability. In general, I didn't need type annotations to help me understand the system. Good Smalltalk is about message passing, so you understood the system through who sends what to whom. What I did experience a lack of, were 100% ironclad guarantees in a couple of instances where we needed to be 100% sure about something. And yes, it is pragmatic to have static typing for the long term!