Discussion :

[Patrick Ruiz]

La programmation peut-elle être automatisée ?
Une analyse du créateur du langage de programmation Leaf

Les progrès de la robotique et de l’IA mettent chaque jour un peu plus en danger certains postes de responsabilités réservés aux hommes dans les entreprises. Tout récemment au Japon, 34 employés d’une compagnie d’assurance perdaient leur travail au profit de l’IA Watson d’IBM, preuve que la robotique et l’IA commencent à remplacer les humains. Du côté du Royaume-Uni, il est anticipé que 30 % des emplois seront automatisés d’ici à 2030 ; on parle ici d’emplois dans des secteurs comme l’industrie manufacturière, le commerce, la finance et les assurances, etc., mais il est rarement fait mention de la programmation. Cela veut-il dire que la programmation serait exemptée de la menace que constituent la robotique et l’IA ? C’est à cette question qu’a essayé de répondre Edaqa Mortoray, le créateur du langage de programmation Leaf, et un développeur Fuse.

Automatisation et robots

Edaqa Mortoray débute par une virgule dans l’industrie manufacturière pour en extraire une définition de la notion d’automatisation, celle bien connue qui stipule qu’il s’agit du processus qui consiste à faire passer une matière d’un état A (matière brute) à un état B (produit fini), ce, en se servant de machines. Le parallèle avec l’univers de la programmation lui permet ensuite d’identifier le produit fini à un exécutable à faire tourner sur une plateforme donnée, la matière brute au code source, et la machine à un compilateur, puisque c’est celui-ci qui est chargé d’opérer la transformation. Pour rester en phase avec ses développements, nous avons jeté un œil à l’utilisation du célèbre compilateur gcc (cf. figure ci-dessous).

Une unique utilisation de la commande gcc –o hello.exe hello.c permet tour à tour d’intégrer le texte des fichiers d’entête au code source (Preprocessing), de compiler le fichier obtenu, de l’assembler, puis de le lier à des bibliothèques pour obtenir un exécutable. Quatre étapes pour lesquelles l’intervention humaine n’a pas été nécessaire, et dont la répétition deviendrait vite fastidieuse pour un opérateur humain.

C’est là tout l’intérêt, d’après le créateur du langage de programmation Leaf, de disposer d’une machine (le compilateur) qui se chargera, chaque fois qu’il sera nécessaire, de passer ces étapes en revue pour fournir automatiquement un exécutable, vous évitant au passage beaucoup de travail. Dans l’industrie manufacturière, on voit généralement des robots effectuer des tâches de nature répétitive à longueur de journée ; le parallèle à l’univers de la programmation permet donc de percevoir le compilateur comme un robot dans cette analyse.

Limites des robots actuels

D’après Edaqa Mortoray, même si le compilateur précédent ôte déjà à l’humain beaucoup de sa charge de travail, l’idéal serait qu’il soit capable de faire plus, c’est-à-dire produire lui-même le code source dont il a besoin pour générer un exécutable. Il faudrait pour cela qu’il soit selon lui doté d’aptitudes cognitives suffisantes pour réceptionner les spécifications techniques d’un projet, les transformer en code source pour en faire un ou des exécutables, toutes choses qui vont bien au-delà des performances de la meilleure des IA disponibles actuellement sur le marché selon lui.

Effectuer des tâches à caractère répétitif, voilà selon Edaqa Mortoray le rôle qu’est censé jouer un robot dans la programmation, rôle qui ne s’écarte finalement pas de celui qu’on lui attribue généralement dans l’industrie manufacturière. De ce point de vue donc, beaucoup de tâches de programmation ont déjà été automatisées et devraient continuer de l’être dans des domaines qui requièrent que l’on dispose de machines capables de rechercher, de comparer, etc., ce, sans arrêt. Il entrevoit l’utilisation de ces robots pour des applications comme les analyseurs de code statique ou autres outils de refactoring qu’ils serviraient à rendre plus performants, mais s’inscrit en faux contre la possibilité de les voir remplacer l’humain dans ce rôle de programmeur, du moins, dans un futur proche.

Sources : Blog Edaqa Mortoray, NTU

Et vous ?

Que pensez-vous ?

Partagez-vous cet avis ?

Voir aussi :

L'automatisation des tâches ou l'automatisation des emplois ? les robots vont-ils bientôt commencer à mettre l'homme au chômage ?

Un développeur est licencié après avoir automatisé ses tâches de programmation pendant six ans, il découvre qu'il ne sait plus écrire un bon programme

Une entreprise chinoise remplace 90 % des employés d'une usine par des robots, et voit sa production augmenter de 250 %

[Shepard]

(http://www.commitstrip.com/en/2016/0...-precise-spec/)

[Mimoza]

Le même en V.O. :

[Ryu2000]

Que pensez-vous ?

Il existe beaucoup de métier plus facilement automatisable que les professions de l'ensemble "programmation".
Qu'on commence par automatiser les banquiers, les traders, les assureurs, etc.. (il faut commencer petit)

Partagez-vous cet avis ?

On ne connait pas les limites de la technologie.
Si on parlaient de la technologie actuel à une personne de 1980 il aurait peut être du mal à nous croire (on se balade avec un petit appareil tactile, équipé de 2 caméras, un micro, un GPS, connecté à un réseau mondial, si ça se trouve les smartphones d'aujourd'hui sont plus performant qu'un super calculateur des années 80).

C'est possible qu'un jour en exprimant un besoin, un programme va créer un programme pour répondre à ce besoin.
Le problème c'est qu'aucun client n'arrive à exprimer un besoin correctement, donc ça ne sert à rien...

[r.morel]

C'est possible qu'un jour en exprimant un besoin, un programme va créer un programme pour répondre à ce besoin.
Le problème c'est qu'aucun client n'arrive à exprimer un besoin correctement, donc ça ne sert à rien...

C'est exactement çà ! Mais tout le monde croit que c'est simple.
Le pire est que c'est universel...

[Aiekick]

c'est un plaisir de programmer. donc pourquoi laisser a un robot ce qui me plait..

[Shepard]

Rien ne t'empêchera de continuer à programmer pour le plaisir, mais l'industrie se passera de tes services à ce niveau là ...

Je pense que tôt ou tard la programmation se fera sur base de diagrammes UML (ou autre similaire) et non plus de code, ce sera juste une autre forme de programmation ...

[paidge]

[Ryu2000]

c'est un plaisir de programmer. donc pourquoi laisser a un robot ce qui me plait..

C'est pas le développeur qui va demander "S'il vous plait, remplacez mon job par une intelligence artificielle, merci.".
C'est les patrons qui se disent "une intelligence artificielle nous coûterait moins cher qu'un développeur".

Ça me rappel le professeur Farnsworth dans Futurama :

The First Robot Capable of Qualifying for a Boat Loan

Peut être qu'il serait plus facile de programmer un commercial...

[NSKis]

Cette histoire me rappèle une entreprise qui a décidé de faire des économies sur son informatique: Elle a licencié son équipe de développeurs et a sous-traité leur travail à une société de développement informatique en Ukraine.

Au final, la société en question a dû engager des mecs à l'interne pour "pondre" les spécifications décrivant le travail à faire réaliser par les ukrainiens. Pas des spécifications décrivant en gros les fonctionnalités désirées mais fournissant une description détaillée permettant de découper le projet en une multitude de mini-développements "faciles" à tester et à vérifier.

Résultat???

Bingo!!! Au final, la société s'est retrouvée avec plus de "spécificateurs" que précédemment de développeurs et a juste perdu son indépendance et ses compétences

[pierre-y]

On devrait plutôt s'inquiéter quand une I.A. va se mater la série des films terminator et se prendre soudain d'une folle passion pour l’électronique et la soudure^^.

[MaximeCh]

On est d'accord que le débat sur la sous-traitance existe en développement comme dans bien d'autres domaines et est légitime. Mais là on parle automatisation en général

Il reste encore du chemin à "l'IA" pour pouvoir digérer des spécifications et programmer toute seule, mais la modification du code-source par les programmes existe déjà. En VBA avec VBE (huehue), dans des languages plus pros avec le refactoring automatique de code.

De ce que j'ai compris de l'état actuel de l'IA, le pallier à franchir et maîtriser est celui de l'apprentissage non supervisé. Aujourd'hui ce que le machine learning fait c'est de l'apprentissage supervisé en digérant des quantités d'exemples faramineuses, plus difficile à faire pour du code que pour d'autres types de données je pense (images, capteurs en tout genres...), quoiqu'avec github et autres...
Mais une fois le pallier "non-supervisé" franchi, voire peut-être celui du sens-commun je ne connais pas vraiment la différence, j'imagine les machines programmant en assembleur en VHDL, en binaire directement, et utilisant les languages naturels ou nos languages informatiques de 3-4ème génération simplement pour expliquer aux humains oO

Une autre prose moyenne sur le sujet https://www.quora.com/Is-it-possible...at-can-program

[koyosama]

Le fait de rendre le travail moins cher, c'est que recherche toutes les societes. Il faut encore des annees pour arriver a ce point.
Qaund tu regardes comment on code aujourd'hui c'est assez generique.

Quand tu regardes comment l'AI a battu les joueurs de go. C'est plus de memorisation et de l'optimisation de la recherche d'informations.

Le truc est que pour avoir une AI, on doit avoir un supercalateur. J'ai deja du mal a faire marcher mon serveur web a pleine puissance, alors AI on va oublier.
En fait la machine sera incapable de faire de la creativite, si c'est le cas alors l'humanite est condamne. Les outils de web design comme dreamwaver, les plugin d'adobe, sketch, les generateur d'animation vers javascript font exactement le remplacement du developeur. C'est pas optimiser mais sa peut marcher.

Excel est execetement de ce qu'on recherche dans l'utilisation du futur. Il ne faut pas un genie des math pour faire de la finance. Et les outils de deisgn c'est pareil, il ne faut pas etre un genie en informatique pour faire un jeu videos par example.
On trouvera toujours de l'informatique, mais on voit les outils comme wordpress, wix, .... qui permet a des non developeur de creer des applications.

Demain on va devoir fournir du travail a des personnes non qualifies, et ces outils sont un moyen de le faire. Donc les developements classiques vont disparaitre pour laisser place a l'ouvirer 2.0.

Ce qui est marrant plus le temps passe et plus il y a de bibliotheque front-end car on est pas arrive au point de la standarisation. Les ouvriers font le meme geste tous les jours, ce qui fait que c'est automtisable. Certain tache sont impossible automatiser car la machine est trop brusques et les elements trop difficile a bouger. Prenons par exemple le turc mecanique d'amazon, Recopie des une lettre de medecin est impossible pour les machines parce que chaque medecin ont leur propre eciture.

Tant que c'est pas standarise, le developpeur ne sera jamais remplace et on est loin encore ou les langages informatiques, les frameworks seront fixes et non evolutifs.

DONC NON, le developpeur ne sera jamais remplacer.

[Ryu2000]

Le fait de rendre le travail moins cher, c'est que recherche toutes les societes.

Moi je trouve qu'il faudrait punir les entreprises qui sous traitent dans des pays moins chère, qui délocalisent leur usines dans des pays pauvres, qui utilisent trop de robots.
Elles n'ont pas besoin de faire autant de profits.
Elles n'ont pas besoin d'augmenter leur marges.
L'argent est une drogue dur, plus un patron en prend, plus il en veut.

DONC NON, le developpeur ne sera jamais remplacer.

On sait pas, si des dizaines de milliards de $ sont investi chaque année pendant des décennies, c'est possible.
La technologie avance.
Aujourd'hui on a Google Maps, c'est quand même super impressionnant, Google Earth également.
Si en 1940 on avait dit à un type que quelques décennies plus tard il y aurait des tas de satellite artificielle lancé par l'homme dans l'espace, il aurait peut être été un peu sceptique.

L’intelligence artificielle est très à la mode en ce moment, ça va peut être évoluer vite.
Il y a aussi des sujets comme la connaissance. (savoir + d'autres trucs)

[Iradrille]

Optimisation et debug peuvent être automatisé relativement simplement, à condition d'avoir un jeu de test suffisant.

L'écriture complète d'un programme, on y est pas encore et ça sous-entend d'avoir des specs (très précise) à donner à l'IA. Specs qu'on a généralement pas.

[el_slapper]

Et je vais encore ressortir les trois essais de Jack Reeves sur le sujet, particulièrement cet extrait de la lettre à l'éditeur :

I know all the arguments for "language independent" software design notations. They all ignore a fundamental problem. Software design involves translating concepts from some problem space into a programming language. This translation has to be done by human beings, and since our programming languages are usually totally inadequate to express the concepts of the problem space directly, it is usually a difficult and error prone process. When we translate concepts from one form to another, especially complex ones, we often loose important information. If several translations are involved, we are likely to end up with a final product that lost too much vital information, that does not accurately reflect our original concept, and/or that simply contains errors. This is compounded several times when the people actually doing the translation are different for each step. Remember, there is nothing sacred about C++ (or Ada, or C, or Smalltalk, or LISP, or any programming language). It is not the native language of our computers. Fundamentally, programming languages are just a design notation themselves. I do not see any point in introducing extra translation steps if they can be avoided.

Les langages cités font terriblement vieux jeu(à part les intuables C/C++), mais le fond est resté le même, en 25 ans. Et il reprend, abordé sous un angle radicalement différent, le thème abordé dans l'excellent Commit Strip : un code, c'est une série de décisions, complète, sans ambiguïté, compréhensible par la machine. Le jour ou l'IA sera capable de définir elle-même ce genre de décisions, effectivement, on aura plus besoin de programmeurs. Mais on aura d'autres problèmes plus graves, je crois.

[NSKis]

On est d'accord que le débat sur la sous-traitance existe en développement comme dans bien d'autres domaines et est légitime. Mais là on parle automatisation en général

Et bien vous avez tord parce que "sous-traitance" et "automation de la programmation" ont très exactement les mêmes conséquences au sein de l'entreprise

Pour pouvoir automatiser la programmation, il va falloir comme dans le cas de la sous-traitance des milliers d'heures de spécification supplémentaires... Ce qui aura pour conséquence que l'entreprise ne gagnera rien à remplacer les développeurs humains par une "IA programmeuse": Les développeurs seront virés et ils seront remplacés par 2 fois plus de mecs devant définir ce que l'IA doit programmer et encore plus de mecs pour tester et intégrer le code automatisé

[leroivi]

Je pense que l'automatisation va atteindre notre métier également, mais je la trouve assez mal exprimée ici, pour moi bien avant l'intelligence capable de générer du code à partir de spécification, je pense que l'évolution des EDI et la sortie de langage de plus en plus haut niveau rendrons Mr Toutlemonde de faire son code lui-même de façon intuitive (sans passer par des phases d'apprentissage du langage ou de prise en main de l'EDI), de le tester et de le déployer comme si de rien n'était. L'IA convertissant une expression naturelle des specs en code viendra forcément après ces étapes (car il s'agit en fait du compilateur) mais le métier de développeur sera déjà mort à ce moment là (enfin, extrêmement réduit, il y aura toujours de la maintenance d'ancien système, et quelques applications où on souhaite rester sur du langage bas niveau)

[bilgetz]

Je pense que tôt ou tard la programmation se fera sur base de diagrammes UML (ou autre similaire) et non plus de code, ce sera juste une autre forme de programmation ...

Je me rappelle que Rational Rose faisait déjà de la conversion UML -> code quand j’étais en BTS, ce qui remonte à loin ...
Ça ne fait pas tous, il y a toujours des parties technique intranscriptible en UML.

[CodeurPlusPlus]

La pensée magique a encore de beaux jours devant elle.