De la programmation comme activité d'écriture
Writing a Letter 1904–1910 – Herbert G. Ponting (British, 1870 – 1935) — https://www.getty.edu/art/collection/object/1043VF
Il y a quelque chose que je pense fondamental dans mon activité de programmation (quand j'ai le temps, ce qui est de moins en moins le cas, mais j'aime toujours autant ça) : quand on est lancé, on se sent porté par quelque chose qui n'est pas vraiment conscient, une espèce de flot de pensées qui s'enchaînent toutes seules, et d'une certaine manière le programme s'écrit tout seul aussi. On ne voit pas passer le temps. Au début, bien sûr, quand on maîtrise mal un langage de programmation, on doit “traduire” un besoin qu'on se formule en langage plus ou moins naturel dans la tête, en utilisation correcte des constructions disponibles dans le dit langage. Parfois on pense encore dans un autre langage de programmation, et on a tendance à essayer de “traduire” de l'un dans l'autre, ce qui n'est pas très efficace, et conduit souvent à mal utiliser les concepts du nouveau langage à apprendre. Par exemple pour passer d'un langage fonctionnel à un langage objet, il faut accepter de penser différemment. Au début on s'interrompt pour lire la doc, regarder des exemples, etc., et c'est un peu laborieux. Mais ensuite c'est comme avec une langue étrangère qu'on parle bien : on pense directement dans cette langue, on ne traduit pas. Dans l'apprentissage d'un nouveau langage de programmation, le moment où l'on réalise qu'on pense directement avec les concepts de ce langage, c'est très gratifiant.
En lisant récemment l'article Can you translate a book with DeepL? d'une traductrice professionnelle, je suis tombée sur un paragraphe qui colle exactement à la notion de flot de pensées ci-dessus : “Authors know the feeling, when they’re writing their book and the rest of the world seems to fall away: they’re in a rhythm where their full concentration is focused on one task. They can see the action and plot of their story in front of them, and the words seem to type themselves into the computer.”. Par ailleurs je comprends cet article comme expliquant que l'activité de traduction n'est pas une activité mécanique de passage d'une forme à une autre. On lit et on digère le texte original, et en quelque sorte on le “repense” dans la langue d'arrivée. Traduire (bien), c'est écrire. Et pour écrire bien, il faut être dans ce flot de pensées décrit dans la citation. L'autrice décrit l'activité de traduction qui s'appuie sur un premier jet produit automatiquement par DeepL comme pénible, parce qu'elle empêche d'atteindre cet état de “flot de pensées” où le texte s'écrit tout seul. C'est perdre ce flot qui rend l'activité pénible, qu'on y “gagne” du temps ou pas. L'article est d'ailleurs intéressant aussi pour la mesure de temps nécessaire, qu'on utilise un outil comme DeepL ou pas. Et finalement la question qu'on peut se poser à la fin, c'est : entre 1h agréable et 45mn pénibles pour la même tâche, que choisiriez-vous ? Ou même pire (vues les conclusions de l'article sur les cas étudiés) : entre 1h agréable et 1h15 pénibles pour la même tâche, que choisiriez-vous ? La question est vite répondue, n'est-ce pas ?
En retombant encore une fois sur cet article de Edsger W.Dijkstra On the foolishness of “natural language programming”, je me suis rappelée les grandes discussions à l'époque où tout un domaine de recherche en informatique travaillait sur la “synthèse” de programme à partir de spécifications en langage plus ou moins naturel. A l'époque je me disais : soit le langage de spécification est suffisamment précis pour que la traduction n'ait pas le choix, et alors on appelle ça un langage de haut-niveau avec son compilateur ; soit le langage de spécification n'est pas assez précis, et alors il reste du travail humain pour aller vers du code, on ne peut pas faire de “synthèse” automatique. On s'amusait de la direction suivie, en se disant que le langage ultime serait réduit à une seule instruction “Do What I Mean”.
Edsger W. Dijkstra argumente ici pour dire que compter sur un outil automatique pour “traduire” en code une pensée en langage naturel est totalement illusoire. La pensée est essentiellement ambiguë (heureusement), alors que le code pas du tout, tout aussi heureusement.
Bref, en reliant ces deux articles et ce à quoi ça me fait penser, je me dis qu'utiliser une IA générative pour programmer, ça a précisément les 2 défauts : – ça s'apparente à traduire avec DeepL, c'est-à-dire que ça remplace un travail d'écriture gratifiant en soi par un travail d'inspecteur des travaux finis essentiellement pénible, et avec lequel on ne gagne même pas forcément de temps – c'est le dernier avatar du rêve de la programmation en langage naturel, qui ne tient pas debout. Au lieu de penser directement dans le langage d'arrivée, on pense dans un langage de départ, et en plus on laisse faire la traduction par des outils très imparfaits.