Formation libre — programmation
Voici la même tâche — additionner les nombres pairs d'une liste — écrite dans douze langages. Ce n'est pas un concours de brièveté. Chaque version révèle ce que son langage considère comme évident : pour l'un, une boucle et un compteur ; pour l'autre, une transformation de suite ; pour un troisième, une question posée à une base de données. Puis un interpréteur qui tourne vraiment dans cette page, et un jeu pour reconnaître un langage à sa silhouette.
Faites défiler
Le même problème, douze regards
La tâche est volontairement minuscule : parcourir [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] et renvoyer la somme des pairs — soit 30. Regardez moins la syntaxe que la forme du raisonnement. Filtrez par famille pour voir les parentés apparaître.
Ce que le nombre de lignes ne dit pas. L'assembleur prend vingt lignes là où SQL en prend une, et il serait absurde d'en conclure que SQL est « meilleur ». Ils ne parlent pas du même niveau : l'assembleur décrit ce que fait le processeur, registre par registre ; SQL décrit ce qu'on veut obtenir et laisse un moteur d'optimisation choisir comment. Entre les deux, soixante ans d'efforts pour déléguer à la machine des décisions qu'il fallait autrefois écrire à la main. La brièveté n'est pas une vertu en soi — c'est le symptôme de tout ce que le langage a accepté de décider pour vous.
Et pourquoi COBOL est toujours là. Écrit en 1959, il paraît verbeux jusqu'à l'absurde. Mais il possède une propriété que presque aucun langage moderne n'offre : l'arithmétique décimale exacte. En Python comme en JavaScript, 0.1 + 0.2 ne vaut pas 0.3, parce que la virgule flottante binaire ne peut pas représenter un dixième. Pour un intérêt bancaire, cette erreur est inacceptable. COBOL calcule en décimal depuis le premier jour, et c'est l'une des raisons pour lesquelles des milliards de lignes tournent encore dans les banques et les assurances. Ce n'est pas de l'inertie : c'est le bon outil qui n'a pas été remplacé.
Un vrai langage, écrit pour cette page
Voici un petit langage complet — variables, arithmétique, conditions, boucles, affichage — dont l'analyseur et l'évaluateur tiennent en deux cents lignes, écrites à la main sans aucune bibliothèque. Modifiez le programme, exécutez : il est réellement analysé puis évalué, jeton par jeton. Vous pouvez aussi voir la trace d'exécution, qui est la meilleure façon de comprendre ce qu'un interpréteur fait vraiment.
Grammaire acceptée : var x = expr, x = expr, affiche expr, si cond { … } sinon { … }, tantque cond { … }. Opérateurs + - * / %, comparaisons == != < > <= >=, et et / ou. Les commentaires commencent par #.
Trois étapes, toujours les mêmes. Tout interpréteur — celui-ci comme celui de Python — fait la même chose. D'abord l'analyse lexicale découpe le texte en jetons : var, x, =, 12. Ensuite l'analyse syntaxique assemble ces jetons en un arbre qui reflète la structure et les priorités : dans 2 + 3 * 4, la multiplication devient un nœud enfant de l'addition, ce qui suffit à garantir le bon résultat sans aucune règle supplémentaire. Enfin l'évaluation parcourt cet arbre en remontant les valeurs. Ce n'est pas de la magie et ce n'est pas hors de portée : deux cents lignes suffisent pour un langage jouet, et l'essentiel des idées y est déjà.
Le jeu
Chaque langage a une allure caractéristique : ses accolades ou son indentation, ses points-virgules, ses parenthèses, sa façon de déclarer. Un développeur expérimenté identifie un langage en une seconde, sans lire une seule ligne. Vous allez voir que c'est plus facile qu'il n'y paraît.
Choisissez le langage de cet extrait.
Quatre visions du monde
Les langages ne diffèrent pas seulement par leur syntaxe : ils reposent sur des réponses opposées à une même question — qu'est-ce que calculer ? Aucune de ces réponses n'est fausse, et tout bon développeur finit par savoir passer de l'une à l'autre.
« Un programme est une suite d'ordres »
On décrit les étapes, on modifie de l'état, on avance. C'est la famille la plus proche de la façon dont la machine fonctionne réellement, et de loin la plus répandue. Python, JavaScript, Java, C#, Ruby. Sa force est l'intuition ; sa faiblesse, que l'état qui change partout devient vite impossible à suivre.
« Un programme est une expression à réduire »
Pas d'état mutable, pas de boucle : des fonctions qui transforment des valeurs en d'autres valeurs. Lisp, Haskell, OCaml, Elixir. Un même appel donne toujours le même résultat, ce qui rend le raisonnement et le parallélisme bien plus sûrs. Le coût d'entrée est réel, mais ses idées ont contaminé tous les autres langages — map et filter viennent de là.
« Un programme est ce que fait le processeur »
La mémoire est visible, elle se gère. Assembleur, C, C++, Rust, Zig. On y écrit les systèmes d'exploitation, les moteurs de jeu, l'embarqué — tout ce qui ne peut pas se permettre un ramasse-miettes imprévisible. Rust a apporté la nouveauté majeure de ces vingt ans : la sûreté mémoire vérifiée à la compilation, sans surcoût à l'exécution.
« Un programme décrit le résultat voulu »
On énonce ce qu'on veut, pas comment l'obtenir. SQL, Prolog, HTML, CSS, les fichiers de configuration. Un moteur se charge de la stratégie — et il la choisit souvent mieux qu'un humain. C'est la famille la plus discrète et la plus omniprésente : vous en écrivez sans doute tous les jours sans appeler cela programmer.
Fortran. Premier compilateur largement adopté, et fin du mythe selon lequel un programme écrit par une machine serait forcément trop lent.
Lisp. Le code y est une structure de données manipulable par le programme lui-même. Cette idée n'a jamais été dépassée, seulement redécouverte.
C. Assez proche de la machine pour écrire un système, assez portable pour le déplacer. Presque tout ce que vous utilisez en descend.
SQL. Cinquante ans plus tard, il reste la façon dont l'humanité interroge ses données — et aucun successeur ne l'a délogé.
Le conseil qui vaut pour toute une carrière. La question « quel langage apprendre en premier » est mal posée, parce que le premier ne compte presque pas. Ce qui se transfère d'un langage à l'autre, ce sont les concepts : ce qu'est une variable, une fonction, une boucle, une structure de données, une complexité. Ces notions s'apprennent une seule fois et resservent partout. La syntaxe, elle, s'oublie et se réapprend en une semaine. Un développeur qui connaît bien deux familles opposées — disons Python et Haskell, ou C et SQL — est structurellement plus solide qu'un développeur qui connaît six langages de la même famille. Apprenez le premier sérieusement, puis choisissez le second aussi différent que possible.
Vérifier par vous-même
Les dates d'apparition sont celles communément retenues pour la première spécification ou la première implémentation fonctionnelle. Les exemples de code ont été écrits pour cette page et sont idiomatiques, non optimisés.
0.1 + 0.2 !== 0.3 dans la quasi-totalité des langages, et pourquoi le décimal exact reste nécessaire en finance.