Suite à ce tuto sur la fabrication d’un DSL en Python, je réalise que quelques personnes recommandent encore de créer des DSL.

Il faut absolument que je vous empêche de commettre cette erreur irréparable !

Une API n’est pas un DSL

Ruby, qui a des parenthèses optionnelles et la capacité d’intercepter les accès d’attributs à la volée, a lancé la mode du mot DSL à tout va. Sauf que la plupart des DSL en Ruby n’en sont pas. Ce sont juste des API écrites en Ruby.

You killed my project, prepare to die

Enchaîner les méthodes et opérateurs overloadés dans un langage populaire n’est pas utiliser un DSL. foo.bar().baz() n’est PAS un DSL si ça tourne dans la VM du langage. Quel que soit l’enrobage syntaxique qu’on a rajouté.

Un format de sérialisation générique n’est pas un DSL: XML et YAML n’en sont pas, contrairement à ce qu’on peut lire. Car ils sont généralistes, et donc pas “domain specific” par nature.

Par contre on peut écrire un DSL en JSON, XML ou YAML, et il en existe d’ailleurs pas mal. MathML et SVG sont des exemples de DSL écrits en XML.

Ne créez jamais un DSL

Pourquoi avez vous besoin d’un nouveau langage ? Il existe des centaines de langages et encore plus de formats de sérialisation. Aucun d’entre eux ne peut répondre à votre besoin ? Vraiment ? Vous avez tout testé pendant un mois ?

Choisir le bon outil, Civ style

Créer un DSL , donc un nouveau langage, implique vous avez besoin:

• d’informations dessus: docs, standards et tutos…
• d’outils : UI, générateurs, wrapper pour le scripting, coloration syntaxique, snippets, linters, checkers, debuggers…
• un support du DSL : garantir qu’on pourra le lire, écrire et manipuler dans 5 ans. Pouvoir fournir de nouveaux outils si le besoin évolue. Pouvoir faire évoluer le standard si (pardon “quand”) il se révélera limité. Répondre aux questions des utilisateurs. Fournir des messages d’erreurs et procédures pour résoudre les problèmes. Avoir un bug tracker.

Et il faut tenir tout ça à jour.

Ah. Ah. Ah.

Personne ne le fait jamais, ce qui fait de l’usage de la plupart des DSL un enfer, sans parler de la maintenance des projets qui l’utilisent sur le long terme. Mais les créateurs de DSL s’en effeuillent amoureusement les génitoires car ils seront dans une nouvelle boîte quand ça arrivera. Eux ils se sont bien amusés à créer un parseur pour le fun. D’ailleurs ça fait classe sur le CV.

Réponse standardisée aux propositions de DSL. Aussi valable pour l’introduction d’une nouvelle stack JavaScript

Créez une API

Votre langage de prédilection est turing complet. Il est donc capable de gérer ce que fait le DSL. Libérez l’anus de cette mouche et traitez votre problème avec un langage supporté, éprouvé, avec un large écosystème et qui résout déjà tout un tas de problèmes.

Ce qu’il vous faut, c’est faire une belle API, pour rendre la tache agréable:

• Créez des méthodes biens découplées, de l’injection de dépendance et un système d’events.
• Faites des wrappers plus haut niveau, et des factories pour les cas courants.
• Utilisez le sucre syntaxique de votre langage pour rendre tout ça tout beau (ex: __getitem__, __enter__, @decorateur, etc. pour python).

Avec une belle présentation, un truc standard ennuyeux devient soudainement très attractif

Si créer une API n’aide pas assez, par exemple vous faites un outil avec un langage haut niveau et avez besoin d’un langage haut niveau pour le scripting ou la configuration, embarquez un langage haut niveau connu. Par exemple Lua ou Python. Ne faites pas comme varnish ou nginx qui ont des fichiers de configuration dans un langage imbitable, indébuggable et mal documenté.

Quelques bonnes raisons de créer un DSL

Allez, il ne faut jamais dire jamais, et comme toujours en informatique, il y a parfois une bonne raison de faire quelque chose. Voici donc la liste des RARES cas où écrire un DSL a du sens:

• Vous avez un jeu de règles métier très complexe et des non informaticiens doivent pouvoir les composer. Et une UI ne ferait pas l’affaire pour une raison qui m’échappe. Et vous ne pouvez pas former les non informaticiens parce que fuck you. Les langages de templates types jinja sont dans cette catégorie.
• Vous avez un jeu de règles métier très complexe, vous voulez pouvoir les serialiser (pour les sauver dans un fichier ou une base de données ou les transmettre à travers le réseau par exemple) et la sérialisation doit pouvoir être accessible depuis plusieurs langages incompatibles (donc pas de dump mémoire, de pickle, etc). Les langages de requêtes comme GraphQL en font partie.
• Vous créez un langage pour remplacer un autre DSL. Par exemple Sass pour le CSS.
• Vous voulez des instructions logiques mais sécurisées pour autoriser une source en laquelle vous n’avez pas confiance à manipuler vos données. Et vous ne pouvez pas mettre une couche d’abstraction (ou c’est la couche d’abstraction) type Web API, RPC ou autre et ça va, maintenant, TG, c’est mon projet. Tous les formats des sérialisations pour le RPC justement répondent à ce problème.

Mais dans tous ces cas, ne faites un DSL que si:

• Une bonne UI n’est pas possible pas pour créer les règles et il faut les sérialiser.
• Il n’existe pas déjà un standard existant.
• Vous êtes certains de fournir des outils pour manipuler le DSL.
• Vous êtes certains de documenter, tester et maintenir le DSL.
• J’ai dit certains de documenter, tester et maintenir votre DSL. Arrêtez de mentir: vous ne le ferez pas.
• Lâchez ce DSL tout de suite ! Vous êtes dans une start-up. Vous n’allez jamais faire tout ça. Oust !

“Mais moi c’est pas pareil”, le hello word du DSL pour prendre des mauvaises décisions dans la vie

Par exemple, le langage de Matlab est un DSL, dédié à l’expression mathématique. SQL est un DSL, orienté requête. PHP a commencé comme un DSL, optimisé pour le Web.

En théorie, un DSL doit vous rendre plus productif. En théorie. En pratique, une fois qu’un DSL sort de son domaine de prédilection, il est extrêmement inéficace. C’est le prix de la spécialisation.

Or, dernièrement, on a fait beaucoup l’apanage des DSL dans le cadre d’autres langages. Car oui, certains langages permettent de créer des DSL. Les macros du C et les capacités de meta programmations de Lisp permettent par exemple de créer des langages complets, avec des dialectes spécialisés.

Vient alors le premier problème : on créé un nouveau langage. Récent. Supporté et donc débuggé et (mal) documenté par l’auteur. Ensuite, on se rajoute un niveau d’indirection. Car du coup ça nous fait une abstraction supplémentaire, et il faut savoir ce que ça fait sous le capot. En prime, on freine l’entrée de nouveaux venus dans le projet, puisqu’il faut qu’ils apprenent à faire avec le DSL en plus, là où une simple lib aurait pu faire l’affaire.

Et on touche ici à une seconde problématique, les faux DSL : des libs ordinnaires qui se déguisent en DSL. Typiquement, je pense à Ruby, ici.

Les rubistes prétendent partout qu’ils peuvent créer des DSL avec leur langage. Encore un mensonge, puisque tout ce qu’ils font c’est utiliser le chaînage de méthode, le namespacing, la surcharge des opérateurs et les parenthèses/virgules facultatives pour donner l’impression qu’un nouveau langage est créé.

Tout comme on donne l’illusion de retourner deux paramètres dans une fonction en Python en retournant un tuple et en faisant de l’unpacking. C’est du sucre syntaxique, mais on est très loin de ce que ça prétend être.

Pourquoi c’est important ? Parce que cela laisse à croire qu’il y a quelque chose de spéciale là dedans, alors qu’il s’agit ni plus ni moins que d’une bête lib avec une API fluide. Ce qu’on peut faire dans tout autre langage (excepté l’absence de parenthèses, sur lequel il faudra que j’écrive un article tellement c’est une FBI).

Donc plutôt que de faire du bruit et du hype autour de cela, et amener les gens à se concentrer sur l’aspect “comment obtenir une syntaxe exotique”, il serait plus intéressant de dire tout simplement : voilà comment on peut faire une belle API, voici les bonnes pratiques, appliquez les.

Et aussi écrire une doc…

J’ai horreur en informatique quand on donne 40 noms différents à la même chose. Comme par exemple pour les promises, les futures, les deferred, etc. Merde, non seulement ça n’aide personne, mais en plus ça rend la comprehension de principes plus difficile. Déjà que c’est rarement bien expliqué…

Au final, un DSL est rarement une bonne idée, que ce soit un vrai ou un faux. SQL nous aura bien servi, il faut le reconnaitre, même si on aurait pu faire mieux. Mais la plupart du temps, ce sont quelques heures de gagnées en redaction de code, et des jours de formation et maintenance perdus, ou alors juste une masquarade cachant simplement derrière le hype des principes sains de programmation.

Languages are more than just languages, they are a form of culture, and by being culture they tend to enforce (indirecty or directly) a certain way of doing things, i.e. standards or conventions. This means that if you know the language and its culture, there are less surprises and a longer learning or adaptation curve

(Extrait de Is Lisp Too Powerful ?)