> I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming
There are a few rather glaring spots that I've noticed.
First, when you're refactoring, you've now got to edit every spot where a variable of that type is created. At the very least, when you're just renaming a class, your IDE can help you, but you still create a lot of diff noise. At worst, when you're splitting up a class or otherwise shifting responsibilities, you may end up with a whole lot of yak to shave. This is not just an annoyance; it's a latent code quality problem, because it creates a disincentive to clean things up.
Second, I've seen it become an impediment to writing clean code in the first place. I have encountered situations where it's clear that the author wrote
someMethodCall(
withOutputOfSomeOtherMethod(
thatTransformsTheOutputOfYetAnotherThing(
basedOnThisInput)));
because creating intermediate variables would have meant having to type out (and burn precious screen real estate on) some ridiculous set of 60-character generic type names.
I've even seen it result in situations where data gets copied or otherwise processed excessively, because the explicit type annotation resulted in an upcast that shed some useful feature that a subsequent developer shimmed back in because they trusted the explicit type annotation and not a function's actual return type.
So yeah, I decry your assertion that this feature is about being lazy. This feature is, at least for me, about code quality.