Quand devrais-je utiliser un langage spécifique à un domaine? [fermé]

Question

Je voudrais des conseils pratiques sur le moment d'utiliser un langage propre au domaine . J'ai trouvé des ressources sur les avantages et les inconvénients, mais quel type de projet justifierait son utilisation?

Il semble qu’il faille beaucoup de temps pour créer et gérer une ligne DSL. Dans quel espace d’application puis-je obtenir un retour sur la productivité de mon investissement en temps?

Modifier: Il semble que l'utilisation la plus courante de DSL concerne les formats de fichier pour l'état persistant des données. Qu'en est-il de l'utilisation d'un DSL pour la logique et la structure du programme (peut-être la génération de code)? Quand est-ce faisable?

Modifier n ° 2 Je voudrais surtout savoir quand créer un DSL spécifique qui en vaut la peine. Bien sûr, nous devrions utiliser autant que possible les DSL existants pour gagner du temps.

Answer 1

Il existe très peu de bonnes raisons de créer un autre DSL. Le monde est gros avec des langues spéciales.

Pensez avec ces lignes.

1. Résolvez le problème avec un langage généraliste tel que Python, Java, C ++ .. peu importe.

2. Optimisez cette solution pour en déduire les fonctionnalités communes et créer une bibliothèque de classes très agréable, très élégante et vraiment extensible.

3. Optimisez cette bibliothèque de classes pour mettre en valeur "orthogonalité". Assurez-vous que toutes les fonctionnalités fonctionnent bien ensemble, sans aucun problème.

4. Si vous avez besoin d'une simplification de la syntaxe uniquement, créez un wrapper de script autour de votre belle bibliothèque de classes. Ceci est votre DSL. Pour Python, c'est facile - c'est déjà un langage dynamique. Pour Java, il y a des choses que vous pouvez exploiter. Pour C ++, la création de cet environnement de script flexible peut s'avérer un peu fastidieux.

5. Si vous avez encore besoin d'optimisation supplémentaire, envisagez d'écrire un compilateur pour votre DSL.

Answer 2

L'article d'ACM Computing Surveys, Quand et comment développer des langues spécifiques à un domaine , fournit des conseils sur ce livre, tout comme le livre de Martin Fowler en 2010, Langages spécifiques à un domaine .

Answer 3

Tout d'abord, j'utiliserais un DSL lorsque le domaine à problèmes que vous développez est un domaine très connu et que certains experts en gestion de ce domaine ont déjà fait créer une telle connexion DSL de manière à ne pas avoir à vous en préoccuper pour résoudre tous les problèmes qu’ils ont déjà résolus.

Si vous envisagez de créer un ADSL, je le ferais si votre entreprise se situe dans un domaine très particulier et si vous passez la majorité de votre temps. temps en se concentrant dans un domaine de problème spécifique. Si vous vous contentez de faire des applications pour plusieurs domaines problématiques, je ne conseillerais pas de prendre cette approche.

Par exemple, si votre entreprise ne construit que des applications fiscales, il peut être judicieux de créer un DSL pour système fiscal. Cela permettrait non seulement à votre langue d'être utilisable dans vos diverses applications fiscales, mais serait également commercialisable (utilisable) par d'autres entreprises de votre secteur qui souhaitent réaliser des tâches similaires à celles que vous accomplissez.

Bien sûr, vous devez pondérer les coûts / avantages de la construction d’un DSL par rapport à un cadre au-dessus d’un langage déjà existant.

Answer 4

Une situation qui vient à l’esprit est celle où les exigences imposent un niveau de personnalisation / configuration très élevé ou improbable . Vous fournissez donc une sorte de modèle de script par rapport à un DSL.

prend un assemblage de voiture " bras " Par exemple, il serait impossible de fournir un modèle de configuration pour prendre en charge diverses configurations d'usine. (détectez ceci, ne détectez pas cela, quand cela se produit, faites ceci ... etc.)

Toutefois, la compilation d’une nouvelle application avec une logique spécialisée pour chaque client n’est probablement pas une bonne solution. Donc, dans ce cas, vous créez un petit cadre qui deviendrait une sorte de DSL, puis pour chaque bras robotique que vous vendez, vous écrivez une petite application dans votre DSL et enregistrez-la avec le logiciel principal qui compilera et exécute votre DSL. scripts à la place. Ou mieux encore, des outils pour programmer la DSL sont inclus avec le bras robotique afin que votre client puisse "programmer". le bras dans le DSL que vous avez créé.

Un exemple concret qui me vient à l’esprit est Yahoo Pipes (on pourrait le considérer comme un ADSL) ou la directive robots.txt pour l’analyse automatisée du Web par exemple. Ils ne sont peut-être pas un DSL à part entière, mais ils montrent en quoi un DSL pourrait être utile.

Answer 5

Eh bien, il faut bien que quelqu'un le dise, alors voici:

Lisp est considéré par certains comme la langue propre au domaine pour tous les domaines . Un DSL bien supporté et très extensible.

Dans certains cas, la création d’un DSL à partir de Lisp (ou d’un langage similaire tel que Haskell) pourrait en réalité générer beaucoup de puissance avec un minimum d’effort, et donc en valoir la peine. Les DSL ne doivent pas toujours être une lourde charge de maintenance.

Answer 6

Le plus évident est que vous devez absolument les utiliser lorsque le langage existe déjà et est bien pris en charge. Les principaux exemples en sont UIL pour le développement d’interface graphique basé sur Motif et permettent de générer des versions de logiciels.

Si vous devez créer le vôtre, je dirais que pour chercher des domaines, il faut s’efforcer de spécifier les choses correctement et où votre compilateur ne peut pas vraiment trouver la plupart des erreurs, mais un compilateur spécifique à un domaine pourrait . Les interfaces graphiques en sont un excellent exemple, car la majeure partie du travail consiste à configurer la mise en page et qu'il existe généralement de nombreuses façons de créer des appels C ++ syntaxiquement valables qui n'ont aucun sens pour votre système d'interface graphique sous-jacent (EG: essayer d'incorporer un dialogue entier widget dans un bouton).

Je trouve que UIL représente un avantage considérable pour le développement d'interface graphique, car un compilateur UIL peut trouver des erreurs dans une spécification d'interface graphique qui ressemblent à un code compilable normal dans un compilateur C ++. Le fait qu’il soit bien pris en charge signifie que le code est facile à porter entre les plates-formes et même les générateurs d’interface graphique.