5 ms·

> 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 wr

> 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.
- pmontra 10y ago
  You're right. I autocomplete Ruby with pabbrev in emacs. Basically it remembers what I wrote and suggests me the strings that match the prefix I'm typing. It's great and more that enough. It can't know the number of arguments I have to pass but it rarely matters. All I usually code in Ruby are Rails apps and they are pretty simple, even the ones with dozens of routes and models. Furthermore the location of classes and files is very predictable. There is no need of an IDE to navigate through the code. I came to think that if a language or a framework needs an IDE there is something wrong with it that the IDE must fix.
- mpweiher 10y ago
  The reason Swift has tooling is that it has a $600 billion company paying for that tooling. Said tooling plugs into Xcode/clang, which is an IDE for, primarily, Objective-C, which happens to be a dynamically typed programming language (with optional static typing). For my own Objective-Smalltalk, I added code-completion to both the REPL and a few IDEs fairly trivially.
  - overgard 10y ago
    Jetbrains has a Swift IDE, and they're not a $600 billion company.
- Oreb 10y ago
  > 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. I've never worked with Ruby, but I do work with (and mostly enjoy) Swift. The one thing I really don't like about Swift is that the currently available tooling (both AppCode and Xcode) is extremely primitive compared to what I am used to from Common Lisp and Clojure.
  - overgard 10y ago
    Anecdotal data point of one guy's opinion, with no elaboration on reasons? Convincing. I'm talking about WHY analyzing dynamic languages is fundamentally undecidable in many cases without run time knowledge. Trying to do anything other than heuristics on some of these things is about as decidable as the halting problem. The only argument I've heard against this is you can have a hybrid environment with a REPL so your dead code is live. Ok, but you can do the same thing with static typing too.

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.
pmontra 10y ago
You're right. I autocomplete Ruby with pabbrev in emacs. Basically it remembers what I wrote and suggests me the strings that match the prefix I'm typing. It's great and more that enough. It can't know the number of arguments I have to pass but it rarely matters. All I usually code in Ruby are Rails apps and they are pretty simple, even the ones with dozens of routes and models. Furthermore the location of classes and files is very predictable. There is no need of an IDE to navigate through the code. I came to think that if a language or a framework needs an IDE there is something wrong with it that the IDE must fix.
mpweiher 10y ago
The reason Swift has tooling is that it has a $600 billion company paying for that tooling. Said tooling plugs into Xcode/clang, which is an IDE for, primarily, Objective-C, which happens to be a dynamically typed programming language (with optional static typing). For my own Objective-Smalltalk, I added code-completion to both the REPL and a few IDEs fairly trivially.
- overgard 10y ago
  Jetbrains has a Swift IDE, and they're not a $600 billion company.
Oreb 10y ago
> 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. I've never worked with Ruby, but I do work with (and mostly enjoy) Swift. The one thing I really don't like about Swift is that the currently available tooling (both AppCode and Xcode) is extremely primitive compared to what I am used to from Common Lisp and Clojure.
- overgard 10y ago
  Anecdotal data point of one guy's opinion, with no elaboration on reasons? Convincing. I'm talking about WHY analyzing dynamic languages is fundamentally undecidable in many cases without run time knowledge. Trying to do anything other than heuristics on some of these things is about as decidable as the halting problem. The only argument I've heard against this is you can have a hybrid environment with a REPL so your dead code is live. Ok, but you can do the same thing with static typing too.