Pendant très longtemps, le seul moyen de faire savoir à l'ordinateur ce que l'on souhaitait qu'il fasse était de lui donner les instructions dans le seul format qu'il soit en mesure de comprendre: le binaire et/ou l'hexadécimal.
Cela consistait à faire "avaler" à la machine une série de carte perforées sur lesquelles un trou représentait un 1 et un trou "bouché" (en fait, l'absence de trou) représentait un 0.
Les 1 et 0 étant les seules possibilités, nous avions bien à faire à du binaire. Mais comme les (absences de) trous étaient groupées par 8, il était effectivement possible de faire 28= 256 combinaisons, soit, en hexadécimal de 00 à FF.
Comme chaque processeur avait un jeu d'instructions qui lui était propre, cette succession de 1 et de 0 prenait, comme par miracle, une signification particulière pour lui, mais on ne pouvait jamais être certain que cette signification serait identique pour un autre processeur.
Comme il n'est jamais très facile d'arriver à décoder des valeurs hexadécimales (et encore moins du binaire), il n'a pas fallu longtemps pour que l'on mette au point un langage plus compréhensible utilisant des moyen mnémoniques pour permettre de traduire ces instructions.
L'assembleur était né.
De cette manière, on pouvait se contenter de se rappeler que ADDA correspondait à l'instruction "Ajoute (une valeur) à la valeur du registre A".
Actuellement, on a mis au point des langages proches du langage humain, et plus précisément de l'anglais, qui permettent d'écrire des applications compréhensibles par l'homme sans devoir trop faire appel au mnémoniques, mais qu'un autre programme se chargera de transformer en langage machine.
Tous ces langages font aussi partie de ce qu'il est convenu d'appeler les langages de troisième génération.
Certaines personnes estiment que les langages dits "Orienté Objet" représentent la quatrième génération des langages de programmation…
Personnellement, j'ai tendance à estimer que, bien que les langages "Orientés Objet" soient d'un grand intérêt et apportent des nouveautés majeures, ils font bel et bien encore partie des langages de programation de troisième génération du fait qu'il sont "proche du langage parlé"…
Il est cependant utile de se rendre compte que, comme on fait appel à un programme pour transformer les instructions de ces langages évolués en langage machine, il n'est pas rare de constater qu'une même application écrite directement en assembleur soit plus rapide que la même application écrite en langage de troisième génération.
Par contre, force est de constater qu'il est largement plus facile de concevoir une application en langage de troisième génération qu'en assembleur.
Bien qu'il soit possible de trier les langages de troisième génération de différentes manières, on distingue une différence fondamentale quand on les observe.
On trouve en effet des langages compilés et les langages interprétés.
Les langages compilés sont des langages qui sont transformés en langage machine avant l'exécution.
Les langages interprétés sont des langages qui dont le code source est utilisé par une couche intermédiaire lors de l'exécution pour fournir le langage machine.
Ces deux types de langages ont bien évidemment chacun leurs avantages et leurs inconvénients, la distinction sur ce critère est la seule manière objective, en dehors de toute préférence personnelle pour tel ou tel langage, qui soit réellement en mesure de diriger son choix vers un langage plutot qu'un autre lorsque l'on décide de développer une application.
Passons donc ces avantages et ces inconvénients en revue:
L'énorme avantage des langages interprétés est que, comme on ne dispose pas directement du langage machine, il est tout à fait possible de les utiliser directement (sans aucune étape préparatoire) sur différentes platteformes (Sous Mac comme sous PC (pour les types les plus connus), sous Windows comme sous Linux)
Dans le même registre, on peut signaler que les langages interprétés peuvent être testé directement après modification, sans avoir besoin de recréer le binaire d'exécution, ce qui facilite la mise au point de l'application.
Leur principal inconvénient est *justement* de ne pas être disponibles sous forme de binaires exécutables:
Le simple fait qu'il faille faire appel à une application externe pour pouvoir disposer du programme fait que ces langages sont généralement plus lents à l'exécution que ceux qui sont directement accessibles pour le processeur
En ce qui concerne les langages compilés, on prend les mêmes arguments, on les inverses, et on recommence…
Le principal avantage des langages compilés est que l'application créée est directement disponible sous forme de binaires exécutables, compréhensible par le processeur
Son exécution sera donc plus rapide que si elle avait été créée avec un langage interprété…
Si l'on souhaites créer une application qui soit utilisable par différentes platteformes, il faudra systématiquement la compiler sur la platteforme voulue…
Une application compilée pour tourner sous Windows ne fonctionnera pas sous Linux ni sous Mac.
Dans le même registre, dés que l'on effectue le moindre changement aussi minime soit il, on est obligé de recompiler la partie du code qui contient cette modification
Le choix à faire est donc soit de gagner en vitesse d'exécution, soit de pouvoir directement fournir quelque chose d'utilisable sur différentes platteformes…
Le léger gain de temps lors de la conception étant suffisemment minime pour ne pas devoir être pris en compte.
Copyright (©) 2005 (Philippe Dunski)
Ce cours est libre, vous pouvez le redistribuer et/ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation (version 2 ou bien toute autre version ultérieure choisie par vous).
Ce cours est distribué car potentiellement utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les garanties de commercialisation ou d'adaptation dans un but spécifique. Reportez-vous à la Licence Publique Générale GNU pour plus de détails.
Cependant, l'auteur apprécierait grandement que vous lui fassiez part de toute modification apportée à son contnu
Vous pouvez le contacter par mail à l'adresse koala01@free.fr
Vous pouvez trouver une adaptation française de la licence GNU/GPL à l'URL http://www.linux-france.org/article/these/gpl.html
