Je comprends les différences entre les langues interprétées et compilées, mais si quelqu'un pouvait fournir des exemples de situations où l'on est susceptible d'utiliser des langues interprétées sur des langues compilées, ainsi que des situations où l'on est susceptible d'utiliser des langues compilées sur des langues interprétées, ce serait être vraiment utile.
Réponses:
Il n'y a (à ma connaissance) rien de tel qu'une «langue» interprétée ou une «langue» compilée.
Les langages spécifient la syntaxe et la signification des mots clés du code, des constructions de flux et diverses autres choses, mais je ne connais aucun langage qui spécifie s'il doit être compilé ou interprété dans la spécification de langage.
Maintenant, si votre question est de savoir quand vous utilisez un compilateur de langue par rapport à un interprète de langue, cela se résume vraiment aux avantages / inconvénients du compilateur par rapport à l'interpréteur et à l'objectif du projet.
Par exemple, vous pouvez utiliser le compilateur JRuby pour une intégration plus facile avec les bibliothèques java au lieu de l'interpréteur ruby MRI. Il y a probablement aussi des raisons d'utiliser l'interpréteur de rubis IRM sur JRuby, je ne connais pas bien la langue et je ne peux pas en parler.
Avantages des interprètes:
Avantages des compilateurs:
Cependant, je parierais que dans 90% des cas, cela ressemble à ceci: je veux écrire ce logiciel en blub parce que je le connais bien et qu'il devrait faire du bon travail. J'utiliserai l'interpréteur blub (ou le compilateur) car c'est la méthode canonique généralement acceptée pour écrire des logiciels dans blub.
Donc TL; DR est fondamentalement, une comparaison au cas par cas des interprètes vs les compilateurs pour votre cas d'utilisation particulier.
Aussi, FFI: Foreign Function Interface, en d'autres termes interface pour interopérer avec d'autres langues. Plus de lecture sur wikipedia
Un point important ici est que de nombreuses implémentations de langage font en fait une sorte d'hybride des deux. De nombreuses langues couramment utilisées aujourd'hui fonctionnent en compilant un programme dans un format intermédiaire tel que le bytecode, puis en l'exécutant dans un interpréteur. C'est ainsi que Java, C #, Python, Ruby et Lua sont généralement implémentés. En fait, c'est sans doute ainsi que la plupart des langues utilisées aujourd'hui sont implémentées. Ainsi, le fait est que le langage interprète et compile aujourd'hui son code. Certains de ces langages ont un compilateur JIT supplémentaire pour convertir le bytecode en code natif pour exécution.
À mon avis, nous devrions cesser de parler des langages interprétés et compilés car ils ne sont plus des catégories utiles pour distinguer les complexités des implémentations de langage d'aujourd'hui.
Lorsque vous posez des questions sur les mérites des langues interprétées et compilées, vous voulez probablement dire autre chose. Vous vous demandez peut-être le mérite du typage statique / dynamique, les avantages de la distribution d'exécutables natifs, les avantages relatifs de la compilation JIT et AOT. Ce sont tous des problèmes qui sont confondus avec l'interprétation / la compilation, mais ce sont des problèmes différents.
Tout d'abord, un langage de programmation peut être à la fois ininterprété et compilé. L'interprétation et la compilation ne sont que des méthodes pour générer du code exécutable à partir du code source. Avec un interprète, le code source est lu et interprété par un interprète qui exécute ensuite le code tel qu'il l'interprète. Un compilateur, d'autre part, lit le code source et génère un fichier binaire exécutable à partir du code source - afin que le programme puisse être exécuté en tant que processus séparé indépendamment.
Maintenant, avant que quiconque ne se demande ... Oui, C / C ++ / C # / Java peut être interprété, et oui, les scripts JavaScript et Bash peuvent être compilés. Qu'il y ait des interprètes ou des compilateurs qui travaillent pour ces langues est une autre question.
Maintenant, pour répondre à la question, nous allons utiliser le "langage interprété" plutôt que le "langage compilé". La question elle-même est quelque peu confuse, mais je suppose que cela signifie quand préférer l'interprétation à la compilation. L'un des inconvénients de la compilation est qu'elle génère des frais généraux en raison du processus de compilation - le code source doit être compilé en code machine exécutable, il n'est donc pas adapté aux tâches qui nécessitent un délai minimal lors de l'appel du code source pour exécuter un programme. D'un autre côté, le code source compilé est presque toujours plus rapide que le code source interprété équivalent en raison de la surcharge causée par l'interprétation du code. Les interprètes d'autre part peuvent invoquer et exécuter le code source avec très peu de frais d'appel, mais au détriment des performances d'exécution.
En fin de compte, il est presque impossible de mentionner des cas d'utilisation définis quand préférer l'un après l'autre, mais par exemple un cas (à mon sens très irréaliste) serait lorsque le code source du programme change dynamiquement entre les invocations de programme et la surcharge de compilation est trop élevé pour qu'il soit un choix viable. Dans ce cas, l'interprétation du code source au lieu de la compilation serait probablement souhaitable.
Cependant, il y a quelque chose qui peut être considéré comme un exemple réel: le code source hidnig lors du déploiement. Avec nativementcode compilé le développeur déploie le code macine exécutable du programme et des données. Avec du code interprété, le code source lui-même doit être déployé, qui peut ensuite être inspecté et rétroconçu avec beaucoup moins d'efforts que ce qu'il en est pour la rétro-ingénierie du code machine natif. Une exception à cela est les langages comme C # et Java qui se compilent en langage / bytecode immédiat (MSIL pour C # et Java bytecode pour Java) qui sont ensuite déployés et compilés "juste à temps" au moment de l'exécution, un peu comme un interprète. Cependant, il existe des soi-disant décompilateurs pour MSIL et Java Bytecode qui peuvent reconstruire le code source d'origine avec une précision relativement bonne et, en tant que tels, la rétro-ingénierie de tels produits est beaucoup plus triviale que les produits de rétro-ingénierie déployés dans du code machine natif.
Je peux penser aux scénarios suivants lorsque vous utiliseriez un langage interprété :
Je peux penser aux scénarios suivants lorsque vous souhaitez compiler votre code:
En fin de compte, le grand compromis est entre la productivité (combien de lignes de code devez-vous écrire) et les performances (à quelle vitesse votre programme s'exécutera-t-il).
Parce que les langages interprétés lorsqu'ils sont transformés en informations CPU ont plus d'informations, ils peuvent s'appuyer sur la réflexion et le typage dynamique qui augmentent considérablement la productivité . Un autre avantage des langages interprétés est qu'ils sont indépendants de la plateforme tant qu'il y a un interprète pour la plateforme.
Parce que le CPU ne doit pas transformer le code de langue en code machine et exécuter le code en même temps, comme dans le cas interprété, les langues compilées produisent des programmes plus rapides. De plus, un système construit dans un langage compilé est plus sécurisé car il peut détecter des problèmes au moment de la compilation, ce qui signifie essentiellement que vous voyez une erreur lorsque vous la tapez (avec des IDE modernes) au lieu de la voir uniquement lorsque vous exécutez réellement le programme (bien sûr , cela ne corrige pas les erreurs logiques).
Sachant cela, les langages interprétés conviennent pour:
Et les langues compilées conviennent lorsque:
Outre les raisons évoquées par les autres, il existe un cas d'utilisation particulièrement important pour choisir une interprétation ad hoc plutôt que toute forme de compilation ou toute approche hybride.
Dans le cas où un langage de programmation est utilisé comme protocole de communication , et lorsque la latence de réponse est importante, il est plus logique d'éviter de perdre du temps sur la compilation et tout prétraitement possible.
Cela s'applique aux langues des agents, par exemple, ou à la façon dont, par exemple, Tcl / Tk est normalement utilisé.
Une autre raison possible de s'en tenir à l'interprétation est lorsqu'un interprète de langue est utilisé pour l'amorçage lui-même ou un langage de niveau supérieur plus élaboré, et sa simplicité est plus importante que les performances du processus d'amorçage.
Pour presque tous les autres cas d'utilisation possibles, la compilation (ou une approche hybride) convient mieux.