1. 13
  1. 11

    This problem is largely solved by “Jump To” in an IDE (or fancy editor). This sort of thing is why I no longer do real work in languages without these niceties. I just don’t have the patience for it any more.

    1. 5

      Code reviews and online examples can suffer though - I have a very hard time reading unfamiliar Haskell and Agda code on Github where definitions aren’t either explicitly imported in an import list or given a qualified name. But perhaps that’s an argument for better online tooling…

      1. 2

        That’s a good point, although I agree that better tooling is probably the answer, particularly since fully-qualified imports still mean you’re stuck tracking down docs and such in code review with most of the existing tools.

        1. 1

          I have to admit, I fully agree with brendan here. Fully qualified imports really do increase readability to any new, or even old code.

          I don’t think better tooling is the best approach, I find explicit versus implicit generally explicit ends up being clearer.

          A possible middle ground is allow ONE unqualified import only as (if i remember right, only skimmed docs) purescript does. That would at least remove ambiguity as to where something could be coming from.

        2. 1

          Haskell’s Haddock supports hyperlinked source and so does Agda.

        3. 4

          you don’t even need that much; I find vim’s split-window feature is perfectly usable if I want to read the code where something is defined, or look at both the current code and the top of a file simultaneously. whereas on the flip side I know if no good way to eliminate the visual clutter caused by fully qualified names everywhere.

          1. 4

            You also can generate ctags and use them in vim ;)

            1. 1

              true :) I used to do that more often in my c++ days; somehow I lost the habit now that I’m doing python at work and ocaml at home, even though ctags would probably help with both of those.

            2. 3

              this doesn’t solve the “import all names” problem that you hit in languages like Python where some people do import * or you are importing something that was already re-exported from another location. You end up with busy work that an IDE could handle with a name lookup

              Though I agree that once you find the definition, split windows is a pretty nice way to operate

              1. 1

                I too find the result to be cluttered. But I also find new programming languages/syntaxes to be strange and chaotic in the same way. Once I use the language long enough, I am no longer overwhelmed. My hypothesis is that the eye will adapt to fully qualified names everywhere in the same way.

              2. 1

                I came here to say just this: with a sufficiently smart editor (vim, ide, or otherwise) this problem goes away almost entirely.

                That said, I think there are some arguments to be made for always-qualified imports

                1. 6

                  I think it can be a cultural thing as well. I never enjoy typing datetime.datetime but don’t mind collections.namedtuple. itertools.ifilter is annoying though. Redundant words or information looks and reads bad.

                  When the culture is to assume qualified imports, then the library will always be used to provide context, and that can be quite nice.

                  When resolving a qualified name is the same syntax as a method call, that can look bad quickly. Python very much suffers from this problem. Think of Clojure stylebanespace syntax as an alternative.

                2. 1

                  Does “Jump To” actually jump you to the import declaration or the function definition? I’ve never used an IDE. My guess is that an IDE would largely eliminate manual identification of the function’s origin. So that’s useful! But I’m not convinced that this would be faster than reading the module name inline in plain text. No keystroke or mouse click required to get the information. I guess the argument for using an IDE to solve this problem is something like the IDE places the information close at hand while also enabling a less verbose code style. That’s a reasonable argument. At some point the conversation becomes purely a debate about the pros and cons of IDEs. Then I would say that it’s nice to have code that doesn’t incur a dependency on a code editor.

                  1. 2

                    You can jump to the declaration in most IDEs (provided there is support for the language). In many you can also view the documentation for a symbol inline, no need to go searching in most cases. I agree with you that this really just changes the debate to one about tooling. However, since many people (myself included) prefer the readability of unqualified imports, tooling support is important to at least think about. For example, I work in Dart a lot at work, the Dart community tends toward unqualified imports because, at least in part, I think, pretty much everyone who writes Dart code uses either an IDE or an editor plugin with IDE-like features.

                3. 5

                  The file is 649 lines because large files are encouraged.

                  A 649-line file is not a large file… ?

                  1. 2

                    The same project has several files that are thousands of lines long. I took a shorter example so it wouldn’t seem hyperbolic. The point is that this file fills more than a single screen so checking the import declaration means jumping to a new context.

                    1. 1

                      Depending on the situation it might be. Though considering that I’ve seen a fair share of 1KLoc and 10KLoc files, that doesn’t really seem too large to me either.