Il y a une question que les gens posent rarement parce qu'ils pensent connaître la réponse : pourquoi inventer un nouveau langage ? La réponse reçue est souvent : parce que les autres ne sont pas assez bons. C'est inexact. Les langages existants sont souvent excellents — pour les problèmes qu'ils ont été conçus pour résoudre. La vraie raison d'inventer un nouveau langage, c'est quand le problème à résoudre n'était pas prévu par aucun des langages existants.
Ce tome est né de cette conviction. Pas d'une frustration envers Kotlin, C#, ou Python — des langages pour lesquels j'ai un profond respect. Mais d'une observation répétée, sur des mois de développement intensif : les systèmes transversaux — des systèmes qui orchestrent d'autres systèmes, qui parlent simultanément plusieurs paradigmes, qui doivent être à la fois déclaratifs et exécutables, lisibles et compilables — ces systèmes n'avaient pas de langage naturel.
Ce n'est pas l'absence de talent dans l'industrie. C'est l'absence d'un problème suffisamment bien formalisé pour avoir justifié, jusqu'ici, l'effort de créer l'outil qui lui correspond. CAKE est cet effort. Ce tome documente pourquoi il était nécessaire.
Dans ma pratique, l'invention d'un nouveau langage ne part jamais d'un désir abstrait de créer quelque chose de nouveau. Elle part de signaux concrets et répétés — des moments dans le développement où quelque chose résiste, où l'outil et le problème ne s'alignent pas malgré tous les efforts. J'ai appris à reconnaître trois de ces signaux.
Le signal III est celui qui a déclenché CAKE. Dans les architectures transversales, chaque intégration d'un nouveau moteur ou d'un nouveau runtime provoquait une onde de choc dans le code existant. Ce n'était pas un problème de compétence ou de discipline — c'était un problème structurel. Le langage d'orchestration n'existait pas encore.
Chaque langage qui dure est la cristallisation d'une philosophie. Pas d'un ensemble de fonctionnalités — d'un point de vue sur ce que la programmation devrait être. Comprendre cette philosophie, c'est comprendre pour quels problèmes ce langage sera toujours excellent — et pour quels problèmes il sera toujours limité.
Cette grille ne hiérarchise pas les langages — elle les situe. Un marteau excellent ne remplace pas un tournevis excellent. La question n'est pas quel langage est le meilleur, mais quel langage sert le mieux ce problème précis. Et quand ce problème précis n'avait pas encore de langage naturel — l'honnêteté intellectuelle commande d'en créer un.
Inventer un langage est l'un des actes les plus audacieux qu'un ingénieur puisse poser. Et l'un des plus mal compris. L'industrie y voit souvent de l'arrogance — une conviction que personne avant n'avait vu le problème correctement. Ce n'est pas ce que j'ai ressenti en créant C% et CXML.
Ce que j'ai ressenti, c'est de l'humilité. La reconnaissance que les langages existants étaient bons — excellents, pour certains — et que le problème que je cherchais à résoudre était simplement hors de leur portée déclarée. Pas parce qu'ils avaient échoué. Parce qu'ils n'avaient pas été conçus pour ce territoire.
Inventer un langage pour un domaine bien délimité, ce n'est pas rejeter ce qui existe. C'est étendre le vocabulaire de l'informatique pour qu'il puisse exprimer des concepts qui n'avaient pas encore de mots. C'est un acte de précision, pas de révolution.
Un nouveau langage naît quand un problème devient suffisamment bien compris pour qu'on puisse en nommer les concepts fondamentaux — et suffisamment récalcitrant pour qu'aucun langage existant ne puisse les exprimer naturellement. Ce moment est rare. Quand il arrive, il faut avoir le courage de ne pas l'ignorer. — Sébastien Roy, CEO Unibool Inc.
Les dix chapitres qui suivent ne sont pas une théorie abstraite sur la conception de langages. Ce sont des réflexions nées de la pratique — de la conception réelle de C%, CXML, CakeLang, et des DSL spécialisés qui composent l'écosystème CAKE. Chaque chapitre traite une question concrète : comment concevoir les trois couches d'un langage extensible, comment créer des DSL adaptés à un domaine, comment déclarer de nouveaux runtimes, comment inventer un paradigme, comment gouverner un écosystème de langages qui grandit.
Ce tome est également une invitation. Parce que l'une des propriétés les plus importantes de CAKE, c'est que vous pouvez en faire autant — déclarer votre propre langage, brancher votre propre runtime, formaliser les concepts de votre domaine dans une syntaxe qui lui ressemble. Ce que j'ai construit n'est pas une destination. C'est une infrastructure pour de futures inventions.
Les nouveaux langages n'apparaissent pas par caprice ou par désir d'innovation pour elle-même. Ils apparaissent quand un domaine a atteint une maturité suffisante pour que ses concepts fondamentaux méritent d'être nommés — et quand aucun langage existant ne dispose du vocabulaire pour les exprimer avec précision.
Reconnaître ce moment, c'est la moitié du travail. Avoir le courage d'agir dessus, c'est l'autre moitié.