Pourquoi les langages interprétés sont-ils principalement ducktypés alors que la compilation est forte?

Question

Je ne le sais tout simplement pas, y a-t-il une raison technique à cela? Est-il plus difficile d'implémenter un compilateur pour un langage à typage faible? Qu'Est-ce que c'est?

Answer 1

Les prémisses de la question sont un peu douteuses. Il n'est pas vrai que les langages interprétés sont pour la plupart ducktyped. Il n'est pas vrai que les langages compilés pour la plupart ont un typage fort. Le système de type est une propriété d'une langue. Compilé rapport à interpréter est une propriété d'une mise en œuvre.

Exemples:

• Le langage de programmation Scheme est dynamiquement typés (aka canard-typé), et elle a plusieurs dizaines d'interpréter les implémentations, mais aussi quelques beaux natif compilateurs de code, y compris le Vol, Gambit, et PLT Régime (qui comprend à la fois les services d'un interprète et d'un compilateur JIT de faire des transitions sans heurt).

• Le langage de programmation Haskell est statiquement typé; les deux plus célèbres implémentations de l'interprète de CÂLINS et le compilateur GHC. Il y a plusieurs autres honorable implémentations divisé à peu près également entre la compilation en code natif (csj) et l'interprétation (l'Hélium).

• Le langage de programmation Standard ML est statiquement typé, et il a eu beaucoup de code natif compilateurs, dont l'un des meilleurs et les plus activement maintenu est MLton, mais l'un des plus utiles implémentations est l'interprète de Moscou ML

• Le langage de programmation Objective Caml est un langage statiquement typé. Il est livré avec une seule mise en œuvre (de l'INRIA en France), mais cette application comprend à la fois les services d'un interprète et d'un code natif compilateur.

• Le langage de programmation Pascal est statiquement typé, mais il est devenu populaire dans les années 1970 en raison de l'excellente mise en œuvre construite à l'UCSD, qui était basée sur un P-code interprète. Dans les dernières années de beaux-native-compilateurs de code est disponible, comme l'IBM Pascal/VS compilateur pour les 370 série d'ordinateurs.

• Le langage de programmation C est statiquement typé, et aujourd'hui, presque toutes les implémentations sont compilées, mais dans les années 1980, ceux d'entre nous qui sont assez chanceux pour être à l'aide de Saber C ont été à l'aide d'un interprète.

Néanmoins, il ya une certaine vérité derrière votre question, de sorte que vous méritez d'être plus réfléchie réponse. La vérité est que typées dynamiquement langues ne semblent être en corrélation avec interprété implémentations. Pourquoi?

• Beaucoup de nouvelles langues sont définies par une mise en œuvre. Il est plus facile de construire un interprète que de construire un compilateur. Il est plus facile de contrôler les types dynamiquement que de vérifier statiquement. Et si vous êtes à la rédaction d'un interprète, il y a peu de gain de performance statique de la vérification de type.

• Sauf si vous êtes de la création ou de l'adaptation d'un très souples, de type polymorphe système, un système de type statique est susceptible d'obtenir dans le programmeur de la sorte. Mais si vous écrivez un interprète, une raison peut être pour créer un petit, léger mise en œuvre qui reste à l'extérieur du programmeur du chemin.

• Dans certains langages interprétés, de nombreuses opérations fondamentales sont tellement chers que la charge supplémentaire de la vérification des types lors de l'exécution n'a pas d'importance. Un bon exemple est post-scriptum: si vous allez courir et de pixelliser les courbes de Bézier à la baisse d'un chapeau, vous n'aurez pas rechigner à la vérification d'une balise de type ici ou là.

Par ailleurs, veuillez méfiez-vous des termes "forte" et "faible", en tapant, parce qu'ils n'ont pas universellement accepté sens technique. En revanche, le typage statique signifie que les programmes sont vérifiées avant d'être exécuté, et un programme peut être rejeté avant qu'il ne commence. Typage dynamique signifie que les types de valeurs sont vérifiées au cours de l'exécution, et un mal tapé l'opération pourrait provoquer le programme de stopper ou autrement signal une erreur au moment de l'exécution. Une des principales raisons pour le typage statique est la règle de programmes qui pourraient avoir de tels "dynamique des erreurs de type". (C'est une autre raison pour laquelle les gens qui écrivent des interprètes sont souvent moins intéressés par le typage statique; l'exécution se produit immédiatement après vérification de type, de sorte que la distinction et la nature de la garantie ne sont pas aussi évidente.)

Typage fort signifie généralement qu'il n'existe pas de lacunes dans le système de type, tandis que le typage faible signifie que le type de système peut être subverti (invalidant des garanties). Les termes sont souvent utilisés de manière incorrecte à la moyenne de la statique et de la dynamique de la frappe. Pour voir la différence, pensez à C: le langage est de type vérifiée au moment de la compilation (typage statique), mais il y a beaucoup de lacunes; vous pouvez très bien la fonte d'une valeur d'un type vers un autre type de la même taille---en particulier, vous pouvez convertir les types pointeur librement. Pascal est un langage qui a été destiné à être fortement typé, mais célèbre eu un imprévu échappatoire: une variante du dossier avec pas de balise.

Les implémentations de langages fortement typés souvent acquérir des lacunes au fil du temps, habituellement de sorte qu'une partie du système d'exécution peut être mis en œuvre dans le langage de haut niveau. Par exemple, Objective Caml possède une fonction appelée Obj.magic qui a l'effet de retour de son argument, mais au moment de la compilation il convertit tout type de valeur à un tout autre type. Mon exemple préféré est Modula-3, dont les concepteurs ont appelé leur type coulée de construire LOOPHOLE.

En résumé:

• Statique vs dynamique est la langue.

• Compilé vs interprété est la mise en œuvre.

• En principe, les deux choix peuvent être et sont fabriqués de façon orthogonale, mais pour le son des raisons techniques typage dynamique souvent en corrélation avec l'interprétation.

Answer 2

La raison pour laquelle vous ne la liaison anticipée (typage fort) est la performance. Avec le début de la liaison, vous trouvez l'emplacement de la méthode au moment de la compilation, de sorte qu'au moment de l'exécution, il sait déjà où il vit.

Cependant, avec la fin de la liaison, vous devez aller à la recherche d'une méthode qui semble la méthode que le code du client appelé. Et bien sûr, avec beaucoup, beaucoup d'appels de méthode dans un programme, qui est ce qui rend la dynamique des langues "lente".

Mais bien sûr, vous pourriez créer un compilés statiquement langue qui fait la liaison tardive, ce qui irait à l'encontre de la plupart des avantages de la compilation statique.

Answer 3

C'est à peu près parce que les gens qui écrivent et utilisent des langages interprétés ont tendance à préférer ducktyping, et les gens qui développent et utilisent les langages compilés préfèrent fort explicite de la frappe. (Je pense que le consensus raison pour laquelle ce serait quelque part dans la région de 90% pour la prévention des erreurs, et 10% pour le rendement.) Pour la plupart des programmes écrits aujourd'hui, la différence de vitesse serait négligeable. Microsoft Word a été exécuté sur le p-code (non compilé) pour - ce - 15 ans maintenant?

Le meilleur des cas, au point que je pense. Classique Visual Basic (VB6/VBA/etc.) Le même programme peut être écrit en VB et de courir avec des résultats identiques et comparables vitesse compilé ou interprété. En outre, vous avez la possibilité de déclarations de type (en fait, les déclarations de variables) ou pas. La plupart des gens ont préféré les déclarations de type, généralement pour la prévention des erreurs. Je n'ai jamais entendu ou lu n'importe où à l'utilisation des déclarations de types pour la vitesse. Et cela remonte au moins aussi loin que de deux pouvoirs de grandeur de la vitesse du matériel et de la capacité.

Google est l'objet de beaucoup d'attention ces derniers temps en raison de leur travail sur un compilateur JIT pour javascript qui nécessitera pas de modifications à la langue, et a besoin de plus d'attention de la part du programmeur. Dans ce cas, le seul avantage de la vitesse.

Answer 4

Parce que les langages compilés besoin de prendre la quantité de mémoire utilisée en compte lorsqu'ils sont compilés.

Quand vous voyez quelque chose comme:

int a

en C++, le compilateur crache code que les réserves de quatre octets de mémoire et attribue le symbole local "a" au point pour que la mémoire. Si vous aviez un sans type langage de script comme javascript, l'interprète, en coulisses, alloue la mémoire nécessaire. Vous pouvez le faire:

var a = 10;  // a is probably a four byte int here
a = "hello world"; // now a is a 12 byte char array

Il ya beaucoup qui se passe entre ces deux lignes. L'interprète supprime de la mémoire à un, alloue le nouveau tampon pour les caractères, puis assigne le var à point à qui une nouvelle mémoire. Dans un langage fortement typé, il n'y a pas d'interprète, qu'il gère pour vous et ainsi, le compilateur doit écrire les instructions qui prennent en compte le type.

int a = 10; // we now have four bytes on the stack.
a = "hello world"; // wtf? we cant push 12 bytes into a four byte variable! Throw an error!

Donc, les compilateurs des arrêts de code à partir de la compilation de sorte que le CPU dosn pas aveuglément écrire 12 octets en une à quatre octets de la mémoire tampon et de la cause de la misère.

La charge supplémentaire pour un compilateur écrit les instructions supplémentaires pour prendre soin de type serait de ralentir la langue de manière significative et de supprimer au profit des langages tels que le C++.

:)

-nelson

EDIT en réponse au commentaire

Je ne sais pas beaucoup au sujet de Python, donc je ne peux pas en dire beaucoup à ce sujet. Mais vaguement typedness ralentit l'exécution considérablement. Chaque instruction que l'interprète (VM) appels a pour evaulate, et, si nécessaire, de le contraindre à le var dans le type attendu. Si vous avez:

mov a, 10
mov b, "34"
div a, b

Ensuite, l'interprète doit s'assurer que a est une variable et un certain nombre, alors il faudrait contraindre b dans un certain nombre avant l'instruction de traitement. Ajouter des coûts indirects pour chaque instruction que la machine virtuelle s'exécute et vous avez un mess sur vos mains :)

Answer 5

Je suppose que les langages avec la frappe dynamique (duc) utilisent une évaluation paresseuse, qui est privilégiée par les programmeurs paresseux, et les programmeurs paresseux n'aiment pas écrire des compilateurs ;-)