Почему в Kotlin нет явной типизации?

Прежде всего: у Kotlin типизация статический. Компилятор точно знает, какой тип идет и куда приходит. И вы всегда можете записать это, например

fun sum(a: Int, b: Int): Int {
  val c: Int = 1

Дело в том, что вы можете написать много кода, который просто полагается на том факте, что все, что вы делаете, является статически типизированным, и тип проверяется тоже!

Вам действительно нужно знать, добавляете ли вы два двойных числа, два целых числа или два длинных числа, когда все, на что вы «заботитесь» смотреть, это a + b?

В конце концов, речь идет о балансировании различных требований. Отказ от типа могу будет полезен: меньше кода, который должен быть прочитан и понят людьми.

Конечно: если вы пишете код так, что люди постоянно обращаются к своей IDE, чтобы IDE сообщала им фактический предполагаемый тип чего-либо, то вы превращаете полезную функцию в проблему!

Настоящий ответ здесь таков: это зависит. Я был во многих обзорах кода, где люди C++ обсуждали использование ключевого слова auto. Было много ситуаций, когда использование auto действительно облегчало чтение и понимание кода, потому что вы могли сосредоточиться на том, «что происходит с переменной», вместо того, чтобы смотреть 1 минуту на ее объявление, пытаясь понять ее тип. Но были также случайные примеры, когда auto достигал прямо противоположного, и было легче следовать «полностью типизированному» объявлению.

И учитывая комментарий ОП: вы должны знать, что делаете в первую очередь. Значение: когда вы пишете код, вы не просто вызываете «любой» метод, который вы найдете для какого-либо объекта. Вы вызываете метод, потому что должны. Вы лучше знать что он делает и что он вам возвращает. Я согласен, когда кто-то торопится, вы быстро вар-назначаете, а затем передаете эту вещь, что мощь приводит к ошибкам. Но для каждой ситуации, когда var помогает создать ошибку, может быть 10 инцидентов, когда это помогает писать более читаемый код. Как говорится: жизнь заключается в балансировании.

Наконец: языки не должны добавлять функции без причины. А разработчики Kotlin тщательно уравновешивают добавляемые функции. Они не добавили вывод типа, потому что он есть в C++. Они добавили его, потому что тщательно изучили другие языки и сочли полезным быть частью этого языка. Возможно неправильное использование языковой функции Любой. Программист должен писать код, который легко читать и понимать, всегда. И когда ваши методы имеют сигнатуры неясно, поэтому простое «чтение» их имен не говорит вам, что происходит, тогда вините в этом имя метода, а не вывод типа!

Чтобы процитировать Java Вывод типа локальной переменной JEP:

In a call chain like:

int maxWeight = blocks.stream()
                    .filter(b -> b.getColor() == BLUE)
                    .mapToInt(Block::getWeight)
                    .max();

no one is bothered (or even notices) that the intermediate types Stream<Block> and IntStream, as well as the type of the lambda formal b, do not appear explicitly in the source code.

Вас это беспокоит?

if one class (let's say "Repository") changes it return type (from String to int for example). With explicit typing, compilation would fail at the class calling "Repository".

Если в вашем примере есть такие перегрузки, как setText, то

Repository repository = ...;
myTextView.setText(repository.getFormerlyStringNowInt());

также не будет ошибкой без вывода типа. Чтобы сделать это неудачным, ваш стандарт кода должен требовать, чтобы результат операции каждый был назначен локальной переменной, как в

Stream<Block> stream1 = blocks.stream();
Predicate<Block> pred = b -> { 
    Color c = b.getColor();
    return c == BLUE;
};
Stream<Block> stream2 = stream1.filter(pred);
ToIntFunction<Block> getWeight = Block::getWeight;
IntStream stream3 = stream2.mapToInt(getWeight);
int maxWeight = stream3.max();

И в этот момент вы упрощаете ошибки только из-за снижения читабельности и шанса случайно использовать неправильную переменную.

Наконец, Kotlin создавался не в вакууме: разработчики могли видеть, что когда в C# в 2007 году появился локальный вывод типов, это не привело к серьезным проблемам. Или они могли бы взглянуть на Scala, которая была с самого начала в 2004 году; у него было (и есть) много жалоб пользователей, но локальный вывод типов не является одной из них.