Essence d'un langage ?

Suite à cette discussion particulière , on peut se poser la question de manière plus générale :

Sachant qu'un programme, c'est à la fois un code écrit par un humain et un code interprété par une machine (virtuelle ou non) et qu'entre les deux, il peut y avoir un intermédiaire ou non (compilateur), qu'est-ce qui fait qu'un programme est en langage X ?

• S'il est écrit en langage X ?
• S'il est compatible à l'exécution avec d'autres programmes écrits en langage X ?
• Les deux à le fois ?
• Autre (préciser ...)

Exemples particuliers :

• Il existe des programmes écrits dans différents langages (Java, Scala, Groovy, ...) mais compatibles à l'exécution (JVM)
• Il existe des programmes écrits dans différents langages (C#, C++, VB, ...) mais compatibles à l'exécution (CLR)
• Il existe des programmes écrits dans un même langage mais incompatibles à l'exécution ? :aie: Est-ce du à quoi ?
  (Dans le cas de java, c'est dû à un compilo différent qui génère du byte code dans un cas et du javascript dans un autre (gwt))

Un avis sur la question ?

Pour moi, pour qu'on puisse dire qu'un programme ou une bibliothèque a été écrit dans un langage donné, il faut et il suffit :

1. qu'il ou elle ait été écrit(e) en majeure partie dans ce langage.
2. OU : qu'il ou elle soit basée sur une bibliothèque (éventuellement "interne") dont les interfaces sont en majeure partie écrites dans ce langage.

Exemple : On dit que Windows et Linux (pour se limiter à ces deux là) sont écrits en C parce qu'ils sont en majeure partie écrits en C.

Autre exemple : Si je développe une application ou une bibliothèque en utilisant le C pour l'interface des fonctions et pour la définition de types, etc. et 90% d'assembleur dans le code des fonctions qui sont les plus appelées (en supposant que tous les appels de fonction se font en C) - ce qui signifie que le point d'entrée est une des fonctions qui ne contiendra pas ou qui contiendra que peu d'assembleur (puisqu'elle n'est appelée qu'une fois (par l'OS)), je peux aussi bien dire que mon application ou ma lib a été écrite en C (en raison de 2.) qu'en assembleur (en raison de 1.).

Je n'ai pas voté ...

J'ai voté autre. Un programme n'est écrit en aucun langage, pour moi un programme est avant tout un algorithme. Le langage utilisé n'est pour moi qu'une vision utilisateur de cet algorithme, au même titre que la coloration syntaxique ou la mise en forme (j'exagère à peine).

Ca fait un certain temps que je défend cette idée, j'ai même fait il y a quelques années un petit programme qui le mettait en pratique: une simple option du menu permettait de switcher entre basic et C, le programme en lui-même étant mémorisé en "pseudo-code formaté".

Me disant qu'il y avait peut être quelque chose qui m'échappait, j'ai bien fait de prévoir une case autre :P

Belle idée en effet :ccool:
Et justement, les plateformes (JVM, CLR) permettant de faire tourner des programmes écrits dans différents langages montrent bien qu'il y a quelque chose de commun derrière.

Je lisais dernièrement cet article où l'histoire se répète ... On réinvente des langages de couche supérieur pour masquer les différentes implémentations des couches inférieure.

A quand des machines qui comprendraient directement les algorithmes ?
Bon, c'est vrai, il faudra bien un langage pour les écrire, ne serait-ce un langage formel ?

Je dirais "s'il est écrit majoritairement en langage X", pour ma part, reste à définir à quelle "majorité" on peut omettre les autres langages utilisés : à 51%, ça fait un peu gros de zapper les 49% restants, alors qu'à 99%, c'est effectivement négligeable d'omettre les autres langages utilisés.

De toutes façons, le résultat produit est, lui, variable (langage machine, bytecode, interprétation directe, ...) et dépend très fortement de la plate-forme où on le compile / exécute (OS, compilateur, langage, ...).

La compatibilité entre langages (deuxième option du sondage) est plus, pour moi, une question de plate-forme de développement (conventions d'appel OS / compilateur, par exemple), ou d'interopérabilité entre programmes (wrapping code natif / VM).


Pour le sous-débat :
La frontière est de toutes façons assez floue entre "langage" et "programme" : au sens strict, un programme n'est que du code machine (ou du bytecode), il n'y a guère que dans les langages interprétés que le langage source garde une importance quelconque. Toutefois, le développeur met rarement les mains dans le code binaire produit, ou dans l'interpréteur. Si l'on considère le langage comme la dernière étape avant de passer intégralement au niveau machine, alors on peut assimiler le code source au programme lui-même... Question de point de vue, donc.

Côté algorithmes, effectivement, un langage n'est qu'un moyen d'implémenter un algorithme. Toutefois, certains langages sont nettement plus doués que d'autres suivant l'algo choisi... ;) Il reste qu'il faut bien un langage, quel qu'il soit, pour donner ses instructions à l'ordinateur.
Cela peut être un langage procédural, fonctionnel, formel, ou même "naturel" lorsque l'IA en sera arrivée au point de passer le test de Turing.
Une idée (=un algo) peut par contre être exprimée dans plusieurs langages, plus ou moins simplement certes. Après tout, on peut décrire les mêmes concepts en français ou en anglais. Toutefois, expliquer une recette de cuisine sera sûrement bien plus simple à faire en français qu'en anglais, le français étant plus riche côté termes culinaires.


Mais demander à un ordinateur une tâche, c'est communiquer avec lui, donc un langage reste nécessaire.

Rien n'interdit toutefois à un ordinateur de connaître plusieurs langages, naturels ou non... Pour l'instant, nos ordinateurs ne connaissent réellement que le langage machine, il faut donc des traducteurs (compilateurs, interpréteurs, VM) pour lui "causer dans le texte". Cela ne change que le nombre de langages intermédiaires entre le nôtre (=specs / CdC par exemple) et celui de l'ordinateur (LM), et donc le nombre de traducteurs (humains ou programmes) nécessaires pour aller de l'un à l'autre.