[skocznymroczny]

Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until build time).

Most people will tell you, "oh just use auto, it makes the code more generic". That's sweet, except as soon as I want to pass it to another function, I need to have the concrete type. Like you, I usually just copy-paste the full type from the error message and move on.

[hibbelig]

In Java, `var` comes in useful at times. For example:

    for (Map.Entry<SomeLongType, AnotherLongType> x : someMap) {
        final SomeLongType key = x.getKey();
        final AnotherLongType value = x.getValue();
        ...
    }

In the above code snippet, `var x` would have been very useful because the actual type just repeats information that can be found in the next two lines. Also, usually, I'll use more speaking names instead of `key` and `value`.

But if the body of the loop just refers to `x.getKey()` and `x.getValue()`, without extracting them into local variables, then it makes sense to put the exact `Map.Entry` type into the loop header.

[enitihas]

You can just use map.forEach and avoid the types in the next two lines too.

[jerven]

In java 10+

    for (Map.Entry<SomeLongType, AnotherLongType> x : someMap)    {
        final var key = x.getKey();
        final var value = x.getValue();
        ...
    }

Is valid.

[hibbelig]

I prefer to put "var" into the loop header because the combination of two types is hard to read. It's easier to read (for me!) when the type of the key and the type of the value are separated, like they are on the first two lines of the loop body.

    for (var x : someMap) {
        final SomeLongType key = x.getKey();
        final AnotherLongType value = x.getValue();
        ...
    }

[stcredzero]

Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until build time).

It's 2020. Why couldn't things work like this, where one can open a window for a concrete type using templates, and it shows the code?

[kevin_thibedeau]

A well designed language should be usable from a text editor. Even in 2020.

[harikb]

I agree. I will paraphrase this as - a well designed language should be usable, at minimum, from a pure text editor, and should not put unreasonable burden on an IDE.

[shrimpx]

The cynic in me wants to say that such a language doesn’t lend itself to static analysis. As soon as you can do great things with static analysis you can build those features into an IDE, therefore causing the “pure text editor” to feel crippled giving rise to the idea that this language is “unusable from a pure text editor”.

[qqssccfftt]

A good dev uses an IDE. In 2020.

[snazz]

This is a really tired argument that we don't need to get into right now. Different things appeal to different people.

[entropicdrifter]

Two things can be true. You shouldn't need an IDE to grok the code.

[petee]

A good dev shouldn't require crutches

[Dylan16807]

Interactivity is not a crutch.

[petee]

Interactivity is a base attribute of an ide, and not the first reason people use it; the context here is that using an ide doesn't define a good programmer. So being able to clicky click is what makes good programmers to you?

[skocznymroczny]

Templates don't exist until compile time, until you build the code, the IDE plugin doesn't have the full data on what types exactly are there. Java/C# generics are more limited in functionality, but it's a tradeoff in exchange for better ahead of time knowledge of types.

[pjmlp]

Visual Studio can do that, you just provide an example type and the IDE shows what the result would be.

https://devblogs.microsoft.com/cppblog/template-intellisense...

Now try that on vim.

[Pxtl]

Hard disagree.

   MyClass myVar = new MyClass()

is not DRY. It also makes it practical to use complicated structures out of generics/templates without killing the developer With<Deeply<Nested,Template>, Declarations>.

[choward]

Hard disagree. If you are assigning a value that's the result of an expression you might have somewhat complicated logic. Being able to say what you expect returned is very useful.

    MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass

[Koshkin]

Anything wrong with

   var myClass = ...

(or some other descriptive name of the variable)?

[Pxtl]

Personally I prefer this, since it also carries on to every following line.

Like, in C#

    List<Account> accountsToDelete = accountService.GetAccountsToDelete();    
    repository.Delete(accountsToDelete);

becomes

    var accountsToDelete = accountService.GetAccountsToDelete();
    deleterService.Delete(accountsToDelete);

So as much type information is already encoded into names so that all references to this object are clear in what we're handling, and so the type declarations at the point where the variable is declared is just redundant noise.

If your variables aren't informative when I'm reading the code, I'll be confused 5 lines later anyways. So make them informative at the start. And given that, doesn't that mean the List<Account> is a bit redundant?

[enhray]

Beware the m_pszSlipperySlope [0].

[0] https://en.wikipedia.org/wiki/Hungarian_notation

[edflsafoiewq]

Even if you have var/auto, you don't have to use it every time.

[hiq]

var/auto is a trade-off which requires good tooling support, as you said. Once you're able to see the types as you see fit in your IDE, I feel that you're mostly better off, for all the reasons already mentioned in the thread.

Of course good tooling is still a big requirement, but I still think it's the best decision in the long-term: it's way easier to improve and change tools like IDEs (especially with LSP?), rather than the language itself.

Regarding explicit types in functions, you also don't always need them in languages such as OCaml. I feel that the answer to your criticism could be to just have "auto" also for function arguments, especially when you're just prototyping.

[johannes1234321]

In places where you need to know the exact type auto probably isn't the right choice.

There are many cases where the type is clear however or irrelevant or in generic code is hard to express (thus depending on documentation/comments unless obvious) which would also be hard to read.