4 ms·

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. Stati

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.

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.