Les langages dynamiques sont-ils toujours interprétés?

18

En regardant la plupart (sinon tous) les langages dynamiques (par exemple Python, PHP, Perl et Ruby), ils sont tous interprétés. Corrige moi si je me trompe. Existe-t-il un exemple de langage dynamique qui passe par la phase de compilation? Le langage dynamique est-il identique au langage interprété?

— Joshua Partogi
source

4

Définir un langage dynamique, est-il typé dynamiquement?

— BenjaminB

3

Objective-C présente de nombreuses propriétés "dynamiques".

— Edward Strange

4

@Job, on pourrait le faire avec Lisp pendant des décennies. Et il est à la fois compilé et typé dynamiquement. Ainsi, il n'y avait jamais eu de frontière exacte entre compilation et interprétation.

— SK-logic

2

@Darien Vous pouvez également le compiler au moment de l'exécution et exécuter le code par la suite. À proprement parler, ce n'est pas de l'interprétation.

— xmm0

3

@Darien Rien n'empêche un compilateur de stocker une information de table de symboles dans le binaire compilé et de générer du code pour y accéder au moment de l'exécution. Il est vrai que certaines langues se prêtent plus à l'interprétation qu'à la compilation, mais le fait est qu'il est possible d'avoir un compilateur pour cette langue. Une autre chose importante à noter est que certaines personnes supposent qu'un compilateur doit générer une sorte de code machine. En pratique, il existe des compilateurs qui effectuent simplement une transformation de niveau source dans deux langues (ou même la même langue, comme certains minificateurs Javascript).

— xmm0

33

En regardant la plupart (sinon tous) les langages dynamiques [c'est-à-dire Python, PHP, Perl et Ruby], ils sont tous interprétés.

Pas vrai. Vous pouvez compiler la source Python. Voilà une preuve existentielle.

Il existe des interprètes pour les langues à typage statique et des compilateurs pour les langues à typage dynamique. Les deux concepts sont orthogonaux.

Note latérale: En général, un langage n'est que cela: un langage, avec un ensemble de constructions syntaxiques pour exprimer la sémantique. Si vous écrivez Python sur un tableau blanc, cela s'appelle toujours Python! C'est l' implémentation qui peut être un interprète ou un compilateur. Être typé statiquement ou dynamiquement (d'une sorte d'hybride des deux) est une propriété du langage, tandis que l'exécution d'un programme par interprétation ou compilation est une propriété de l'implémentation.

— xmm0
source

19

À quelle précision les retraits doivent-ils correspondre sur un tableau blanc pour que le Python soit syntaxiquement valide? ;)

— edA-qa mort-ora-y

1

Vous ne pouvez pas compiler Python. PYC accélère uniquement la charge d'un module. Et py2exe intègre simplement l'interpréteur dans l'exe avec le fichier source.

— BenjaminB

8

@ Ubiquité: les .pycfichiers sont en bytecode. Le code source de Python a été analysé, optimisé et compilé pour les créer. Les instructions de bytecode sont relativement de haut niveau et l'implémentation la plus populaire est un interpréteur simple (pour le contraste, regardez PyPy qui compile JIT bytecode en code machine très intelligent au moment de l'exécution) mais Python n'est pas moins compilé que Java ou C #. Python n'est "non compilé" que si "la compilation" était limitée à la compilation native à l'avance , mais personne n'a rien dit à ce sujet et généralement il peut faire référence à toute transformation de lanugage en langage.

4

@ Ubiquité: Oui, c'est exact, mais cela n'a rien à voir avec votre affirmation selon laquelle "Vous ne pouvez pas compiler Python" ou s'il est possible de compiler Python. D'abord et avant tout, vous mixez Pythonet CPython, alors que le second est une implémentation du premier, il en est de même PyPy.

— phant0m

2

@ClemC TOUTES les propriétés d'une langue sont intégrées dans un compilateur ou un interpréteur, sinon l'interpréteur ou le compilateur est quelque chose pour une autre langue.

— Pieter B

15

Common Lisp est typé dynamiquement (et fortement) et généralement compilé .

Étant donné que cette dynamique est obtenue au moment de l'exécution, il existe certaines directives que vous pouvez utiliser dans le code source pour assurer au compilateur qu'un symbole ne contiendra qu'un certain type de valeur, afin que le compilateur puisse optimiser le code généré et augmenter les performances.

— Federico klez Culloca
source

12

C # 4.0 prend en charge les types dynamiques (liaison tardive) et il est compilé.

— Matt H
source

4

node.js est basé sur le moteur javascript V8 de Google. V8 fait la compilation à l'exécution. Le V8 est aveuglément rapide compte tenu de ce fait. Consultez simplement http://shootout.alioth.debian.org et comparez le V8 à l'un des langages interprétés ci-dessus.

— LLeo
source

3

Non - il est certainement possible de compiler des langages dynamiques.

Il existe même des langages dynamiques qui sont toujours compilés par conception (par exemple Clojure).

Cependant, la question touche à un point connexe important: bien que les langages dynamiques puissent être compilés, il arrive souvent que les langages dynamiques ne puissent pas être compilés en un code aussi efficace qu'un langage typé statiquement . Cela est dû au fait que certaines fonctionnalités inhérentes aux langages dynamiques nécessitent des vérifications d'exécution qui ne seraient pas nécessaires dans une jauge de langue compilée statiquement.

Un exemple de ceci: les langages qui autorisent l'application de correctifs au moment de l'exécution d'objets (par exemple Ruby) nécessitent souvent que l'objet soit inspecté (avec une recherche de table de hachage ou similaire) chaque fois que vous appelez une méthode sur l'objet. Même si cela est compilé, le compilateur devra générer du code pour effectuer la recherche de méthode lors de l'exécution. Dans une certaine mesure, cette recherche de méthode n'est pas différente de ce que devrait faire un interprète.

Cela ajoute une surcharge importante par rapport à un appel de méthode dans un langage comme Java, où la bonne méthode peut être déterminée statiquement par le compilateur à partir de la définition de classe et réduite à un simple appel de fonction en code natif.

Je crois que c'est cet effet plus que toute autre chose qui fait que les langages dynamiques ont des performances plus lentes en moyenne que leurs homologues compilés statiquement. Comme vous pouvez le voir sur les benchmarks défectueux , ce sont les langages typés statiquement (C, Java, Fortran, etc.) qui ont tendance à être les plus rapides avec les langages dynamiques (Perl, Python, Ruby, PHP, etc.) en bas du classement.

— mikera
source

2

Il était une fois BASIC a été interprété. Et certaines variantes de BASIC avaient un typage dynamique. Et vous pouvez également obtenir des compilateurs pour eux.

(C'était à l'époque des lecteurs de disquettes 100K, lorsque les dinosaures parcouraient encore la terre et mangeaient des développeurs s / w sans méfiance pour le petit-déjeuner.)

— vite_maintenant
source

... mais seulement quand ils ont utilisé GOTO. (Ce qui était, bien sûr, assez courant s'ils se développaient en BASIC. AHA! Cela explique cela!)

— Mason Wheeler

BASIC à l'époque de sa conception était un langage compilé.

— AProgrammer

2

Différentes implémentations Smalltalk gèrent cela différemment, mais plusieurs d'entre elles se compilent en bytecodes qui s'exécutent sur une machine virtuelle haute performance.

— Randy Coulman
source

2

En fait, la plupart des langages dits "interprétés" passent par / permettent une compilation juste à temps pour la faire fonctionner plus rapidement. Et certains d'entre eux doivent être compilés en code octet avant de pouvoir les exécuter.

En fait, dynamique et interprété sont deux idées totalement différentes, bien qu'il y ait une corrélation. La raison étant que ceux qui sentent que la frappe dynamique rend leur travail plus facile et plus rapide, ils ne s'inquiéteraient pas du fait que le code soit exécuté un peu plus lentement mais portable.

— user658991
source

1

Chrome, IE9 et Firefox 3.1+ compilent tous JavaScript en binaires natifs, et JavaScript est typé dynamiquement.

Je pense que la raison pour laquelle les langages dynamiques ont tendance à être historiquement interprétés est que le typage et l'interprétation dynamiques (ou plus précisément, le manque de compilation) ont tous deux tendance à être des fonctionnalités utiles aux langages de script et aux tâches de script en général.

La performance n'est pas non plus (pas) une préoccupation majeure pour les types de programmes qui ont été écrits dans ces langues, donc encore une fois, le surcoût de la frappe et de l'interprétation dynamiques n'était pas un problème aussi important que dans les langues cette valeur de performance.

— Rei Miyasaka
source

1

Python est généralement compilé. Certes, compilé en code octet qui est ensuite interprété.

Perl fonctionne de façon similaire.

Common Lisp se compilera généralement en un code natif ou octet. Cela diffère entre les implémentations (et, dans une certaine mesure, au sein d'une implémentation, selon divers paramètres d'optimisation).

— Vatine
source

-5

Oui. Toutes les langues dynamiques sont des langues interprétées (mais une langue interprétée peut être non dynamique).

La raison est simple: s'il est dynamique, il a besoin d'un interprète pour effectuer le dynamisme au niveau de la compilation binaire.

ex. : lorsque nous mettons une donnée dans une variable PHP, puis plus tard une autre d'un type différent, notre programme ne peut pas être compilé en code binaire car chaque type a son propre format de représentation binaire; l'interprète gère les décalages au niveau binaire de manière dynamique

— Esprit clair
source

2

Faux. Les langages dynamiques peuvent être compilés (et parfois très efficacement, par exemple en utilisant JIT et des techniques de compilation adaptative)

— Basile Starynkevitch

"En gros, la compilation JIT combine la vitesse du code compilé avec la flexibilité d'interprétation, avec les frais généraux d'un interprète ..." en.wikipedia.org/wiki/Just-in-time_compilation votre programme ne compile pas: il est compilé par l'interprète pour vous

— ClearMind

Lire les articles liés à SELF

— Basile Starynkevitch

Sûr. Votre lien mentionne: "Une caractéristique de Self est qu'il est basé sur le même type de système de machine virtuelle que les systèmes Smalltalk antérieurs. C'est-à-dire que les programmes ne sont pas des entités autonomes comme ils le sont dans des langages tels que C, mais ont besoin de leur environnement de mémoire entier afin de fonctionner. " pas autonome = pas binaire compilé la machine virtuelle est nécessaire pour effectuer la compilation binaire

— ClearMind

1

Votre définition de compilateur est trop restrictive. Tous les compilateurs ne produisent pas un fichier exécutable binaire. Pour un contre-exemple récent, étudiez la mise en œuvre de SBCL . Lire le dernier Dragon Book et Lisp In Small Pieces

— Basile Starynkevitch