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. 