Ну, слабая и сильная типизация довольно расплывчаты. Кроме того, так как наиболее близким к общему использованию «строгой типизации» является обращение к вещам, которые затрудняют приведение типов, что не оставляет ничего другого для описания еще более сильных систем типов. Это все равно, что сказать, что если вы можете нести менее 30 фунтов, вы слабые, и каждый, кто может поднять больше, относится к той же категории «сильных», что вводит в заблуждение.
Поэтому я предпочитаю определение:
- Слабо типизированные системы используют типы, чтобы помешать вам делать определенные вещи (например, ошибки)
- Строго типизированные системы используют типы, чтобы сделать что-то для вас
Что я имею в виду, делая вещи для вас? Что ж, давайте рассмотрим написание API для преобразования изображений в инфраструктуре Servant (в Haskell, но вам не нужно знать, что нужно, чтобы следовать, вы увидите ...)
{-# LANGUAGE
TypeOperators,
DataKinds
#-}
import Codec.Picture
import Data.Proxy
import Network.Wai.Handler.Warp (run)
import Servant
import Servant.JuicyPixels
main :: IO ()
main = run 8001 conversion
Это говорит о том, что нам нужны некоторые модули, в том числе пакет Servant и плагин JuicyPixels, в Servant, и что основной точкой входа в программу является запуск функции «преобразования» на порту 8001 в качестве сервера с использованием бэкэнда Warp. Не обращайте внимания на язык немного.
conversion :: Application
conversion = serve (Proxy :: Proxy ConversionApi) handler
Это говорит о том, что функция преобразования является сервером, где API должен соответствовать типу «ConversionApi», а запросы обрабатываются функцией handler
type ConversionApi
= ReqBody '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
:> Post '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
Это указывает ConvesionApiтип. Он говорит, что мы должны принять входящие типы контента, указанные в списке '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE], и обработать их как DynamicImage, и что мы должны вернуть DynamicImage, преобразованный в тот же диапазон контента типы. Не беспокойтесь о том, что:> означает, просто покажите это счастливой магией.
Итак, учитывая мое предпочтительное определение, система со слабой типизацией теперь может обеспечить такие вещи, как:
- Вы не возвращаете неправильный исходящий тип контента
- Вы не анализируете входящий запрос как неправильный тип контента
- Если бы наш сервер был более сложным, это помешало бы нам создавать искаженные URI, но на самом деле мы не возвращаем никаких HTML-страниц, содержащих ссылки (а тип гарантирует, что мы не можем!)
- Действительно амбициозная система слабой типизации может даже проверить, чтобы убедиться, что мы исчерпывающе обрабатываем все входящие и исходящие типы контента, позволяя типу также действовать как документ спецификации, а не просто как ограничение.
Все высокие цели, но на самом деле не достаточно, чтобы квалифицироваться как строго типизированная система, учитывая приведенное выше определение. И теперь мы должны перейти к сложной части написания кода, соответствующего этой спецификации. В действительно сильной системе типов мы пишем:
handler = return
И тогда мы закончили. Вот и все, больше нет кода для написания . Это полностью работающий веб-сервер (по модулю любые опечатки, которые я пропустил). Тип рассказал компилятору все, что ему нужно для создания нашего веб-сервера из типов и пакетов (технически модулей), которые мы определили и импортировали.
Итак, как вы научитесь делать это в масштабах основных приложений? Ну, это не сильно отличается от использования их в небольших приложениях. Типы, которые являются абсолютными, не заботятся о том, сколько кода написано относительно них.
Вероятно, вы захотите избежать проверки типов во время выполнения, потому что это исключает огромное количество преимуществ и позволяет типам усложнять работу с вашим проектом, а не упрощает типы.
Таким образом, это в основном просто практика моделирования вещей с типами. Два основных способа моделирования вещей (или построения вещей в целом) - снизу вверх и сверху вниз. Нисходящий процесс начинается с наивысшего уровня операций, и при построении модели у вас есть детали, на которые вы откладываете моделирование на потом. Моделирование снизу вверх означает, что вы начинаете с базовых операций, точно так же, как вы начинаете с базовых функций, затем строите все большие и большие модели, пока вы полностью не захватите работу проекта. Внизу более конкретный и, вероятно, быстрее построить, но сверху вниз может лучше информировать ваши модели нижнего уровня о том, как они должны вести себя на самом деле.
Типы - это то, как программы относятся к математике, в буквальном смысле, поэтому на самом деле нет верхней границы того, насколько сложным они могут стать, или точки, в которой вы можете «закончить», узнав о них. Практически все ресурсы за пределами университетских курсов более высокого уровня посвящены тому, как шрифты работают на каком-то конкретном языке, поэтому вам также нужно решить это.
Насколько я могу предложить, типы могут быть разделены следующим образом:
- Очень слабый тип, такие вещи, как JavaScript, где определено [] + {}
- Слабо набирается как Python, где вы не можете сделать [] + {}, но это не проверяется, пока вы не попробуете
- Слабая типизация, например C или Java, где вы не можете сделать [] + {}, но это проверяется во время компиляции, однако у вас нет более продвинутых функций типа
- Преодолевая границу между слабо и строго типизированным, таким как метапрограммирование шаблонов C ++, и более простым кодом на Haskell, где типы обеспечивают только свойства.
- Полностью в строго типизированных, как более сложные программы на Haskell, где типы делают вещи, как показано выше
- Очень строго типизированный, такой как Agda или Idris, где типы и значения взаимодействуют и могут ограничивать друг друга. Это так же сильно, как системы типов, и программирование в них такое же, как написание математических доказательств того, что делает ваша программа. Примечание: кодирование в Agda - это не буквальное написание математических доказательств, типы - это математические теории, а функции с этими типами являются конструктивными примерами, доказывающими эти теории.
Как правило, чем дальше вы идете по этому списку, тем больше типов могут сделать для вас, но на самом деле вы забираетесь в стратосферу, и воздух становится немного тоньше - экосистема пакета намного меньше, и вы ' Я должен буду написать больше вещей, а не найти соответствующую библиотеку. Барьер для входа также возрастает по мере того, как вы спускаетесь, поскольку вы должны понимать систему типов, достаточную для написания крупномасштабных программ.