On: Type inference has usability problems

[chmaynard]

Many text editors and IDEs can reveal the type of an expression in real time. I'm surprised the author doesn't mention this.

[azhenley → chmaynard]

I thought I did in the paragraph starting with “Tools can help a lot with this.” Or do you mean something else?

I also make the point that often I’m reading code on GitHub or outside an IDE, which does not have such features.

[matt2000 → azhenley]

Agreed, better to use an IDE to insert the full type of a variable automatically so the code is readable in any environment afterwards.

Inferred types feels like an invention for people who don’t like IDEs, that somehow forces everyone _else_ to use an IDE.

[rienbdj → matt2000]

But then an otherwise small change might result in changes to type annotations all over a code base.

[matt2000 → rienbdj]

Again, I find refactoring tools handle this well, and also this is kind of the point for me - I want to see the effect of type changes.

[o_nate → azhenley]

This is maybe slightly off-topic but one reason I prefer Java to C# when it comes to reading code outside an IDE is that it forces you to explicitly declare where every external class is being imported from, which makes it much easier to go looking for the definition if you need it, when you don't have access to the IDE's right-click "Go to Definition".

[chmaynard → azhenley]

Mea culpa. I didn't read the article closely enough and I missed this.

[matt2000 → chmaynard]

Many IDEs can automatically insert the type of a variable when developing. This seems preferable: have one person do this one action once, rather than every person reading the code in the future having to do work to decode the type.

[jddj → matt2000]

As a reader, faced with:

  Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<string, KeyValuePair<int, string>>();

And

  DictionaryOfStringsWithKeyValuePairs contrivedExample = new DictionaryOfStringsWithKeyValuePairs();

And

  var contrivedExample = new Dictionary<string, KeyValuePair<int, string>>();

I'd definitely prefer the latter.

-- Edit: rephrased to be less presumptuous

[hibbelig → jddj]

I think if it avoids having to repeat the type then type inference helps. And especially that last Java example, there I feel it is useful:

    for (var x : someMap.entrySet()) {
        String key = x.getKey();
        Entity value = x.getValue();
        ...
    }

Here, the reader just needs look at the next two lines to understand the type of x. In the article, the key and value types were long and complicated, and they asked us to refactor. But in the above example, the types are very simple, yet still it's better than

    for (Map.Entry<String, Entity> x : someMap.entrySet()) {
        String key = x.getKey();
        Entity value = x.getValue();
        ...
    }

I feel in this example, the type in front of x doesn't help me, as a reader.

[matt2000 → jddj]

I hear you, but the current state of affairs in Java (I know this isn't quite Java, but just for illustration) is more like:

  Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<>();

Which seems ok to me? And we don't enter the slippery slope of allowing variables without types, and hoping people just use it where appropriate.

[balfirevic → matt2000]

C# developer here, which has local variable type inference. It is appropriate in 95% of places. It hasn't caused an apocalypse yet. It has, in fact, been great!