Est-ce que "non typé" signifie également "dynamiquement typé" dans le monde universitaire de la société civile ?

Question

Je lis un diaporama qui dit que "JavaScript est untypé". Cela contredisait 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 est no non typée et offrait des exemples de diverses formes de typage statique, dynamique, fort et faible avec lesquelles je suis familier et heureux donc ce n'était pas la voie à suivre.

J'ai donc demandé à Brendan Eich, le créateur de JavaScript, et il a répondu :

les types académiques utilisent "untyped" pour signifier "pas de types statiques". ils sont assez intelligents pour voir que les valeurs ont des types (duh !). le contexte importe.

Les informaticiens à vocation académique utilisent-ils "untyped" comme synonyme de "dynamically typed" (et est-ce valable ?) ou y a-t-il quelque chose de plus profond que je ne comprends pas ? Je suis d'accord avec Brendan sur le fait que le contexte est important, mais toute citation d'explications serait la bienvenue, car mes livres actuels ne jouent pas le jeu sur ce sujet.

Je veux en avoir le cœur net afin d'améliorer ma compréhension et parce que même Wikipédia ne fait pas référence à cet usage alternatif (que je peux trouver, du moins). Je ne veux pas m'embrouiller en utilisant le terme ou en remettant en question son utilisation à l'avenir si je me trompe :-)

(J'ai également vu un grand Smalltalker dire que Smalltalk est "untyped" aussi, donc ce n'est pas un cas isolé qui m'a poussé à cette quête ! :-))

Answer 1

S'il est vrai que la plupart des chercheurs en informatique qui écrivent sur les types considèrent essentiellement que seuls les langages avec des types dérivables syntaxiquement sont des langages typés, nous sommes beaucoup plus nombreux à utiliser des langages typés de manière dynamique/latente et à prendre ombrage de cet usage.

Je considère qu'il y a 3 types [SIC] de langues :

Untyped - 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 - des types sont associés aux valeurs, 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 à typage dynamique sont sûrs au niveau du type - c'est-à-dire que seuls les opérateurs valides peuvent opérer sur les valeurs. Mais il n'en va pas de même pour les langages à typage statique. Selon la puissance du système de types utilisé, certains opérateurs peuvent être vérifiés uniquement à l'exécution, ou pas du tout. Par exemple, la plupart des langages à typage statique ne gèrent pas correctement le débordement des entiers (l'addition de deux entiers positifs peut produire un entier négatif), et les références à des tableaux hors limites ne sont pas vérifiées du tout (C, C++) ou ne sont vérifiées qu'à l'exécution. En outre, certains systèmes de types sont si faibles que la programmation utile nécessite des hachures d'échappement (casts en C et en famille) pour changer le type des expressions au moment de la compilation.

Tout cela conduit à des affirmations absurdes, comme celle selon laquelle le C++ est plus sûr que le Python parce qu'il est (statiquement typé), alors que la vérité est que le Python est intrinsèquement sûr alors que vous pouvez vous tirer une balle dans la jambe avec le C++.

Answer 2

Cette question porte sur Sémantique

Si je vous donne ces données : 12 quel est son type ? Vous n'avez aucun moyen de le savoir avec certitude. Il peut s'agir d'un entier, d'un flottant ou d'une chaîne de caractères. En ce sens, il s'agit bien 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 sur d'autres données arbitraires, le "type" n'est pas très pertinent (pour mon langage imaginaire) (exemple : peut-être add(12, a) rinde 109 qui est 12 plus la valeur ascii de a ).

Parlons de C une seconde. Le C vous permet de faire ce que vous voulez avec n'importe quel élément de données. Si vous utilisez une fonction qui prend deux uint vous pouvez utiliser et passer ce que vous voulez - et les valeurs seront simplement interprétées comme des uint s. Dans ce sens, C est "non typé" (si vous le traitez de cette manière).

Cependant - et pour en venir à la remarque 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 le problème 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 qu'on nous ait jamais appris à faire ces distinctions.

Pour en revenir à mon exemple du début, un langage qui "ne se soucie pas des types" (per-se) peut vous permettre d'"ajouter" un "âge" et un "nom" sans produire d'erreur de syntaxe... mais cela ne signifie pas que c'est une opération logiquement saine.

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 au développeur d'y réfléchir.

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 "dynamiquement typé" ?

Sémantique.

EDITAR

Je voulais ajouter quelque chose ici parce que certaines personnes semblent s'accrocher à "oui, mais Javascript a des "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 les "humains", d'autres uniquement sur les "singes", et d'autres encore uniquement sur les "choses avec des bras". Que le langage ait été informé ou non de l'existence d'une catégorie d'objets telle que les "choses avec des bras" est aussi peu pertinent pour l'assemblage ("non typé") que pour Javascript ("dynamique"). C'est une question d'intégrité logique - et la seule erreur serait d'utiliser quelque chose qui n'a pas de bras avec cette méthode.

Donc, si vous considérez que Javascript a une certaine "notion de types" en interne - et, par conséquent, des "types dynamiques" - et que cela est en quelque sorte "distinctement différent d'un système non typé" - vous devriez voir dans l'exemple ci-dessus que toute "notion de types" qu'il a en interne n'est pas vraiment pertinente.

Pour effectuer la même opération avec C#, par exemple, j'aurais besoin d'une interface appelée ICreatureWithArms ou quelque chose de similaire. Ce n'est pas le cas en Javascript, ni en C ou en ASM.

Il est clair que le fait que Javascript ait ou non une quelconque compréhension des "types" n'est pas pertinent.

Answer 3

Je ne suis pas informaticien, mais je serais plutôt surpris si "non typé" était vraiment utilisé comme synonyme de "dynamiquement typé" dans la communauté CS (au moins dans les publications scientifiques) car, à mon avis, ces deux termes décrivent des concepts différents. Un langage dynamiquement typé a une notion de type et applique les contraintes de type à l'exécution (vous ne pouvez pas, par exemple, diviser un entier par une chaîne de caractères en Lisp sans obtenir une erreur), tandis qu'un langage non typé n'a aucune notion de type (par exemple, l'assembleur). Même l'article de 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 le sens que "les variables ne sont pas typées" en Javascript (ce qui est vrai). Mais cela ne signifie pas automatiquement que le langage est non typé (ce qui serait faux).

Answer 4

Je suis d'accord avec Brendan - le contexte est primordial.

Mon avis :

Je me souviens avoir été confus, vers 2004, parce qu'il y avait des discussions pour savoir si Ruby était non typé ou dynamiquement typé. Les personnes de la vieille école C/C++ (dont je faisais partie) pensaient au compilateur et disaient que Ruby était non typé.

Rappelez-vous, en C, il n'y a pas de types d'exécution, il n'y a que des adresses et si le code qui s'exécute décide de traiter ce qui se trouve à cette adresse comme quelque chose qu'il n'est pas, oups ! C'est définitivement non typé et très différent du typage dynamique.

Dans ce monde, le "typage" est une question de compilateur. Le C++ avait un "typage fort" parce que les contrôles du compilateur étaient plus stricts. Java et C étaient plus "faiblement typés" (il y a même eu des débats pour savoir si Java était fortement ou faiblement typé). Les langages dynamiques étaient, dans ce continuum, "non typés" parce qu'ils n'avaient pas de vérification de type par le compilateur.

Aujourd'hui, pour les programmeurs en exercice, nous sommes tellement habitués aux langages dynamiques, que nous pensons évidemment que non typé signifie pas de vérification du type par le compilateur ou l'interpréteur, ce qui serait incroyablement difficile à déboguer. Mais il y a eu une période où cela n'était pas évident et dans le monde plus théorique de la CS, cela peut même ne pas être significatif.

Dans un sens profond, rien ne peut être non-typé (ou presque rien, en tout cas) parce que vous devez avoir une certaine intention en manipulant une valeur pour écrire un algorithme significatif. C'est le monde de la CS théorique, qui ne traite pas des spécificités de l'implémentation d'un compilateur ou d'un interprète pour un langage donné. Donc "non typé" est (probablement, je ne sais pas) entièrement dépourvu de sens dans ce contexte.