Il y a plusieurs langages de programmation qui mettent en avant leur capacité à être lu et écrit comme du langage naturel.
Par exemple, Hypertalk :
set the location of card button x to pos add 15 to item 1 of pos
Ou encore Perl :
move $this from => $here, to => $there; print $message if $name eq "Bob" and $age > 10;
I want window and the window title is Hello World.
Pourquoi faire ?
Le but de ces langages est, de manière évidente, de faciliter les développements. En réduisant l’effort cognitif nécessaire pour écrire un programme, on peut raisonnablement penser qu’ils deviendront plus faciles et rapides à écrire.
En fait, c’est surtout en terme d’apprentissage que cette approche montre une quelconque valeur : une personne n’ayant jamais utilisé le moindre langage de programmation sera moins rebutée si elle a l’impression de parler à la machine pour lui dire quoi faire, plutôt que de devoir apprendre les codes cabalistiques que la machine lui impose.
C’est l’une des raisons du succès remporté par Hypercard à la fin des années 80 et au début des années 90. Non seulement il proposait de créer des interfaces graphiques à la souris, mais il permettait ensuite de les contrôler d’une manière plus simple que tout ce qui était connu jusqu’alors. Dans une certaine mesure, le succès du Visual Basic repose sur les mêmes fondamentaux (en remplaçant le langage pseudo-naturel par le langage informatique désigné comme étant le plus simple).
Le culte du cargo
Ça faisait un bout de temps que je voulais parler du culte du cargo. À la base, il s’agit du fait que certaines peuplades du Pacifique, voyant des avions-cargo larguer des vivres après que les soldats américains l’aient demandé à la radio, se sont mis à construire de fausses cabines-radio (voire même de fausses pistes d’atterrissage), espérant pouvoir ainsi faire venir de nouveaux parachutages après le départ des troupes à la fin de la deuxième guerre mondiale.
Par extension, on parle du culte du cargo lorsque quelqu’un observe une chose et tente de la reproduire, sans la comprendre, en espérant que cela générera les mêmes effets.
J’en profite pour en parler, car l’article Wikipédia parle notamment des concepteurs de langages informatiques (en citant le Cobol comme exemple) qui essaient d’imiter l’anglais sans pour autant maîtriser sa construction, et sans l’adapter correctement aux spécificités des langages informatiques.
Verbosité versus concision
Le problème fondamental et évident avec le langage naturel, c’est qu’il manque de concision. Il a été conçu (si je puis dire) pour véhiculer des informations mais aussi des émotions, de la nuance. Ajoutez à cela qu’un langage réel évolue au fil des siècles, ce qui lui apporte toute sa richesse ; c’est d’ailleurs l’une des choses qui − du point de vue des linguistes − différenciera toujours les langues naturelles des langues construites (espéranto, volapük, interlingua, interlingue, idiom neutral, …).
Il faut aussi prendre en compte un aspect important : l’héritage mathématique.
On apprend assez jeune, au collège, les concepts de variables et de fonctions. Et même si je pense les avoir découvert grâce aux langages de programmation plusieurs années avant de les apprendre en cours de math, la logique de cette enseignement est indéniable.
Il faut toutefois différencier ces deux concepts, qui sont au cœur de tous les langages de programmation.
Les variables sont faciles à comprendre et à manipuler. Il est donc inutile de vouloir écrire :
mettre la valeur 27 dans la variable toto
Alors qu’on peut écrire simplement :
toto = 27
Par contre, pour les fonctions (ou les méthodes), c’est un peu différent. Si on y réfléchit bien, elles reflètent un comportement naturel. Un comportement, pas un langage.
Je m’explique. Tous les jours, à tous moments, nous employons des termes qui synthétisent nos idées ; nous utilisons des synonymes qui regroupent plusieurs idées à la fois.
Quand on dit « Monte dans la voiture », on utilise une expression qui est un résumé signifiant « Va jusqu’à la voiture, ouvre la portière, entre dans la voiture, assois-toi sur la banquette, ferme la portière, attache ta ceinture« . Même « attache ta ceinture » peut être décomposé en « lève le bras, attrape la ceinture, descend le bras, fait entrer la boucle dans l’attache, pousse jusqu’à entendre un “clic”, lâche la boucle« .
Quand on y pense, cela est très similaire avec la manière dont on utilise les fonctions et les méthodes. On cache une complexité en lui donnant un nom identifiable, avec une profondeur infinie. Et quand on n’a besoin que de manipuler des concepts globaux, on se s’embarrasse pas à vouloir comprendre ce qu’ils renferment.
Conclusion
Je me rend compte que cet article ne sert pas à grand-chose. :-)
C’est juste que j’entends régulièrement parler d’efforts de simplification de la programmation. Et quand ces efforts tentent de singer des concepts naturels (le langage naturel en est un exemple, mais il faudrait aussi que je vous parle de la programmation visuelle un de ces jours), on sait d’avance que le résultat ne sera jamais à la hauteur des ambitions « révolutionnaires » qui sont annoncées…
L’essence même de l’informatique implique quelle nous fasse manipuler des notions qui ne sont pas naturelles. Ce qui importe, c’est de pouvoir utiliser l’outil informatique pour créer des choses plus avancées, et cela plus rapidement.
N’importe quel enfant de 3 ans est capable de dire ce qu’il veut. C’est une bonne chose d’offrir à ces enfants la possibilité de se frotter à la programmation. Par contre, il n’est pas nécessaire que les outils de programmation que nous utilisons au quotidien soient ceux que nos enfants pourraient aussi utiliser.