Toute la complexité est masquée derrière une syntaxe et des « outils » qui se veulent simples.
La partie masquée de la complexité est rendue artificiellement inaccessible, parce que les API mises à disposition sont trop partielles et n’ont pas de points d’extension :
Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.
On doit donc se reposer entièrement sur la documentation, qui est souvent mauvaise.
La notion même de DSL rends complexe le lien entre une déclaration et le code exécuté – ce qui empêche l’exploration pour savoir ce qui va être fait exactement.
On peut mettre du code arbitraire ou presque, mais le debug est impossible (notamment les points d’arrêt).
Rien n’est typé et la syntaxe est trop libérale, on découvre toutes les typo au runtime.
Comme le DSL masque la complexité, plus personne ne comprends ce qui se passe réellement2. Conséquence : les plugins sont d’une qualité catastrophique et conçus pour ne gérer que le cas précis de la personne qui les a développés – or ces plugins sont indispensables.
Pire : les documentations pour développer (ou aider à la maintenance) des plugins sont elles-mêmes mauvaises, ce qui empire le phénomène.
Tout ce que tu décrit au choix :
marche aussi bien pour l'utilisation de langages déclaratifs (1, 2, 4, 5, 8)
n'ont rien d'intrinsèque à l'utilisation d'un langage impératif (7, 9)
le typage est très dépendant du langage que tu choisi (7)
je ne vois pas beaucoup d'outil véritablement aider pour le 3, par exemple netbeans est le seul outil à faire une intégration poussée de maven, les gens se contente très bien d'intelij qui a une intégration à peu près équivalente pour maven et gradle
Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.
Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.
# Bof
Posté par barmic 🦦 . En réponse au lien La « configuration » par langage dédié (DSL), une invention de Satan. Évalué à 3.
Tout ce que tu décrit au choix :
Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.
Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll