Le langage de programmation du futur
Les nouvelles fonctions qui faciliteront le développement pour le Web, les mobiles ou la robotique.
Ces dernières années on a vu se populariser certaines caractéristiques dans les outils de programmation, notamment la concurrence et le mode asynchrone. Des fonctions qui accompagnent la transition de l'application locale à l'application universelle, en ligne ou locale.
Mais cela est loin d'être suffisant pour permettre l'accomplissement final dans l'évolution de la programmation. Il faut de nouvelles caractéristiques pour les langages, mais lesquelles?
La tolérance dans le code
Aucun langage actuel n'est vraiment adapté à la robotique du fait de leur caractère formel. La moindre virgule manquante et le programme est défaillant. Cela convient peut-être pour les applications actuelles, quoiqu'on puisse s'en douter quand on sait qu'une fusée Ariane a explosé en vol du fait d'une simple division par zéro, mais c'est totalement inacceptable pour la robotique.
A l'inverse le langage HTML est tolérant: une balise non fermée et le moteur de rendu infère la partie manquante. S'il ne reconnait pas une balise, il l'ignore purement et simplement. Cela facilite grandement la tâche des développeurs du Web et cela à permis la popularisation de HTML. Les langages et compilateurs du futur devraient être tolérants, et cela est même indispensable pour la robotique afin de permettre un certain apprentissage. L'interpréteur doit être capable de faire des inférences et de fournir lui-même le code nécessaire pour compléter une tâche.
Le service comme module
Dans un environnement nouveau où l'on ne peut plus bien définir ce qui est local et ce qui est distant, parce que les applications locales utilisent des services distants et les applications en ligne peuvent fonctionner localement, on devrait revoir la conception des modules et librairies et leur donner la forme d'un service.
Un service est moins strict dans l'interface avec l'application qu'une librairie. Il peut être utilisé directement avec des applications écrites en des langages différents. Le principe de tolérance s'étend aux services également. Le service répond à ce qu'il comprend et ignore ce qu'il ne comprend pas ou essaie d'y suppléer en fonction de ce dont il dispose.
Le langage pour les outils
Le langage Dart, langage ultra-classique conçu pour permettre au vétérans de programmer des applications Web sans avoir à changer leurs habitudes acquises sur le bureau au cours des décennies précédentes à la prétention de venir avec des outils facilitant la programmation. Le langage lui-même facilite la création de ces outils de développement.
Les langages classiques peuvent déjà produire une version de déboguage qui contient des méta-informations permettant de suivre le déroulement d'un programme et localiser les erreurs. Cela doit aller plus loin.
On ne doit plus seulement faire des outils pour les langages mais aussi des langages pour les outils.
Le plus utile est en fait la synchronisation entre d'une part la vue du programme en déroulement et d'autre part la vue du code source. Il ne s'agit pas seulement de mettre des points d'arrêt et de regarder le contenu des variables lors de chaque arrêt, mais au contraire de laisser se dérouler le programme au ralenti en pouvant voir le code source correspondant dans une autre fenêtre.
Cela suppose que l'interpréteur affiche chaque instruction du source avant de l'exécuter mais aussi que l'on puisse interagir avec lui, "plier" une partie du programme que l'on veut passer ou "étendre" une partie que l'on veut voir. L'interpréteur réagit aux évènements venant d'une interface et sait adapter son comportement, cette capacité se développera avec des suggestions sur le code, ce qui suppose que l'interpréteur puisse inférer les objectifs de chaque partie du programme. Il devrait aussi proposer des alternatives au code. L'outil de développement doit être interactif et intelligent et cela suppose que le langage intègre des notions sur ses objectifs.
Visualisation du code en cours d'exécution
Même si certains langages essaient de rendre le code plus compact à écrire et ainsi permettre de taper un peu moins sur le clavier, la part de l'écriture d'un programme est infime comparée au temps de conception et surtout au temps de déboguage.
Le déboguage est le point faible de la programmation: comment trouver l'instruction qui produit le défaut que l'on constate dans quelques milliers de lignes de code? Tout deviendrait tellement plus simple si on pouvait voir le code qui s'exécute en même temps que l'on voit le résultat de l'exécution.
Aucun outil ne peut ajouter cette fonctionnalité, placer des points d'arrêt est une solution de rechange, mais cette fonction doit être construite dans le langage et son compilateur.
Le compilateur quand il produit le code objet, devrait ajouter des appels à une fonction qui contient une représentation du code source, qui pourrait ainsi s'afficher durant l'exécution.
Mieux encore, on devrait pouvoir modifier le code source et reprendre l'exécution...
Auto-correction
La capacité d'un programme a corriger lui-même ses erreurs n'est pas quelque chose de nouveau. Cela avait été inclut dans le programme d'Apollo 11 qui a permis pour la première fois à des hommes de marcher sur le lune en 1969, et c'était une sage précaution car le programme s'est affolé et est devenu erratique durant la mission, mais grâce à sa capacité de se corriger, la mission a pu continuer normalement.
L'auto-correction doit être ajoutée par des routines supplémentaires actuellement, c'est pourquoi les programmes ne disposent presque jamais de cette possibilité. Une erreur dans le code a provoqué l'explosion d'une fusée Ariane 5 en 1996 (coût: 500 millions de dollars!).
Il faudrait que le langage dispose d'objets auto-correcteurs basé sur des contraintes pour éviter les comportements dommageables à cause de bogues dans le code.
Auteur: Denis Sureau, créateur du langage Scriptol.
Le 30 Mars 2013. Mis à jour le 12 février 2017.
Note: Je parle d'interpréteurs et pas de compilateurs, mais avec les JIT et AOT comme Asm.js, la différence tend à s'estomper.