Вступление
Ниже приведена моя личная точка зрения 🙂
Если я напишу одностраничную программу, я не возражаю против отсутствия типов, нулевых типов, -1 типов, и я доволен этим .
Если я напишу более крупное приложение, управляемое несколькими программистами команды, которое, как ожидается, будет поддерживаться, я считаю, что типы должны быть обязательными! Я все еще доволен этим!
Когда мне нравятся типы
Сегодня в современных языках есть вывод типа , поэтому набранный код выглядит очень лаконично, как и нетипизированный код, Scala, Haskell, OCaml, Kotlin, ELM , лаконичный типизированный код в значительной степени красив и правилен!
Когда мне не нравятся типы
Нам все еще нужно скомпилировать его, это требует времени , но я готов заплатить эту цену, время обслуживания и время понимания кода , это тоже время. Время есть время, секунда есть секунда, я бы предпочел заплатить секунды или даже минуты времени компиляции за часы необычных ошибок и времени на чтение кода.
Вывод типа + Типы => Краткий читаемый код!
Но все же иногда вы обнаруживаете, что ждете компилятора, я обычно беру кофе:) но это похоже на менее приятное время .
Снижение производительности при выводе типа
Вы платите цену во время компиляции. Как упоминалось ранее, Я предпочитаю платить кому-то за компиляцию, чем платить кому-то за чтение и непонимание кода.
Программы, которые трудно понять, также компилируются медленнее.
Так что, если вы напишете читаемый код, он будет компилироваться быстрее 😉
Параметрический полиморфизм
Параметрический полиморфизм: Тот же подтип [A] для контейнера, который мы определили.
Массив[A] Таким образом, у вас может быть одна реализация, которая что-то делает с массивом и использует его для другого типа – полиморфизм .
Полиморфизм подтипов
Вы наследуете для того, чтобы иметь несколько реализаций. Но в итоге вы получаете один большой гигантский объект (иерархию классов) для меня, который похож на глобальный комок грязевого кода.
Полиморфизм подтипов – большой клубок грязевого кода, при прохождении массива существует несколько типов.
Простая система Ввода
Как в java мы по-прежнему получаем так много пользы от инструментов , от того, что делают наши функции, как построена программа.
Системы простого типа дают нам отличный инструментарий!
Простые системы типов предоставляют нам отличную документацию, проверенную компилятором!
Вам нужно объяснить компилятору, что вы имеете в виду под этими языками вывода без типов.
Богатая система Типов
(например, scala, ocaml, haskell).
Богатые системы типов позволяют нам иметь чистый и простой код!
Это звучит неестественно, но, например, дженерики для выражения единого кода, который может использоваться полиморфно по типам, повторное использование кода. Я возвращаю Int, Мне все равно, я возвращаю A но я возвращаюсь A .
Системы С Богатым Типом Обнаруживают Ошибки
Ложь: Если он компилируется, то работает!
Я не отношусь к этому как к истине. Но многие ошибки просто исчезают:
- Исключение нулевого указателя, я не помню, чтобы у меня было такое с момента использования Scala.
- Неопределенное – это не функция, забудьте об этом с помощью ELM.
- Вводящее в заблуждение имя переменной: это был номер телефона но я получил электронное письмо.
- Забудьте изменить имя вызывающего абонента после мини-рефакторинга.
Резюме
Мое резюме очень простое: для кода, который потребует обслуживания новыми разработчиками и не является одностраничным проектом, я использую типизированные языки, для простых сценариев и коротких фрагментов кода, без типов.
Оригинал: “https://dev.to/tomerbendavid/types-when-i-use-when-i-dont-1p65”