5 ms·

> Being able to hit . and get a reliable list of things I can do is worth many millions of dollars to me. ...and mostly is possible because of the many million

> Being able to hit . and get a reliable list of things I can do is worth many millions of dollars to me. ...and mostly is possible because of the many millions of dollars that were thrown into developing it rather than the type system. Quality of tooling has much more to do with the amount of money invested in it than whether the language is statically typed. But this isn't a post about static vs dynamic typing as I said right at the top. It's a post about the effect of static typing on software quality.

heinrich5991 10y ago
Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages, as you might need whole-program and control flow analysis to even get the types of local variables. This fact has nothing to do with the money involved, it's probably rather another formulation of the halting problem.
- DRMacIver 10y ago
  > Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages Code completion tools originally came out of Smalltalk. It's relatively doable if you can attach to a running process that has dynamic access to your code. So that's "not necessary". It's also not sufficient: Most statically typed languages simply don't have this sort of tooling because it's very hard to write, and advanced type systems make it even harder.
  - overgard 10y ago
    Most Smalltalks didn't really have great code completion (or code completion at all), and when they did, a lot of it had to do with the verbosity of method signatures removing a lot of ambiguity. Don't get me wrong, Smalltalk has some really cool features, but they did it by having a workflow completely different from static languages, and trying to imitate Smalltalk's environment in a language not designed from the ground up for it (ie, python or perl or whatnot) would be a lot harder. The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one.
    - DRMacIver 10y ago
      > Most Smalltalks didn't really have great code completion (or code completion at all), Ditto most statically typed languages. > The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one. It doesn't, but the fact that there's nearly as much variation within statically typed languages in terms of how difficult this is to do as there is between statically and dynamically typed languages does. And this only gets worse as we move to the sort of languages that the static-types-for-correctness people advocate for.
      - overgard 10y ago
        > It doesn't, but the fact that there's nearly as much variation within statically typed languages in terms of how difficult this is to do as there is between statically and dynamically typed languages does. I really don't buy this. Yes different languages present different degrees of difficulty, but the ceiling is much lower for dynamic languages compared to static ones. In dynamic languages, there are absolutely (very common) situations where types cannot be accurately inferred (or inferred at all). If I write def f(x, a): return x[a] That's practically impossible for an IDE to do anything with. The reason why not every static language has great tool support is more to do with A) if the compiler was designed with hooks/apis for tools to use (like clang and rust do), and B) if the language has enough popularity for anyone to bother. I'm pretty sure if you take two languages of relatively equal popularity, and compare the dynamic one to the static one, the static one almost always has better IDE/tool support. For instance, lets take Swift vs Ruby (they're next to each other on the Tiobe index). I've yet to see a Ruby IDE that is much of an improvement on a text editor, whereas Swift is pretty young and already has tooling comparable to much more mature languages.
        steveklabnik 10y ago
        That function looks like this in Rust: https://doc.rust-lang.org/std/ops/trait.Index.html https://doc.rust-lang.org/std/ops/trait.Index.html (it's heavily generic, it could be slightly less verbose if it didn't have to handle Sized) The compiler will errr if x isn't indexable, or if it is but not by the type of a, in terms of your function's names.
- crdoconnor 10y ago
  >Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages, as you might need whole-program and control flow analysis to even get the types of local variables. This pre-supposes that you don't have a test to run the program, because if you do you can just embed an interpreter in it and you have access to everything - tab completion included. IMO This approach is partly what made IPython notebooks so spectacularly successful, and the future of dynamic language programming will look something like that.

heinrich5991 10y ago

Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages, as you might need whole-program and control flow analysis to even get the types of local variables. This fact has nothing to do with the money involved, it's probably rather another formulation of the halting problem.

DRMacIver 10y ago
> Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages Code completion tools originally came out of Smalltalk. It's relatively doable if you can attach to a running process that has dynamic access to your code. So that's "not necessary". It's also not sufficient: Most statically typed languages simply don't have this sort of tooling because it's very hard to write, and advanced type systems make it even harder.
- overgard 10y ago
  Most Smalltalks didn't really have great code completion (or code completion at all), and when they did, a lot of it had to do with the verbosity of method signatures removing a lot of ambiguity. Don't get me wrong, Smalltalk has some really cool features, but they did it by having a workflow completely different from static languages, and trying to imitate Smalltalk's environment in a language not designed from the ground up for it (ie, python or perl or whatnot) would be a lot harder. The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one.
  - DRMacIver 10y ago
    > Most Smalltalks didn't really have great code completion (or code completion at all), Ditto most statically typed languages. > The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one. It doesn't, but the fact that there's nearly as much variation within statically typed languages in terms of how difficult this is to do as there is between statically and dynamically typed languages does. And this only gets worse as we move to the sort of languages that the static-types-for-correctness people advocate for.
    - overgard 10y ago
      > It doesn't, but the fact that there's nearly as much variation within statically typed languages in terms of how difficult this is to do as there is between statically and dynamically typed languages does. I really don't buy this. Yes different languages present different degrees of difficulty, but the ceiling is much lower for dynamic languages compared to static ones. In dynamic languages, there are absolutely (very common) situations where types cannot be accurately inferred (or inferred at all). If I write def f(x, a): return x[a] That's practically impossible for an IDE to do anything with. The reason why not every static language has great tool support is more to do with A) if the compiler was designed with hooks/apis for tools to use (like clang and rust do), and B) if the language has enough popularity for anyone to bother. I'm pretty sure if you take two languages of relatively equal popularity, and compare the dynamic one to the static one, the static one almost always has better IDE/tool support. For instance, lets take Swift vs Ruby (they're next to each other on the Tiobe index). I've yet to see a Ruby IDE that is much of an improvement on a text editor, whereas Swift is pretty young and already has tooling comparable to much more mature languages.
      - steveklabnik 10y ago
        That function looks like this in Rust: https://doc.rust-lang.org/std/ops/trait.Index.html https://doc.rust-lang.org/std/ops/trait.Index.html (it's heavily generic, it could be slightly less verbose if it didn't have to handle Sized) The compiler will errr if x isn't indexable, or if it is but not by the type of a, in terms of your function's names.
crdoconnor 10y ago
>Code completion is a fundamentally harder (if not impossible) problem with dynamically typed languages, as you might need whole-program and control flow analysis to even get the types of local variables. This pre-supposes that you don't have a test to run the program, because if you do you can just embed an interpreter in it and you have access to everything - tab completion included. IMO This approach is partly what made IPython notebooks so spectacularly successful, and the future of dynamic language programming will look something like that.