Les langages de programmation : aujourd’hui et demain ?

J’ai trouvé cette image sur un blog :

Je ne sais pas comment est calculé le graphique ci dessus.

Un autre copain m’a envoyé un lien vers un autre article, qui parle de l’avenir des langages de programmation.

Mon point de vue est le suivant :

Les langages de programmation n’évoluent pas beaucoup ces derniers temps. Il y a des framework qui sortent, mais pas grand chose d’innovant au niveau langages.

La programmation est, et restera encore quelques décennies, un métier. Je ne crois pas du tout que le développement de nouveaux paradigmes de programmation peuvent rendre la programmation tellement simple qu’elle devient accessible à tous. Pourquoi ? Parce que ce qu’on doit faire, quand on programme, c’est prévoir une grande combinaisons de cas, et que, intrinsèquement, c’est complexe.

Je n’ai jamais été fan de la programmation graphique. C’est une idée sympathique, mais je ne crois pas que ça soit une vrai solution industrielle. Ca peut par contre être un bon moyen pour appendre.

Par contre, je crois en l’intérêt d’un « package » complet et cohérent : un framework.

L’enjeu n’est donc pas d’écrire un langage, mais de proposer une solution complète. Ce qu’à plutôt bien fait Microsoft avec .Net.

Ce qui manque, à mon avis aujourd’hui :

  • Un langage résolument orienté Web. Je pense que le web est suffisamment spécifique pour nécessiter un langage, et tout ce qui va avec, spécifique. Considérer que n’importe quel langage peut faire n’importe quoi n’est pas, à mon sens, la bonne approche.
  • Une programmation par couche : c’est une idée qui me trotte dans la tête depuis bien longtemps. L’idée est de découper la programmation en plusieurs couches, en se disant qu’un même programme doit résoudre des aspects différents d’un problème. En fait, quand on programme, on commence par aller très vite pour régler le ‘cas normal’. Ensuite, on passe beaucoup de temps à traiter tout le reste : les cas limites, les cas d’erreurs, … Et tout cela est mélangé ce qui fait, qu’au bout du compte, on ne sait plus ce que fait le programme dans le cas normal. Mon idée, que je n’ai jamais vue mise en oeuvre, est de proposer une programmation « par calques », comme sur Phtotoshop. Chaque calque traite un aspect du problème.
  • Considérer les formats du web (html, css, js) non comme du texte, mais comme un arbre (DOM) dans lequel on peut naviguer. Le langage de programmation pourrait manipuler cet arbre, pour ajouter des bouts, en supprimer d’autres… Le texte ne serait que le résultat final. Avantage : on peut complètement optimiser le flux de sorti, pour avoir des temps de chargement beaucoup plus court. Quand j’étais étudiant en informatique, des chercheurs travaillaient sur un langage dont la structure de base est un arbre (dérivé de l’idée du lisp, ou la structure fondamentale est une liste. Je ne sais pas ce que ça a donné.
  • Considérer que certains aspects doivent être traités par le framework et pas par le programmeur : les sessions et le garbage collector par exemple.
  • Un système intégrant nativement la persistance des données, et pas via un SGBD relationnel, mais plutôt avec une modélisation fondamentalement objet.

Tout cela devrait permettre :

  • Beaucoup moins de ressource côté serveur. Je suis toujours impressionné par les besoins en ressources serveurs avec les solutions actuelles.
  • Une programmation plus facile, plus propre, et donc plus facile à maintenir, plus évolutive.

Si j’avais du temps, je bosserais bien là dessus ;)