Discussion :

[lemacdupc33]

Bonjour

Quels sont les tendances d'avenir à long terme ( dans 30 ans ) de la programmation ?
Y aura t il des créations de nouveaux langages de programmation ? ou bien une révolution avec un langage universel ?
Merci de m'éclairer sur ce qui se dit dans le milieu des programmeurs.

Cdt

[DonQuiche]

Bonjour.

Il n'y a aucun consensus parmi les communautés PL (programming language - les communautés qui tournent autour de la création de langages et d'outils : Lambda The Ultimate, plusieurs personnes sur Reddit ou HackerNews). Mais peu de personnes dans ces communautés soutiendront que l'on continuera à utiliser les mêmes langages (ils existeront toujours mais essentiellement pour maintenir de vieilles applis). Il y a toutefois un consensus pour dire que la recherche sur le sujet est aujourd'hui stagnante, même si certains s'attendent à ce que ce soit le calme avant la tempête.

Pour l'heure les grands axes de développement sont les problèmes de vérifiabilité (preuve par les types - Rust, dependent types, etc -, analyse statique plus efficace, banalisée, systématisée, ...) et de concurrence (modèles vérifiables, mémoire transactionnelle, calcul hétérogène, etc). On pourrait aussi citer l'hygiène (Go), la facilité (besoin de recruter de plus en plus de personnel de moins en moins compétents et qualifiés), les systèmes réactifs (Rx, Sean McDirmid) et le débogage (possibilité de rebrousser le temps et de connaître la série d'actions qui a débouché sur une valeur présente).

Pour ma part je suis convaincu qu'à l'avenir le langage naturel dominera très largement la programmation, et je m'attends à ce que d'ici quelques années seulement il soit possible de réaliser vocalement des programmes rudimentaires ("Cortana/Siri/Google, quand je clique sur ce bouton, affiche tous les clients dont le pays est indiqué ici dans la liste là") et qu'une partie significative du code puisse être générée à partir de spécifications. Mais le reste du chemin sera long, très long : il faudra notamment qu'à partir du résultat voulu le compilateur puisse déboucher sur un algorithme (constraint-based programming, example-based programming), ce qui est encore expérimental aujourd'hui et pour longtemps.

Enfin tous les progrès à venir vont demander beaucoup de puissance de calcul et j'imagine que les compilateurs migreront donc vers le nuage. Par ailleurs certains actes du développement logiciel ne relèveront plus de la programmation telle qu'on l'entend mais plutôt de tâches liées au traitement de données et à la création de réseaux neuraux. Les outils nécessaires seront sans doute spécialisés et très différents.

[lemacdupc33]

Bonjour et merci beaucoup pour votre longue analyse

Malheureusement si j'ai bien compris dans l'avenir une intelligence artificielle fera tout le boulot à notre place. C'est à dire : je pose le problème en français ou en anglais et le compilateur vas y répondre et afficher le code automatiquement.

Es ce bien cela ?

Merci de bien vouloir me répondre.

[DonQuiche]

Malheureusement si j'ai bien compris dans l'avenir une intelligence artificielle fera tout le boulot à notre place. C'est à dire : je pose le problème en français ou en anglais et le compilateur vas y répondre et afficher le code automatiquement.

Ces AI n'afficheront même pas de code, elles manipuleront directement des arbres sémantiques en interne, ne présentant que le résultat final créé depuis un texte décrivant les spécifications et assorti de diagrammes, ou des instructions vocales.

Quant à savoir si ces AI feront tout le boulot, tout dépend d'à quel point elles seront intelligentes. Pendant longtemps il faudra un développeur qui comprenne à un haut niveau le fonctionnement des machines et du matériel, capable de deviner les algorithmes générés par la machine, et capable d'imagination et d'une fine perception des organisations humaines. Ce sera une étape très intéressante pour nous car nous pourrons nous focaliser sur des problèmes architecturaux de haut niveau et laisser la basse plomberie de côté, pour produire en masse des logiciels de très haut niveau. Tout comme nous l'avons fait dans le passé : un programmeur contemporain ne se préoccupe plus des registres et instructions du CPU.

Puis les AI seront capables de créer de bout en bout un document depuis des spécifications. Mais rédiger de bonnes spécifications sera encore un savoir-faire humain : la plupart des clients ne savent pas ce dont ils ont besoin et il faut les aider à "accoucher", ce qui demande de la psychologie et de l'intuition et une compréhension du domaine du client, puis suggérer un bon design, faire preuve de créativité, de sensibilité. Et enfin les AI deviendront capables de faire tout ce qu'un humain pourra faire, y compris des interactions sociales fines. Il sera sans doute possible de lui passer commande d'un logiciel sans savoir exactement quels sont nos besoins et d'entrer dans un dialogue socialement complexe avec elle.

Cela dit ces évolutions seront observées dans tous les métiers. D'ici quelques décennies dessiner un bâtiment ne nécessitera sans doute aucune compétence technique, le diagnostic médical sera posé par une infirmière et il sera possible de produire un jeu vidéo sans avoir de compétences artistiques ou en programmation.

[lemacdupc33]

Merci de votre réponse

Quand vous parlez de haut niveau, entendez vous par la des diagrammes UML ?
Car actuellement on est pas capable de faire le moindre calcul avec ces diagrammes.
Par exemple je souhaite calculer une valeur approchée d'une intégrale par différentes méthodes avec des fonctions compliqués. Es ce que le compilateur sera capable, dans un avenir plus ou moins lointain, de la calculer si l'énoncé du problème est long et compliqué à expliquer ?
Merci bien de me guider

Cdt

[DonQuiche]

Quand vous parlez de haut niveau, entendez vous par la des diagrammes UML ?

UML n'est pas un outil de conception, ce n'est pas non plus une architecture. Juste un outil de communication.

Par ailleurs ce n'est qu'un outil de communication parmi d'autres : UML ne vise pas aujourd'hui à être exhaustif ou à se substituer au langage naturel dans la rédaction des spécifications. Il est complémentaire. Chaque diagramme est ciblé sur un besoin précis, un ensemble limité de concepts (séquence d'événements, arbre de décision, graphe d'objets, etc) qui ne constituent pas un ensemble exhaustif des concepts humains.

Enfin il y a plusieurs types de diagrammes UML. Certains sont orientés code (diagrammes de classe) et plutôt à destination des développeurs. Ils auront de moins en moins d'intérêt. D'autres sont orientés métier / cas d'utilisation et sont plutôt à destination du commanditaire et ses intermédiaires. Dans les seconds il est tout à fait possible d'avoir un noeud contenant un texte tel que "calculer le score de pertinence comme la somme du nombre de liens pointant vers cette page". A ce titre UML supporte donc les calculs via l'inclusion du langage naturel ou des équations, qui sont déjà parfaits pour les concepts mathématiques. Cela dit en général on renverra plutôt vers des définitions extérieures où seront détaillés les calculs - toujours via équations et langage naturel.

Quand vous parlez de haut niveau

Les problèmes de haut niveau qu'affronteront quotidiennement ces développeurs seront plutôt liés au parallélisme de masse, aux problèmes de transactions, de consistance, de tolérance de panne, de fiabilité, de logique floue, de réseaux neuraux, d'internationalisation, d'expérience utilisateur, d'ergonomie, de caches matériels, de latence réseau, de protocoles, de quelques algorithmes complexes, etc. Leur tâche sera d'imaginer des solutions techniques capables de satisfaire ces problèmes puis d'utiliser divers supports de communication (texte, diagrammes, équations, images, exemples, parfois même pseudo-code d'un algorithme particulier voire instructions asm si nécessaire, etc) pour rédiger des instructions suffisamment détaillées pour que le compilateur sache quel programme créer.

Par exemple je souhaite calculer une valeur approchée d'une intégrale par différentes méthodes avec des fonctions compliqués. Es ce que le compilateur sera capable, dans un avenir plus ou moins lointain, de la calculer si l'énoncé du problème est long et compliqué à expliquer ?

Matlab ou Mathematica en sont déjà capables.

Et il n'y a pas une grande différence entre le fait de découper un problème en plusieurs sous-variables/expressions/fonctions rentrées une à une dans Mathematica, et le fait de découper un problème en plusieurs définitions listées les unes à à la suite des autres dans un fichier texte, mêlant anglais et équations.

[lemacdupc33]

Bonjour merci c'est déjà plus cler

Mais avec un langage de haut niveau pourra t on également faire des choses simples ? Ou ne peut on faire que des choses compliquées : les choses simples étant déja résolues automatiquement ?

Merci de votre réponse.

Cdt

[AliusEquinox]

Et il n'y a pas une grande différence entre le fait de découper un problème en plusieurs sous-variables/expressions/fonctions rentrées une à une dans Mathematica, et le fait de découper un problème en plusieurs définitions listées les unes à à la suite des autres dans un fichier texte, mêlant anglais et équations.

Tiens ça me fait penser à du Prolog ça !

La vision énoncée est une bonne vision, une petite critique cependant : je la trouve un peu trop collée, si je puis dire, aux problèmes actuels. Bien qu'évidemment un grand nombre pour ne pas dire presque toutes les entreprises aujourd'hui ont un ou deux trains de retard en matière de technologie. Pour ma part, j’imagine un tout autre avenir des langages de programmation et je parle bien de langages de programmation et pas d'utilisation de ces langages. Il faut avant tout reconsidérer la chose dans son essence, à savoir qu'il s'agit ni plus ni moins de différents types d'outils plus ou moins "semblables". Le fait que ces langages se ressemblent s'explique très bien par le fait que nous évoluons dans une société fortement concurrentielle. Ce n'est pas étonnant que le même schéma se reflète sur les langages de programmation, puisque ce sont des outils qui permettent de travailler sur des machines et des systèmes "semblables". Des questions méritent d'être posées à ce sujet. Est-il vraiment nécessaire d'avoir plusieurs langages "semblabes" ? A vrai dire, dans le système actuel, OUI ! Si Steve Jobs avait bien comprit quelque chose, c'est bien ça : innoves ou crève ! Sauf que ceci ne durera qu'un temps. Si aujourd'hui on a l'impression que tout bouge à une vitesse phénoménale, c'est tout simplement que notre système social, économique... n'est pas stable. Mais il s'équilibrera avec le temps (je l'espère sincèrement). C'est pour cela que notre système change fondamentalement : On ne communique pas de la même manière aujourd'hui qu'il y a 10-20 ans. Un autre schéma s'installe. Si cela vous intéresse, je vous renvoies au livre Understanding Media de Marshall McLuhan, il me parait être une bonne piste de départ.

Alors pour revenir à cette "vision trop collée à la problématique actuelle", je penses que cet avenir que tu énonces renvoi à des problèmes qui se posent aujourd'hui et aujourd'hui seulement. Il faut bien se le dire, Internet est venue avec son lot de difficultés, il est donc naturel que les outils d'aujourd'hui s'y adaptent. Je parle donc bien des aspects techniques que tu as cités plus haut : concurrence, latence... Pour conclure, a termes je pense sincèrement qu'il n'existera plus que quelques langages de programmation, voir un seul langage. Ceci sera rendu possible par une adaptabilité, une fusion que sais-je des langages les uns avec les autres. A l'avenir, le plus important ce ne sera pas les langages (les outils), mais ce seront les données et surtout, la manière de les structurer.

[DonQuiche]

Tiens ça me fait penser à du Prolog ça !

La vision énoncée est une bonne vision, une petite critique cependant : je la trouve un peu trop collée, si je puis dire, aux problèmes actuels.

En fait je crois que nous nous sommes simplement mal compris.

Ce que je propose, ce n'est pas de forcer l'utilisateur-programmeur à utiliser des symboles abscons et des équations. Non, le langage naturel suffirait et pourrait être utilisé de la même façon que lorsque nous nous adressons à un être humain. En revanche si un utilisateur veut avoir recours à des symboles mathématiques pour exprimer certains points, le compilateur devrait aussi comprendre ce langage-là.

Alors pour revenir à cette "vision trop collée à la problématique actuelle", je penses que cet avenir que tu énonces renvoi à des problèmes qui se posent aujourd'hui et aujourd'hui seulement. Il faut bien se le dire, Internet est venue avec son lot de difficultés, il est donc naturel que les outils d'aujourd'hui s'y adaptent. Je parle donc bien des aspects techniques que tu as cités plus haut : concurrence, latence...

Je ne suis pas d'accord, ces aspects ne disparaîtront pas, pour deux raisons :

a) Nous n'aurons jamais suffisamment de puissance de calcul et des communications suffisamment rapides, et ces contraintes techniques influeront sur les choix du domaine métier. Par exemple tu peux choisir de réduire la latence en instaurant des sources de données redondantes à travers le monde (CDN). Si les employés du bureau attendent la photocopieuse (accès exclusif à une ressource partagée entraînant une contention) tu peux choisir d'en acheter une seconde. Sauf que tout cela a un coût. Ce sera souvent à un humain de prendre les décisions correspondantes.

b) Nombre de problèmes techniques sont en fait intrinsèquement des problèmes du domaine métier : si l'utilisateur a ajouté un article à son panier pendant que tu préparais la page de paiement, c'est à toi de décider quoi faire. Et comme l'asynchronisme marche toujours de pair avec des anomalies (pics de latence, pannes distantes, etc), on en vient à la robustesse : si le DAB ne parvient pas à contacter le serveur de ta banque, il peut soit t'afficher un message d'erreur ou bien te donner l'argent et vérifier plus tard. Cette décision relève du métier. Tout comme la décision de déclarer que les transactions bancaires doivent être atomiques : on ne débite pas Paul sans créditer Jacques.

En revanche tous ces aspects pourront bien sûr être ignorés par la majorité des programmes, tout comme aujourd'hui la majorité des applications peut ignorer le temps de calcul ou la consommation mémoire.

A l'avenir, le plus important ce ne sera pas les langages (les outils), mais ce seront les données et surtout, la manière de les structurer.

Les données doivent devenir plus centrales, mais les traitements sont une part intégrale du problème métier : fondamentalement, je veux que mon programme fasse X. X n'est pas un détail technique, c'est l'objectif même de l'utilisateur.

Les notions d'événement, de séquence de traitements, etc, sont aussi présents dans le domaine métier. Au mieux certains peuvent être inférés depuis un ensemble de règles avec une bonne dose de sens commun et de logique. Par exemple on pourrait dire qu'une partie de sport consiste en des données (les joueurs, le terrain), des règles (décidées par le plus gros pot-de-vin), et un programme (la stratégie décidée par l'entraîneur). De ces trois éléments un compilateur pourrait bâtir une partie de sport.