La différence entre un compilateur et un interprète

Selon leurs définitions, la différence entre un compilateur et un interprète semble assez claire :

• l’interprète est un programme qui exécute directement des instructions écrites dans un langage de programmation
• le compilateur est un programme qui transforme le code source dans un langage de bas(er)niveau

Si l’on creuse un peu plus, cependant, on constate un certain flou entre les deux.

En fait un interprète pourrait traduire le langage source sous une forme intermédiaire, pour accélérer l’exécution. C’est ce qui se passe généralement avec un langage qui s’appuie sur une machine virtuelle. Cela conduit naturellement à quelques questions :

Les langages qui utilisent une machine virtuelle sont-ils tous interprétés ?

Sont-ils tous réellement compilés ?

On pourrait dire les deux : un langage est d’abord compilé dans une forme/langue intermédiaire et ensuite cette chose intermédiaire est interprétée au moment de l’exécution. Ce qui mène aussi à une autre question, un compilateur et un interprète ne doivent pas être pensés comme un seul programme, mais plus comme un groupe de programmes, un système. Ce que vous, en tant qu’utilisateur, pensez être un compilateur peut en fait inclure plus d’un programme. Par exemple, il peut inclure un éditeur de liens : un programme qui combine différents fichiers objets en un seul fichier, afin qu’il puisse être utilisé plus facilement. On pourrait dire quelque chose de similaire d’un interprète.

Pouvez-vous me dire tout sur les compilateurs &interprètes ?

Alors, quelles sont toutes les pièces qui composent un compilateur ou un interprète ? Vous pourriez chercher une réponse précise et technique à ces questions dans le milieu universitaire. Ou vous pouvez trouver des discussions sur ces questions sur StackOverflow.

Ce qui compte vraiment pour nous en tant que développeurs, ou même pour nous en tant que créateurs d’un langage, c’est de savoir quelles sont les différences pour travailler avec eux. Les deux ont des avantages et des inconvénients, et en fait certains langages peuvent avoir à la fois un interprète et un compilateur, ou plus d’un. C’est ce que nous allons voir.

Le point principal demeure : un interprète exécute le code maintenant, un compilateur prépare le code source pour une exécution qui vient plus tard. Toutes les différences pratiques descendent de ces différents objectifs.

Comment distribuer un programme

En termes pratiques, une différence importante est qu’un compilateur génère un programme autonome, alors qu’un programme interprété a toujours besoin de l’interprète pour fonctionner.

Une fois que vous avez un programme compilé, vous pouvez l’exécuter sans avoir besoin d’installer autre chose. Cela simplifie la distribution. D’autre part l’exécutable fonctionne sur une plateforme spécifique : différents systèmes d’exploitation et différents processeurs ont besoin de différentes versions compilées. Par exemple, un programme C++ compilé peut fonctionner sur un ordinateur équipé d’un processeur x86, mais pas sur un ordinateur équipé d’une puce ARM. Ou encore, il pourrait fonctionner sur un système Linux, mais pas sur un système Windows.

Si vous allez interpréter un programme, vous pouvez distribuer la même copie aux utilisateurs sur différentes plateformes. Cependant, ils auront besoin d’un interprète qui fonctionne sur leur plateforme spécifique. Vous pouvez soit distribuer le code source original, soit une forme intermédiaire. Une façon intuitive de considérer un interprète est la suivante : il est comme la fonction eval en JavaScript. Elle fonctionne partout où JavaScript fonctionne, mais elle a besoin d’un interprète JavaScript pour cette plateforme pour fonctionner.

Support multiplateforme

C’est une différence technique qui conduit à des conséquences réelles importantes : il est plus facile de faire des programmes multiplateforme avec un langage de programmation interprété.

C’est parce que, pour la plupart, vous créez juste un programme pour la plateforme de l’interprète. Ce sera l’interpréteur lui-même qui le traduira dans la forme appropriée pour la plate-forme réelle (par exemple, Windows/Linux et x86/ARM). Bien entendu, il existe encore quelques différences dans chaque plate-forme dont vous devez être conscient. Un exemple courant est le caractère séparateur de répertoire.

Lorsque vous compilez un programme, au contraire, vous devez vous occuper vous-même de toutes les petites différences entre chaque plate-forme. Cela se produit en partie parce que les langages compilés ont tendance à être des langages de bas(er) niveau, comme le C++, donc ils vous donnent un accès plus faible au système et donc plus de responsabilité. Mais une autre raison est que toutes les bibliothèques que vous utilisez doivent elles-mêmes supporter différentes plateformes. Ainsi, si elles ne supportent pas Windows, vous ne pouvez pas supporter Windows.

La vitesse a de multiples visages

De nouveau, dans le cas de la vitesse, nous avons une sorte de paradoxe : un compilateur est à la fois plus rapide et plus lent qu’un interprète. Beaucoup de gens savent qu’un programme compilé est beaucoup plus rapide qu’un programme interprété, mais ce n’est pas tout. Un programme compilé est plus rapide à exécuter qu’un programme interprété, mais il faut plus de temps pour compiler et exécuter un programme que pour simplement l’interpréter.

Un compilateur produit effectivement des programmes plus rapides. Cela se produit fondamentalement parce qu’il doit analyser chaque déclaration une seule fois, alors qu’un interprète doit l’analyser à chaque fois. De plus, un compilateur peut optimiser le code exécutable qu’il produit. Cela tient à la fois au fait qu’il sait exactement où il s’exécutera et au fait que l’optimisation du code prend du temps. Temps qui rendrait l’interprétation trop lente.

Vitesse d’exécution versus vitesse de développement

Vous pourriez penser que c’est du pinaillage : si vous compilez un programme, il s’exécute plus rapidement, le temps qu’il faut pour compiler n’a pas d’importance. C’est généralement l’opinion de la vieille école. Et il ne fait aucun doute que le programme résultant est exécuté plus de fois qu’il n’est compilé. Alors qui se soucie de savoir si le développement prend plus de temps ? Eh bien, il est certain qu’il faut une attitude de « souffrance » au développement qui est quelque peu admirable. Mais que se passe-t-il si les gains en temps d’exécution ne sont pas pertinents, alors que les pertes de productivité du développement sont importantes ?

C’est une chose si vous créez un système d’exploitation et une autre si vous faites une application selfie. Même vos utilisateurs pourraient préférer une perte de vitesse d’exécution même pas perceptible en échange d’obtenir des fonctionnalités plus rapidement. Il n’y a pas de réponse unique : dans certains contextes, la productivité compte plus que la vitesse, dans d’autres, c’est l’inverse.

Les mystères du débogage

Il y a un autre aspect particulier qui finit par être plus incertain que ce qu’on pourrait croire : le débogage. Sur le papier, le débogage est plus facile en utilisant un interpréteur qu’en utilisant un compilateur. C’est vrai pour plusieurs raisons :

• avec l’interpréteur il y a une seule version de l’exécutable ; vous n’avez pas besoin d’une version de débogage pour le développement et d’une version de sortie pour l’utilisateur final
• il y a moins de bugs spécifiques à la plateforme en utilisant un interpréteur
• puisque l’interpréteur transforme le code à la volée, les informations du code source sont toujours disponibles
• puisque l’interpréteur exécute une instruction à la fois, il est plus facile de trouver une erreur

La différence que les outils de développement font

Bien que tout cela soit vrai dans la pratique, cela pourrait être moins pertinent qu’il n’y paraît. En fait, si vous réfléchissez à votre expérience, vous trouverez probablement que le débogage de JavaScript est plus difficile que le débogage de C++. Comment cela se fait-il ? Cela tient en partie à la conception des langages eux-mêmes. JavaScript utilise le typage dynamique, tandis que C++ utilise le typage statique. Ce dernier facilite la détection précoce des erreurs. Mais au final, tout dépend des outils de développement. Compiler C++ à la main est difficile, c’est pourquoi la plupart des gens utilisent des IDE pour développer avec ce langage. D’autre part, vous pouvez facilement utiliser un éditeur de texte et des outils de ligne de commande pour développer en JavaScript.

Cela signifie que, en termes pratiques, si vous développez avec C++, vous pouvez également déboguer C++. Au contraire, vous pouvez développer avec JavaScript sans savoir comment faire un débogage correct en JavaScript.

Ayant dit cela, si nous les mettons dans le même contexte, chacun avec un grand IDE et des outils de soutien, la situation revient à la normale. En effet, de nombreux environnements interprétés sont utilisés par des personnes qui veulent apprendre à utiliser un nouveau langage. Il est plus facile de tester, et de trouver ce qui est bon ou mauvais, en regardant ce qui se passe ligne par ligne et en temps réel.

Sommaire

Nous avons vu les principales différences qui comptent entre un compilateur et un interprète. Plus important encore, nous avons vu que les conséquences des différentes philosophies sont plus importantes que les conséquences techniques. En bref, il y a des cultures qui viennent avec certains choix techniques qui finissent par être pertinents par eux-mêmes. Si vous voulez de la vitesse et de la facilité de développement, vous allez choisir toutes les technologies pour la vitesse et pas seulement une. Et vos utilisateurs vont suivre votre exemple.

C’est un aspect crucial auquel il faut réfléchir, surtout si vous voulez créer votre propre langage de programmation. Rasmus Lerdorf a créé PHP pour être facile à utiliser. Et en effet, il était incroyablement plus facile à utiliser par rapport aux alternatives, du moins à l’époque de sa création. Mais il a commencé plus comme une bibliothèque que comme un langage. Et s’il s’est beaucoup amélioré, il souffre toujours de ses débuts. Vous pouvez toujours créer du bon code PHP, mais ses utilisateurs sont moins nombreux que d’habitude. Parce que si vous avez juste besoin de quelque chose qui fonctionne, la sécurité, la maintenance, etc, tout le reste vient plus tard.

Si vous voulez savoir comment vous pouvez pratiquement construire un interpréteur ou un compilateur pour votre langage, vous pouvez jeter un coup d’œil aux ressources pour créer un langage de programmation. Si vous voulez apprendre cela, et tout ce dont vous avez besoin pour créer votre propre langage, il vous suffit de choisir un excellent livre, aimé par les enfants et les adultes, sur la façon de créer des langages pragmatiques et légers.

5 choses à bien faire lors de la construction d’un langage

Recevoir la liste de contrôle par courriel et obtenir plus de conseils sur la construction de langages

.