On the one hand: "...what coder is slinging 100 lines of code a day? That's an exceptionally GREAT day of coding... " and on the other, "Strong typing is one reason that languages like C++ and Java require more finger typing..."
There's a lot of froth right now that claims that implicit typing is an important contributor to programmer productivity. The all-industries average productivity in software development is 1,500 debugged lines of source code per month -- call it 75 lines per day. Also, it's long been said that the number of lines per code written per month is pretty much independent of the language used; it varies greatly per individual, but the same programmer reasonably versed in Python and COBOL will write about the same amount of lines per month.
The corollary in language design is that you want to maximize the amount of expressiveness per line of code written. It takes fewer lines to express a text-matching-and-replacement intent in Python than it is in COBOL, so it's legitimate to say that Python is more productive for that kind of work than COBOL. Similarly, a spreadsheet is more productive than Python for, say, expressing a variable rate mortgage calculation.
But the point is that finger typing on a given line is a small contributor to productivity, everything else being equal. I've spent the past month working in Visual Basic .NET, in which I can write:
dim x = y
or
dim x as Type = y
It's my thesis that the 8 extra keystrokes in the second form are less-than-trivial in terms of mental and physical effort and have major benefits. The first form is not easier to conceive -- I clearly have an intention relating to the type of x when I write the first form, it's just a matter of making it explicit or not. But by making it explicit, I aid in comprehensibility, maintainability, and tool support. I'm not aware of any implicitly typed languages whose editors perform on-the-fly type inference and provide features such as code and parameter completion.
It seems incontrovertible to me that on-the-fly lists of available methods and properties provide more of a programmer boost than is lost by explicit typing. For one thing, explicit typing is only required for declaration, but on-the-fly type-support is available for wherever the variable is in scope. For another, whatever mental burden is required to explicitly state one's intent as to type is undeniably trivial compared to the mental burden of remembering the precise form of a type's operations.
And don't try to argue that editor support "is not part of the language and therefore is irrelevant." Your interaction with the editor is a language; one in which you express the programming language. Just because there's sometimes close to a 1-to-1 correspondence between the pressing of keyboard keys and code characters, you can't ignore the fact that the languages of editors differ in how tersely you can accomplish certain goals. With on-the-fly type support, for instance, I can express the intent to retrieve the value of x's PropertyWithALongName with, perhaps,
x.P[Tab][space]
rather than
x.PropertyWithALongName[space]
And those savings in "finger typing" are at least as valid as the savings from implicit typing.
I say "implicit, schmimplicit." Until design-time type-inferencing editors become available, be explicit.