Ну, слабке та сильне введення тексту досить невиразно визначено. Крім того, оскільки найбільш близьким до загального використання "сильного набору тексту" є посилання на речі, які ускладнюють виведення типів, що не залишає нічого більше для опису ще сильніших типів систем. Це як сказати, що якщо ти можеш носити менше 30 фунтів, ти слабкий, і кожен, хто може підняти більше, перебуває в одній категорії «сильних» - оманливе відмінність.
Тому я віддаю перевагу визначенню:
- Слабо типізовані системи використовують типи, щоб запобігти вам робити певні речі (наприклад, помилки)
- Сильно типізовані системи використовують типи, щоб робити речі для вас
Що я маю на увазі під те, що роблю для вас речі? Що ж, давайте вивчимо написання API перетворення зображень у рамках Служби (в 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 як сервер, що використовує сервер Backp. Ігноруйте мову трохи.
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, де типи роблять речі, як показано вище
- Дуже сильно типізований, як Агда або Ідріс, де типи та значення взаємодіють і можуть обмежувати одне одного. Це так сильно, як отримують типові системи, а програмування в них - це те саме, що писати математичні докази того, що робить ваша програма. Примітка: кодування в Агді - це не буквальне написання математичних доказів, типи - це математичні теорії, а функції з цими типами - конструктивні приклади, що підтверджують ці теорії.
Як правило, чим далі ви переходите до цього списку, тим більше, що типи можуть зробити для вас, але вже в самому дні ви забираєтесь у стратосферу, і повітря стає дещо тонкішим - екосистема пакету набагато менша, і ви ' Вам доведеться писати більше речей самостійно, знайшовши відповідну бібліотеку. Перешкода для входу також стає вище, коли ви спускаєтесь, оскільки вам потрібно насправді зрозуміти систему типів, достатню для написання масштабних програм.