Какой компромисс для вывода типа?

Кажется, что все новые языки программирования или, по крайней мере, те, которые стали популярными, используют вывод типов. Даже Javascript получил типы и вывод типов через различные реализации (Acscript, typcript и т. Д.). Это выглядит великолепно для меня, но мне интересно, есть ли какие-то компромиссы или почему, скажем, Java или старые добрые языки не имеют вывода типа

• При объявлении переменной в Go без указания ее типа (с использованием var без типа или синтаксиса: =) тип переменной выводится из значения в правой части.
• D позволяет писать большие фрагменты кода без избыточного указания типов, как это делают динамические языки. С другой стороны, статический вывод выводит типы и другие свойства кода, предоставляя лучшее из статического и динамического миров.
• Механизм вывода типов в Rust довольно умный. Он делает больше, чем просто смотрит на тип значения r во время инициализации. Также выглядит, как переменная впоследствии используется для определения ее типа.
• Swift использует вывод типа для разработки подходящего типа. Вывод типа позволяет компилятору автоматически определять тип определенного выражения при компиляции вашего кода, просто проверяя предоставленные вами значения.

Система типов в Haskell полностью незаметна (оставляя в стороне полиморфную рекурсию, некоторые расширения языка и устрашающее ограничение мономорфизма ), однако программисты по-прежнему часто предоставляют аннотации типов в исходном коде, даже когда они не нужны. Зачем?

1. Тип аннотации служат документацией . Это особенно верно с типами, такими же выразительными, как у Haskell. Учитывая имя функции и ее тип, вы обычно можете довольно точно догадаться, что делает функция, особенно когда функция параметрически полиморфна.
2. Тип аннотации могут стимулировать разработку . Написание сигнатуры типа перед тем, как писать тело функции, похоже на разработку через тестирование. По моему опыту, когда вы компилируете функцию на Haskell, она обычно работает в первый раз. (Конечно, это не избавляет от необходимости автоматизированных тестов!)
3. Явные типы могут помочь вам проверить ваши предположения . Когда я пытаюсь понять некоторый код, который уже работает, я часто добавляю к нему то, что я считаю правильными аннотациями типов. Если код все еще компилируется, я знаю, что понял. Если это не так, я прочитал сообщение об ошибке.
4. Сигнатуры типов позволяют вам специализировать полиморфные функции . Очень редко API является более выразительным или полезным, если определенные функции не являются полиморфными. Компилятор не будет жаловаться, если вы дадите функции менее общий тип, чем было бы выведено. Классический пример map :: (a -> b) -> [a] -> [b]. Его более общая форма ( fmap :: Functor f => (a -> b) -> f a -> f b) применяется ко всем Functors, а не только к спискам. Но считалось, что mapэто будет легче понять новичкам, поэтому он живет вместе со своим старшим братом.

В целом, недостатки статически типизированной, но выводимой системы во многом совпадают с недостатками статической типизации в целом, изношенное обсуждение этого сайта и других («Недостатки статической типизации в поиске» принесут вам сотни страниц пламенных войн). Конечно, некоторые из указанных недостатков улучшаются благодаря меньшему количеству типовых аннотаций в выводимой системе. Кроме того, вывод типов имеет свои преимущества: разработка с использованием дырок невозможна без вывода типов.

Java * доказывает, что язык, требующий слишком большого количества аннотаций типов, становится раздражающим, но слишком мало вы теряете преимущества, описанные выше. Языки с логическим выводом типа «отказ от участия» обеспечивают приемлемый баланс между двумя крайностями.

_{* Даже Java, этот великий козел отпущения, выполняет определенное количество локальных выводов типов. В таком выражении, как Map<String, Integer> = new HashMap<>();, вам не нужно указывать универсальный тип конструктора. С другой стороны, языки в стиле ML, как правило, являются глобально выводимыми.}

В C # вывод типов происходит во время компиляции, поэтому стоимость времени выполнения равна нулю.

По стилю varиспользуется для ситуаций, когда вручную или неудобно указывать тип вручную. Linq - одна из таких ситуаций. Другой это:

var s = new SomeReallyLongTypeNameWith<Several, Type, Parameters>(andFormal, parameters);

без которого вы будете повторять свое действительно длинное имя типа (и параметры типа), а не просто говорить var.

Используйте фактическое имя типа, когда оно явное, улучшает ясность кода.

В некоторых ситуациях невозможно использовать определение типа, например, объявления переменных-членов, значения которых установлены во время построения, или когда вы действительно хотите, чтобы intellisense работал правильно (IDE Hackerrank не будет intellisense для членов переменной, если вы не объявите тип явно) ,

Хороший вопрос!

1. Поскольку тип явно не аннотирован, он может иногда усложнять чтение кода, что приводит к большему количеству ошибок. Правильное использование, конечно, делает код чище и более читабельным. Если вы пессимист , и думаете , что большинство программистов плохо (или работы , где большинство программистов являются плохо), то это будет чистый убыток.
2. Хотя алгоритм вывода типов относительно прост, он не является бесплатным . Такие вещи немного увеличивают время компиляции.
3. Поскольку тип явно не аннотирован, ваша IDE также не может угадать, что вы пытаетесь сделать, нанося вред автозаполнению и аналогичным помощникам во время процесса объявления.
4. В сочетании с перегрузками функций вы можете иногда попадать в ситуации, когда алгоритм вывода типов не может решить, какой путь выбрать, что приводит к более уродливым аннотациям стиля приведения. (Это случается, например, с синтаксисом анонимной функции C #).

И есть более эзотерические языки, которые не могут делать свои странности без явной аннотации типов. Пока что я не знаю ничего такого, что было бы достаточно распространенным / популярным / многообещающим, чтобы упомянуть, за исключением случая.

Это выглядит великолепно для меня, но мне интересно, есть ли какие-то компромиссы или почему, скажем, Java или старые добрые языки не имеют вывода типа

Ява оказывается скорее исключением, чем правилом. Даже C ++ (который, как я полагаю, квалифицируется как «старый добрый язык» :)) поддерживает вывод типа с autoключевым словом начиная со стандарта C ++ 11. Он работает не только с объявлением переменной, но и с типом возвращаемого значения функции, что особенно удобно для некоторых сложных шаблонных функций.

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

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

Я не вижу реального недостатка в том, чтобы дать возможность разработчику использовать вывод типа.

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

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

Основное различие между системой логического вывода типа Хиндли-Милнера и логическим типом логического вывода заключается в направлении потока информации. В HM информация типа передается вперед и назад через унификацию; в Go информация о типах передается только перенаправлениями: она рассчитывает только перестановки подстановок.

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

1. Тот факт, что информация передается как вперед, так и назад, означает, что вывод типа HM является очень нелокальным делом; в отсутствие аннотаций типов каждая строка кода в вашей программе может способствовать вводу одной строки кода. Если у вас есть только прямое замещение, вы знаете, что источником ошибки типа должен быть код, предшествующий вашей ошибке; не код, который идет после.

2. С выводом типа HM вы склонны думать в ограничениях: когда вы используете тип, вы ограничиваете возможные типы. В конце дня, могут быть некоторые переменные типа, которые остаются полностью без ограничений. Понимание вывода типов HM состоит в том, что эти типы действительно не имеют значения, и поэтому они превращаются в полиморфные переменные. Однако этот дополнительный полиморфизм может быть нежелательным по ряду причин. Во-первых, как отмечают некоторые люди, этот дополнительный полиморфизм может быть нежелателен: HM завершает фиктивный, полиморфный тип для некоторого поддельного кода и позже приводит к странным ошибкам. Во-вторых, когда тип остается полиморфным, это может иметь последствия для поведения во время выполнения. Например, чрезмерно полиморфный промежуточный результат является причиной, по которой «шоу». читать 'считается в Хаскеле неоднозначным; в качестве другого примера,

Это вредит читабельности.

сравнить

var stuff = someComplexFunction()

против

List<BusinessObject> stuff = someComplexFunction()

Это особенно проблема при чтении вне IDE, как на github.