David Madore's WebLog: Quels sont mes langages de programmation préférés ?

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #1745 [older|newer] / Entrée #1745 [précédente|suivante]:

(jeudi)

Quels sont mes langages de programmation préférés ?

L'avantage des langages de programmation, par opposition aux langues naturelles, c'est qu'on peut très rapidement devenir hautement polyglotte : il m'est arrivé de devoir écrire ou modifier un programme dans un langage de programmation dont je ne connaissais que le nom, et de me débrouiller passablement bien au bout de seulement quelques heures. (Il est vrai, cependant, que les langages les plus intéressants sont ceux qui demandent quelques efforts à apprendre parce qu'ils ne se contentent pas de changer de syntaxe par rapport à un autre langage, ils vous forcent à penser autrement, ce qui est toujours un enrichissement mental. Un peu comme quand on découvre que deux mots qui sont confondus dans notre langue maternelle sont différencés dans une autre langue naturelle et que cela nous apprend une distinction à laquelle on n'aurait pas pensé.) L'inconvénient, c'est que l'embarras du choix peut être angoissant ; et que plus on connaît de langages plus on se dit que c'est dommage qu'il n'en existe pas un qui combine l'idée X du langage A et les idées Y et Z du langage B, avec aussi quelques trucs de C, et on finit par envisager d'inventer son propre langage et d'ajouter une petite niche à une tour de Babel déjà bien assez compliquée.

Une autre chose, c'est que les langages de programmation ont tendance à avoir leurs zélotes, qui insistent pour vous dire qu'il faut absolument que vous l'appreniez et que vous vous en serviez pour faire votre café le matin, et que leur langage il est plus beau, plus logique, plus cohérent, plus simple, plus lisible, plus concis, plus rapide à l'exécution, plus efficace à coder voire tout ça à la fois. Les zélotes sont fatigants : j'ai tendance à avoir un avis nuancé sur tous les langages de programmation que j'utilise et je soupçonne toujours les gens qui s'enthousiasment trop devant un langage donné d'être d'une mauvaise foi absolue ou de mauvais programmeurs. Bizarrement, il y a des langages qui sont plus des langages à zélotes que d'autres (et ça ne semble ni très corrélé aux meilleurs langages ni aux moins bons) : j'ai l'impression qu'il y a beaucoup plus de zélotes Python ou Haskell que de zélotes C ou JavaScript.

Bref, je ne crois pas avoir de langage préféré. Le langage dans lequel je me retrouve bien souvent à coder, c'est le C, parce qu'il s'avère que telle bibliothèque n'est disponible que pour le C, ou que ses bindings pour tous les autres langages ne sont pas bien à jour, ou pas parfaits, ou trop mal documentés, ou toute autre combinaison de ce genre. Ce n'est presque jamais le choix que j'aurais fait naturellement, même si je suis loin de détester le C. Programmer en C peut donner l'impression satisfaisante qu'on comprend ce qui se passe, qu'on évite les baguettes magiques : ça a un côté bio-sans-pesticides-préserve-la-mémoire jusqu'à ce qu'on s'en lasse parce que vraiment on perd son temps avec des détails insignifiants comme écrire une demi-douzaine de lignes pour faire un remplacement dans une chaîne de caractères.

Le langage dans lequel je code le plus efficacement, c'est indiscutablement le Perl. La puissance du Perl, c'est dans tout ce qu'on peut faire en une seule ligne avec lui. Quand je veux faire un remplacement global dans tout un arbre de fichiers, j'utilise Perl (et le Shell) ; quand je veux transformer les bookmarks de mon navigateur en un fichier HTML à ma sauce, j'utilise Perl ; quand je veux transformer une suite de caractères Unicode en leurs noms pour démystifier tel ou tel symbole bizarre, j'utilise Perl ; quand je veux extraire des données utiles d'une page Web, faire des statistiques sur un fichier ou un tableau de nombres (ou les traiter pour les fournir à un outil pour faire des graphes) ; bref, pour tout ce qui ressemble à des traitements de textes, de chaînes de caractères, Perl est l'arme absolue, et la possibilité d'écrire énormément de choses en une seule ligne, exécutée directement dans un terminal, est vraiment précieuse. Je me sers aussi de Perl pour des vrais programmes, par exemple le système de commentaires de ce blog, ou le programme qui me sert à générer des calendriers, ou encore celui qui convertit les fragments littéraires gratuits que j'écris depuis un format HTML vers un joli document XeTeX. Ce que j'aime surtout avec Perl, c'est qu'il est tout sauf religieux : il n'essaie pas de vous imposer une approche particulière des problèmes, il vous laisse faire ce que vous voulez et il vous donne toutes les armes pour ça. Évidemment, ça peut produire des programmes illisibles (et il est vrai que le Perl devient vite illisible), mais je trouve que c'est un reproche injuste à faire au Perl que de mettre sur son dos les défauts des programmeurs qu'il ne châtie pas. Ce qui me pose surtout problème avec Perl, en fait, c'est qu'il a l'air complètement moribond depuis que son créateur a imaginé de créer Perl 6, un nouveau langage dont le rapport avec le Perl actuel (Perl 5) est assez ténu, et qui ressemble plus à une blague maintenant — une blague qui dure depuis dix ans, qui a plein d'idées intéressantes mais dont il n'est pas sorti un seul truc utilisable et c'est prévu pour continuer comme ça pour tout l'avenir envisageable.

J'aime beaucoup moins Python que Perl : la principale raison est celle que j'ai déjà expliquée : Perl n'est pas un langage qui essaie de vous imposer sa façon de voir les choses — Python, si. Je n'ai pas de problème avec le fait que la syntaxe Python dépende de l'indentation (il est whitespace-sensitive : si vous ajoutez ou retirez des espaces, ça peut changer l'effet programme) ; par contre, j'ai un sérieux problème avec le fait que ce soit la seule façon d'organiser les blocs et que, par conséquent, on ne puisse quasiment rien coder en une seule ligne en Python (ou, en tout cas, pas sans astuces pénibles) : Python aurait très bien pu adopter l'approche pragmatique de Haskell (où l'identation est effectivement prise en compte, mais si on n'aime pas ce fait, il y a toujours moyen de forcer telle ou telle interprétation avec des accolades explicites), mais apparemment l'aspect religieux l'a emporté. Ce n'est pas catastrophique (contrairement à ce que dirons certains zélotes anti-Python, qui sont aussi fastidieux que les zélotes pro-Python), mais c'est révélateur d'un état d'esprit gênant. De même, le langage impose une distinction (assez gratuite dans un langage de haut niveau, surtout qu'il prétend avoir récupéré des idées de la programmation fonctionnelle) entre instructions et expressions, en omettant volontairement un mécanisme qui permettrait de transformer une instruction en expression (en Perl, on peut utiliser do{...} pour transformer n'importe quelle suite d'instructions en une expression susceptible d'être utilisée comme valeur), et quitte à rendre quasiment inutilisables le fonctions anonymes que Python permet quand même. Cette limitation n'est pas ce qui m'ennuie le plus : ce qui m'ennuie le plus est qu'on ose la justifier par autoriser la transformation d'une instruction en expression (ou les fonctions anonymes important des instructions) encouragerait les programmeurs à écrire du mauvais code — un langage de programmation n'est pas là pour faire la morale aux programmeurs, il est là pour leur donner ce qu'ils veulent, y compris de quoi se tirer une balle dans le pied si c'est ça qu'ils veulent (et la tradition d'Unix, et de Perl, a toujours été de fournir un abondant arsenal pour les programmeurs qui veulent se tirer des balles dans le pied ☺ ; plus sérieusement, le programmeur est quand même mieux placé que le concepteur du langage, aussi malin soit-il, pour décider ce qui est le mieux dans le contexte précis de son programme). Après, il est indéniable que Python a des fonctionnalités très intéressantes : les itérateurs et coroutines, par exemple ; ou simplement, le fait que les entiers soient illimités par défaut. Par rapport à Perl, aussi, il gagne sur les exceptions (beaucoup plus agréables en Python que l'affreux $@ de Perl), mais il perd sur les références (les références du Perl, il faut peut-être un moment pour les comprendre, mais ensuite c'est vraiment élégant et logique).

Haskell devrait, logiquement, être mon langage préféré, parce que c'est un langage d'une grande beauté pour les mathématiciens. J'en pense effectivement beaucoup de bien, mais dans la pratique je trouve qu'il souffre de deux défauts. Le premier est purement psychologique : le langage est tellement pur qu'on se sent obligé de faire les choses de façon pure, et on finit par perdre beaucoup de temps parce qu'on ne veut pas céder à la façon évidente de faire les choses qu'on aurait choisie dans tout autre langage que Haskell (par exemple, on se sent obligé de dégager des fonctions d'ordre supérieur, de ne jamais utiliser de unsafePerformIO ni de IORef, et ainsi de suite… cela peut représenter un boulot supplémentaire considérable). L'autre est plus réel : l'évaluation paresseuse a tendance à être tellement insidieuse qu'on peut perdre un temps fou à comprendre pourquoi tel ou tel truc est atrocement lent, parce qu'on avait complètement oublié que telle variable n'allait être évaluée que bien après le moment où on le pensait. Et saupoudrer le code de `seq`, de $! et de constructeurs stricts, c'est vraiment horrible. Malgré cela, Haskell reste un langage vraiment unique, et pour faire des calculs mathématiques ou combinatoires j'y ai souvent recours. Et, pour le coup, le genre de choses qu'on peut faire avec des one-liners, ce ne sont pas tant des manipulations de chaînes de caractères comme en Perl, ce sont plutôt des calculs de suites récurrentes ou des choses comme ça, où les listes paresseuses montrent toute leur puissance (par exemple, pour calculer le nombre d'itérations pour atteindre 1 dans le problème de Collatz en partant des entiers de 1 à 100, cela s'écrit take 100 $ let ev n | n`mod`2==0 = n`div`2 ; ev n = 3*n+1 in map (Maybe.fromJust . List.elemIndex 1 . iterate ev) [1..] ; le Haskell n'est souvent pas beaucoup plus clair que le Perl, mais pour des raisons beaucoup plus profondes).

Un langage pour lequel je suis très partagé, c'est JavaScript. Par certains côtés, c'est une horreur : la bibliothèque standard est pourrie, les règles de conversion automatique sont tellement magiques qu'on n'y comprend plus rien (exemple aléatoire : []==![] s'évalue en true, ce qui est quand même violent), il y a des chausse-trapes partout (ce quiz n'est pas mauvais pour s'en rendre compte). D'un autre côté, JavaScript a certains aspects très satisfaisants : le mélange entre l'impératif, l'orienté objet et le fonctionnel, tout ça avec une syntaxe à la C, me semble vraiment bien réalisé ; et l'orienté objet à la sauce prototypage, finalement, j'aime beaucoup, et ça permet de faire des choses très puissantes. Un peu dans le même genre, il y a Lua, que j'aime assez bien (et je suis content qu'il ait été choisi comme langage d'extension pour étendre TeX), même s'il faut admettre que sa bibliothèque standard est, disons, minimaliste (enfin, c'est un peu le principe d'un langage d'extension). Il y avait Pike que j'avais repéré également, dans un genre probablement semblable.

Je suis aussi partagé pour Java, mais pour des raisons presque diamétralement opposées à JavaScript : la bibliothèque standard est très intéressante, mais je ne suis pas trop convaincu par le modèle de programmation orienté objet à fond, où les fonctions n'ont pas la citoyenneté de première classe (voire, pas d'existence du tout) sauf comme méthode d'un objet. (Ceci étant, les fanatiques anti-Java sont tellement pénibles qu'ils me donnent envie d'aimer le langage malgré ses quelques défauts.) Je ne connais pas C#, mais il est possible qu'il réalise un meilleur compromis.

Parmi les autres langages dont au moins certaines fonctionnalités ou idées me semblent intéressantes, je pourrais citer Scheme (ou une autre variante de Lisp), ou bien Smalltalk. Mais il y a quantité d'autres langages dont je me dis qu'ils pourraient être intéressants et que ça m'intéresserait d'en apprendre un peu un jour : Ruby, Erlang, Mercury, Dylan, Forth et Scala me viennent à l'esprit. Par contre, je n'ai aucune envie d'apprendre quoi que ce soit de C++ : tout ce que j'en ai vu m'a surtout donné envie de fuir (c'est-à-dire des programmes qui cassent à chaque mise à jour de gcc parce que l'interprétation de la norme n'arrête pas de changer), mais je ne vais pas m'étendre là-dessus parce que je trouve assez pénibles les gens qui disent uniformément du mal d'un langage quelconque pour ne pas m'y jeter moi-même, surtout s'agissant de quelque chose que je ne connais pas. De même, je ne commenterai pas sur mon absence d'envie d'apprendre le PHP.

J'en profite pour signaler cette page, qui recense la façon d'écrire la fonction 91 de McCarthy dans un certain nombre de langages. Ça peut donner envie d'en éviter certains. 😉

↑Entry #1745 [older|newer] / ↑Entrée #1745 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées