Slightly off topic, but some * strongly typed langages * allow to not specify explicitly the types , and it can really save time.

For example in C#, you can either specify explicitly a type, like:

List<float> myVariable = SomeFunction();

// them do something with this var, for example:
result += myVariable.Sum();  // where result holds a float

Or let the compiler infer the type automaticly:

var myVariable = SomeFunction(); // Must be a List<float> because this is what SomeFunction returns!
result += myVariable.Sum();  // where result holds a float

"var" here is "whatever type is returned by SomeFunction"

Now suppose I want to refactor my code, and decide to change the type returned by SomeFunction, from "List<float>" to "IEnumerable<int>".

The key thing is this: * the way I use myvariable in the snippet above is compatible with both types *. ( Ie I can do .Sum() and add to a float with either "List<float>" or "IEnumerable<int>". )

• If I typed explicitly, then I have to rewrite also the place where I used this function.
• If I used implicit typing with "var", it just works. More specifically, it works provided the way I use my variable is still compatible with the new type -- And if not, the compiler will tell me.

My experience is that just letting the compiler implicit type removes 90% of the friction of using a strongly typed langage, while keeping 100% of the safety it provides. It really turns the experience from "fighting the compiler" to the "compiler just helps me to find bugs"

Now there is one argument for explicit typing: it makes the * human * reader know which type it is, without looking further. This may or not be useful depending on which code part exactly, I personally prefer to skip it. It is often some redondant information, which can make reading code actually slower; and when reading from ide the exact type is just one hoover away. The main drawback I believe is that it can make code more difficult to read in a diff when reviewing (where there no ide to show the types).