У чому полягає компроміс для виводу типу?

Здається, що всі нові мови програмування або, принаймні, ті, що стали популярними, використовують умовивід. Навіть Javascript отримав типи та умови виводу, хоча різні реалізації (Acscript, typecript тощо). Мені це здається чудово, але мені цікаво, чи є компроміси чи чому, скажімо, Java або старі добрі мови не мають висновку про тип

• При оголошенні змінної в Go, не вказуючи її тип (використовуючи var без типу або синтаксис: =), тип змінної виводиться зі значення праворуч.
• D дозволяє писати великі фрагменти коду без надмірного введення типів, як це роблять динамічні мови. З іншого боку, статичний висновок виводить типи та інші властивості коду, надаючи найкраще як статичному, так і динамічному світам.
• Двигун виводу типу в Rust досить розумний. Це більше, ніж дивитися на тип r-значення під час ініціалізації. Він також виглядає, як змінна використовується згодом для висновку про її тип.
• Swift використовує умовивід типу для опрацювання відповідного типу. Вибір типу дозволяє компілятору автоматично виводити тип певного виразу, коли він компілює ваш код, просто досліджуючи надані вами значення.

Система типу Хаскелла є повністю невідповідною (залишаючи осторонь поліморфну ​​рекурсію, певні розширення мови та жахливе обмеження мономорфізму ), але програмісти все ще часто надають анотації типів у вихідному коді, навіть коли цього не потрібно. Чому?

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 працювала належним чином (ID ID Hackerrank не буде інтелігувати членів змінної, якщо ви чітко не заявите тип) .

Гарне питання!

1. Оскільки тип не позначається явно, він може часом ускладнювати читання коду - що призводить до появи більше помилок. При правильному використанні це звичайно робить чистий код і більш читабельним. Якщо ви песиміст , і думаєте , що більшість програмістів погано (або роботи , де більшість програмістів є погано), то це буде чистий збиток.
2. Хоча алгоритм виводу типу порівняно простий, він не є безкоштовним . Такі речі дещо збільшують час складання.
3. Оскільки тип не є явно анотованим, ваш IDE також не може здогадатися, що ви намагаєтесь зробити, завдаючи шкоди автозаповненню та подібним помічникам під час декларації.
4. У поєднанні з перевантаженнями функцій ви можете час від часу потрапляти в ситуації, коли алгоритм виводу типу не може визначитися, який шлях пройти, що призводить до більш потворних анотацій стилю кастингу. (Це відбувається зовсім небагато, наприклад, з синтаксисом анонімних функцій C #).

Є ще езотеричні мови, які не можуть здійснити свою дивність без явного анотації типу. Поки немає жодного, про який я знаю, що є загальним / популярним / досить перспективним, щоб згадати, окрім як мимохідь.

Мені це здається чудово, але мені цікаво, чи є компроміси чи чому, скажімо, Java або старі добрі мови не мають висновку про тип

Java, швидше, є винятком, ніж правилом. Навіть C ++ (який, на мою думку, кваліфікується як "стара стара мова" :)) підтримує тип висновку з autoключовим словом, оскільки стандарт C ++ 11. Він працює не тільки зі змінним оголошенням, але також як тип повернення функції, що особливо зручно для деяких складних функцій шаблону.

Неявне введення тексту та умови виводу мають багато корисних випадків використання, а також є деякі випадки використання, коли ви дійсно не повинні цього робити. Іноді це питання смаку, а також предмет дискусій.

Але те, що, безсумнівно, є добрі випадки використання, саме по собі є законною причиною для будь-якої мови його впровадження. Це також не важко реалізувати функцію, не виконувати покарання та не впливає суттєво на час компіляції.

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

Деякі відповідачі пояснюють, наскільки явний введення тексту іноді добре, і вони, безумовно, праві. Але непідтримка неявного введення означає, що мова весь час виконує явне введення тексту.

Таким чином, справжній зворотний рух полягає в тому випадку, коли мова не підтримує неявне введення тексту, тому що при цьому він стверджує, що розробник не має законних причин використовувати його, що не відповідає дійсності.

Основне відмінність між системою виводу типу Гіндлі-Мілнера та висновком типу Го-го - напрямок потоку інформації. У HM введіть інформацію, яка рухається вперед і назад шляхом об'єднання; У програмі Go введіть інформацію лише вперед: вона обчислює лише заміну.

Висновок типу HM - чудова інновація, яка добре працює з поліморфно типованими функціональними мовами, але автори Go, напевно, стверджують, що вона намагається зробити занадто багато:

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

2. З висновком типу HM ви схильні думати з обмеженнями: коли ви використовуєте тип, ви обмежуєте, які можливі типи він може мати. Зрештою, можуть бути деякі змінні типу, які залишаються абсолютно не обмеженими. Розуміння виводу типу HM полягає в тому, що ці типи дійсно не мають значення, і тому вони перетворюються на поліморфні змінні. Однак цей додатковий поліморфізм може бути небажаним з кількох причин. По-перше, як зазначають деякі, цей додатковий поліморфізм може бути небажаним: НМ укладає фальшивий, поліморфний тип для якогось фальшивого коду, а згодом призводить до дивних помилок. По-друге, коли тип залишається поліморфним, це може мати наслідки для поведінки під час виконання. Наприклад, надмірно поліморфний проміжний результат є причиною того, що 'показують. read 'вважається неоднозначним у Хаскеллі; як інший приклад,

Це шкодить читабельності.

Порівняйте

var stuff = someComplexFunction()

проти

List<BusinessObject> stuff = someComplexFunction()

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