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 😉

 

11 commentaires

  1. Merci de ce billet. J’aime bien l’idée d’un langage « web », j’ajouterais même « orienté commerce » (histoire de pouvoir maitriser les promotions autrement que par des pointeurs de pointeurs 🙂

    Par contre le premier langage de programmation est le « ladder » ou langage à contact (symbole électrique type interupteur)
    |___/ _____(x)____|
    | |

    (bon les symboles sont normalisés et pas respectés ici 😉 mais ca ressemble à ça )

  2. Programmation par couche -> MVC non ? D’ailleurs si on code ‘propre’ , et quelque soit le langage, on utilise normalement une approche assez proche : lecture, filtre, gestion des erreurs ou des exceptions puis traitement.

    Pour le garbage collector et les sessions, la plupart des langages web le font automatiquement depuis perpete (ou alors je n’ai pas compris ton propos).

    Pour la persistance des données, integrer Hibernate par exemple est assez simple.

    voili voilou

  3. Votre description du futur des langages de programmation est assez proche de ce que propose le couple Ruby et ROR, sauf au niveau des ressources 🙁
    Pourrais t-on en savoir plus sur votre idée de la programmation par couche?

  4. @Neoty> Oui, c’est sûr que RoR est intéressant mais :
    – Je n’aime pas le principe de génération de code,
    – Je crois vraiment qu’il vaut mieux un langage compilé pour améliorer la fiabilité et la performance

    Pour la programmation en couche, mon idée est un mix, entre des concepts au niveau du langage, et un IDE :
    L’IDE permet de sélectionner le calque: base, ou différents type d’erreurs.

  5. Tout cela m’indique juste que tu n’es juste… Pas un programmeur. Tout ce que tu indique soit existe déjà depuis des décennies ou bien est juste une hérésie – dans le sens où cela n’a rien à faire dans la couche langage.

    On reste potes hein ? 😉

  6. &Pieroxy> J’ai une autre hypothèse : tu n’as pas capté ce que je propose 😉

    Maintenant, c’est sûrement parce que je l’exprime pas clairement !

  7. Alors reprenons les points un par un ! 😉

    Un langage résolument orienté Web. Je ne voit pas ce que le Web a de spécifique par rapport à une autre tâche pour un langage de programmation. Que je programme un serveur FTP ou un serveur web ou un traitement de texte, ce dont le langage a besoin c’est d’accéder au réseau et aux disques et à l’écran. Il ne faut pas oublier que le langage est un concept somme toute assez bas niveau. C’est pas là qu’il faut intégrer les spécificités du web.

    Une programmation par couche : Cela existe dans tous les langages est c’est appliqué (avec plus ou moins de succès) depuis que je fais de l’informatique, c’est-à-dire depuis plus de 10 ans. En effet, comme tu le décris, ce n’est pas la première approche qu’un programmeur prend. C’est ce qui sépare un programmeur « mauvais » d’un « bon ». Notes que je ne met pas « débutant » et « confirmé » car le nombre d’années d’expérience n’est pas toujours gage de qualité. J’en profite pour noter qu’un programmeur qui coûte le double mais qui vous produit un truc que vous n’êtes pas obligé de jeter au bout de quelques années vous a en fait fait gagner de l’argent. Extrêmement compliqué à maîtriser, mais à toujours prendre en compte.

    Considérer les formats du web (html, css, js) non comme du texte, mais comme un arbre (DOM) dans lequel on peut naviguer. Encore une fois, il y a de très bonnes librairies pour faire ça. Et là encore on se parle d’un outil à la disposition des langages, pas d’une fonctionnalité d’un langage. Cela existe depuis au moins 10 ans aussi. C’est aussi beaucoup plus verbeux et compliqué à lire que des bêtes chaines de caractères dans ton code.

    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. Encore une fois, tout cela existe de façon simplissime, en tout cas en Java. Java gère le garbage collector pour toi. Tomcat gère les sessions. Tomcat sérialise les sessions tout seul comme un grand, sans que tu n’aie rien à faire. Les frameworks de persistence non-jdbc ne se comptent plus sur les doigts de la main…

    Quand à tes conclusions, elles sont elles-aussi erronées:
    Beaucoup moins de ressource côté serveur: Plus tu as de couches d’abstraction côté serveur, plus tu consommeras de ressources. C’est pour cela que les applis consomment de plus en plus de ressources côté serveur: Elles utilisent de plus en plus de couches d’abstractions « génériques » et de librairies « à tout faire » – par souci de maintenabilité et de facilité de programmation. Par exemple, ton idée de gérer les documents HTML comme des arbres prendra plus de CPU et de mémoire côté serveur. Beaucoup plus, puisqu’il s’agit de faire le travail en double: Générer un arbre d’un côté, puis le transformer en texte alors que sans cet outil, tu te contentes de générer du texte.

    Une programmation plus facile, plus propre, et donc plus facile à maintenir, plus évolutive. Oui, là c’est bon. Mais cette conclusion va à l’encontre de la précédente. Plus c’est facile pour le développeur, plus c’est « abstrait » de la complexité de la machine. Donc, plus c’est lent et gourmand en ressources. A l’inverse, plus le programmeur se donne du mal à optimiser, plus ça va vite, et plus c’est compliqué à maintenir.

    J’aimerai bien moi aussi qu’il y ait un graal qui permette d’aller vite, bien et faire une appli optimisée. Ca n’est pas le cas malheureusement. On peut même en revenir aux fondamentaux de la programmation: Vite, Bien, Pas cher. On peut toujours essayer de tirer sur un, mais les deux autres montent. L’optimal est un équilibre entre les trois. On peut faire un parallèle avec ton post: Optimisé, Maintenable, Pas cher à construire. C’est la même logique. Si tu en veux un très élevé, les deux autres vont toucher le plancher. Si tu en veux deux très élevés, le troisième va faire de la spéléo…

  8. @ Pieroxy> Pas d’accord avec toi sur de nombreux points 😉

    Et c’est trop long pour détailler tout ça ici. Si le sujet te passionne, il faudrait qu’on en discute. Mais, vu ton point de vue, je ne suis pas sûr que ça donne grand chose : puisque mes idées, cela fait 10 ans que c’est déjà fait 😉

    @Jean Baptiste> ok, merci pour l’info, je ne connaissais pas votre solution.

  9. Il y a toujours de l’innovation, ou au moins de l’espace pour l’innovation dans le domaine des langages, notamment des langages aux syntaxes non naturelles comme le J qui permet de faire certaines opérations en extrèmement peu de caractères.
    Cependant l’aspect ésotérique de la syntaxe repousse de nombreux programmeurs.
    A noter aussi le langage SCALA, une sorte de Java optimisé (plus rapide à rogrammer, moins redondant …) qui génère du bytecode Java et avec lequel on peut directement utiliser toute la bibliothèque Java.
    En effet comme tu le dis dans ton billet, un language est loin de se limiter à un syntaxe et des mots réservés, entrent en compte toute la solution dans laquelle il s’inscrit.
    Pour SCALA on observe également une forte inertie du milieu des programmeurs qui préfèrent rester en Java, cependant on a des firmes qui tentent de l’introduire en l’utilisant comme twitter et the guardian, ce qui l’amènera sans doute à devenir ‘mainstream’ un jour.

    Je suis en train d’écrire un dossier sur les langages de programmation, la façon dont ils apparaissent et les facteurs qui vont déterminer leur succès, ton billet m’a aidé dans mon travail, je prend tes remarques (et les commentaires, merci aussi à eux) en compte. Merci.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *