Langues de type dynamique par rapport aux langages de type statique

Question

Quels sont les avantages et limites des langues de type dynamique par rapport aux langages de type statique ?

Voir aussi: quel est l’amour de langages dynamiques (un fil beaucoup plus argumentatif...)

Answer 1

La capacité de l'interprète d'en déduire le type et les conversions de type rend les temps de développement plus rapide, mais il peut aussi provoquer l'exécution d'échecs qui vous juste ne peut pas obtenir dans un langage statiquement typé, où que vous les attraper au moment de la compilation. Mais laquelle est la meilleure (ou même si c'est toujours vrai) est vivement débattue dans la communauté de ces jours (et depuis longtemps).

Une bonne lecture sur le sujet est ici

Les défenseurs de typage statique soutiennent que les avantages du typage statique inclure la détection précoce de erreurs de programmation (par exemple en empêchant l'ajout d'un integer boolean), une meilleure documentation sous la forme de type de signatures (par exemple en incorporant des le nombre et les types d'arguments lors de l' la résolution de noms), plus de possibilités pour les optimisations du compilateur (par ex. en remplaçant les appels virtuels en direct les appels lorsque le type exact de l' le récepteur est connu statiquement), augmenté d'exécution de l'efficacité (par exemple, ne pas toutes les valeurs doivent porter une dynamique type), et un meilleur moment de la conception expérience de développement (par exemple, sachant que la type de récepteur, l'IDE peut présenter un menu déroulant de toutes les échéant, les membres). Le typage statique les fanatiques essayez de nous faire croire que "bien tapé programmes ne peuvent pas aller mal". Tout ceci semble impressionnant, il est plutôt vide de sens l'énoncé. Vérifier le type statique est un au moment de la compilation abstraction de la comportement d'exécution de votre programme, et il est donc nécessairement que partiellement son et incomplète. Cela signifie que les programmes peuvent toujours aller de mal en raison de les propriétés qui ne sont pas suivis par le type-checker, et qu'il y a programmes alors qu'ils ne peuvent pas aller mal ne peut pas être vérifié. L' l'impulsion pour faire le typage statique moins partielle et plus complète des causes de type les systèmes à devenir trop compliqué et exotiques, comme en témoignent les concepts comme les "types fantômes" [11] et "bancale types" [10]. C'est comme essayer de courir un marathon avec un ballon et de la chaîne liée à votre jambe et triomphalement en criant que vous près de qu'il fait, même si vous renflouées après le premier kilomètre.

Les défenseurs de typées dynamiquement langues affirment que le typage statique est trop rigide, et que la douceur de dynamiquement langues rend idéal pour le prototypage de systèmes de avec l'évolution des inconnus ou à des exigences, ou qui sont en interaction avec d'autres systèmes ce changement de façon imprévisible (données et intégration de l'application). Bien sûr, dynamiquement typé langues sont indispensable pour traiter vraiment dynamique du comportement des programmes tels que méthode d'interception, le chargement dynamique, code mobile, la durée d'exécution de réflexion, etc. Dans la mère de tous les documents sur script [16], John Ousterhout soutient que statiquement typé systèmes les langages de programmation de rendre le code moins réutilisable, plus de commentaires, pas plus fort, et moins expressif que de façon dynamique tapé des langages de script. Cette l'argument est effacèrent littéralement par de nombreux les promoteurs de typées dynamiquement les langages de script. Nous soutenons que c'est une erreur et tombe dans la même catégorie que faisant valoir que la l'essence de la programmation déclarative est l'élimination de la cession. Ou comme John Hughes a dit [8], c'est logique l'impossibilité de faire un langage plus puissant en omettant de fonctionnalités. Défendre le fait que le report de toutes les la vérification de type à l'exécution est un bon chose, est de jouer à l'autruche tactiques avec le fait que les erreurs doivent être pris dès le début du processus de développement de possible.

Answer 2

Type statique des systèmes de chercher à éliminer certaines erreurs de manière statique, en inspectant le programme sans l'exécuter et de tenter de prouver la solidité à certains égards. Certains systèmes sont capables d'attraper plus d'erreurs que les autres. Par exemple, C# peut éliminer pointeur null exceptions lorsqu'il est utilisé correctement, alors que Java n'a pas un tel pouvoir. Twelf a un type de système qui, de fait, garantit que les épreuves de résilier, de "résoudre" le problème de l'arrêt.

Cependant, aucun système n'est parfait. Afin d'éliminer une classe particulière d'erreurs, ils doivent également refuser certains parfaitement valide les programmes qui ne respectent pas les règles. C'est pourquoi Twelf n'a pas vraiment résoudre le problème de l'arrêt, il évite tout en jetant un grand nombre de parfaitement valide les épreuves qui arrivent à mettre fin d'une manière étrange. De même, la Java du type de système de rejeter du Clojure de l' PersistentVector mise en œuvre en raison de son utilisation hétérogène des tableaux. Il fonctionne au moment de l'exécution, mais le type de système ne peut pas le vérifier.

Pour cette raison, la plupart des systèmes de type " fournir "s'échappe", des façons de remplacer le vérificateur statique. Pour la plupart des langues, elles prennent la forme de casting, même si certains (comme le C# et Haskell) ont ensemble de modes qui sont marqués comme "dangereux".

Subjectivement, j'aime le typage statique. Correctement mis en œuvre (indice: pas de Java), un système de type statique peut être d'une grande aide en enlevant les erreurs avant qu'elles crash du système de production. Typées dynamiquement les langues ont tendance à exiger plus de tests unitaires, ce qui est pénible dans le meilleur des cas. Aussi, les langages statiquement typés peuvent avoir certaines caractéristiques qui sont soit impossible ou dangereux dans la dynamique des systèmes de type (conversions implicites du printemps à l'esprit). Tout est une question de besoins et de goût subjective. Je voudrais ne plus construire la prochaine Éclipse Ruby que je voudrais tenter d'écrire un script de sauvegarde dans l'Assemblée ou de patch du noyau à l'aide de Java.

Oh, et les gens qui disent que "x tape est 10 fois plus productif que d' y taper" sont tout simplement souffler de la fumée. Typage dynamique peut "sentir" plus vite, dans de nombreux cas, mais il perd le sol une fois que vous en fait essayez de faire de votre fantaisie application à exécuter. De même, le typage statique peut sembler comme il est parfait pour le filet de sécurité, mais un coup d'oeil à certains des plus complexes de type générique définitions en Java envoie la plupart des développeurs se précipiter pour les yeux des oeillères. Même avec des systèmes de type et de la productivité, il n'y a pas de solution miracle.

Note finale: ne vous inquiétez pas au sujet de la performance lors de la comparaison statique avec typage dynamique. Moderne Ece comme les V8 et TraceMonkey sont à venir dangereusement-près de langage statique de la performance. Aussi, le fait que Java fait compile vers le bas pour un caractère dynamique intermédiaire de la langue doit être une allusion au fait que pour la plupart des cas, le typage dynamique n'est pas l'énorme performance-killer que certaines personnes font dehors pour être.

Answer 3

Eh bien, les deux sont très, très, très, très mal compris et de deux choses complètement différentes. qui ne sont pas mutuellement exclusives.

Types statiques sont une restriction de la grammaire de la langue. Typé statiquement langues strictement pourrait être dit de ne pas être sans contexte. La simple vérité est qu'il devient gênant pour exprimer une langue sainement dans des grammaires hors contexte qui ne permet pas de traiter l'ensemble de ses données simplement en tant que vecteurs de bits. Type statique de systèmes font partie de la grammaire de la langue le cas échéant, ils suffit de les restreindre plus qu'un contexte de libre-grammaire pourrait grammaticales, vérifie donc arriver dans deux passe au-dessus de la source de vraiment. Types statiques correspondent à la notion mathématique de la théorie des types, le type de théorie en mathématiques restreint la légalité de certaines expressions. Comme, je ne peux pas dire 3 + [4,7] en mathématiques, c'est à cause de la théorie des types.

Types statiques sont donc pas une façon "d'éviter les erreurs" d'un point de vue théorique, ils sont d'une limitation de la grammaire. En effet, à condition que +, 3 et intervalles habituels des définitions théoriques, si on enlève le système de type 3 + [4,7]a assez bien défini résultat qui est un ensemble. 'exécution des erreurs de type' théoriquement n'existent pas, le système de type de l'utilisation pratique est d'empêcher les opérations que pour les êtres humains , n'aurait aucun sens. Les opérations sont toujours en juste à le déplacement et la manipulation de bits de cours.

Le hic, c'est qu'un type de système ne peut pas décider si de telles opérations vont se produire ou pas si il serait autorisé à s'exécuter. Comme dans, exactement de la partition de l'ensemble de tous les programmes possibles à ceux qui vont avoir un "type" d'erreur", et ceux qui ne le sont pas. Il ne peut faire que deux choses:

1: prouver que les erreurs de type vont se produire dans un programme
2: prouver qu'ils ne vont pas se produire dans un programme

Cela peut sembler comme je suis en contradiction avec moi-même. Mais ce que le C ou le Java de type checker n'est il rejette un programme comme "non grammaticale", ou comme il l'appelle 'erreur de type" si elle ne peut pas réussir à 2. Il ne peut pas prouver qu'ils ne vont pas se produire, cela ne signifie pas qu'ils ne vont pas se produire, cela signifie simplement qu'il ne peut pas le prouver. Il se pourrait très bien qu'un programme qui n'aura pas une erreur de type est rejetée simplement parce qu'il ne peut pas être prouvé par le compilateur. Un simple exemple, if(1) a = 3; else a = "string";, sûrement, puisque c'est toujours vrai, l'autre branche ne sera jamais exécutée dans le programme, et aucune erreur ne doit se produire. Mais il ne peut pas prouver ces cas, d'une manière générale, il est donc rejetée. C'est la principale faiblesse de beaucoup de langages à typage statique, à vous protéger contre vous-même, vous êtes nécessairement protégés dans le cas où vous n'en avez pas besoin.

Mais, contrairement à la croyance populaire, il y a aussi les langages statiquement typés travail par principe 1. Ils ont simplement rejeter tous les programmes dont ils peuvent prouver qu'il va provoquer une erreur de type, et de passer tous les programmes dont ils ne peuvent pas. Il est donc possible qu'ils permettent à des programmes qui ont des erreurs de type, un bon exemple de la saisie de la Raquette, c'est hybride entre la dynamique et le typage statique. Et certains diront que vous obtenez le meilleur des deux mondes dans ce système.

Un autre avantage de typage statique, c'est que les types sont connus au moment de la compilation, et donc le compilateur peut utiliser ce fichier. Si nous en Java n' "string" + "string" ou 3 + 3, les deux + des jetons dans le texte en fin de compte représentent un complètement différentes, et datum, le compilateur sait laquelle choisir l'un des types seuls.

Maintenant, je vais faire une déclaration controversée ici, mais nu avec moi: 'typage dynamique" n'existe pas.

Des sons très controversé, mais il est vrai, typées dynamiquement langues à partir d'un point de vue théorique, non typée. Ils sont juste des langages statiquement typés avec un seul type. Ou tout simplement, qu'ils sont des langues qui sont en effet grammaticalement généré par une grammaire sans contexte dans la pratique.

Pourquoi n'ont-ils pas? Parce que chaque opération est défini et autorisé sur chaque opérante, ce qui est un "runtime erreur de type" exactement? C'est à partir d'un exemple théorique purement un effet secondaire. Si cela print("string") qui imprime une chaîne de caractères est une opération, alors qu'est - length(3), l'ancien a pour effet de bord de la rédaction string sur la sortie standard, ce dernier simplement error: function 'length' expects array as argument., c'est tout. Il est à partir d'un point de vue théorique, aucune une telle chose comme un typées dynamiquement de la langue. Ils sont typées

Tout à droite, l'avantage évident de "dynamiquement typé" la langue est l'expression de la puissance, un système de type n'est rien mais une limitation de la puissance expressive. Et en général, les langues avec un système de type, en effet, aurait un résultat défini pour l'ensemble de ces opérations qui ne sont pas autorisés si le type de système a été tout simplement ignorés, les résultats seraient tout simplement pas faire sens pour l'homme. De nombreuses langues perdent leur Turing à l'exhaustivité, après application d'un système de type.

L'inconvénient évident est le fait que les opérations peuvent se produire qui permettrait de produire des résultats qui sont dénués de sens pour les êtres humains. Pour se prémunir contre ce, de façon dynamique langages à typage généralement redéfinir ces opérations, plutôt que la production de ce résultat absurde, ils redéfinissent à l'effet secondaire de l'écriture, une erreur, et éventuellement d'arrêter le programme tout à fait. Ce n'est pas une "erreur" à tous, en fait, la spécification du langage implique généralement, c'est autant le comportement de la langue comme l'impression d'une chaîne à partir d'un point de vue théorique. Type de systèmes ainsi forcer le programmeur à raison, sur le flux de code pour s'assurer que cela ne se produise pas. Ou en fait, la raison, afin qu'il ne se passera peut également être utile en certains points, à des fins de débogage, montrant que ce n'est pas une "erreur", mais une propriété de la langue. En effet, le seul vestige de "typage dynamique" que la plupart des langues ont garde contre une division par zéro. C'est ce typage dynamique est, il n'existe pas de types, il n'y a pas plus de types que zero est un type différent de tous les autres numéros. Ce que les gens appellent un "type" est juste une autre propriété d'une donnée, comme la longueur d'un tableau, ou le premier caractère d'une chaîne. Et de nombreux typées dynamiquement langues également vous permettre d'écrire des choses comme "error: the first character of this string should be a 'z'".

Une autre chose est que typées dynamiquement langues ont le type disponibles à l'exécution et on peut le vérifier et de le gérer et de décider à partir. Bien sûr, en théorie, il n'est pas différent de l'accès le premier char d'un tableau et de voir ce que c'est. En fait, vous pouvez faire votre propre dynamique C, il suffit d'utiliser un seul type long long int et utiliser les 8 premiers bits pour stocker votre "type" dans l'écriture de fonctions, partant, de les vérifier et d'effectuer flottant ou entier plus. Vous avez un langage statiquement typé, avec un type, ou d'un langage dynamique.

Dans la pratique, ce que tous les spectacles, les langages statiquement typés sont généralement utilisés dans le cadre de l'écriture d'un logiciel commercial, alors que typées dynamiquement les langues ont tendance à être utilisé dans le contexte de la résolution de certains problèmes et l'automatisation de certaines tâches. L'écriture de code dans des langages statiquement typés simplement prend du temps et est lourde parce que vous ne pouvez pas faire des choses qui vous savez qui va arriver, ok, mais le système de type encore vous protège contre vous-même pour les erreurs que vous ne faites pas. De nombreux programmeurs ne réalisent même pas qu'ils le font parce que c'est dans leur système, mais lorsque l'on code dans les langages statiques, vous travaillez souvent sur le fait que le type de système ne les laissez pas vous faire des choses qui ne peuvent pas se tromper, parce qu'il ne peut pas prouver qu'il ne vous tromperez pas.

Comme je l'ai noté, 'typé statiquement' signifie en général le cas 2, la présomption de culpabilité. Mais certaines langues, qui ne tirent pas leur système de type de type de théorie du tout à l'utilisation de la règle 1: Innocent jusqu'à preuve du contraire, ce qui pourrait être l'idéal hybride. Alors, peut-être Tapé la Raquette, c'est pour vous.

Aussi, bien, pour une plus absurde et de l'extrême exemple, je suis actuellement à la mise en œuvre d'une langue où les "types" sont vraiment le premier caractère d'un tableau, elles sont données, les données de l' 'type', 'type', qui est lui-même un type et de la donnée, la seule donnée qui est elle-même en tant que type. Les Types ne sont pas finies, ou délimitée de manière statique, mais de nouveaux types peuvent être générés sur la base des informations d'exécution.

Answer 4

Peut-être le plus grand "avantage" de typage dynamique est la moins profonde de la courbe d'apprentissage. Il n'existe pas de système de type d'apprendre et de non-trivial de la syntaxe pour les cas particuliers tels que les contraintes de type. Qui fait de typage dynamique accessible à beaucoup plus de gens et faisable pour beaucoup de gens pour qui sophistiqués de type statique des systèmes sont hors de portée. Par conséquent, typage dynamique a pris dans les contextes de l'éducation (par exemple, Régime/Python au MIT) et spécifiques au domaine des langues pour les non-programmeurs (par exemple, Mathematica). Les langages dynamiques ont aussi pris dans des niches où ils ont peu ou pas de concurrence (par exemple, Javascript).

La plus concise dynamiquement typés langues (par exemple, Perl, APL, J, K, Mathematica) sont spécifiques au domaine et peut être beaucoup plus concis que le plus concis usage général statiquement typé langues (par exemple, OCaml) dans les niches qu'ils étaient conçus.

Les principaux inconvénients de typage dynamique sont:

• De type à l'exécution des erreurs.

• Peut être très difficile, voire pratiquement impossible à atteindre le même niveau d'exactitude et nécessite beaucoup plus de tests.

• Pas de compilateur vérifié la documentation.

• De mauvaises performances (généralement au moment de l'exécution, mais parfois, au moment de la compilation au lieu de cela, par exemple, Staline Régime) et imprévisible de la performance en raison de la dépendance sur des optimisations.

Personnellement, j'ai grandi sur la dynamique des langues, mais de ne pas y toucher avec 40' pôle en tant que professionnel, sauf si il n'y avait pas d'autres options viables.

Answer 5

De Artima est Saisissant: Forte vs Faible, Statique vs Dynamique de l'article:

typage fort empêche de mélanger des opérations incompatibles entre types. Afin de mélanger les types, vous devez utiliser une conversion explicite

le typage faible signifie que vous pouvez mélanger des types sans une conversion explicite

Dans le Pascal Costanza du papier, Dynamique vs Statique Saisissant Un Modèle Basé sur l'Analyse (PDF), il affirme que, dans certains cas, le typage statique est plus sujette à des erreurs de typage dynamique. Certains langages statiquement typés vous forcer manuellement émuler typage dynamique afin de faire "La bonne Chose". Il en parle à Lambda Ultime.