4 ms·

This. Not just, "who the hell uses this", but "where the hell is this defined" as well.

flavio81 9y ago
>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.
- Eire_Banshee 9y ago
  Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.
  - amirouche 9y ago
    Python has jump to definition too.
    - adamnemecek 9y ago
      You mean there’s an ide with that feature? It’s never as good as with any statically type language.
      - hwayne 9y ago
        Have you tried it? It's usually pretty good for Python.
        steelbird 9y ago
        Which IDE?
        hwayne 9y ago
        PyCharm and VSCode are both pretty good.
      - markbnj 9y ago
        Sublime Text has this feature on hover, but I am fairly certain it is based on text search of the modules in the python path.
    - catnaroek 9y ago
      Does it work in the presence and (ab)use of dynamic features? (e.g., when you have lots of decorated functions) Or is it just a best effort thing? (i.e., only works when your code would actually be expressible in a static way)
      - fulafel 9y ago
        This is a continuum... in many statically typed languages there are regularly used paths that lead outside the realm of the language-defined type system as well. Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.
        catnaroek 9y ago
        > This is a continuum. It is not. A language feature is either amenable to static analysis (not necessarily type checking) or it is not. > Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc. This actually emphasizes my point. Features that are not amenable to static analysis are problematic for tooling.
  - pvorb 9y ago
    IntelliJ/WebStorm is also pretty good at this (with JavaScript at least) by indexing a whole project and its dependencies. Refactoring doesn't work that well, though.
  - fulafel 9y ago
    There have been references to Clojure, Elixir, Smalltalk, Common Lisp in the comments here, what makes you think just Javascript & Python?
    - yellowapple 9y ago
      It's worth noting that Elixir (by descent from Erlang) can emulate at least a basic static typing system pretty easily through pattern matching. You miss out on some features common in more traditionally-object-oriented languages (namely: subtypes), but tagged tuples and structs do provide a lot of the same safety benefits in runtime (and tools like Dialyzer can - last I check - use such pattern matching as a basis for static verification).
      - nv-vn 9y ago
        Elixir and Erlang still lack the ability to typecheck any process behaviors because messages can take any type anywhere.
        yellowapple 9y ago
        You can still pattern match when receiving, though (in fact, 'receive' in both Erlang and Elixir does pattern matching already in the same vein as 'case'); just match messages based on a tagged tuple or a record (Erlang) / struct (Elixir) signature or however else you want to define your "types".
  - flavio81 9y ago
    >Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification? You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.
  - hellofunk 9y ago
    Why would you say that? There are far more dynamically typed languages in widespread use than those 2!
- deleted 9y ago
  [deleted]
- KMag 9y ago
  But if the compiler doesn't enforce that types are statically determinable, there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at. Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions. The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.
  - ubernostrum 9y ago
    there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically. I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.
    - jaggederest 9y ago
      When $problem happens to $language_I_prefer, it's an unavoidable difficulty that is easy to work around. When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.
- caseymarquis 9y ago
  I had to do a decent amount of setup and wrote a quick script to run the tools which generate ctags to make this happen in CL using slimv. With top tier ides for static languages, this is built in from day 1 with no effort. You can't not have it. That said, a top tier repl for development is missing in languages like C#. I'd love to see that gap bridged.
- dvlsg 9y ago
  You can even do this with Javascript, too. And without doc types. At least in vscode, anyways. Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.
- Eridrus 9y ago
  I think it's telling that while there are Lisp aficionados in this thread telling us how great it is, none of these ideas have been implemented in Python or JavaScript or Ruby, the most common dynamically typed languages. And that's really all I care about, I'm not about to start writing production code in Lisp.
fulafel 9y ago
The module system makes it very easy to find definitions, because one namespace = one source file. And the other way around: Statically typed languages without module systems, such as C, exhibit this problem too.
icebraining 9y ago
PyCharm gets it right 99% of the time. That 1% is hardly worth switching the a different language.
- kodablah 9y ago
  IME, add that 1% to another "1% isn't worth switching" argument with some other Python deficiency and then to another and so on, and reasonable case for choosing other languages can be made. I'm not saying Python should be abandoned for all projects, but we should be careful with "but if we make everyone use this one tool, and this one tool does it right almost all of the time, so we're good" arguments.
  - icebraining 9y ago
    I'm reading Type-Driven Development with Idris right now exactly because I don't think Python is always the correct choice. I just don't find slight improvements in IDE features to be relevant.
- sidlls 9y ago
  What about the time accounted for in each of those buckets? If "that 1%" accounts for more than 1% of debugging, error chasing, and related time it starts to look more important, yes?
  - deleted 9y ago
    [deleted]
- Peaker 9y ago
  For someone paranoid about correctness, that's 1% of lingering doubt about every single operation in the IDE. The 99% stat is quite likely a big exaggeration. Refactoring is far far harder to do reliably, and more straining as so much more responsibility on the programmer.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

Eire_Banshee 9y ago
Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.
- amirouche 9y ago
  Python has jump to definition too.
  - adamnemecek 9y ago
    You mean there’s an ide with that feature? It’s never as good as with any statically type language.
    - hwayne 9y ago
      Have you tried it? It's usually pretty good for Python.
      - steelbird 9y ago
        Which IDE?
        hwayne 9y ago
        PyCharm and VSCode are both pretty good.
    - markbnj 9y ago
      Sublime Text has this feature on hover, but I am fairly certain it is based on text search of the modules in the python path.
  - catnaroek 9y ago
    Does it work in the presence and (ab)use of dynamic features? (e.g., when you have lots of decorated functions) Or is it just a best effort thing? (i.e., only works when your code would actually be expressible in a static way)
    - fulafel 9y ago
      This is a continuum... in many statically typed languages there are regularly used paths that lead outside the realm of the language-defined type system as well. Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.
      - catnaroek 9y ago
        > This is a continuum. It is not. A language feature is either amenable to static analysis (not necessarily type checking) or it is not. > Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc. This actually emphasizes my point. Features that are not amenable to static analysis are problematic for tooling.
- pvorb 9y ago
  IntelliJ/WebStorm is also pretty good at this (with JavaScript at least) by indexing a whole project and its dependencies. Refactoring doesn't work that well, though.
- fulafel 9y ago
  There have been references to Clojure, Elixir, Smalltalk, Common Lisp in the comments here, what makes you think just Javascript & Python?
  - yellowapple 9y ago
    It's worth noting that Elixir (by descent from Erlang) can emulate at least a basic static typing system pretty easily through pattern matching. You miss out on some features common in more traditionally-object-oriented languages (namely: subtypes), but tagged tuples and structs do provide a lot of the same safety benefits in runtime (and tools like Dialyzer can - last I check - use such pattern matching as a basis for static verification).
    - nv-vn 9y ago
      Elixir and Erlang still lack the ability to typecheck any process behaviors because messages can take any type anywhere.
      - yellowapple 9y ago
        You can still pattern match when receiving, though (in fact, 'receive' in both Erlang and Elixir does pattern matching already in the same vein as 'case'); just match messages based on a tagged tuple or a record (Erlang) / struct (Elixir) signature or however else you want to define your "types".
- flavio81 9y ago
  >Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification? You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.
- hellofunk 9y ago
  Why would you say that? There are far more dynamically typed languages in widespread use than those 2!
deleted 9y ago
[deleted]
KMag 9y ago
But if the compiler doesn't enforce that types are statically determinable, there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at. Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions. The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.
- ubernostrum 9y ago
  there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically. I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.
  - jaggederest 9y ago
    When $problem happens to $language_I_prefer, it's an unavoidable difficulty that is easy to work around. When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.
caseymarquis 9y ago
I had to do a decent amount of setup and wrote a quick script to run the tools which generate ctags to make this happen in CL using slimv. With top tier ides for static languages, this is built in from day 1 with no effort. You can't not have it. That said, a top tier repl for development is missing in languages like C#. I'd love to see that gap bridged.
dvlsg 9y ago
You can even do this with Javascript, too. And without doc types. At least in vscode, anyways. Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.
Eridrus 9y ago
I think it's telling that while there are Lisp aficionados in this thread telling us how great it is, none of these ideas have been implemented in Python or JavaScript or Ruby, the most common dynamically typed languages. And that's really all I care about, I'm not about to start writing production code in Lisp.

fulafel 9y ago

The module system makes it very easy to find definitions, because one namespace = one source file. And the other way around: Statically typed languages without module systems, such as C, exhibit this problem too.

icebraining 9y ago

PyCharm gets it right 99% of the time. That 1% is hardly worth switching the a different language.

kodablah 9y ago
IME, add that 1% to another "1% isn't worth switching" argument with some other Python deficiency and then to another and so on, and reasonable case for choosing other languages can be made. I'm not saying Python should be abandoned for all projects, but we should be careful with "but if we make everyone use this one tool, and this one tool does it right almost all of the time, so we're good" arguments.
- icebraining 9y ago
  I'm reading Type-Driven Development with Idris right now exactly because I don't think Python is always the correct choice. I just don't find slight improvements in IDE features to be relevant.
sidlls 9y ago
What about the time accounted for in each of those buckets? If "that 1%" accounts for more than 1% of debugging, error chasing, and related time it starts to look more important, yes?
- deleted 9y ago
  [deleted]
Peaker 9y ago
For someone paranoid about correctness, that's 1% of lingering doubt about every single operation in the IDE. The 99% stat is quite likely a big exaggeration. Refactoring is far far harder to do reliably, and more straining as so much more responsibility on the programmer.