Eh bien, le typage faible vs fort est défini de façon assez vague. En outre, étant donné que le plus proche d'une utilisation générale du «typage fort» est de renvoyer des choses qui rendent difficile la conversion de types, ce qui ne laisse rien de plus pour décrire des systèmes de types encore plus forts. C'est comme dire que si vous pouvez transporter moins de 30 livres, vous êtes faible, et tous ceux qui peuvent soulever plus sont dans la même catégorie de «fort» - une distinction trompeuse.
Je préfère donc la définition:
- Les systèmes mal typés utilisent des types pour vous empêcher de faire certaines choses (comme des erreurs)
- Les systèmes fortement typés utilisent des types pour faire des choses pour vous
Qu'est-ce que je veux dire par faire des choses pour vous? Eh bien, examinons l'écriture d'une API de conversion d'image dans le framework Servant (dans Haskell, mais vous n'avez pas vraiment besoin de le savoir pour suivre, vous verrez ...)
{-# 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
Cela signifie que nous voulons certains modules, y compris le package Servant et le plug-in JuicyPixels pour Servant, et que le point d'entrée principal du programme est d'exécuter la fonction de `` conversion '' sur le port 8001 en tant que serveur utilisant le backend Warp. Ignorez le bit de langue.
conversion :: Application
conversion = serve (Proxy :: Proxy ConversionApi) handler
Cela signifie que la fonction de conversion est un serveur où l'API doit correspondre au type 'ConversionApi' et les demandes sont traitées par la fonction handler
type ConversionApi
= ReqBody '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
:> Post '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
Ceci spécifie le ConvesionApitype. Il dit que nous devons accepter les types de contenu entrants spécifiés par la liste '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE], et les traiter comme une DynamicImage, et que nous devons renvoyer une DynamicImage convertie dans la même plage de contenu les types. Ne vous inquiétez pas exactement de ce que:> signifie, considérez-le comme une magie heureuse pour l'instant.
Donc, étant donné ma définition préférée, un système faiblement typé peut désormais garantir des choses comme:
- Vous ne renvoyez pas le mauvais type de contenu sortant
- Vous n'analysez pas la demande entrante comme un type de contenu incorrect
- Si notre serveur était plus compliqué, cela nous empêcherait de créer des URI malformés, mais nous ne renvoyons en fait aucune page HTML contenant des liens (et le type garantit que nous ne pouvons pas!)
- Un système de typage faible vraiment ambitieux pourrait même vérifier pour s'assurer que nous traitons de manière exhaustive tous les types de contenu entrant et sortant, permettant au type d'agir également comme un document de spécification au lieu d'une simple contrainte.
Tous les objectifs élevés, mais pas suffisamment pour être considérés comme un système fortement typé, compte tenu de la définition ci-dessus. Et maintenant, nous devons passer à la partie difficile de l'écriture du code qui suit cette spécification. Dans un système de type très fort , nous écrivons:
handler = return
Et puis nous avons terminé. Ça y est , il n'y a plus de code à écrire . Il s'agit d'un serveur Web entièrement opérationnel (modulo toutes les fautes de frappe que j'ai manquées). Le type a dit au compilateur tout ce dont il a besoin pour créer notre serveur Web à partir des types et des packages (modules techniquement) que nous avons définis et importés.
Alors, comment apprenez-vous à le faire à l'échelle de l'application principale? Eh bien, ce n'est vraiment pas très différent de les utiliser dans des applications à plus petite échelle. Les types absolus ne se soucient pas de la quantité de code écrit les concernant.
L'inspection des types d'exécution est quelque chose que vous voudrez probablement éviter, car cela élimine une énorme quantité d'avantages et permet aux types de rendre votre projet plus compliqué à travailler, plutôt que d'avoir des types simplifiant les choses.
En tant que tel, il s'agit principalement de s'entraîner à modéliser des choses avec des types. Les deux principales façons de modéliser des choses (ou de construire des choses en général) sont de bas en haut et de haut en bas. De haut en bas commence avec le plus haut niveau d'opérations, et lorsque vous construisez le modèle, vous avez des pièces où vous reportez la modélisation à plus tard. La modélisation ascendante signifie que vous commencez par les opérations de base, tout comme vous commencez par les fonctions de base, puis créez des modèles de plus en plus grands jusqu'à ce que vous ayez entièrement capturé le fonctionnement du projet. De bas en haut est plus concret et probablement plus rapide à construire, mais de haut en bas peut mieux informer vos modèles de niveau inférieur sur la façon dont ils doivent réellement se comporter.
Les types sont la façon dont les programmes se rapportent aux mathématiques, littéralement, donc il n'y a pas vraiment de limite supérieure sur la complexité de leur complication, ou un point où vous pouvez en finir avec eux. Pratiquement toutes les ressources en dehors des cours universitaires de niveau supérieur sont toutes consacrées au fonctionnement des types dans une langue particulière, vous devez donc en décider également.
Du mieux que je puisse offrir, les types peuvent être stratifiés comme suit:
- Très faiblement typé, des choses comme JavaScript où [] + {} est défini
- Faible type comme Python, où vous ne pouvez pas faire [] + {}, mais cela n'est vérifié que lorsque vous essayez
- Faible type comme C ou Java, où vous ne pouvez pas faire [] + {}, mais qui est vérifié au moment de la compilation, mais vous n'avez pas les fonctionnalités de type plus avancées
- À cheval sur la frontière entre les types faiblement et fortement typés, comme la métaprogrammation de modèles C ++ et le code Haskell plus simple où les types ne font qu'appliquer des propriétés.
- Complètement dans Fortement typé, comme les programmes Haskell plus compliqués où les types font des choses, comme indiqué ci-dessus
- Le très fortement typé, comme Agda ou Idris, où les types et les valeurs interagissent et peuvent se contraindre. C'est aussi fort que les systèmes de types, et leur programmation équivaut à écrire des preuves mathématiques sur ce que fait votre programme. Remarque: coder dans Agda ce n'est pas littéralement écrire des preuves mathématiques, les types sont des théories mathématiques et les fonctions avec ces types sont des exemples constructifs prouvant ces théories.
Généralement, plus vous descendez dans cette liste, plus les types peuvent faire pour vous, mais tout en bas, vous grimpez dans la stratosphère et l'air devient un peu mince - l'écosystème du package est beaucoup plus petit et vous '' Je vais devoir écrire plus de choses vous-même que d'avoir trouvé une bibliothèque appropriée. La barrière à l'entrée augmente également au fur et à mesure que vous descendez, car vous devez comprendre suffisamment le système de type pour écrire des programmes à grande échelle.