Les ordinateurs utilisent des commandes de très bas niveau connues sous le nom de «code machine». Ce code est constitué de groupes de bits formant des motifs binaires (des 0 et des 1). Ces instructions permettent de faire des boucles (répéter une séquence de commandes), des conditions (ne faire une chose que si un certain critère est rencontré ou non) et des fonctions mathématiques (telles que l'addition, soustraction, multiplication et division, ainsi que des fonctions spéciales «booléennes»). Cela représente environ 95% de ce qu'un ordinateur (CPU) peut faire -- il fait ces choses très rapidement, on peut décrire à peu près tous les problèmes en utilisant uniquement ces instructions simples.
Les instructions binaires sont uniques à chaque processeur et sont difficiles à utiliser pour les être humains; alors on fabrique des «langages» d'ordinateur plus humains que les programmeurs utilisent. Parmi ces langages d'ordinateur humains, vous reconnaîtrez probablement ces noms : C, C++, Pascal, Java et plusieurs autres encore.
Lisez les articles «Le fonctionnement des langages de programmation ou «Langages et Systèmes d'exploitation» pour de plus amples informations.
Les langages compilés sont convertis dans le langage natif de l'ordinateur. Ce processus est semblable à la traduction d'un document d'une langue vers une autre (de l'anglais à l'espagnol, par exemple); une fois traduit, vous ne pouvez pas vraiment revenir à l'original (facilement). Une fois «compilé» le code résultant est plus compact et facile d'utilisation pour l'ordinateur (rapide, natif, simple).
Le code compilé est spécifique à chaque processeur d'ordinateur (puisque chaque génération de processeurs parle un langage légèrement différent). Ainsi le code compilé ne peut pas être transporté d'un processeur à un autre (par exemple, du PowerPC vers le Pentium). À un moindre degré, le code est également spécifique à un système d'exploitation (Mac ou Windows) ou le code a besoin de certaines librairies (code de support).
Note: Le «code source» (le programme AVANT la traduction), peut être partiellement utilisé par plusieurs plates-formes -- cependant ce code doit être compilé pour chaque plate-forme, et cette opération nécessite souvent du travail (temps et argent) pour que cela soit fait avec succès. De plus, uniquement des parties de code peuvent être utilisées sur plusieurs plates-formes (entre 20% et 80%, tout dépendant de la conception et du problème).
Le C, C++, Pascal, FORTRAN et plusieurs autres langages sont des langages «compilés». Les programmes écrits dans ces langages sont habituellement destinés à une seule plate-forme et sont compilés pour un processeur en particulier.
Applications FAT Apple et NeXT ont créé une technologie appelé des «FAT binaires» permettant à plusieurs saveurs (cibles) de codes compilés d'être livrés ensembles. Seul le bon code (celui du processeur que vous utilisez) est exécuté. Cela signifie qu'une même application peut tourner sur plus d'un processeur (si ceux-ci sont sur le même OS et possèdent les mêmes librairies).
Ces applications s'appellent «FAT» parce qu'elles possèdent du code pour plus d'un processeur (ce qui les rend un peu plus grosses, d'où le terme anglais Fat, gras, gros). Puisque la majorité de la taille d'un programme réside dans les «ressources» (textes, images, sons, et autres données), le programme ne devient pas aussi gros que les gens le croient -- probablement de 30% à 40% plus gros (et non pas le double).
Les langages interprétés ne sont pas «précompilés» en un langage natif d'ordinateur, ils sont «interprétés» sur le tas. L'ordinateur examine chaque instruction, puis interprète ces instructions une par une (en exécutant une routine «native» pour chaque instruction). C'est un peu comme si vous aviez un interprète entre vous et une autre personne parlant une autre langue). Cet entre-deux ralenti le processus de communication, causé par «l'étape» supplémentaire. Ainsi les programmes conçus avec des langages interprétés sont plus lents que ceux conçus avec des langages compilés.
Les langages interprétés offrent des avantages aux programmeurs parce qu'ils leur permettent de modifier le code immédiatement sans avoir à passer par le processus de «compilation». Alors pour le développement (écriture du code), c'est très bien. Les programmeurs n'ont qu'à ajouter des instructions et les tester immédiatement (tout en évitant les longs délais de recompilation -- qui peuvent prendre de quelques minutes à quelques heures pour chaque compilation).
Le code interprété n'a pas à être spécifique à une plate-forme en particulier (processeur d'ordinateur, OS, etc.). Il peut être «interprété» sur le tas -- si vous avez l'interpréteur, vous pouvez parler son «langage». Ainsi les langages interprétés sont de loin beaucoup plus multi-plateformes (ils tournent sur plusieurs ordinateurs différents).
10 à 20 ans auparavant, alors que les ordinateurs étaient des centaines ou des milliers de fois plus lents que ceux d'aujourd'hui, on ne pouvait se permettre de sacrifier la performance pour la commodité -- mais la réalité d'aujourd'hui a changé cela. N'oubliez pas que la performance des ordinateurs double chaque 18 mois et que les coûts de programmation ne cessent d'augmenter. La programmation interprétée va tranquillement prendre le dessus dans le développement.
PCODE - Le code «interprété» par l'ordinateur n'est pas toujours le «texte» affiché aux programmeurs. Bien souvent un langage va compiler/contracter le texte en une forme spéciale abrégée (pour usage interne seulement). En terme technique, ce code s'appelle «P-Code» (pCode) ou Pseudo-Code. Ce n'est pas vraiment du code machine (car il ne peut être exécuté nativement, il doit être interprété), et ce n'est pas quelque chose que les utilisateurs peuvent lire.
Cette technique du «pCode» a été inventée à la UCSD vers la fin des années 70. Sun a retapé cette idée avec Java. Java est un compilateur de «pCode», c'est donc un type d'interpréteur.
Langages de scripting - certains langages (habituellement ceux interprétés) ne sont pas très puissants (complexes), pas assez pour être appelés des «langages de programmation». Ces langages sont plutôt utilisés pour faire du scripting (une forme simple de programmation). Si les utilisateurs désirent écrire des applications puissantes, ils n'utiliseront pas les langages de scripting (ils utiliseront des langages de programmation) -- mais quelquefois les programmeurs (ou les utilisateurs chevronnés) ne voudront qu'ajouter une fonctionnalité à une application. Pour ajouter une fonctionnalité à un programme, ils peuvent utiliser un langage de «scripting» (si l'application en supporte un).
Plusieurs programmes possèdent leur propre langage de scripting, HyperCard et QuickTime (QTi) ont HyperScript, Microsoft Office a VisualBasic pour les applications, ou Macromedia Director avec Lingo, Apple a un langage de scripting extensible pour le Finder et la plupart des applications, appelé AppleScript. DOS et Unix (qui sont de réels programmes / applications agissant comme interface de l'OS pour les utilisateurs) ont, eux aussi, des langages de scripting. Il existe des centaines de langages de scripting, tels que Perl, Awk, la plupart des bases de données ont leur propre langage de scripting (et quelques unes ont même un «vrai» langage de programmation), et ainsi de suite, il y a également un langage de scripting pour le HTML appelé JavaScript (qui n'a rien à voir avec Java). Rappelez-vous, les langages de scripting ne sont que des «langages de programmation» simples, destinés à des applications (ou pour envoyer des commandes à l'OS via un Shell), et ne sont pas conçus pour faire de la «vrai» programmation.
JavaScript et JScript JavaScript n'a rien à voir avec Java -- son nom original était LiveScript. Mais Netscape (dans un geste stupide et embarrassant motivé par le marketing) a voulu prendre une certaine position dans l'engouement provoqué par le «Java» de Sun -- ainsi ils ont rebaptisé LiveScript en JavaScript, provoquant la confusion chez les utilisateurs. C'est comme si Boeing voulait rebaptiser le 747 en «navette spatiale», même s'il s'agit de choses complètement différentes.
Java est un langage d'ordinateur (syntaxe) et un ensemble de librairies (Frameworks). JavaScript est un langage de scripting (que vous pouvez incorporer aux pages HTML) qui ne ressemble pas, même vaguement, au Java. Le Java fonctionne. JavaScript a tendance à mal fonctionner et faire planter le navigateur Netscape -- mais puisque c'est la seule manière de faire certaines choses, JavaScript est tout de même utilisé.
Microsoft n'a pas voulu faire progresser les choses (et ils détestent les standards), alors ils ont implémenté un sous-ensemble de JavaScript appelé JScript. Microsoft s'est assuré qu'il soit subtilement différent du JavaScript en plusieurs endroits différents (pour torturer les programmeurs). Cela a forcé les sites Web à choisir entre Netscape et Explorer et les a contraints à ne pouvoir rien écrire en JavaScript (facilement) pour que tout fonctionne dans les deux navigateurs. Tout cela va disparaître d'ici quelques années, cette souffrance est principalement attribuable aux vilains du marketing de Microsoft qui tentent intentionnellement de ralentir le progrès (lorsqu'ils n'ont pas le contrôle), même si cela blessent des milliers de programmeurs et des millions d'utilisateurs.
Alors qu'est-ce que Java ?
Java est un langage interprété (qui utilise le pCode). Il a une syntaxe (langage) qui tourne sur plusieurs plates-formes différentes -- ce qui signifie que les programmeurs peuvent écrire pour ce langage, et faire tourner leurs programmes sur n'importe quelle plate-forme. Certains autres langages permettent cela également, mais vous devez recompiler pour chaque plate-forme cible -- Java vous permet de compiler une seule fois (en pCode), puis l'application résultante peut tourner n'importe où. Java diffère des autres langages car il possède un riche ensemble de Frameworks (librairies d'objets pour les programmeurs, leur permettant d'être plus productifs). Par-dessus tout, le langage est conçu pour éviter ce qu'on appelle les «pointeurs» (c'est là que 60% de TOUS les programmeurs font des erreurs. Ces erreurs coûtent des milliers de dollars en recherche et réparation). De plus, Java permet plus facilement aux programmeurs de livrer leurs propres Frameworks/librairies afin de les réutiliser dans d'autres projets (par une technique appelée JavaBeans).
Le développement en Java est moins dispendieux (en temps et argent) et il coûte moins chère en frais de maintenance et de déboguage (parce qu'il n'y a pas de pointeurs «fous» ou des bogues subtils semblables), vous avez plus de chance de réutiliser du code écrit en Java (et ainsi ne pas avoir à créer ce qui a déjà été fait), et lorsque vous écrivez en Java, vous pouvez faire tourner l'application résultante n'importe où (sur n'importe quelle plate-forme). Il coûte moins et fait plus. C'est pas mal, pas vrai ? Ça l'est.
Et bien malheureusement, en ingénierie (et dans la vie), il y a toujours des compromis.
Performance -- Pour l'instant un des compromis est la vitesse. Les applications Java ne sont pas très rapides (la période de rodage d'un langage est longue). Les implantations actuelles sont interprétées -- elles existent dans un langage intermédiaire que les ordinateurs ne comprennent pas «nativement». Ainsi le JVM (Java Virtual Machine, machine Java virtuelle) doit interpréter chacune des commandes pour l'ordinateur. Parce que ce processus prend du temps, les programmes Java ne sont pas très rapides (pas encore). Des améliorations s'en viennent pour remédier à cette situation.
Non seulement les ordinateurs vont de plus en plus vites (rendant ainsi la vitesse du Java «suffisamment rapide»), mais les technologies utilisées dans le Java le rendent encore plus rapide. Ce n'est qu'une question de temps.
Les changements coûtent toujours de l'argent (ainsi que du temps et de l'effort). Les gens résistent au changement, même s'ils savent que c'est pour le mieux. La seule chose retenant Java, c'est le temps requis pour le changement. Il existe une énorme quantité d'infrastructures, outils et code écrits pour d'autres langages -- ça prend du temps à Java pour rattraper cela. Mais les gens n'ont pas chômé, il y a maintenant des douzaines d'outils commerciaux (et d'autres naissant chaque jour). De plus, il y a énormément de librairies Java commerciales permettant d'étendre le Java pour qu'il en fasse plus (et d'autres sont à venir). Les coûts reliés au changement ralentissent le progrès -- mais ils n'arrêtent pas le progrès.
Malgré la résistance au changement, et la performance de Java, il ne cesse de gagner du terrain (l'engouement existe depuis longtemps déjà). La question n'est pas de savoir «si» le Java va triompher, la question est de savoir «quand».
Une réponse rapide serait que Java triomphera de la plupart des autres langages de programmation (à usage général). Mais cela n'arrivera pas aussi rapidement que les gens le croient. En fait, il est là depuis déjà quelques années, et n'a pas apporté beaucoup à la plupart des programmeurs, pas encore -- et quelques années seront encore nécessaires avant de ressentir son impact total.
Il y a deux façons de distribuer des programmes Java -
La programmation d'applications Java a déjà pris son envol dans certains marchés et l'intérêt augmente. Des universités enseignent le Java, et certains programmes universitaires sont orientés uniquement sur le Java. Les programmeurs apprennent le Java, les fabricants d'outils conçoivent des outils Java, les endroits où on vend des librairies de code vendent des librairies Java (Frameworks). Toujours plus d'intérêt. L'intérêt entraîne l'intérêt -- l'effet boule de neige.
1998 sera une année de transition, beaucoup d'applications Java feront leur apparition (au fur et à mesure que de meilleurs outils deviennent disponibles) -- 1999 sera probablement l'année où Java commencera sa domination dans le monde de l'informatique. Au tournant du millénaire, je crois que la majorité des autres langages seront balayés par l'intérêt suscité par Java -- ainsi il survivra à l'engouement passager (l'intérêt est trop grand pour que ça ne soit pas le cas). Ça se passe seulement un peu moins vite que ce que les gens croyaient.