Site original : Sam & Max: Python, Django, Git et du cul
Un Domain Specific Language est un langage créé pour une tache très particulière. CSS, HTML et SQL sont des bons exemples de DSL populaires. Moins connus: ReactQL, QML, Less, Latex, XPath, Graphviz…
Suite a ce tuto sur la fabrications 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 !
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.
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: XLM et YML n’en sont pas, contrairement à ce qu’on peut lire. Car ils sont généralistes, et donc pas “domain spécific” 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.
Pourquoi avez vous besoin d’un nouveau langages ? 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 ?
Créer un DSL , donc un nouveau langage implique vous avez besoin:
Et il faut tenir tout ça à jour.
Ah. Ah. Ah.
Personne ne le fait jamais, ce qui font 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 boite quand ça arrivera. Eux il se sont bien amusé a créer un parseur pour le fun. D’ailleurs ça fait classe sur le CV.
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:
Si créer une API n’aide pas assez, par exemple vous faites 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é.
Aller, 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:
Mais dans tous ces cas, ne faites un DSL que si: