Il y a une phrase que j'ai entendue souvent dans les cercles d'ingénierie : "N'inventez pas votre propre langage — utilisez ce qui existe." C'est un conseil raisonnable, la plupart du temps. Et comme tous les conseils raisonnables, il devient dangereux quand on l'applique sans discernement. Parce que parfois, le problème que vous cherchez à résoudre est précisément le fait que aucun des langages existants ne parle votre domaine.
Un DSL n'est pas un caprice d'architecte. Ce n'est pas de l'over-engineering déguisé en innovation. Un DSL apparaît naturellement quand on observe qu'un développeur passe plus de temps à traduire son intention dans la syntaxe d'un langage généraliste qu'à exprimer cette intention elle-même. Ce moment de friction — cette distance entre la pensée et l'outil — est exactement là où un DSL bien conçu peut changer l'expérience de développement de façon radicale.
J'ai conçu CXML et C% précisément à ce carrefour. Pas parce que Kotlin ne suffisait pas. Parce que Kotlin ne parlait pas architecture transversale — et que ce domaine précis méritait ses propres mots.
L'une des meilleures façons de comprendre pourquoi les DSL sont puissants, c'est de réaliser qu'on en utilise tous les jours sans les identifier comme tels. SQL, HTML, CSS, Makefile — ce sont des langages entiers, avec leur syntaxe, leur sémantique, leur modèle d'exécution. Ils sont "petits" dans le sens où ils ne cherchent pas à tout faire. Mais dans leur domaine, ils sont extraordinairement précis — et c'est précisément leur force.
Ce tableau dit quelque chose d'important : les DSL industriels ont été créés parce que quelqu'un, à un moment précis, a refusé d'accepter que son domaine devait se plier aux constructs d'un langage généraliste. Don Chamberlin n'a pas implémenté la manipulation de données relationnelles en C. Il a inventé SQL. Cette décision a changé l'industrie pour les cinquante années suivantes.
Voici comment je mesure si un domaine mérite son propre DSL : je regarde combien de tokens syntaxiques un développeur doit écrire pour exprimer une intention métier unitaire. Plus le ratio est élevé — plus il y a de bruit syntaxique par unité d'intention — plus le domaine souffre d'un manque de DSL adapté.
La différence n'est pas que CXML est "plus court". C'est qu'il est plus honnête. Le code Kotlin à gauche exprime une procédure — une séquence d'opérations qui aboutit à une connexion. Le CXML à droite exprime une intention — la connexion elle-même, sans le bruit de son implémentation. Dans un système qui déclare des centaines de connexions, cette différence de densité d'intention est la différence entre une architecture lisible et une architecture qui ne peut être comprise que par son auteur.
Dans CAKE, les DSL ne coexistent pas par accident. Ils sont conçus pour s'articuler à des niveaux d'abstraction différents — et chaque niveau a sa propre densité d'intention. CXML parle de structure. C% parle de coordination. CakeLang parle de logique éditable. Les DSL de domaine parlent leurs métiers respectifs.
Cette stratification n'est pas de la complexité ajoutée — c'est de la complexité nommée. Au lieu d'avoir un seul langage qui essaie de tout exprimer avec des niveaux d'abstraction mélangés, on a plusieurs langages qui savent exactement où s'arrête leur territoire. Chaque couche fait une seule chose — et la fait avec toute la précision qu'elle mérite.
Un bon DSL, c'est comme un outil de luthier spécialisé. Il ne peut pas faire le travail d'un marteau ou d'une scie. Mais pour sculpter la volute d'un violon, rien d'autre ne convient. La spécialisation n'est pas une limitation — c'est ce qui permet d'atteindre un niveau de précision impossible avec un outil généraliste. — Sébastien Roy, CEO Unibool Inc.
Le dernier seuil de maturité d'un système extensible, c'est quand il peut générer ses propres DSL à partir d'une description de domaine. Ce n'est plus le développeur qui conçoit le langage — c'est le système qui observe un domaine et en produit une notation adaptée.
Dans CAKE, ce mécanisme est en construction permanente. L'objectif n'est pas de générer des DSL arbitraires — c'est de permettre à n'importe quel module d'exposer son propre vocabulaire d'intention, formalisé et intégré dans le pipeline sans friction. Chaque nouveau domaine peut apporter ses mots. Le système s'enrichit. L'architecture reste cohérente.
C'est une vision qui demande de la discipline — parce qu'un écosystème de DSL mal gouverné devient aussi difficile à comprendre qu'un seul langage trop général. La génération dynamique de langages n'est pas une licence d'inventer à l'infini. C'est une responsabilité architecturale de premier ordre — dont le chapitre suivant traitera en profondeur.
Un DSL n'est pas un luxe réservé aux grandes infrastructures. C'est une réponse proportionnée à un problème de distance entre l'intention et l'outil. Quand cette distance est suffisamment grande, la création d'un DSL n'est pas de l'over-engineering — c'est la décision la plus pragmatique qu'un architecte puisse prendre.
Le domaine mérite d'avoir ses propres mots. Donner ces mots au domaine, c'est respecter sa complexité naturelle.