Est-ce que "non typé" signifie également "typé dynamiquement" dans le monde académique CS?
Je lis un jeu de diapositives qui dit que "JavaScript n'est pas typé". Cela contredit ce que je pensais être vrai, alors j'ai commencé à creuser pour essayer d'en savoir plus.
Chaque réponse à JavaScript est-il un langage non typé? dit que JavaScript n'est pas non typé et offre des exemples de diverses formes de statiques, dynamiques , typage fort et faible que je connais et dont je suis content ... donc ce n'était pas la voie à suivre.
J'ai donc demandé à Brendan Eich, le créateur de JavaScript, et il a dit:
les types universitaires utilisent "non typé" pour signifier "pas de types statiques". ils sont assez intelligents pour voir que les valeurs ont des types (duh!). le contexte compte.
Les informaticiens à vocation académique utilisent-ils "non typé" comme synonyme de "typé dynamiquement" (et est-ce valable?) Ou y a-t-il quelque chose de plus profond que cela me manque? Je suis d'accord avec Brendan que le contexte est important mais toutes les citations d'explications seraient formidables car mes livres "à consulter" actuels ne jouent pas le ballon sur ce sujet.
Je veux clarifier cela afin que je puisse améliorer ma compréhension et parce que même Wikipedia ne fait pas référence à cette utilisation alternative (que je peux trouver, de toute façon). Je ne veux pas me tromper avec l'utilisation du terme ou remettre en question l'utilisation du terme à l'avenir si je me trompe :-)
(J'ai également vu un petit Smalltalker dire que Smalltalk est "non typé" aussi, donc ce n'est pas un one-off qui est ce qui m'a déclenché dans cette quête! :-))
Oui, c'est une pratique courante dans la littérature universitaire. Pour le comprendre, il est utile de savoir que la notion de "type" a été inventée dans les années 1930, dans le contexte du lambda calcul (en fait, même plus tôt, dans le contexte de la théorie des ensembles). Depuis lors, une branche entière de la logique de calcul a émergé, connue sous le nom de "théorie des types". La théorie du langage de programmation est basée sur ces fondements. Et dans tous ces contextes mathématiques, le "type" a une signification particulière et bien établie.
La terminologie "typage dynamique" a été inventée beaucoup plus tard - et c'est une contradiction dans les termes face à l'utilisation mathématique courante du mot "type".
Par exemple, voici la définition de "système de type" que Benjamin Pierce utilise dans son manuel standard Types et langages de programmation :
Un système de types est une méthode syntaxique traitable pour prouver l'absence de certains comportements de programme en classant les phrases en fonction des types de valeurs qu'ils calculent.
Il remarque également:
Le mot "statique" est parfois ajouté explicitement - nous parlons d'un "langage de programmation typé statiquement", par exemple - pour distinguer les types d'analyses de compilation que nous considérons ici du typage dynamique ou latent trouvé dans des langages tels que Scheme (Sussman et Steele, 1975; Kelsey, Clinger et Rees, 1998; Dybvig, 1996), où des balises de type d'exécution sont utilisées pour distinguer différents types de structures dans le tas. Des termes comme "typé dynamiquement" sont sans doute des malentendus et devraient probablement être remplacés par "vérifié dynamiquement", mais l'utilisation est standard.
La plupart des personnes travaillant sur le terrain semblent partager ce point de vue.
Notez que cela ne signifie pas que "non typé" et "typé dynamiquement" sont synonymes. Plutôt, que ce dernier est un nom (techniquement trompeur) pour un cas particulier du premier.
PS: Et FWIW, il se trouve que je suis à la fois chercheur universitaire dans les systèmes de types et implémenteur non académique de JavaScript, donc je dois vivre avec le schisme. :)
Je suis un informaticien universitaire spécialisé dans les langages de programmation, et oui, le mot "non typé" est fréquemment (mal) utilisé de cette manière. Ce serait bien de réserver le Word pour une utilisation avec des langues qui ne portent pas de balises de type dynamique, comme le code Forth et Assembly, mais ces langues sont rarement utilisées et encore plus rarement étudiées, et il est beaucoup plus facile de dire "non typé" que "typé dynamiquement".
Bob Harper aime dire que les langages comme Scheme, Javascript, etc. doivent être considérés comme des langages typés avec un seul type: value. Je m'appuie sur cette vision, car elle permet de construire une vision du monde cohérente en utilisant un seul formalisme de type.
P.S. Dans le calcul lambda pur, les seules "valeurs" sont des termes sous forme normale, et les seuls termes fermé sous forme normale sont des fonctions. Mais la plupart des scientifiques qui utilisent le calcul lambda ajoutent des types de base et des constantes, puis vous incluez un système de type statique pour lambda ou vous êtes de retour aux balises de type dynamique.
P.P.S. À l'affiche originale: en ce qui concerne les langages de programmation, et en particulier les systèmes de type, les informations sur Wikipédia sont de mauvaise qualité. Ne lui faites pas confiance.
J'ai examiné la question et constaté que la réponse à votre question est simplement et étonnamment "oui": les types de CS académiques, ou du moins certains d'entre eux, utilisent "non typé" pour signifier "typé dynamiquement". Par exemple, Langages de programmation: principes et pratiques, Third Edition (par Kenneth C. Louden et Kenneth A. Lambert, publié en 2012) dit ceci:
Les langues sans système de type statique sont généralement appelées langues non typées (ou langues typées dynamiquement ). Ces langages incluent Scheme et d'autres dialectes de LISP, Smalltalk et la plupart des langages de script tels que Perl, Python et Ruby. Notez, cependant, qu'un langage non typé ne permet pas nécessairement aux programmes de corrompre les données - cela signifie simplement que toutes les vérifications de sécurité sont effectuées au moment de l'exécution. […]
[ link ] (note: gras dans l'original) et continue d'utiliser "non typé" de cette façon.
Je trouve cela surprenant (pour les mêmes raisons qu'afrischke et Adam Mihalcin donnent), mais vous y êtes. :-)
Modifié pour ajouter: Vous pouvez trouver plus d'exemples en branchant "untyped languages" dans Google Recherche de Livres. Par exemple:
[…] Il s'agit du principal mécanisme de dissimulation d'informations dans de nombreuses langues non typées. Par exemple, le schéma PLT [4] utilise des générateurs
structs, […]
- Jacob Matthews et Amal Ahmed, 2008 [ lien ]
[…], Nous présentons une analyse de temps de liaison pour un langage fonctionnel non typé […]. […] Il a été mis en œuvre et est utilisé dans un évaluateur partiel pour un dialecte libre d'effets secondaires de Scheme. Cependant, l'analyse est suffisamment générale pour être valable pour les langages fonctionnels typés non stricts tels que Haskell. […]
- Charles Consel, 1990 [ lien ]
Soit dit en passant, mon impression, après avoir parcouru ces résultats de recherche, est que si un chercheur écrit à propos d'un langage fonctionnel "non typé", il/elle considère très probablement qu'il est "non typé" dans le même sens que le lambda non typé. calcul qu'Adam Mihalcin mentionne. Au moins, plusieurs chercheurs mentionnent Scheme et le calcul lambda dans le même souffle.
Ce que la recherche ne fait pas dit, bien sûr, est de savoir s'il y a des chercheurs qui rejettent cette identification, et ne faites pas considère ces langues comme "non typées" ". Eh bien, j'ai trouvé ceci:
J'ai alors réalisé qu'il n'y a vraiment pas de circularité, car les langues typées dynamiquement ne sont pas des langues non typées - c'est juste que les types ne sont généralement pas immédiatement évidents à partir du texte du programme.
- quelqu'un (je ne peux pas dire qui), 1998 [ link ]
mais évidemment la plupart les personnes qui rejettent cette identification ne ressentiraient pas le besoin de le dire explicitement.
Non typé et typé dynamiquement ne sont absolument pas synonymes. Le langage qui est le plus souvent appelé "non typé" est le Lambda Calculus, qui est en fait un langage unitaire - tout est une fonction, nous pouvons donc prouver statiquement que le type de tout est la fonction. Un langage typé dynamiquement a plusieurs types, mais n'ajoute pas un moyen pour le compilateur de les vérifier statiquement, forçant le compilateur à insérer des vérifications d'exécution sur les types de variables.
Ensuite, JavaScript est un langage typé dynamiquement: il est possible d'écrire des programmes en JavaScript de telle sorte qu'une variable x puisse être un nombre, ou une fonction, ou une chaîne, ou quelque chose d'autre (et déterminer lequel nécessiterait résolution du problème d'arrêt ou d'un problème mathématique difficile), vous pouvez donc appliquer x à un argument et le navigateur doit vérifier à l'exécution que x est une fonction.
Les deux déclarations sont correctes, selon que vous parlez de valeurs ou de variables. Les variables JavaScript ne sont pas typées, les valeurs JavaScript ont des types et les variables peuvent s'étendre sur n'importe quel type de valeur au moment de l'exécution (c'est-à-dire `` dynamiquement '').
En JavaScript et dans de nombreux autres langages, les valeurs et non les variables portent des types. Toutes les variables peuvent s'étendre sur tous les types de valeurs et peuvent être considérées comme "typées dynamiquement" ou "non typées" - du point de vue de la vérification de type, une variable qui n'a pas de type/inconnaissable et une variable qui peut prendre n'importe quel type sont logiquement et pratiquement équivalentes . Lorsque les théoriciens des types parlent de langages et de types, ils en parlent généralement - des variables portant des types - parce qu'ils sont intéressés par l'écriture de vérificateurs de types et de compilateurs, etc., qui fonctionnent sur le texte du programme (c'est-à-dire les variables) et non sur un programme en cours d'exécution en mémoire. (c'est-à-dire les valeurs).
En revanche, dans d'autres langages, comme C, les variables portent des types mais pas les valeurs. Dans des langages comme Java, les variables et les valeurs portent toutes deux des types. En C++, certaines valeurs (celles avec des fonctions virtuelles) portent des types et d'autres non. Dans certaines langues, il est même possible que les valeurs changent de type, bien que cela soit généralement considéré comme une mauvaise conception.
Cette question concerne Sémantique
Si je vous donne ces données: 12 Quel est son type? Vous n'avez aucun moyen de le savoir avec certitude. Pourrait être un entier - pourrait être un flottant - pourrait être une chaîne. En ce sens, il s'agit essentiellement de données "non typées".
Si je vous donne un langage imaginaire qui vous permet d'utiliser des opérateurs comme "ajouter", "soustraire" et "concaténer" sur ces données et d'autres données arbitraires, le "type" est quelque peu hors de propos (pour mon langage imaginaire) (exemple : peut-être add(12, a) donne 109 qui est 12 plus la valeur ascii de a).
Parlons C pendant une seconde. C vous permet à peu près de faire ce que vous voulez avec n'importe quelle donnée arbitraire. Si vous utilisez une fonction qui prend deux uints - vous pouvez transtyper et transmettre tout ce que vous voulez - et les valeurs seront simplement interprétées comme uints. En ce sens, C est "non typé" (si vous le traitez de cette manière).
Cependant - et pour en venir au point de Brendan - si je vous disais que "mon âge est 12" - alors 12 A un type - au moins nous savons que c'est numérique. Avec le contexte tout a un type - quelle que soit la langue.
C'est pourquoi j'ai dit au début - votre question est une question de sémantique. Quelle est la signification de "non typé"? Je pense que Brendan a mis le doigt sur la tête quand il a dit "pas de types statiques" - parce que c'est tout ce que cela peut signifier. Les humains classent naturellement les choses en types. Nous savons intuitivement qu'il y a quelque chose de fondamentalement différent entre une voiture et un singe - sans jamais avoir appris à faire ces distinctions.
Pour revenir à mon exemple au début - un langage qui "ne se soucie pas des types" (en soi) peut vous permettre "d'ajouter" un "âge" et un "nom" sans produire une erreur de syntaxe ... mais cela ne signifie pas que c'est une opération logique.
Javascript peut vous permettre de faire toutes sortes de choses folles sans les considérer comme des "erreurs". Cela ne signifie pas que ce que vous faites est logique. C'est pour le développeur de travailler.
Un système/langage qui n'applique pas la sécurité des types au moment de la compilation/construction/interprétation est-il "non typé" ou "typé dynamiquement"?
Sémantique.
[~ # ~] modifier [~ # ~]
Je voulais ajouter quelque chose ici parce que certaines personnes semblent se rattraper sur "oui, mais Javascript a quelques" types "".
Dans mon commentaire sur la réponse de quelqu'un d'autre, j'ai dit:
En Javascript, je pourrais avoir des objets que j'ai construits pour être des "singes" et des objets que j'ai construits pour être des "humains" et certaines fonctions pourraient être conçues pour fonctionner uniquement sur des "humains", d'autres sur des "singes" seulement, et d'autres encore sur "Things With Arms". Que l'on ait ou non dit au langage qu'il existe une catégorie d'objets telle que "les choses avec des armes" n'a pas autant d'importance pour Assembly ("non typé") que pour Javascript ("dynamique"). Tout est une question d'intégrité logique - et la seule erreur serait d'utiliser quelque chose qui n'a pas d'armes avec cette méthode.
Donc, si vous considérez Javascript comme ayant une "notion de types" en interne - et, par conséquent, "des types dynamiques" - et pensez que c'est en quelque sorte "distinctement différent d'un système non typé" - vous devriez voir de l'exemple ci-dessus que toute "notion de types" qu'il possède en interne est vraiment hors de propos.
Pour effectuer la même opération avec C #, par exemple, j'avais BESOIN d'une interface appelée ICreatureWithArms ou quelque chose de similaire. Ce n'est pas le cas en Javascript - ce n'est pas le cas en C ou en ASM.
De toute évidence, que Javascript comprenne ou non les "types" est sans importance.
S'il est vrai que la plupart des chercheurs CS qui écrivent sur les types ne considèrent essentiellement que les langages avec des types dérivables syntaxiquement comme des langages typés, nous sommes beaucoup plus nombreux à utiliser des langages typés dynamiquement/latents qui ombragent cet usage.
Je considère qu'il existe 3 types [SIC] de langues:
Non typé - seul l'opérateur détermine l'interprétation de la valeur - et cela fonctionne généralement sur n'importe quoi. Exemples: assembleur, BCPL
Typé statiquement - les expressions/variables ont des types qui leur sont associés, et ce type détermine l'interprétation/la validité de l'opérateur au moment de la compilation. Exemples: C, Java, C++, ML, Haskell
Typé dynamiquement - les valeurs ont des types qui leur sont associés, et ce type détermine l'interprétation/la validité de l'opérateur au moment de l'exécution. Exemples: LISP, Scheme, Smalltalk, Ruby, Python, Javascript
À ma connaissance, tous les langages typés dynamiquement sont sécurisés - c'est-à-dire que seuls les opérateurs valides peuvent opérer sur des valeurs. Mais il n'en va pas de même pour le langage de type statique. Selon la puissance du système de type utilisé, certains opérateurs peuvent être contrôlés uniquement au moment de l'exécution, ou pas du tout. Par exemple, la plupart des langages de type statique ne gèrent pas correctement le débordement d'entier (l'ajout de 2 entiers positifs peut produire un entier négatif) et les références de tableau hors limites ne sont pas du tout vérifiées (C, C++) ou sont vérifiées uniquement à au moment de l'exécution. De plus, certains systèmes de types sont si faibles qu'une programmation utile nécessite des hachures d'échappement (transtypages en C et famille) pour changer le type d'expressions au moment de la compilation.
Tout cela conduit à des affirmations absurdes, telles que C++ est plus sûr que Python parce qu'il est (typé statiquement), alors que la vérité est que Python est intrinsèquement sûr pendant que vous pouvez tirer votre jambe avec C++.
Je ne suis pas un informaticien, mais je serais plutôt surpris si "non typé" était vraiment utilisé comme synonyme de "typé dynamiquement" dans la communauté CS (au moins dans les publications scientifiques) car à mon humble avis ces deux termes décrivent des concepts différents. Un langage typé dynamiquement a une notion de types et il applique les contraintes de type lors de l'exécution (vous ne pouvez pas par exemple diviser un entier par une chaîne dans LISP sans obtenir une erreur) tandis qu'un langage non typé n'a aucune notion de types à tous (par exemple assembleur). Même l'article Wikipedia sur les langages de programmation (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) fait cette distinction.
Mise à jour: Peut-être que la confusion vient du fait que certains textes disent quelque chose dans la mesure où "les variables ne sont pas tapées" en Javascript (ce qui est vrai). Mais cela ne signifie pas automatiquement que la langue n'est pas typée (ce qui serait faux).
D'accord avec Brendan - le contexte est tout.
Ma prise:
Je me souviens avoir été confus, vers 2004, car il y avait des arguments pour savoir si Ruby n'était pas typé ou tapé dynamiquement. Les gens de la vieille école C/C++ (dont j'étais un) pensaient au compilateur et dire Ruby n'était pas typé.
N'oubliez pas qu'en C, il n'y a pas de types d'exécution, il y a juste des adresses et si le code qui s'exécute décide de traiter ce qui se trouve à cette adresse comme quelque chose qui ne l'est pas, whoops. C'est définitivement non typé et très différent de typé dynamiquement.
Dans ce monde, "taper" concerne le compilateur. C++ avait un "typage fort" car les vérifications du compilateur étaient plus strictes. Java et C étaient plus "faiblement typés" (il y avait même des arguments pour savoir si Java était fortement ou faiblement typé). Les langages dynamiques étaient, dans ce continuum, "non typé" car ils n'avaient aucune vérification de type de compilateur.
Aujourd'hui, pour les programmeurs pratiquants, nous sommes tellement habitués aux langages dynamiques, nous pensons évidemment que non typé ne signifie aucun compilateur ni interprète, ce qui serait incroyablement difficile à déboguer. Mais il y a eu une période où ce n'était pas évident et dans le monde plus théorique de la CS, cela n'a peut-être même pas de sens.
Dans un sens profond, rien ne peut être non typé (ou presque rien, de toute façon) car vous devez avoir une certaine intention de manipuler une valeur pour écrire un algorithme significatif. C'est le monde de la CS théorique, qui ne traite pas des détails de la façon dont un compilateur ou un interprète est implémenté pour une langue donnée. Donc, "non typé" est (probablement, je ne sais pas) totalement dénué de sens dans ce contexte.