Le carnet du grincheux

Dans les années 1990, une foule immense s'est élevée contre le langage Basic parce que la plupart du temps, ce langage n'était pas compilé, que les variables étaient déclarées à la volée et qu'un programme Basic ne contenait que des sous-programmes accessibles au travers de la fonction GOSUB. Pourtant, le Turbo Basic permettait aussi l'utilisation des fonctions, des procédures ainsi que des blocs structurés de programmes. Rien n'y a fait, le Basic traînait derrière lui une sulfureuse rumeur que n'a pas arrangée la série intitulée Visual Basic. Microsoft étant capable de pervertir n'importe quel concept, le Basic passé à sa moulinette n'a pas échappé à cette règle.

Il existe pourtant aujourd'hui un langage utilisé malheureusement partout qui est bien pire que le pire des langages de la famille des Basic. Il s'agit de Python. Non seulement les différentes versions de Python sont incompatibles entre elles, mais il n'y a même pas la plus minimale des compatibilité ascendante. Entre Python 2 et 3, l'annonce a été faite on ne peut plus clairement. Mais d'une branche de la version 2 à une autre plus récente, la compatibilité n'est pas assurée dès que l'on creuse un petit peu. J'ai pu il y a quelque mois réinstaller un vieux Python 2.6, parce que ni le 2.7 ni le 3.0 ne permettait de faire fonctionner un système de programmation d'une carte d'électronique embarquée. Le programme en question était peut-être mal écrit, certainement d'ailleurs, mais le résultat était là. Un programme parfaitement fonctionnel avec Python 2.6 ne fonctionnait plus avec le 2.7.

Revenons donc à Python. Depuis une quinzaine d'années, mon activité m'a poussé à étudier les formalismes et à concevoir des langages de programmation. Un exemple de mes travaux se trouve ici et est utilisé actuellement pour des calculs massivement parallèles. Je vais donc me permettre d'analyser les défauts de Python à l'aulne de mon expérience de logicien fou. Je n'entrerai pas dans le détail, mais vous pouvez toujours poster des commentaires, je développerai un peu plus.

Le fait de mélanger le fond et la forme est la première aberration de ce langage. En Python, l'espace et la tabulation sont signifiantes. Là où l'immense majorité des langages de programmation utilise une syntaxe spécifique pour déclarer des blocs de programmes, qu'il s'agisse de begin/end, d'accolades ouvrantes et fermantes ou de tout autre système, Python considère que cette déclaration est implicite et fonction du nombre d'espaces ou de tabulations en début de ligne. C'est assez amusant, surtout lorsqu'un éditeur décide dans le dos de l'utilisateur de changer des tabulations en espaces et réciproquement. Et encore, il faut savoir combien d'espaces représente une tabulation.

Entre nous, c'est dommage. Cela nous prive de programmes agréables à lire comme ceux de l'IOCCC.

Python mélange un tas de paradigmes assez orthogonaux. D'après ses concepteurs, il peut être procédural, fonctionnel, objet voire encore d'autres familles qu'il resterait à inventer. Il paraîtrait même que l'on pourrait faire du lamba-calcul avec Python. Comme tous les langages qui font plein de choses, il fait un peu tout, mais mal, puisqu'il cherche à avoir une syntaxe générique pour traiter tous les cas. Et qui dit langage objet dit ramasse-miette quasiment à coup sûr. Ce n'est en effet pas tout de créer des objets, il faut encore libérer la mémoire. Et si on le fait de façon synchrone, les performances peuvent s'en ressentir.

La question est de savoir ce qu'apporte le paradigme objet. Le seul intérêt que j'y vois est qu'un développeur médiocre peut essayer de coder quelques applications sans jamais se poser réellement la question de la gestion de la mémoire. Subséquemment, lorsqu'il cherche à appeler une banane, il est souvent contraint de siffler un singe qui apporte cette banane sur un plateau et qui vient avec tous ses copains de la jungle. En termes stricts de ressources, la programmation objet est une aberration.

Il faudrait contraindre Python a rester dans le domaine du prototypage rapide où son utilisation pourrait à la rigueur se justifier en tant que langage pouvant être interprété et surtout se débrouiller pour qu'il n'en sorte pas. Le fait de disposer de nombreuses bibliothèques fait que personne ne se préoccupe de sa pérennité, le choix du langage se faisant en fonction des outils déjà existants et surtout pas en fonction de critères objectifs intrinsèques au langage. Je pourrais faire exactement le même reproche aux gens qui choisissent le C ou le C++ là où le Fortran serait le plus adapté ou à ceux qui ne jurent que par Java ou par Matlab. Le choix d'un langage n'est pas anecdotique, il impose une façon de penser, une manière d'implanter un algorithme. Penser Python, ou C, ou n'importe quel autre langage avant de penser algorithme revient à mettre la charrue avant les bœufs et à s'imposer des limites qui ne devraient pas exister. Souvent, cela complexifie les programmes.

Mais ce type de pensée se perd. Aujourd'hui, il faut développer vite quitte à ce que le code soit jetable car non maintenable. La génération des développeurs Python ou Java a donc malheureusement encore de beaux jours devant elle. Et tant qu'il restera des objectifs inatteignables, des cahiers de charges mal fichus, des délais raccourcis et sur le marché autant de mauvais développeurs, cela risque de ne pas s'arranger.

Si vous êtes bien sages et que vous le demandez gentiment, je vous expliquerai dans un prochain billet ce qui est pour moi un langage correctement conçu.