à la recherche de preuves scientifiques des avantages de l'utilisation d'une LIS

Question

Le discours de Greg Wilson "des éléments de preuve" ( http://www.slideshare.net/gvwilson/bits-of-evidence -2338367 ) discute du manque de preuves derrière les affirmations suivantes que Martin Fowler a avancées comme avantages de l’utilisation d’une DSL:

"[utilisant un langage spécifique au domaine] a deux avantages principaux. Le premier, et le plus simple, est l'amélioration de la productivité du programmeur. La seconde ... est ... une communication avec des experts du domaine. " - Martin Fowler dans IEEE Software juillet / août 2009

Question: Existe-t-il des études empiriques démontrant l'amélioration de la productivité des programmeurs ou une meilleure communication avec les experts de domaine grâce à l'utilisation d'un DSL?

De nombreuses personnes qui construisent des DSL ne sont pas en mesure de fournir une réponse motivée à "pourquoi construisez-vous un DSL?" et "pourquoi un DSL vous aiderait-il davantage qu'un modèle d'objet bien factorisé?"

J'entends beaucoup de "je le fais parce que c'est cool et que tout le monde le fait" - ce qui n’est pas une réponse rationnelle.

Je pense que les DSL sont utiles au moins une partie du temps, mais qu'ils ne sont pas susceptibles de constituer une "solution miracle". cela devrait être utilisé sans discernement. J'aimerais voir des travaux scientifiques décrivant quand les DSL devraient être utilisés ou non, sur la base de recherches empiriques.

Answer 1

Juste sur Google, j'ai trouvé quelques articles intéressants:

Langues spécifiques à un domaine dans la pratique: Etude utilisateur sur les facteurs de réussite

Langages spécifiques à un domaine par rapport à des cadres orientés objet: étude de cas sur l'ingénierie financière

Incorporation d'un langage spécifique à un domaine spécifique: un cas Étudier dans le domaine du génie logiciel

Et j'imagine que vous pourriez trouver de meilleures références à partir de Google Scholar ...

Answer 2

Cela dépend de ce que vous considérez comme un DSL.

Par exemple, css est-il un DSL? Je pense que oui, alors cela peut évidemment faciliter le style d’une page, car en HTML 3, nous utilisions des tableaux pour les arrangements, mais nous n’avions pas la souplesse que nous avons maintenant.

Si vous avez une LIS afin que les étudiants puissent concevoir des molécules en utilisant uniquement les symboles atomiques (H20), il serait alors plus simple que de coder vous-même, car vous pouvez examiner rapidement la configuration moléculaire si vous donnez les symboles et les types de collage, par exemple.

Je ne connais pas de document montrant d'une manière ou d'une autre, mais si votre public cible n'est pas des programmeurs, un DSL est logique. Vous pouvez donc demander à des comptables d'écrire leur application, en utilisant leur terminologie, plutôt que de les avoir. donner des exigences aux développeurs.

Les DSL existent depuis longtemps, mais deviennent de plus en plus populaires. Le temps nous dira quand il y aura plus d'exemples d'utilisations bonnes et mauvaises, quand il est préférable de les utiliser et quand c'est réellement préjudiciable. Je n'écrirais pas de logiciel de surveillance médicale avec un DSL, par exemple.

Answer 3

La prémisse de "scientifique" dans ce cas est douteux. Il n'y a tout simplement aucun moyen de garantir les critères de "reproductible", "contrôle (groupe)". requis pour une étude empirique.

Answer 4

En général, dans les programmes d’entreprise, il n’existe pas d’études empiriques sérieuses sur les avantages d’un produit avant son utilisation. Qu'il s'agisse de SQL, de langages orientés objet, de langages fonctionnels, de garbage collection, etc.

Ces choses ont tendance à être décidées par le marché au fil du temps.

La raison en est probablement une combinaison de deux raisons. Premièrement, il est très coûteux d’obtenir une bonne étude empirique et il est beaucoup moins coûteux d’un point de vue économique de simplement essayer. L’autre est que chaque situation est différente et qu’une étude empirique devrait commencer par limiter le problème à l’étude de façon très restrictive pour permettre une comparaison appropriée entre l’utilisation d’une LIS et la non-utilisation, et le résultat final de l’étude ne serait pas très précis. utile au-delà du type de problème choisi.

Je pense que nous pouvons affirmer par expérience que rien n’est une solution miracle, et insister sur le bien-fondé d’une approche améliorera toute solution, car même si un DSL aiderait à résoudre une situation, si vous ne savez pas pourquoi vous le faites, vous ne saurez pas si vous le faites bien et vous risquez de rater tout le bénéfice.

Answer 5

C’est une question judicieuse, et je pense qu’il existe des problèmes de définition, tels que "Qu'est-ce qu'un DSL"? Lorsqu'un mot buzword devient "chaud" cela devient une opportunité de marketing et s’écarte de la science sous-jacente, s’il en existe.

Il y a quelques années, j'ai écrit un livre (Building Better Applications, ISBN 0-442-01740-5, longtemps épuisé) dans lequel j'essayais d'examiner la performance, non seulement des programmes, mais également des programmeurs. J'ai essayé de le regarder en utilisant la théorie de l'information.

J'ai proposé une mesure grossière de maintenabilité, où un problème existe sous la forme d'une structure de connaissances dans la tête de quelqu'un (aucun problème pour un responsable de l'IA), et sa solution existe sous la forme d'une structure textuelle traitée par une machine. Ce que je regarde est la relation entre ces deux structures. Par exemple, si une modification est apportée à la description du problème mental, combien de modifications du code source sont nécessaires pour la transférer correctement dans le texte du programme? Un moyen simple de mesurer cela consiste à différencier le code entre avant et après. Maintenant, faites la moyenne de cette mesure sur l’espace des modifications probables, et plus la moyenne est basse, plus le code source est maintenable.

Ma thèse était que plus le code était maintenable, plus il ressemblait au modèle mental du domaine, il était donc raisonnable de l'appeler davantage "orienté problème". ou plus "spécifique au domaine". Une caractéristique de ce code que j’ai remarquée est qu’il tend à être davantage une déclaration du problème que une solution du problème. La solution ne réside pas dans le langage, mais dans la mise en œuvre du langage, la sous-structure. C’est un écho, bien que pas un accord direct, avec le concept de "déclaratif" vs "impératif" langue.

Donc, pour tenter de répondre à votre question, je dirais que nous devons nous écarter de ce que les gens voudraient peut-être "DSL". pour signifier et au lieu de regarder une définition qui est au moins modérément non ambiguë.

Dans le cadre de l'élaboration de cette idée, je suis tombé sur un certain nombre de techniques, dont Exécution différentielle , ce qui semble offrir une bonne maintenabilité pour le codage des interfaces utilisateur et réduit également la taille du code source d'un ordre de grandeur approximatif. Ma théorie est que c'est un exemple réussi de ce que pourrait être un DSL.

Je ne prétends pas que la maintenabilité puisse être obtenue sans que le responsable ne soit obligé de gravir une courbe d'apprentissage. Je pense que la maintenabilité réelle a un coût pour les programmeurs qui doivent apprendre des choses difficiles à comprendre, mais qui, une fois comprises, ont la valeur désirée.

Answer 6

Des linguistes Saphir et Worf, nous pouvons apprendre que les caractéristiques grammaticales d’une langue influencent notre façon de penser = si vous créez un DSL, vous penserez plus spécifiquement à un domaine et probablement moins généraliste. Tout est une question d’abstraction, tout comme les langages de programmation généraux tendent à s’abstraire de la machine. Nous pouvons donc nous concentrer davantage sur les algorithmes, les structures et la conception que sur les jeux d’instructions, les modes d’adressage, les tailles de registre, etc.

Answer 7

Je ne suis pas sûr que quelqu'un ait fait des études dans la mesure où vous en avez besoin. Mon expérience est cependant qu’un DSL peut être coûteux à créer en premier lieu (éventuellement plus de deux fois plus d'effort qu'un modèle d'objet plus simple pour faire la même chose). Cependant, une fois créés, les développeurs obtiendraient un avantage immédiat en étant en mesure de faire les choses plus rapidement avec le DSL qu'avec le modèle.

Le problème avec la question est que tous les DSL sont traités de la même manière. Certaines seraient plus faciles à mettre en œuvre, d’autres plus difficiles - qu’il s’agisse d’interfaces Fluent / DSL internes ou de DSL externes, la mise en œuvre nécessiterait des temps / coûts différents.

Le principal avantage qui pourrait ne pas être couvert par de telles études est la facilité avec laquelle un DSL peut conduire à l’expression et à la mise en oeuvre de code. Cela peut également aider les autres utilisateurs à comprendre plus facilement l’intention du code. Etant donné que la phase de maintenance du cycle de vie du développement logiciel est une composante si importante du SDLC, elle pourrait générer des avantages beaucoup plus importants (à long terme) que ceux initialement perdus lors de la création du DSL. .