Journal De la rigueur dans la programmation

Sommaire

• Assembleur
• BASIC
• Perl
• Bash
• JavaScript
• Python
• C++
• Rust
• L'IA agentique

Le boulot des développeurs change constamment et pourtant l'histoire me semble se répéter. Dis-moi si toi aussi tu vois une constante émerger des outils qui suivent.

Assembleur

Connais-tu ce merveilleux langage qu'est l'assembleur ? C'est le premier langage de programmation. En assembleur il n'y a pas de type de donnée, ni même de code en fait. Tout n'est qu'octet, et encore si l'architecture utilise des octets.

L'assembleur c'est pénible. On ne comprend rien, toute l'information est dupliquée dans des commentaires et le pauvre qui doit déboguer tout ça se retrouve avec deux tâches : comprendre ce qu'expliquent les commentaires et voir si le code correspond. De quoi s'arracher les cheveux.

Bien sûr le fait qu'il soit spécifique à une architecture ainsi qu'infernal à écrire et à lire n'empêche pas de faire de grandes choses en assembleur. Après tout c'est le langage à l'origine de tous les logiciels, et même aujourd'hui on l'utilise encore pour tirer de meilleures performances du matériel, comparé à ce que le compilateur aurait généré. Cependant les développeurs expérimentés lui préféreront un langage de plus haut niveau.

BASIC

Connais-tu les options Strict et Explicit de ce merveilleux langage qu'est Visual Basic ?

Le BASIC est un langage de programmation pour débutant. Il abstrait beaucoup de choses de la machine et permet à n'importe quel ignorant d'écrire un programme, ce qui est une bonne chose. Comme il se veut facile d'accès il est très laxe sur les déclarations de variables et le typage. Si un identifiant inconnu est utilisé dans une expression, pouf ! ça devient une variable et le compilateur devine son type.

Bien sûr le fait qu'il soit destiné à des débutants n'empêche pas la création de grands programmes dans ce langage. Des programmes écrits dans un cadre PROfessionnel (insister sur le « pro ») par des vrais PROs (idem) qui font du business (à nouveau), pas de misérables amateurs (prendre un ton dégradant). Malheureusement ce laxisme n'est pas gratuit et à force d'empiler des trucs approximatifs qui ont l'air de marcher on fini avec un tout qui s'écroule.

C'est à ce moment que le dev perd ses cheveux à essayer de comprendre ce qu'il se passe dans ce programme, traquant les variables et les types comme s'il était le compilateur. Mais on ne pourrait déclarer ça une bonne fois pour toute et demander au compilateur de valider ça ? Se demande-t-il. Oui on le peut en Visual Basic, grâce aux options Strict et Explicit. Deux options qui vont demander un peu plus de rigueur au dev et permettre d'économiser des heures de problèmes en maintenance.

Perl

Connais-tu les options use strict et use warnings de ce merveilleux langage qu'est Perl ?

Perl est un langage de script qui, comme beaucoup d'autres dans son genre, est très laxiste. Contrairement au BASIC il n'est pas facile d'accès. Il se réclame d'une syntaxe concise, donc cryptique, et ne voit pas d'inconvénient à laisser des pièges béants pour le développeur :

It looks like a function, therefore it is a function, and precedence doesn't matter. Otherwise it's a list operator or unary operator, and precedence does matter.

There is no rule that relates the behavior of an expression in list context to its behavior in scalar context, or vice versa. It might do two totally different things.

Tu ne vas sans doute pas me croire mais même un langage aussi approximatif a ses adeptes.

Comme pour le BASIC et nombre de langages de script, Perl va vous laisser utiliser des variables sorties de nulle part et additionner des pommes avec des bananes. Comme pour le BASIC celui qui devra déboguer cela est bon pour une calvitie précoce. C'est pourquoi un développeur Perl expérimenté n'hésitera pas à commencer ses scripts avec use strict et use warnings pour se libérer des problèmes les plus élémentaires tels qu'une typo dans l'utilisation d'une variable causant la création silencieuse d'une nouvelle variable.

Bash

Connais-tu les options -e -u -o pipefail de ce merveilleux langage qu'est Bash ?

Bash est un interpréteur de lignes de commande de type script. C'est un langage de programmation qui fait très bien ce qu'il doit faire même si on se demande si on a bien fait de lui demander.

Comme nombre d'outils dans son genre Bash est terriblement laxiste et va volontiers exécuter n'importe quoi, remplacer des variables inconnues par rien, et continuer à s'exécuter alors même que tout finit en erreur tandis que l'utilisateur bourrine ctrl+C dans une tentative désespérée de réduire la casse.

Le développeur Bash expérimenté (existe-t-il quelqu'un qui se revendique « développeur Bash » ?) tentera de contrôler ces problèmes en commençant ses scripts par un set -euo pipefail, trois options signifiant respectivement qu'il faut s'arrêter à la première erreur (-e), interdire le remplacement de variables sans valeur (-u) et considérer une erreur dans un pipe comme une erreur (-o pipefail).

Sans doute penses-tu que ce mode strict de Bash reste bien fragile, et tu as bien raison. Programmer en Bash est aussi rassurant que de jongler avec des tronçonneuses enflammées en marche. Cela n'empêche pas de construire de gros programmes dans ce langage, ni même de l'utiliser comme méthode d'installation d'un programme à coup de curl -s https://random-script-from-the-web.sh | sh.

JavaScript

Connais-tu l'instruction "use strict" (avec les guillemets) de ce merveilleux langage qu'est JavaScript ?

[[JavaScript] est un langage de script destiné à être utilisé dans les navigateurs web. On peut par exemple s'en servir pour afficher une traînée d'étincelles qui suivent le curseur. C'est un langage extrêmement laxiste et proposant un très faible coût d'entrée. Si tu as un navigateur web tu as un environnement de développement JavaScript.

Sa facilité d'accès a permis à bon nombre d'entre nous d'accéder au monde de la programmation peut-être même sans le savoir. Comme Bash, Perl et BASIC avant lui, JavaScript a opté pour la facilité d'accès en permettant la création de variables silencieusement à la volée dès lors qu'un nouvel identifiant apparaît. Comme pour Bash, Perl et BASIC, les développeurs en ont eu ras-le-bol de chercher des bugs liés à des typos dans les noms de variables. C'est pourquoi ECMAScript 5 a introduit le mode strict, optionnel bien sûr.

On retiendra cette description sur le site w3schools :

Strict mode changes previously accepted "bad syntax" into real errors.

J'apprécie l'utilisation de guillemets autour de « bad syntax », comme si c'était subjectif. Qui t'es pour dire que la syntaxe est mauvaise ? C'est juste, genre, ton opinion mec.

Bien sûr le laxisme du langage n'empêche pas de construire de grandes choses. Longtemps réputé pour sa lenteur, la situation s'est grandement amélioré dans les années 2010 quand l'industrie s'est mise à tout faire en JavaScript. De gros efforts ont ainsi été faits sur les machines virtuelles JavaScript pour passer de performances terriblement mauvaises à des performances sacrément décevantes.

Qu'à cela ne tienne, ce n'est pas parce que le langage est bancal et inefficace qu'il ne faut pas l'utiliser ! Tel l'élève médiocre pointant le cancre du doigt, l'industrie s'est dit que ça va, ça pourrait être pire, et a continué d'investir le gros de ses ressources dans cette voix. C'est pourquoi nous sommes passés d'étincelles derrière le curseur à des applications web puis à des applications desktop qui embarquent un navigateur entier, ainsi qu'à des applications serveur. Ce langage adresse tous les systèmes de manière égale. À moins que ce soit égal-égal ? Ou égal-égal-égal ?

Python

Savais-tu qu'il n'y avait pas de mode strict dans ce merveilleux langage qu'est Python ?

Python est un langage de programmation interprété initialement développé pour l'enseignement de la programmation aux débutants. Il se veut facile d'accès et a le bon goût d'insister sur la lisibilité du code notamment en revendiquant une seule façon de faire chaque chose.

Python est beaucoup plus strict que les langages cités précédemment, pas d'addition de pommes avec des bananes ici. Cependant, bien qu'il applique un typage fort, il pratique aussi le typage dynamique, c'est à dire qu'il déduit le type des données lorsqu'elles sont utilisées ce qui procure une certaine souplesse. En particulier, Python est certainement le plus populaire des langages pratiquant le Duck typing.

Bien sûr cette souplesse n'empêche pas de construire de grandes choses, et à force d'empiler des trucs qui ont l'air de marcher on se retrouve à déboguer des exceptions et d'autres trucs obscurs parce que quelque part quelque chose a été appelé avec une donnée d'un mauvais type. Par exemple, savais-tu que Python te laissera écrire un appel à une fonction en lui passant un nombre incorrect de paramètres ? Tant que l'exécution ne passe pas par cet appel, tout va bien, mais dès lors qu'on passe par cet appel, paf ! C'est la fin.

J'ai longtemps trouvé que l'ambiance au sein de la communauté Python s'apparentait à une secte, une sorte un culte qui se veut au-dessus du reste et qui peine à envisager d'être dans l'erreur malgré les critiques. Par exemple, il était pendant longtemps hors de question de typer les données. Trop restrictif. Heureusement la situation semble s'être améliorée et on a vu apparaître des choses comme PEP 484 pour introduire un peu de rigueur de typage.

C++

Connais-tu le C++ ? C'est un langage compilé, fortement et statiquement typé. Ça sent la rigueur non ?

Le langage C++ a été créé il y a plus de 40 ans par un chercheur en informatique qui s'est dit un jour que ça serait cool d'avoir une sorte de langage C mais orienté objet. Il a posé une syntaxe ambiguë et pour une raison que j'ignore l'industrie a adopté son langage. Bien sûr le langage a évolué et s'est adapté aux époques tant et si bien qu'il est aujourd'hui connu pour permettre de faire chaque chose de dix façons différentes, toutes mauvaises.

Le langage est connu pour faciliter les problèmes de mémoire : fuites, accès hors bornes, il est très facile de créer ce genre de problème. Et comme il s'agit d'un langage pour créer des binaires natifs, ces problèmes de mémoire deviennent des problèmes de sécurité.

Pendant la conception de la version C++11 du langage, le commité définissant ses règles rencontre un problème pour typer les closures et introduit le type auto pour laisser le compilateur déduire le type. Dès lors, les programmeurs frustrés depuis toujours de devoir expliciter leurs intentions au compilateur s'engouffrent dans la brèche et décident de mettre auto partout, avec des raisonnements tels que : si on dit que auto veut dire let ou var alors ça ressemble à un langage moderne, hein ? Bah répondez, quoi !

Dans la foulée, des pontes du langage reconnus pour leur niveau technique poussent à leur tour pour mettre auto partout, avec des arguments en béton tels que : si je déclare toutes mes variables avec auto elles sont bien alignées dans mon éditeur. C'est joli hein ? Bah répondez, quoi !

Les versions suivantes du langage suivent la même tendance. On veut que le langage soit différent. Pas mieux. Différent. Si possible semblable à des langages plus récents mais pas trop pareil non plus. On introduit des concepts tels que les ranges parce que ça a l'air cool et ça permet d'alimenter les conférences de consultants expliquant à quel point rien ne marche comme on veut avec cet outil.

Plus récemment il est question de traiter les problèmes de sécurité liés au laxisme sur les accès mémoire. Il faut dire que l'aura de Rust, quelque part successeur du C++ et qui gère magistralement le problème, pèse sur ce vieux langage. Mais comme la tendance est à ne pas casser l'existant on est bien parti pour avoir une version safe du C++ qui ne fonctionne pas vraiment. Le C++ est malheureusement un langage qui souhaite évoluer dans un espace où il ne peut plus grandir.

Cela dit ce n'est pas parce que le langage est mal fichu, bancal, plein d'ambiguïtés, et spécifié par des gens qui codent à peine, qu'on ne peut pas créer de grandes choses avec. C'est pourquoi les développeurs C++ se retrouvent aujourd'hui à perdre leurs cheveux en déboguant du code où l'auteur initial a refusé de dire quels types de donnée sont manipulés. C'est générique man, ça peut être tout et n'importe quoi du moment que ça respecte les contraintes implicites de l'implémentation, c'est cool non ? Bon ça ne marche que pour des int mais c'est cool hein ? Bah répondez, quoi !

Rust

Connais-tu le langage Rust ? C'est un langage ciblant le même domaine que le C++, sans les problèmes.

Le langage Rust corrige quasiment tous les problèmes mémoire du C++. Vraiment, si on vient du C++ on voit dès les premières lignes que les créateurs de Rust ont bien compris le problème, et le borrow checker devient une bénédiction.

Cependant on sait à quel point les développeurs ne veulent pas s'engager sur le type des données. Tous les langages modernes laissent le compilateur déduire les types à partir des expressions. C'est tellement beau sur le plan conceptuel. Quand on dit qu'on laisse le compilateur déduire les types, ça veut aussi dire qu'on laisse le relecteur déduire les types. Le relecteur est-il aussi à l'aise que le compilo pour cela ? Ha ! Ha ! Certainement pas ! Tant pis pour lui !

Pendant trop longtemps la culture autour de ce langage était polluée par des adeptes dignes des plus grandes sectes de l'histoire, toujours prêts à partir en croisade et faire du zèle pour éclairer, éduquer, l'ignorant. Il me semble que la situation s'est grandement améliorée.

Rust n'a que 15 ans, c'est un ado. Et encore, la version 1.0 du langage n'en a que 10. On est très loin d'avoir du recul sur ce langage mais c'est de loin le plus prometteur de ces dernières années. Cela signifie en particulier qu'il n'y a pas de développeur expérimenté en Rust ! On peut donc s'attendre à ce que tous les devs de ce langage aient encore leurs cheveux (enfin ceux qu'ils n'ont pas perdus avec les langages précédents). Cependant, mon petit doigt me dit qu'ils ne vont pas rigoler longtemps quand il faudra déboguer du code où une variable est déclarée sans type et que celui-ci est déduit des dizaines de lignes plus bas via une expression obscure :) Bientôt un mode strict en Rust ?

L'IA agentique

Connais-tu l'IA agentique ? C'est une mode de développement consistant à concevoir des programmes en donnant des instructions à des IAs, puis à les laisser se débrouiller pour pondre un truc.

Un des gros soucis de tout éditeur logiciel est que le dev est lent (ça prend plus que zéro secondes) et cher (ça coûte plus que zéro euro). Comprends bien que pour faire des dollars aujourd'hui il faut être le premier sur le marché, et une fois que tu as le marché il faut réduire les coûts pour faire du bénef'. Encore récemment un des moyens d'adresser ces problèmes était de délocaliser. On prend quelques manageurs de nos pays riches et on leur fait superviser des devs d'un pays pauvre qui vont nous sortir du code pour pas cher.

Depuis peu on peut faire la même chose sans avoir à s'embêter à délocaliser ! Les outils d'IA sont excellents pour produire des choses. Pose une question à un chatbot, hop tu as une réponse exposée avec l'assurance d'un expert. Parfois même, la réponse est bonne. Ça fait quinze ans que tu t'éduques à coup de TL;DR et te voilà face à un document est un peu long ? Donne ça à une IA et elle te fera un résumé. Parfois même, il sera pertinent.

J'écris tout ça sur un ton sarcastique mais clairement les outils d'IA ont de très bons côtés, abstraction faite des aspects éthiques et écologiques. Cela m'a aidé à plusieurs reprises pour trouver des informations sourcées que j'étais bien incapable de trouver sur le web. De là à leur laisser les tâches cognitives cependant, faut pas exagérer non plus.

Comme tu l'auras déduit au long de ce post, nous les devs somes de gros fainéants. Nous ne voulons pas coder, nous ne voulons pas documenter, nous ne voulons pas expliciter nos intentions, et nous ne voulons pas déboguer. C'est pourquoi je ne suis pas surpris de voir des devs s'enjouer d'avoir leur délocalisation à eux. On donne les specs et les agents se débrouillent pour pondre un truc. Et là où c'est génial en termes de business c'est que c'est encore moins cher que le tiers monde. Auparavant il fallait superviser les devs à l'étranger avec un manageur en local, et payer tout le monde. Maintenant on paye pas cher pour avoir des agents IA, et le manageur est un dev, payé au prix d'un dev. Manageurs d'une armée de stagiaires, quel devs n'a pas rêvé de ça ?

Au final le développeur consciencieux n'a plus qu'à faire la revue de code et valider. Quiconque a pratiqué la revue de code sait que c'est loin d'être suffisant pour comprendre ce qu'il se passe, et quiconque a déjà programmé sait qu'il est deux fois plus difficile de déboguer du code que de l'écrire ; alors quand tu ne l'as même pas écrit… Et puis OSEF après tout, S'il y a besoin de comprendre ce qu'il se passe il suffira de demander à l'IA. Soyons positifs, il n'y a pas de raison que ça pose des problèmes. Toute technologie révolutionnaire a eu ses détracteurs après tout.

Cette méthode de développement est encore très jeune et on n'a pas de recul sur la qualité de la production, et vu la vitesse à laquelle celle-ci croît on ne peut qu'espérer qu'elle soit de qualité. Heureusement on peut s'inspirer de l'histoire de la programmation et constater que lorsqu'un outil a été fait pour accueillir des devs qui ne veulent rien avoir à faire avec le sujet, le résultat a plutôt été mauvais, au point que des contraintes ont dû être ajoutée a posteriori pour les empêcher de causer des problèmes. Et on peut se demander si l'industrie ne serait pas un peu con-con à recréer les mêmes problèmes encore et encore.

Et toi cher lecteur, as-tu connaissance d'un autre outil qui se voulait facile d'accès avant de rétropédaler en mettant des garde-fous avec une sorte de mode strict ? Ou au contraire d'outils très stricts qui se sont dégradés en voulant être plus accessibles ?