Func' programming - un blog homéopathique

Toute la terre avait une seule langue et les mêmes mots. (...) Ils dirent encore: «Allons! Construisons-nous une ville et une tour dont le sommet touche le ciel et faisons-nous un nom afin de ne pas être dispersés sur toute la surface de la terre.» L'Eternel descendit pour voir la ville et la tour que construisaient les hommes, et il dit: «Les voici qui forment un seul peuple et ont tous une même langue, et voilà ce qu'ils ont entrepris! (...) Allons! Descendons et là brouillons leur langage afin qu'ils ne se comprennent plus mutuellement.» (...) Alors ils arrêtèrent de construire la ville. C'est pourquoi on l'appela Babel: parce que c'est là que l'Eternel brouilla le langage de toute la terre et c'est de là qu'il les dispersa sur toute la surface de la terre. Genèse 11 1-9

Connaître plusieurs langages est-il souhaitable? Ce débat animé trouve dans la Genèse une réponse tranchante: l'unité rend l'homme égal à Dieu; la langue adamique, vestige du Paradis perdu, est rayée de la surface de la terre pour châtier l'orgueil des hommes que la dispersion réduit à l'impuissance. Il est vrai que les avantages d'un langage unique sont évidents: compréhensible par tous, compatible avec tout, pérenne, il rend les développeurs pour ainsi dire interchangeables. Plus de code mort, dont l'intelligibilité a disparu avec le créateur, plus d'erreurs ni de manque dans les bibliothèques mille fois testées! Tout le reste n'est que jouet de geek ou lubie de chercheur...

En comparaison, les avantages de la multiplicité des langages sont obscurs. La fragmentation paraît bien un châtiment, une malédiction. Pourquoi alors s'y obstiner? Qu'est-ce qui pousse des programmeurs respectables à en explorer, voire à en créer toujours de nouveaux? Ce billet est une tentative de répondre à la question: j'y dénonce le mythe du langage unique -une incompréhension profonde de ce qu'est un langage informatique- pour en tirer quelques leçons et une grande fierté pour les programmeurs.

Pourquoi un langage, c'est déjà plusieurs langages
La création de mots est l'activité principale du développeur: création de nouveaux types (substantifs), de nouvelles fonctions (verbes), de nouvelles macros (constructions grammaticales)... Défini par sa syntaxe et ses mots-clés, un langage informatique est plutôt un méta-langage, un outil pour créer d'autres langages aux vocabulaires et aux tournures variées. Cette caractéristique des langages de programmation n'est peut-être pas apparente dans les programmes les plus triviaux; mais dès que le code s'allonge et devient plus complexe, et d'autant plus s'il est une affaire d'équipe, il devient évident que chaque bibliothèque, chaque application crée son propre langage -un langage nouveau qui doit s'apprendre.

L'importance du langage naturel dans le code vient précisément de ce phénomène. Que ce soit sous la forme de documentation, de commentaires, des noms de variable, il témoigne du fait que le langage utilisé n'est que l'hôte d'un langage nouveau et que le connaître ne suffit pas à comprendre le code dont il fixe les règles. Si le paroxysme de ce processus de création est atteint dans les Domain Specific Languages, il n'y a entre eux et le reste des programmes qu'une différence de degré, pas de nature. Autrement dit, le langage unique n'est dans une certaine mesure qu'une fiction.

La complexité croissante des programmes, le recours aux frameworks, à la création automatique de code -que ce soit par des interfaces XML ou dans le cadre de la programmation orientée aspect, par exemple- ne fait que renforcer cette hétérogénéité entre le langage lui-même et les langages qu'il abrite; et, d'un certain point de vue, les standards de qualité, les design patterns et les fonctionnalités des EDI se surajoutent encore au vocabulaire que doit maîtriser un développeur qui intègre une équipe.

Les objections du "pointy hairy boss"
Considérer qu'il n'existe pas de langage, mais toujours des langages, paraît néanmoins très intellectuel. L'objection vient naturellement: quand bien même chaque programme créerait un langage différent, il reste plus facile à lire -et à écrire- pour quelqu'un qui est familier avec le langage hôte. Cet argument est pourtant imparfait: il y a le risque des "faux amis", qui trompent plus sûrement un connaisseur qu'un néophyte; et puis dans certains cas, des pans importants du langage hôte sont exprès recouverts: ainsi le framework Qt, qui fait l'impasse sur la plus grande partie de la librairie standard du C++. Surtout, cet argument est réversible: si connaître Java est censé faciliter la compréhension d'un programme écrit avec Hadoop, par exemple, on peut tout autant soutenir que connaître le C++ aide à comprendre Java (une affirmation du créateur de Java lui-même), le C C++, et tout langage impératif le C. Réciproquement, connaître des langages fonctionnels ou distribués permet de mieux comprendre un programme Java écrit à grand renfort de map, de reduce et de lambdas pour un cluster de serveurs.

Il est vrai que ces arguments risquent de ne pas convaincre un responsable de SI, préoccupé par des exigences immédiatement opérationnelles. A vrai dire, ce personnage qui hante les blogs de développeurs - le "pointy hairy boss", chef pointilleux et poilu, pour une raison qui m'échappe - risque plutôt, en prenant conscience du risque de fragmentation, de réduire encore les options à disposition des développeurs, sous prétexte de productivité. Eh bien, tant pis! si on ne me laisse pas le choix, d'accord, mais je refuse de me couper les c... avant qu'on me l'ait demandé!

Les leçons à en tirer
Si la diversité est inhérente à la programmation, autant en tirer profit. C'est ce qu'ont fait avec succès des entreprises comme IBM, qui utilise Prolog dans son système intelligent Watson, Facebook, Whatsapp ou Call of Duty qui ont choisi Erlang pour leurs applications de chat ou leurs serveurs de jeu. Un exemple plus ancien mais plus frappant encore d'une réussite fondée sur l'utilisation d'un langage "à part" est celui que raconte Paul Graham dans son article Beating the averages: c'est grâce aux particularités de LISP qu'il s'est maintenu devant la concurrence lorsqu'il a crée ce qui est devenu Yahoo Store aujourd'hui.

Il ne faut bien sûr pas chercher la diversité à tout prix. Mais il faut l'aimer pour elle-même, pour ce qu'elle donne d'ouverture d'esprit et d'adaptabilité. La diversité est, qui plus est, en partie apparente: pour celui qui connaît les grandes familles de styles de programmation et de systèmes de types, la plupart des langages, quelle que soit leur nouveauté ou leur bizarrerie apparente, deviennent vite familiers. Ne nous restreignons pas à Java! Allons voir ces langages déclaratifs, fonctionnels, homoiconiques, à pile, à prototypes, objet, aspect, ces systèmes de types statiques, dynamiques, stricts ou souples, à types dépendants, génériques!

De toute façon, l'expertise dans un langage ou un domaine particulier n'est possible qu'au prix d'une véritable culture générale. Prenez le C++: je suis frappé, sur le forum, du nombre de personnes qui ne songent pas à utiliser les algorithmes de la librairie standard et les nouveautés du C++11, parce qu'elles reposent sur des principes fonctionnels, les fonctions d'ordre supérieur et la composition. Comme le fait remarquer le créateur du langage, Bjarne Stroustrup, ce n'est pas un langage orienté objet mais un langage traversé par différents paradigmes; sans culture générale, on n'en fera jamais qu'une utilisation limitée. L'exemple du C++ contient en fait plus encore d'enseignements: la méta-programmation, qui en est une part désormais constitutive, a été développée en grande partie grâce à la fécondation de la culture fonctionnelle; une bonne part du livre fondateur d'Andrei Alexandrescu, Modern C++ design, consacrée aux typelists, est directement inspirée de LISP.

Programmeurs de tous les pays, unissez-vous!
L'article à la base de la discussion sur le forum affirme -combien de fois l'ai-je entendu- que la variété est un plaisir de geek, le caprice d'un enfant qui trouve un nouveau jouet sous le sapin. Que de mépris! Cette variété est le résultat de l'incorporation de réflexions sérieuses et interdisciplinaires. Le clivage entre les préoccupations académiques et celles de la production existe certainement à un certain stade de maturité d'un projet, mais l'histoire de l'informatique est celle de la fécondation de l'industrie par la recherche (la réciproque étant également vraie). L’interdisciplinarité crée, à la faveur des projets de recherche, des rapprochements inattendus: du calcul lambda à LISP, de LISP à l'intelligence artificielle, pour donner un exemple, dont le poids actuel est suffisant, je pense, pour récuser l'idée d'un caprice: un nouveau langage n'est pas le dernier iPhone mais le véhicule de concepts dont la portée, en gestation encore, pourrait être déterminante dans les années à venir.

Je comprends que ce ne soient pas là les préoccupations d'un chef de SI. Mais il me semble que nous autres devons respecter notre art, et ne respecter les exigences du chef poilu qu'avec la pensée de derrière. Tirons fierté de cette variété!