5 ms·

Statically typed languages have a few large advantages over dynamic languages. These include: - Refactoring. Refactoring a large JavaScript codebase (> 100k lo

by johnfn 10y ago

Statically typed languages have a few large advantages over dynamic languages. These include: - Refactoring. Refactoring a large JavaScript codebase (> 100k loc) is nearly impossible and at best incredibly painful, error prone and time consuming. With static types, it becomes a trivial and straightforward process. - Your code is now more discoverable. You can easily find definitons, and discovering all methods and properties on an object is as simple as triggering an autocomplete pop up. - Code is now more readable. Objects are never opaque. You never have to dig through multiple calls just to see what the shape of an object is. It's all right there. For me, the killer app is refactoring. Writing huge amounts of JS is very painful to me because I refactor almost constantly as I add more code. Most dynamic languages have this problem. Static typing changes that completely.

jshen 10y ago
I just want to point out there is very little emporical data on this front which makes almost every statement along the lines of "static is better because ..." or "dynamic is better because ..." to be pure opinion.
jeremiep 10y ago
I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. Static types won't help you refactor a monster class into a structure of arrays. It won't refactor your callback hell into coroutines. It won't refactor your "one-at-a-time" algorithm into batches. Yet these all yield more agility and performance. The thing is, I usually have so much less code when throwing static types out the window that refactorings become a non-issue. I get away with basic Emacs macros and unix tools.
- bsimpson 10y ago
  Or in a GUI: Apple-Shift-F Find: <old name> Replace: <new name> …continue working.
  - shados 10y ago
    Won't work super hot if you have 2 functions with the same name in 2 different modules and you want to rename one and all its usages but not the other. It's quite impressive what VisualStudio + Resharper + plugins or IntelliJ with a few plugins can do in their respective first class languages.
    - jeremiep 10y ago
      I used to like ReSharper but quickly uninstalled it from the large amount of false positives it reported. Back when I did C# last year I was doing 2D skeletal animations in Unity3D and pretty much wrote the most non-idiomatic C# code ever. Everything was bitfields, structures of arrays and integer indices into contiguous memory buffers rather than heap references. The tooling was completely useless there. You can't optimize for cache misses and branch predictions without throwing all that nice typed goodness out the window. As much as types, tests and whatnot can help you, at the end of the day it is impossible to do engineering without understanding what you're doing, regardless of what is there to do heavylifting for you.
  - westoncb 10y ago
    This doesn't actually work. Let's say the variable you'd like to rename is 'label,' and you also have variables named 'labelOne' and 'labelTwo'—see the problem?
  - SiVal 10y ago
    That crosses namespace boundaries and risks hitting embedded parts of names, which means that you can't simply replace all as a general practice. You can inspect each one before replacing and be your own type checker or just go ahead and blast them all blindly. With a little thought, blind replace-all will usually work with small code written very recently by you but will become increasingly error-prone with more code, more developers, over more time. You can, of course, try using case-sensitivity and whole-word search modifiers while trying to maintain naming conventions to keep replace-all working a little longer, but that's just an incomplete and buggy attempt at creating your own watered-down type system, not proving that types aren't useful.
- coldtea 10y ago
  >I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. First, the trivial ones are great and useful refactorings too -- and still difficult in dynamic type systems. Second, static types also benefit the more difficult refactorings that you still have to do manually, by giving you compiler errors and warnings when you botched them at least at the type level. With dynamic languages those need to be done both 100% manual and with no aid. Third, static languages are a superset of dynamic typed languages, so they can do everything the latter can do, while the inverse is not true. You can have a "var" or "variant" etc type in a dynamic language that lets you code exactly like in a dynamic typed language where you want it. (In fact dynamic typed languages are just static type languages with a single type: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... ).
  - jeremiep 10y ago
    I'd rather have tests than types. Unless your type-system is sound; most of them are very, very far from it. You can specify the domain of values with types, but not their ranges. Side-effects fall through unaffected by types as well. I've done plenty of refactorings in huge statically typed codebases; types are a very, very superficial help there. Everything compiles fine but now you're passing 20 to a function whose range is 1-10. Or you're now generating the wrong filenames. To me the overhead of using types outweighs the advantages they bring to the table. If I can help it I'd even choose to have a spec I can enforce at runtime using custom predicates than some vague predefined types with weak semantics or unit tests I have to maintain manually.
    - lloyd-christmas 10y ago
      > I'd rather have tests than types. They aren't mutually exclusive. I'd rather have both.
      - jeremiep 10y ago
        Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to development than agility. I do want types when building native software, because these sit directly on the CPU and have to match the hardware. Other than that I feel they at best give you the illusion of robustness - unless the type-system is actually sound but very, very few are.
- hota_mazi 10y ago
  > I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. These alone are already huge. Think about it for a while, keeping a code base healthy as it goes through evolutions involves a lot of renaming and moving things around. But there are so many more refactorings that are tedious or even dangerous to do manually. For example, switching the parameters of a method, lifting a method in a base class, extracting an interface out of a class and using that interface everywhere in your code base instead of the concrete class, etc... Spend some time reading the extremely long list of refactorings offered by IDEA and Eclipse, it will open your eyes.
- johnfn 10y ago
  > I usually have so much less code when throwing static types out the window that refactorings become a non-issue. This is almost certainly our difference. The utility of static typing is greatly diminished when the codebase is not very large. > Static types won't help you refactor a monster class into a structure of arrays. Sure they will. I mean, sure, it won't be a one-click magic refactor, but that was never the benefit anyways. One strong advantage of static typings is that now you'll know exactly when all your call sites break, so that finding and fixing them will be much more straightforward.
- duaneb 10y ago
  Renaming and moving is still more than you can get with a dynamic language.
stcredzero 10y ago
Statically typed languages have a few large advantages over dynamic languages Fallacies! I'd have said "lies" but I realize you just have limited information. See below. - Refactoring. Refactoring a large JavaScript codebase (> 100k loc) is nearly impossible Really? Refactoring large codebases in VisualWorks Smalltalk was a joy! Hyper nimble. If you stuck to canned refactorings, you had 100% confidence. For years, we were talking about how we could refactor an order of magnitude faster than other environments, and this is still true. - Your code is now more discoverable. You can easily find definitons, and discovering all methods and properties Discovery in Smalltalk was much superior and way more nimble. Combining senders/implementors searches, syntactic pattern matching, and runtime discovery was powerful and joyful to use. - Code is now more readable. Objects are never opaque. You never have to dig through multiple calls I don't know what you're getting at here. No environment has been more transparent to work in than Smalltalk. You don't just get to read a spec of the object -- you actually get to see it and poke and prod the live version of it to verify your understanding and test your theories. (I understand you can do this in languages like C++ -- it's what I use in my day job -- but it's literally an order of magnitude nimbler in Smalltalk.) What you have to say about dynamic languages perhaps has to do with somewhat ad-hoc language design combined with somewhat ad-hoc design of the environment and distribution/execution platform. (Javascript/Web browsers?) It certainly doesn't have to be true for dynamic environments per se.
- johnfn 10y ago
  Recall that we're talking in the context of TypeScript vs JavaScript. :P I'm not saying that it's impossible for dynamic languages to be able to refactor, but the truth in the industry is that your choice is probably between JavaScript and TypeScript, not JavaScript and VisualWorks Smalltalk. ;)
  - qwertyuiop924 10y ago
    Well, amber does exist... But yeah, probably not.
Roboprog 10y ago
> more readable Well, you have very detailed trees, anyway. But the forest is often quite obscured: http://stackoverflow.com/questions/39672359/make-all-identifiers-more-visible-types-and-modifiers-less-visible-in-intellij http://stackoverflow.com/questions/39672359/make-all-identif... Yeah, I know I'm complaining about one of the worst offenders, rather than TypeScript, but "Welcome to My Nightmare", as it were.

by johnfn 10y ago

jshen 10y ago

I just want to point out there is very little emporical data on this front which makes almost every statement along the lines of "static is better because ..." or "dynamic is better because ..." to be pure opinion.

jeremiep 10y ago

I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. Static types won't help you refactor a monster class into a structure of arrays. It won't refactor your callback hell into coroutines. It won't refactor your "one-at-a-time" algorithm into batches. Yet these all yield more agility and performance. The thing is, I usually have so much less code when throwing static types out the window that refactorings become a non-issue. I get away with basic Emacs macros and unix tools.

bsimpson 10y ago
Or in a GUI: Apple-Shift-F Find: <old name> Replace: <new name> …continue working.
- shados 10y ago
  Won't work super hot if you have 2 functions with the same name in 2 different modules and you want to rename one and all its usages but not the other. It's quite impressive what VisualStudio + Resharper + plugins or IntelliJ with a few plugins can do in their respective first class languages.
  - jeremiep 10y ago
    I used to like ReSharper but quickly uninstalled it from the large amount of false positives it reported. Back when I did C# last year I was doing 2D skeletal animations in Unity3D and pretty much wrote the most non-idiomatic C# code ever. Everything was bitfields, structures of arrays and integer indices into contiguous memory buffers rather than heap references. The tooling was completely useless there. You can't optimize for cache misses and branch predictions without throwing all that nice typed goodness out the window. As much as types, tests and whatnot can help you, at the end of the day it is impossible to do engineering without understanding what you're doing, regardless of what is there to do heavylifting for you.
- westoncb 10y ago
  This doesn't actually work. Let's say the variable you'd like to rename is 'label,' and you also have variables named 'labelOne' and 'labelTwo'—see the problem?
- SiVal 10y ago
  That crosses namespace boundaries and risks hitting embedded parts of names, which means that you can't simply replace all as a general practice. You can inspect each one before replacing and be your own type checker or just go ahead and blast them all blindly. With a little thought, blind replace-all will usually work with small code written very recently by you but will become increasingly error-prone with more code, more developers, over more time. You can, of course, try using case-sensitivity and whole-word search modifiers while trying to maintain naming conventions to keep replace-all working a little longer, but that's just an incomplete and buggy attempt at creating your own watered-down type system, not proving that types aren't useful.
coldtea 10y ago
>I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. First, the trivial ones are great and useful refactorings too -- and still difficult in dynamic type systems. Second, static types also benefit the more difficult refactorings that you still have to do manually, by giving you compiler errors and warnings when you botched them at least at the type level. With dynamic languages those need to be done both 100% manual and with no aid. Third, static languages are a superset of dynamic typed languages, so they can do everything the latter can do, while the inverse is not true. You can have a "var" or "variant" etc type in a dynamic language that lets you code exactly like in a dynamic typed language where you want it. (In fact dynamic typed languages are just static type languages with a single type: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... ).
- jeremiep 10y ago
  I'd rather have tests than types. Unless your type-system is sound; most of them are very, very far from it. You can specify the domain of values with types, but not their ranges. Side-effects fall through unaffected by types as well. I've done plenty of refactorings in huge statically typed codebases; types are a very, very superficial help there. Everything compiles fine but now you're passing 20 to a function whose range is 1-10. Or you're now generating the wrong filenames. To me the overhead of using types outweighs the advantages they bring to the table. If I can help it I'd even choose to have a spec I can enforce at runtime using custom predicates than some vague predefined types with weak semantics or unit tests I have to maintain manually.
  - lloyd-christmas 10y ago
    > I'd rather have tests than types. They aren't mutually exclusive. I'd rather have both.
    - jeremiep 10y ago
      Oh I know, but my opinion and experience in half a dozen statically typed languages over a decade is that most type systems add much more overhead to development than agility. I do want types when building native software, because these sit directly on the CPU and have to match the hardware. Other than that I feel they at best give you the illusion of robustness - unless the type-system is actually sound but very, very few are.
hota_mazi 10y ago
> I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. These alone are already huge. Think about it for a while, keeping a code base healthy as it goes through evolutions involves a lot of renaming and moving things around. But there are so many more refactorings that are tedious or even dangerous to do manually. For example, switching the parameters of a method, lifting a method in a base class, extracting an interface out of a class and using that interface everywhere in your code base instead of the concrete class, etc... Spend some time reading the extremely long list of refactorings offered by IDEA and Eclipse, it will open your eyes.
johnfn 10y ago
> I usually have so much less code when throwing static types out the window that refactorings become a non-issue. This is almost certainly our difference. The utility of static typing is greatly diminished when the codebase is not very large. > Static types won't help you refactor a monster class into a structure of arrays. Sure they will. I mean, sure, it won't be a one-click magic refactor, but that was never the benefit anyways. One strong advantage of static typings is that now you'll know exactly when all your call sites break, so that finding and fixing them will be much more straightforward.
duaneb 10y ago
Renaming and moving is still more than you can get with a dynamic language.

stcredzero 10y ago

Statically typed languages have a few large advantages over dynamic languages Fallacies! I'd have said "lies" but I realize you just have limited information. See below. - Refactoring. Refactoring a large JavaScript codebase (> 100k loc) is nearly impossible Really? Refactoring large codebases in VisualWorks Smalltalk was a joy! Hyper nimble. If you stuck to canned refactorings, you had 100% confidence. For years, we were talking about how we could refactor an order of magnitude faster than other environments, and this is still true. - Your code is now more discoverable. You can easily find definitons, and discovering all methods and properties Discovery in Smalltalk was much superior and way more nimble. Combining senders/implementors searches, syntactic pattern matching, and runtime discovery was powerful and joyful to use. - Code is now more readable. Objects are never opaque. You never have to dig through multiple calls I don't know what you're getting at here. No environment has been more transparent to work in than Smalltalk. You don't just get to read a spec of the object -- you actually get to see it and poke and prod the live version of it to verify your understanding and test your theories. (I understand you can do this in languages like C++ -- it's what I use in my day job -- but it's literally an order of magnitude nimbler in Smalltalk.) What you have to say about dynamic languages perhaps has to do with somewhat ad-hoc language design combined with somewhat ad-hoc design of the environment and distribution/execution platform. (Javascript/Web browsers?) It certainly doesn't have to be true for dynamic environments per se.

johnfn 10y ago
Recall that we're talking in the context of TypeScript vs JavaScript. :P I'm not saying that it's impossible for dynamic languages to be able to refactor, but the truth in the industry is that your choice is probably between JavaScript and TypeScript, not JavaScript and VisualWorks Smalltalk. ;)
- qwertyuiop924 10y ago
  Well, amber does exist... But yeah, probably not.

Roboprog 10y ago

> more readable Well, you have very detailed trees, anyway. But the forest is often quite obscured: http://stackoverflow.com/questions/39672359/make-all-identifiers-more-visible-types-and-modifiers-less-visible-in-intellij http://stackoverflow.com/questions/39672359/make-all-identif... Yeah, I know I'm complaining about one of the worst offenders, rather than TypeScript, but "Welcome to My Nightmare", as it were.