Les langages de programmation, les frameworks, les techniques… évoluent en permanence.
Alors, petite question d’anticipation, comment développerons-nous dans 10 ans ? A quoi ressembleront les langages ? Les IDE ? Les frameworks ? Les paradigmes ?
1 « J'aime »
Avec des langages fonctionnels.
1 « J'aime »
Je m’avance peut-être en pensant 10 ans, disons plutôt 20 ou plus, mais le sujet m’intéresse et mérité d’être discuté !
La recherche sur les ordinateurs quantiques avance à grands pas, et avec eux disparaissent nos langages de programmation basé sur une logique de bits.
De nouveaux langages supportant les “qubits” (induit de la mécanique quantique) font leur apparition depuis quelques temps déjà et il sera impératif pour les futurs développeurs de les apprendre.
Un petit SlideShare sur la question !
Il se trouve justement que l’un d’eux, Quipper, a pour base Haskell ;)
2 « J'aime »
De nos jours avec les patterns récurrents, la modularité et surtout le développement de l’IA. Il n’est pas impossible que dans quelques années on ne fasse plus que du bugfix sur les programmes qui développeront à notre place.
Il y a bien eu un ordinateur qui a pondu un livre…
1 « J'aime »
Effectivement, le raisonnement sur l’informatique Quantique me semble extrêmement pertinent. (Attention attention, je suis réellement novice en la matière et je n’ai jamais eu de physique quantique, peut être que dans ma dernière année de lycée on l’effleurera, donc je peux dire des sottises et je m’en excuse ! N’hésitez donc pas à pointer du doigts mes maladresses).
J’ai deux questions à ce sujet, justement.
-
Est ce que l’informatique Quantique se substituera à toute forme d’informatique? Ou comme pour la physique quantique, elle complète (en ouvrant son domaine de raisonnement), la physique classique? Pourrait on imaginer que l’informatique quantique ne reste “qu’une” particule de l’informatique, ne faisant pas tomber nos langages en désuétude ?
-
J’aime considérer qu’un langage est une abstraction d’un comportement plus bas niveau. Est ce que l’arrivée de l’informatique Quantique ne changera, au final, que les méthodes de compilations? Offrant, dans une même structure sémantique, plus d’outils? Et donc que au final, les langages ne changent pas tant que ça ? Juste une réforme au niveau des traitements interne?
Kakawait
Oui, sans aucun doute, ça arrive déjà presque avec Eclipse, qui défini de manière intelligente des manque dans des programmes. Coupler avec un typage efficace (à la ML), et des méthodes de résolution (beta and co), pourquoi pas :)
2 « J'aime »
Logiquement, vous n’en parlerez pas au lycée, ce n’est pas du tout au programme. Tu peux toujours poser quelques questions à ton prof de physique !
Si cela t’interesse, tu peux suivre des MOOC sur le sujet, pour ma part j’avais suivi l’été dernier celui-ci Quantum Mechanics and Quantum Computation et à partir de Février 2015 je suivrai peut-être Mastering Quantum Mechanics.
Pour répondre à tes questions :
-
Je pense que les deux formes vont cohabiter pendant longtemps, jusqu’à démocratisation de l’ordinateur quantique. Mais alors, pour moi, nos langages actuels devront disparaitre, ils ne permettront plus de suivre les capacités matérielles fournit par ces “supercalculateurs”.
-
J’aime aussi le considérer, et c’est le cas ! En y réfléchissant, il me semble évident que des compilateurs de nos langages vers des langages quantiques feront leur apparition. Mais c’est au niveau language machine que tout change. Les compilateurs actuels produisent un langage machine basé sur un logique binaire (bits), ce qui n’est plus le cas avec les ordinateurs quantiques offrant les états binaires ainsi que leur superposition.
Pour résumer, oui nos langages peuvent potentiellement perdurer, mais il me semble plus adapté que nous devions apprendre ces languages un jour ou un autre.
D’acc ! Merci beaucoup pour ces liens et pour cette opinion :)
1 « J'aime »
Hello,
Un sujet qui devrait se populariser d’ici peu est la programmation distributée, et en particulier la disparition d’une mémoire vive partagée ou de la cohérence de caches. Je pense que dans pas bien longtemps, nous aurons trop de processeurs dans une machine pour qu’il soit possible de garder une cohérence entre leurs caches, ce qui pourrait petit à petit à oublier certaines notions comme le fait qu’un programme s’exécute séquentiellement. On aura par contre des bouts de code spécialisés qui discuteront avec d’autres via envoi de message (ou autre). Nous passerons AMHA d’une programmation séquentielle à une programmation basée sur la causalité.
Regardez ce qui tourne autour du bigdata on est passé d’un modèle centralisé où un site est hébergé sur une machine (ou le classique cluster avec load balancing) à un modèle totalement distribué où aucune machine n’a plus d’importance que les autres. Je pense que le même phénomène va se répandre aux autres disciplines.
2 « J'aime »
Par langage fonctionnel, tu parle du paradigme fonctionnel ou de langages dédiés aux fonctionnels ? :)
Parce que paradigme fonctionnel, ça fait pas mal d’années que ça existe et que ça s’utilise dans des langages moins en retard (comprendre java ?)
Il faut savoir qu’aujourd’hui, nous sommes de plus en plus enclin à faire la programmation concurrente au vu des limites physiques que nous avons atteint dans la création des processeurs. Ce qui fait qu’on se focalise désormais à l’ajout de cœurs (d’unité de calcul) et non sur la puissance brute qu’ils peuvent fournir indépendamment. Ce point, bien que technique et bien loin des considérations sémantiques des langages mainstream change tout de même la donne sur notre façon de programmer.
Et c’est là où je te rejoins en disant que dans un avenir très très proche, les problématiques liées à la programmation concurrente seront/devront être essentielles ! On ne pourra plus faire fi d’ignorer les problématiques de deadlock par exemple juste parce que c’est bien trop complexe à gérer pour un développeur - ce qui est normal, avoir une représentation conceptuelle de tout les états possibles d’un programme séquentiel n’est pas chose aisé déjà, si on rajoute à ça un ordonnancement partiel et inconnu de nos instructions, cela devient très vite mystique (le mot est juste) de trouver un bug dans un tel programme.
C’est pour cela que les centres de recherches mais aussi les entreprises se sont posé la question. L’idée est désormais d’abstraire la complexité lié à utiliser des mutex à la main tout en gardant la même expressivité possible qu’on retrouve en C et en C++. Et on a déjà pas mal de réponse qui sont bien loin que la simple abstraction des processus légers sur Windows et GNU/Linux tel que l’a fait la dernière version de C++.
Les langages comme OCaml ou encore Haskell proposent des solutions intéressantes et l’héritage qu’ils ont de la programmation fonctionnelle fait que les problématiques usuelles à la programmation concurrente qu’on peut retrouver en C++ (typiquement partager une variable non-constante entre plusieurs processus) disparaissent (je dis “disparaissent” mais en vérité, on peut retrouver ces problématiques particulièrement en OCaml qui est un langage impur si on utilise son aspect impératif) puisque toutes les valeurs sont immuables et donc il ne peut y avoir de conflit.
Maintenant, dans la vraie vie, cela ne veut pas dire que OCaml ou Haskell est fait pour la programmation concurrente. Leurs abstractions sont sémantiquement bonnes mais techniquement, c’est plus complexe. Et c’est en particulier le Garbage Collector qui pose soucis (car on revient à cette problématique de deadlock global, elle est juste caché). C’est particulièrement sur ce point que Scala (utilisé par Twitter) ce démarque avec la JVM qui a, je pense, le meilleur Garbage Collector au monde. Il a été pionné dans la gestion du multi-thread et Java l’a montré. Cependant les abstractions et leurs expressivités ne sont pas au même niveau que ce que propose Scala. OCaml rattrape tout de même son retard avec cet agglomérat de référénces et les sessions de hacking de Cambridge
Je pense que la programmation fonctionnelle a carrément plus de chance que la programmation objet ou impérative dans le domaine de la concurrence puisque son aspect pur et sa politique de confinement des effets de bords (qui sont la véritable problématique au final de la programmation concurrente) permet d’offrir une sémantique plus enclin à une programmation distribué. Cela a d’ailleurs aboutit à la création de MirageOS pour OCaml, HaLVM pour Haskell ou encore OSv pour Java qui sont des systèmes spécialisés pour le Cloud Computing.
De l’autre côté, on a un tout aussi ancien mais non moins important langage proposant une solution à la programmation concurrente avec le principe d’envoi de message qui est Erlang. Sa solution est tout aussi intéressante que ce que peut proposer OCaml, Haskell ou encore Scala et on pourrait dire que la sémantique qu’il propose a tenu contre le temps car elle répond assez bien à ce qu’on cherche réellement à faire dans une programmation concurrente. Il faut savoir que Erlang a été créé par Ericson pour le développement de logiciel sur les terminaux mobiles. En cela, ce langage a été fait pour la programmation concurrente. Cela ne décrédibilise pas pour autant les langages fonctionnels car Erlang est un langage fonctionnel. Au final, je dirais que Erlang a tout de même plus de maturité dans le domaine ce qui fait que WhatsApp a été plus disposé à l’utiliser exclusivement que OCaml ou Haskell.
Ce que je veux dire, c’est que pour répondre à ces nouvelles problématiques, il ne suffit plus de garnir la librairie standard de bindings pour l’utilisation d’instructions atomiques ou pour la création de processus léger comme le fait C++, Python ou encore Ruby. Il faut revoir la sémantique du langage pour abstraire la complexité de développement d’un logiciel multi-processus ou créer un nouveau langage comme c’est le cas pour Go (bien que celui ci reste encore une pâle copie d’Erlang) ou de Rust en se posant les bonnes questions sur ce qu’il adviendra du développement de logiciel plus tard - à mon avis, Rust est bien plus intéressant que Go car la sémantique qu’il propose n’existe pas dans le paysage des langages informatiques et l’idée d’associer une durée de vie à la variable ainsi qu’une appartenance avec une fonction dès la compilation permet d’exclure drastiquement le problème du deadlock, je dis pas que c’est la solution miracle, mais au moins, ils essayent quelque chose.
EDIT: avant qu’on me le reproche, j’ai été un peu sec sur Go et sa pâle ressemblance avec Erlang ce qui n’est pas vrai comme l’explique bien ce post. Ces points sont de l’ordre technique surtout mais je maintiens toujours que Rust est plus intéressant !
5 « J'aime »
Je pense que créer des applications sera plus accessible. Pour la partie graphique, Xcode, Visual Studio et consorts permettent déjà de créer des interfaces sans avoir à la coder. Mais il est toujours indispensable de coder les intéractions avec les différents services.
Il y a cependant des concepts actuellement pour créer graphiquement des services. Chris Granger, le créateur de Light Table (un IDE permettant une visualisation real-time du programme, “recopié” par Apple dans Xcode pour Swift) travaille sur des concepts depuis quelques années et devrait prochainement sortir une application à ce sujet : http://www.chris-granger.com/2014/10/01/beyond-light-table/
En gros une sorte de tableur permettra de créer une API sans coder ou presque (avec un petit langage pour gérer la logique). Et je pense que c’est un premier pas pour la création de services en tout genre et pas juste pour les données. Ce sera un peu comme Heroku (on se branche à tous les services qu’on veut sans les configurer sur son serveur) mais chaque service pourra être intégré à son application sans programmation préalable.
Je trouve ce sujet passionnant car cela permettrait d’augmenter notre productivité et passer plus de temps à programmer des choses intéressantes (qui a envie d’être forcé à passer des semaines à intégré l’API de Facebook totalement buggée dans son application).
1 « J'aime »
En utilisant un langage que j’aurai défini et qui lèvera les brides avec lesquelles les langages tant fonctionnels qu’objets nous tiennent actuellement en joue ;)
Je pense que Meteor est précurseur. La séparation nette entre client(s) et serveur(s) tendra à disparaître.
1 « J'aime »
Pour le coup, Meteor n’est pas vraiment précurseur :) (c’est juste les premiers à l’avoir “nommé” langage “isomorphique”)
Hello,
Je me permets de partager ce lien vers une vidéo (avec retranscription rapide des dialogues) où 3 experts des langages débattent un peu de ça:
http://cyberkarma.net/videos/conversation-with-three-language-experts/
Vis à vis de ce qui a été dit ici, j’aurais quelques remarques:
- le fonctionnel c’est pas nouveau, c’est même antérieur au C/C++. Ca a eu son heure de gloire, et puis, plouf, ça a été balayé. Donc perso je ne crois pas que ce soit le futur, je pense que l’avenir est à l’hybridation des genres. En fait, c’est même déjà le présent : la plupart des langages ont incorporé les lambdas par exemple. A l’inverse, il y a une tendance à vouloir faciliter l’accès au natif depuis les mondes managés.
Vis à vis de C++ que je connais mieux :
-
C++11 introduit déjà des primitives qui vont plus loin que les simples thread : future et async() en particulier, qui au passage accepte une lambda en paramètre (=> on lance l’exécution asynchrone d’une lamba et récupère son résultat plus tard au moyen d’un future).
-
un travail important est en cours pour C++17 afin d’aller plus loin en terme d’abstraction. Tout ceci est très bien débattu dans la vidéo ci-dessus, avec différents point des vue:
-
Celui qui pense que le future est à la programmation concurrente lock-free
-
Celui qui pense que c’est à des systèmes non cohérents (sans synchronisation => états incohérents de la mémoire!)
-
Celui qui pense qu’on ne sait pas faire à l’heure actuelle, et qu’il faut expérimenter plein de modèles afin de voir ce qui en sort
-
Le dernier point de vue est celui de B. Stroustrup, l’auteur de C++, et il explique que son ambition est faire que C++ devienne la plateforme pour évaluer tous les modèles possibles
-
A part ça, à l’heure où les objets à faible puissance (embarqués) sont censé nous envahir, où les giga data center font la course aux performances (chez Facebook, une optimisation de 1% faire économiser une somme supérieur à 10 ans de salaire d’un bon développeur…), je pense que le natif a encore de beaux jours devant lui, avec toute la complexité qu’il y a derrière
-
en m’intéressant à Rust, j’ai été surpris de découvrir un langage où des concepts habituellement réservés au C++ moderne sont naturellement présent. Aussi je ne te rejoins pas quand tu dis que la sémantique de Rust n’existe pas ailleurs. C’est d’ailleurs pour moi un mystère : pourquoi quand Rust propose de se prendre la tête avec de tels concepts c’est perçu comme novateur, et quand c’est C++, c’est perçu comme archaïque ? lol !
Ce que je pressens venir pour les 10 ans à venir, c’est la montée en puissance des “meta-outils” à notre disposition. J’entends par là des outils et pratiques basées sur l’interraction avec le compilateur et son AST. De ce que j’en sais, finalement, c’est encore un concept des langages fonctionnels qui est en train d’être intégré !
De manière générale, la programmation c’est quelque chose de complexe, et les tentatives de langages “simples” finissent toujours pas aboutir à des langages de plus en plus compliqués. La raison est très bête : langage simple = langage au périmètre restreint. Plus on élargit son périmètre d’utilisation, plus il se complexifie. Ou dit autrement : “un langage simple est un langage dont on n’a pas encore découvert la complexité”. Donc rendez-vous dans 10 ans pour voir où en seront Go, Rust, & Co. Je pense qu’ils seront devenus assez complexes pour que des mecs se disent : “et si on faisait à la place un nouveau langage + simple ?” lol!
Pour ce qui est des ordinateurs quantiques, ce que j’en sais c’est qu’ils ne fonctionnent pas du tout de la même manière. Y’a aussi le DNA computing… Mais je ne crois pas un instant que tout ça sera mature dans 10 ans.
:-)
2 « J'aime »
Hmmmhmmm, c’est justement l’inverse que je dirais. Si les langages mainstream cherchent à patcher leurs sémantiques de traits fonctionnels, ce n’est pas pour rien. JavaScript est le parfait exemple d’un langage fonctionnel ayant eu du succès mais Lisp et OCaml sont tout aussi présent dans l’industrie. Enfin, j’ai bien signaler patcher car l’implémentation tel qu’on l’a connais des lambda en C++ ou en Python par exemple n’est juste pas viable (plus spécifiquement pour Python qui est une hérésie mais C++ fait pas mal quand même).
Enfin, le fonctionnel n’est pas un gadget qui est apparu au même moment que le C par le biais de Lisp. Il suffit de parler du lambda-calcul créer par Alonzo Church qui a travaillé avec Alan Turing sur la machine de Turing que tout le monde connait comme fondement de l’informatique d’aujourd’hui et enfin de la correspondance de Curry-Horward qui tente de chercher encore aujourd’hui une équivalence entre le lambda-calcul et les mathématiques. Le fonctionnel a encore de beau jour devant lui.
Au final, ça n’a pas fait plouf comme tu dis car l’INRIA investit encore énormément dans ce domaine (rien qu’en continuant à maintenir OCaml mais on peut voir d’autres projets comme js_of_ocaml ou Mezzo). Ensuite, l’ANSSI a fait une conférence dans les locaux de l’IRILL en disant que OCaml est le meilleur choix technique dans leurs problématiques d’analyse des données. De l’autre côté de la Manche, nous avons Cambridge avec l’OCaml Labs (qui maintiens en passant Xen, inutile de le présenter - dont une partie du projet est en OCaml). Outre atlantique, la tendance est plus au Haskell et au Lisp/Scheme (puisque celui-ci a été fait au MIT) mais Scala montre aussi un certains succès avec Twitter et Erlang avec What’s App.
Et pour finir, l’hybridation des genres existe déjà dans la programmation fonctionnel. OCaml a intégré l’orienté objet (en réalité, c’est l’orienté objet qui a donné le ‘O’ de OCaml) et la programmation impérative était déjà présente depuis la version Caml. Scala propose un autre modèle orienté objet basé sur les type-class et c’est de même pour Clojure. JavaScript fait aussi de même donc de ce point, on est aussi bien loti que Python ou Ruby.
Oui, c’est aussi ce qu’on peut voir depuis pas mal de temps avec Lwt (ou son copain outre-atlantique Async) pour OCaml et JavaScript plus récemment avec Node.js et sa programmation asynchrone. Ces concepts ne sont pas nouveaux et même si je respecte l’effort de C++ de s’intéresser à la recherche dans le domaine de la programmation concurrente, il n’empêche que les problèmes sémantiques cités plus haut font qu’il est objectivement plus viable d’utiliser des langages qui ont été pensé pour ça, non ?
Créer des nouveaux modèles sémantiques pour évaluer leurs utilisabilités ne demande pas uniquement de savoir faire un compilateur. Cela demande en particulier une communauté de développeurs et de chercheurs et Rust a justement cette communauté (en partie française d’ailleurs). Je dis pas que les chercheurs sont plus enclin à travailler sur Rust que sur C++, mais on dénote une participation assez active de cette communauté ce qui n’est pas négligeable.
Que cela soit OCaml ou Haskell, ils sont tout les deux natifs (OCaml a de très bonnes performances d’ailleurs). Pour Scala, Clojure et JavaScript, ce n’est pas le cas mais ces derniers avaient d’autres ambitions au moment de leurs développements (en particulier Scala qui voulait intégrer tout l’user-land de Java et JavaScript qui voulait s’intégrer comme langage de scripting interagissant avec la page Web avec l’abstraction DOM - ce qu’on nommé au passage le DHTML à l’époque).
Il est logique que tu vois du C++ dans Rust, en réalité, c’est un des objectifs du langage (on peut donc dire qu’il l’a plus ou moins atteint). L’objectif de Rust est de supplanter le C++ (et on peut dire qu’il y a un bon début) en rajoutant des concepts novateurs (oui !) comme l’appartenance à une variable calculé dès la compilation (ce que ne fais pas C++) et l’idée de life-time pour les variables calculé aussi dès la compilation (ce que ne fais pas aussi le C++). Et non, on ne retrouve pas dans le paysage des langages informatique ce genre de concept (on peut trouver cependant des racines avec Mezzo notamment mais ça reste des inspirations sur des prototypes).
C’est même Lisp qui a intégré ce concept dès le départ (donc aussi ancien que le C).
Bah je préfère de loin cette attitude de créer des langages qui peuvent supplanter l’existant que de rester à coder du C. C’est même normal. Ce n’est pas une question de faire un langage plus simple, c’est une question de faire des langages pouvant répondre aux problématiques d’aujourd’hui qui ne sont pas les mêmes qu’avant. Je dis pas que C++ va juste subir un échec de cette transition mais il faut bien se rendre compte qu’il est en retard par rapport à ce qui se trouve déjà dans l’industrie (rien que d’un point de vu de la maturité de l’implémentation - et les entreprises ne vont pas se risquer à passer tout le code-base en C++17 dès sa sortie, il ne vont pas d’ailleurs s’amuser à changer tout le code-base en Rust, je te l’accorde).
D’une manière objective, l’entropie d’un langage informatique augmente avec le temps et c’est normal. Cela offre certainement plus de possibilité mais à qu’elle prix (et là, j’ai des exemples à la pelle) ? En augmentant cette entropie, on augmente la surface d’attaque et de bug plus mystique les uns des autres. Il est bon de faire table rase et de recommence parfois. Et bien sûr, un jour on fera des langages qui voudront remplacer Rust, Go & co.
Bien entendu, le succès de tel ou tel langage dépasse de loin l’objectivité (cf. PHP) qu’on puisse accorder à un langage. Et peut être que C++ aura toujours le leader-ship (d’ailleurs je le pense) mais il faut non seulement savoir rendre à César ce qui appartient à César mais aussi se rendre compte qu’on ne vit pas dans un monde se limitant à C, C++ ou Java (et encore heureux) et qu’il peut être mieux selon la problématique de changer de langage parfois.
J’ai pas pour ambition de faire en sorte que tout le monde fasse de l’OCaml (même si j’en rêve tout les soirs, c’est vrai) mais connaître l’existant par rapport à toutes ces nouvelles problématiques, c’est ce qui fait un bon développeur et il y a un temps où on faisait du PHP, hier c’était du Python, aujourd’hui c’est JavaScript et demain ça sera n’importe qu’elle langage car les développeurs auront le recul nécessaire pour choisir ce qui correspond le mieux à leurs attentes. C’est pour cette raison qu’on a des grosses boites qui ne font pas de C ou de C++ mais plutôt des langages (qu’on nomme encore comme exotique) comme OCaml, Scala ou Erlang. Et il y aura des boites qui feront du Rust (de facto, Mozilla) et pas du C++ et c’est très bien comme ça.
1 « J'aime »
Le sujet date pas mal et ma vision a quelque peu évoluée depuis mes précédentes réponses donc je me lance dans une nouvelle réponse. Ce qui ma fait changer de vision est mon apprentissage de rails, une certaine prise de recul sur des outils comme maven et ce qui s’est passé avec deepmind et alphago en début d’année.
A l’heure actuelle, on voit la programmation surtout comme une description détaillée de comment faire les choses et on emboîte ces composants pour produire un système cohérent pour résoudre un problème donné.
Or, depuis quelques temps j’ai l’impression que le paradigme a tendance à changer, par exemple avec maven pour décrire le build que l’on veut faire, avec les annotations dans java pour décrire ce que l’on veut représenter dans ce bout de code (c’est un test, c’est un singleton, …), avec les descriptions qu’offre rails quant à ce que l’on cherche à faire, …
On assiste de plus en plus à un code descriptif du problème/de la solution plus que fonctionnel et les frameworks génèrent le code nécessaire pour l’implémentation. En gros, on écrit de plus en plus un modèle de solution plus qu’une solution à part entière. Bien entendu, il est encore nécessaire d’écrire du code glu, mais plus ça va et plus j’ai l’impression d’en écrire de moins en moins. Donc première idée : ce que l’on écrira demain sera une description du problème et le framework/langage génèrera la solution.
En parallèle, les intelligence artificielles arrivent de plus en plus à créer des modélisations d’un problème donné via un apprentissage assisté. Il y a quelques mois, l’algo de Google a pu apprendre à jouer au go et à vaincre plusieurs très bons joueurs. Cette prouesse technique a montré qu’il était possible à une machine de trouver une modélisation d’un problème et de s’inspirer de solutions existantes pour le résoudre, mais encore plus loin, la machine a été capable d’«imaginer» des solutions innovantes et plus efficaces que les solutions classiques. Partant de ce constat, ne pouvons nous pas imaginer qu’une machine soit capable de modéliser un problème informatique à l’aide l’un langage déclaratif quasi complet comme on peut le voir plus haut ? Voire générer les concepts qui lui manque en faisant preuve de cette créativité étrange dont alphago a fait preuve face à Lee Sedol ?
La question que ça amène à me poser est de savoir comment évoluera le travail de l’humain dans un tel domaine ?
Qu’en pensez-vous ?
1 « J'aime »
Disclaimer : je vends un outil de production d’applications automatisé : voici ce que j’ai pu retenir de ma veille concurrentielle, de mes ventes, et de ce que je constate dans tant d’équipes/entreprises.
“Tout système dure plus longtemps que prévu, mais chute plus rapidement que prévu”.
“L’industrie de l’informatique est la seule industrie qui est davantage soumise aux effets de mode… que l’industrie de la mode elle-même.” – Stallmann
Je pense que dans 10 ans on codera presque comme aujourd’hui (j’espère que je me trompe)
à moins d’une prise de conscience sur le manque d’industrialisation/rationalisation du secteur.
Sinon, les pratiques vont évoluer mais le fond restera pareil (et ce serait dommage).
Je recommande aux geeks de prendre le contrôle sur ce changement, au lieu de rester satisfaits de peu (si si), sinon il sera imposé par d’autres qui auront, eux, de vraies exigences business.
Et aux patrons/managers d’anticiper ce changement, sinon il sera imposé par la concurrence.
Les gens n’aiment pas changer
Regardez comment le choix d’outils est une guerre incessante, et comment changer une “best practice” est dur… mais, rarement, l’une “gagne” (comme Docker) et l’adoption est fulgurante.
Les geeks font semblant d’aimer l’innovation mais résistent presque plus fort que tous les autres parce qu’ils arrivent à expliquer en détail leurs choix irrationnels de départ, avec culture, détails, jargon et dialectique.
Plus jeune, je trouvais horrible qu’un manager ignore un détail. Maintenant je comprends que les devs seniors parlent avec des mots et images simples, et la technique n’est pas un problème, faudra toujours arrondir les angles et ils sauront faire.
C’est cette mentalité et ces gens qu’on cherche tous.
Les idées sont déjà là depuis longtemps
Les langages fonctionnels (Lisp), concurrents (Erlang), les outils de dev (SmallTalk IDE, HyperCard) sont là depuis longtemps, pourtant on code toujours avec des vieux trucs et, essentiellement, des fichiers texte.
Vous vous rappelez de la vidéo LightTable ? Tout le monde s’est excité mais finalement on a eu Atom et pas grand-chose d’autre.
Et en plus on aime, au gré des modes, aller et venir : gros serveur, puis client lourd, puis ASP/ SaaS, puis retour aux apps, puis Cloud/Serverless, puis… bref on aime bien faire deux pas en arrière tous les trois pas en avant.
Je ne dis pas qu’il y a une “bonne direction” : je dis qu’on met tous nos oeufs dans le même panier à chaque fois, au lieu de spécialiser et regarder ce qui serait bon pour chaque projet. Auquel cas on aurait plusieurs branches très avancées avec chacune des manières de faire super différentes (pensez web vs embarqué, ops vs jeu vidéo) et notre métier mériterait enfin le mot “ingénierie”.
Le dev n’est ni standard ni organisé ni responsable
C’est plutôt de l’artisanat (c’est bien, encore faudrait-il que l’apprentissage et la transmission marchent !) mais rien de proche des autres corps de métier comme la médecine ou le génie civil : une “guilde” met un code d’éthique et déontologie, des principes encadrent la pratique du métier, quand des gens meurent ou mentent il y a des conséquences.
On peut radier un médecin, ou l’ingé d’un pont qui s’écroule, mais aucune conséquence pour les devs de Volkswagen : c’est à ce moment-là qu’il y a eu des posts de blog qui parlaient bien du sujet.
Je ne réclame pas des lois idiotes à corps et à cris (sur la vie privée et la sécu peut-être), mais une culture de la qualité, de la responsabilité et une ouverture aux conséquences de notre job qui pour beaucoup fait encore défaut.
J’en croise trop qui pensent mériter un gros salaire, sans savoir ce qui le paie et comment.
Mais surtout, on fait tout au doigt mouillé
Soi disant on a des tests et de l’intégration continue, OK.
Mais qui fait de vraies données dessus ? Qui dit “voici l’endroit du code d’où viennent un max de bugs, concentrons-nous dessus”, ou “voici les causes majeures de bugs en terme d’archi, de syntaxe, etc”. Le tout avec un vrai traitement “scientifique” ?
Parfois une étude sort, elle nous excite et nous fait rire, mais finalement on ne change pas nos manières de faire. Dans votre team, vous allez dire “attention à ce bout de code” entre geeks ou “attention à ces features-là” au métier. Mais rien de systématique chez les devs (à part Science de GitHub pour faire tourner deux versions et comparer résultats et perf) : on est très loin de ce que font certains devops ou SRE pour monitorer / analyser leur plateforme par exemple.
Le métier de dev est encore trop peu considéré
Je dis pas ça pour nous rajouter de l’ego : on a déjà trop facilement des attitudes de divas et d’autruches, ce qui d’ailleurs ne nous aide pas à passer pour des gens sérieux, adultes et responsables vis à vis des autres métiers.
Mais peu de gens/métiers savent bosser efficacement avec un dev. Avocats, médecins, experts en astrophysique : on ne les dérange pas souvent, mais quand on les veut on les paie et on les écoute. Et on les a laissés se former super longtemps avant, et continuer d’investir dans un apprentissage permanent.
Le vieux lion, la matriarche des éléphants, on les respecte, on les admire, et on leur demande de sauver le troupeau… et on leur en donne les moyens.
Mais il y a de l’espoir !
L’état de l’art est déjà bon. Il progresse lentement et à force de tout réinventer on a plein de gens qui ont de bonnes idées et techniques sous le bras.
Toutes ces choses-là, un jour, vont se cristalliser dans une poignée d’approches remarquables, dont certaines sont déjà mentionnées plus haut dans la discussion : IA pour ci (tests/debug), système expert pour ça (analyse de code, lister des cas), features de ou encouragées par les langages (typage encore plus malin, immutabilité).
Je ne sais pas si ces choses-là vont décoller tout de suite (je crains que non) ou si elles vont exister pendant dix, vingt… soixante ans avant qu’on s’y intéresse (LISP, “découvert” en 1958 !) ? L’histoire (qui est un éternel recommencement) dit qu’à part un cygne noir (événement rare et imprévisible) tous les dix à cinquante ans, c’est surtout le second sort qui attend la plupart des idées et pratiques.
Ite missa est
Je vous laisse réfléchir (et agir ? ce serait bien !) là-dessus, et corriger/améliorer aussi bien sûr parce que personne n’a la science infuse et que l’amélioration globale de notre champ ne se fera qu’avec des efforts concertés.
Acceptons nos responsabilités, soyons aussi sérieux et professionnels qu’on prétend l’être, et on sera considérés comme tels, puis on nous donnera davantage de responsabilités.
Bon courage et bonnes vacances :D
3 « J'aime »