Mise à jour vs langages interprétés

Question

Je vais essayer d'obtenir une meilleure compréhension de la différence. J'ai trouvé beaucoup d'explications en ligne, mais ils tendent vers l'abstrait différences plutôt que les conséquences pratiques.

La plupart de mes expériences de programmes a été avec Disponible (dynamique, interprété), et Java (statique, compilé). Cependant, je comprends qu'il y a d'autres types de interprétées et les langages compilés. Hormis le fait que les fichiers exécutables peuvent être distribués à partir de programmes écrits dans les langages compilés, quels sont les avantages/inconvénients de chaque type? Souvent, j'entends des gens disant que les langages interprétés peut être utilisé de manière interactive, mais je crois que les langages compilés peuvent avoir interactive des implémentations ainsi, correct?

Answer 1

Un langage compilé, c'est celui où le programme, une fois compilé, est exprimé dans les instructions de la machine cible. Par exemple, une addition "+" de l'opération dans votre code source pourrait être traduit directement sur la page "AJOUTER" instructions en code machine.

Un langage interprété, c'est celui où les instructions ne sont pas directement exécuté par la machine cible, mais au lieu de lire et exécuté par un autre programme (qui normalement est écrit dans le langage de la machine natif). Par exemple, le même "+" opération serait reconnu par l'interprète au moment de l'exécution, qui serait alors appel à son propre "ajouter(a,b)" la fonction avec les arguments appropriés, qui serait ensuite exécuter le code machine "AJOUTER" de l'enseignement.

Vous pouvez faire tout ce que vous pouvez faire dans un langage interprété dans un langage compilé et vice-versa - ils sont à la fois Turing. Néanmoins toutes deux ont des avantages et des inconvénients pour la mise en œuvre et à utiliser.

Je vais complètement généraliser (les puristes me pardonne!) mais, en gros ici sont les avantages des langages compilés:

• Des performances plus rapides en utilisant directement le code natif de la machine cible
• Possibilité d'appliquer assez puissant optimisations lors de la compilation de scène

Et ici sont les avantages des langages interprétés:

• Plus facile à mettre en œuvre (l'écriture de bons compilateurs est très dur!!)
• Pas besoin d'exécuter une phase de compilation: peut exécuter directement du code "à la volée"
• Peut être plus commode pour les langages dynamiques

Notez que les techniques modernes telles que la compilation du bytecode ajoutent de la complexité - ce qui se passe ici est que le compilateur cible une "machine virtuelle" qui n'est pas le même que le matériel sous-jacent. Ces instructions de la machine virtuelle peut alors être intégré à un stade ultérieur pour obtenir le code natif (par exemple, comme le fait la Java JVM compilateur JIT).

Answer 2

Un langage en lui-même n'est ni compilé ni interprété, seulement une mise en œuvre spécifique d'une langue. Java est un parfait exemple. Il y a un code binaire à base de plate-forme (la JVM), un compilateur natif (gcj) et un interprète pour un sur-ensemble de Java (bsh). Donc, qu'est-ce que Java maintenant? Bytecode compilé, natif compilé ou interprété?

D'autres langues, qui sont compilées ainsi que interprétées, sont Scala, Haskell ou Ocaml. Chacun de ces langages est interactif interprète, ainsi que d'un compilateur pour le byte-code ou code machine natif.

Donc, généralement, la catégorisation des langues par "compilé" et "interprété" ne fait pas beaucoup de sens.

Answer 3

Commencer à penser en termes de: blast from the past

Once upon a time, il y a bien longtemps, vivait dans la terre de l'informatique les interprètes et les compilateurs. Toutes sortes de tracas s'ensuivit sur les mérites de l' l'un sur l'autre. De l'avis général, à l'époque était quelque chose le long des lignes de:

• Interprète: Rapide à développer (modifier et d'exécuter). Lent à exécuter parce que chaque énoncé doit être interprété en code de l'ordinateur à chaque fois qu'il a été exécuté (pensez à ce que cela signifiait pour une boucle exécuté des milliers de fois).
• Compilateur: Lente à se développer (éditer, compiler, de lien et de l'exécuter. La compilation/lien étapes pourrait prendre beaucoup de temps). Rapide pour l'exécuter. L'ensemble du programme était déjà en code machine natif.

Un ou deux ordres de grandeur de différence dans l'exécution performance existait entre un programme interprété et un programme compilé. Autre distinction points, au moment de l'exécution de la mutabilité du code, par exemple, ont également un certain intérêt, mais le principal la distinction est articulée autour de l'exécuter à temps les problèmes de performances.

Aujourd'hui, le paysage a évolué à un point tel que compilé/interprété distinction est joli beaucoup de pertinence. De nombreux les langages compilés appel à des services d'exécution qui ne sont pas complètement de la machine en fonction de code. Aussi, la plupart des langages interprétés sont compilé en byte-code avant l'exécution. Byte-code des interprètes peuvent être très efficaces et rival certains généré par le compilateur code à partir d'une vitesse d'exécution de point de vue.

La différence classique est que les compilateurs généré du code machine natif, les interprètes de lire le code source et généré machine de code à la volée en utilisant une sorte de système d'exécution. Aujourd'hui, il y a très peu d'interprètes classiques de la gauche - la quasi-totalité d'entre eux compilé en byte-code (ou une autre semi-compilé état) qui s'exécute sur un virtuel "machine".

Answer 4

L'extrême et les cas les plus simples:

• Un compilateur va produire un binaire exécutable dans la machine cible, natif du format de fichier exécutable. Ce fichier binaire contient toutes les ressources nécessaires, sauf pour le système de bibliothèques, il est prêt à fonctionner sans plus de préparation et de traitement et il fonctionne comme la foudre, car le code est le code natif pour le CPU sur la machine cible.

• Un interprète sera présent à l'utilisateur une invite dans une boucle où il peut entrer des instructions ou de code, et au moment de frapper RUN ou l'équivalent de l'interprète d'examiner, d'analyse, l'analyse et l'interprétation d'exécuter chaque ligne jusqu'à ce que le programme s'exécute à un point d'arrêt ou d'une erreur. Parce que chaque ligne est traitée sur son propre et l'interprète n'est pas "apprendre" quoi que ce soit d'avoir vu la ligne avant, les efforts de conversion lisible par l'homme, de la langue d'instructions machine est engagée à chaque fois pour chaque ligne, il est donc chien lent. Sur le côté positif, l'utilisateur peut contrôler et d'interagir avec son programme dans toutes sortes de façons: Changement de variable, changeant le code, l'exécution à l'état de traces ou de modes de débogage... que ce soit.

Avec ceux de la route, laissez-moi expliquer que la vie n'est pas si simple. Par exemple,

• De nombreux interprètes de pré-compiler le code qu'ils sont donnés, de sorte que l'étape de la traduction n'a pas à être répété encore et encore.
• Certains compilateurs de la compilation de ne pas spécifique au PROCESSEUR des instructions machine, mais en bytecode, une nature artificielle en code machine pour un ficticious de la machine. Cela rend le programme compilé un peu plus portable, mais nécessite un interpréteur de bytecode sur chaque système cible.
• Le bytecode interprètes (je suis à la recherche d'Java ici) récemment ont tendance à re-compiler le bytecode qu'ils obtiennent pour le PROCESSEUR de la section cible juste avant l'exécution (appelé JIT). Pour gagner du temps, c'est souvent uniquement fait pour le code qui s'exécute souvent (hotspots).
• Certains systèmes qui ressemblent et agissent comme des interprètes (Clojure, par exemple) compiler le code, immédiatement, mais de permettre un accès interactif à l'environnement du programme. C'est en gros la commodité des interprètes avec le débit binaire de la compilation.
• Certains compilateurs ne sont pas vraiment de la compilation, ils ont juste pré-digérer et de compresser le code. J'ai entendu tout à l'arrière c'est la façon dont Perl fonctionne. Alors parfois, le compilateur est juste faire un peu de travail et la plupart de c'est encore l'interprétation.

En fin de compte, ces jours-ci, l'interprétation vs compilation est un compromis, avec le temps passé (une fois) compilation souvent récompensé par de meilleures performances d'exécution, mais une interprétative de l'environnement en donnant plus de possibilités d'interaction. La compilation vs interprétation est surtout une question de la façon dont le travail de "comprendre" le programme est divisé entre les différents processus, et la ligne est un peu floue de ces jours que les langues et les produits d'essayer d'offrir le meilleur des deux mondes.

Answer 5

Tout d'abord, une clarification, Java n'est pas complètement statique-compilé et lié dans le cours C++. Il est compilé en bytecode, qui est ensuite interprété par une machine virtuelle java. La JVM peut aller et faire juste-à-temps de la compilation, de la machine natif de la langue, mais ne pas avoir à le faire.

Plus au point: je pense que l'interactivité est la principale différence pratique. Puisque tout est interprété, vous pouvez prendre un petit extrait de code, de les analyser et de les exécuter à l'encontre de l'état actuel de l'environnement. Donc, si vous avez déjà exécuté le code qui a initialisé une variable, vous aurez accès à cette variable, etc. Il se prête vraiment moyen pour des choses comme le style fonctionnel.

L'interprétation, toutefois, les coûts beaucoup, surtout quand vous avez un système avec un grand nombre de références et le contexte. Par définition, il est peu rentable car un code identique pourrait être interprétée et optimisé par deux fois (bien que la plupart des exécutions ont certains de la mise en cache et les optimisations pour que). Encore, vous payez un coût d'exécution et ont souvent besoin d'un environnement d'exécution. Vous êtes également moins susceptibles de voir le complexe interprocedural optimisations car à l'heure actuelle leur performance n'est pas assez interactif.

Par conséquent, les systèmes de grande taille qui ne va pas changer beaucoup, et pour certaines langues, il est plus logique de précompiler et prelink tout, faire toutes les optimisations que vous pouvez faire. Cela se termine avec un très maigre runtime qui est déjà optimisé pour la machine cible.

Comme pour la génération executbles, qui a peu à voir avec elle, à mon humble avis. Vous pouvez souvent créer un exécutable à partir d'un langage compilé. Mais vous pouvez aussi créer un fichier exécutable à partir d'un langage interprété, sauf que l'interprète et le moteur d'exécution est déjà emballé dans l'exécutable, et cachés de vous. Cela signifie que vous devez généralement payer les coûts d'exécution (même si je suis sûr que pour certaines langues, il existe des moyens pour traduire tout à un arbre exécutable).

Je suis en désaccord que toutes les langues puissent être interactive. Certains langages, comme le C, sont tellement liée à la machine et de l'ensemble de la structure des liens que je ne suis pas sûr que vous pouvez construire un sens à part entière, une version interactive