alla ricerca di prove scientifiche dei vantaggi dell'utilizzo di una DSL

Question

Il discorso di Greg Wilson "parti di prove" ( http://www.slideshare.net/gvwilson/bits-of-evidence -2338367 ) discute la mancanza di prove dietro le seguenti affermazioni che Martin Fowler ha avanzato come benefici dell'uso di una DSL:

" [utilizzando un linguaggio settico specifico] porta a due vantaggi principali. Il primo e più semplice è la produttività del programmatore migliorata. Il secondo ... è ... comunicazione con esperti di dominio. & Quot; - Martin Fowler in Software IEEE luglio / agosto 2009

Domanda: ci sono studi empirici che dimostrano il miglioramento della produttività del programmatore o una migliore comunicazione con gli esperti del dominio dall'uso di una DSL?

Molte persone che costruiscono DSL non sono in grado di fornire una risposta motivata a "perché stai costruendo una DSL?" e "perché un DSL potrebbe aiutarti più di un modello a oggetti ben ponderato?" "

Ho sentito molto " Lo sto facendo perché è bello e tutti lo stanno facendo " - che non è una risposta razionale.

Credo che i DSL siano utili almeno in alcuni casi, ma che probabilmente non saranno un "proiettile d'argento". che dovrebbe essere usato indiscriminatamente. Mi piacerebbe vedere alcuni lavori scientifici che descrivono quando le DSL dovrebbero e non dovrebbero essere utilizzate, sulla base di ricerche empiriche.

Answer 1

Solo su Google, ho trovato un paio di articoli interessanti:

Lingue specifiche del dominio in pratica: Uno studio utente sui fattori di successo

Lingue specifiche del dominio rispetto a strutture orientate agli oggetti: un caso di studio di ingegneria finanziaria

Incorporamento del linguaggio specifico del dominio post-design: un caso Studia nel dominio dell'ingegneria del software

E immagino che potresti trovare dei riferimenti migliori a partire da Google Scholar ...

Answer 2

Dipende da ciò che consideri un DSL.

Ad esempio, css è un DSL? Penserei di sì, quindi ovviamente può rendere più semplice lo stile di una pagina, poiché in HTML 3 abbiamo usato le tabelle per gli arrangiamenti e non avevamo la flessibilità che facciamo adesso.

Se hai un DSL in modo che gli studenti possano progettare molecole usando solo i simboli atomici (H20), allora sarebbe più semplice che fare da soli la codifica, poiché puoi dare una rapida occhiata alla configurazione molecolare se dai simboli e tipi di legame, per esempio.

Non conosco un documento che mostri in un modo o nell'altro, ma, se il tuo pubblico di destinazione non è programmatore, allora un DSL ha un senso, quindi possiamo avere contabili che scrivono la loro applicazione, usando la loro terminologia, piuttosto che averli fornire requisiti agli sviluppatori.

Le DSL sono in circolazione da molto tempo, ma ora stanno diventando più popolari, quindi il tempo dirà quando ci sono più esempi di usi buoni e cattivi su quando è meglio usarlo e quando effettivamente è dannoso. Non scriverei software di monitoraggio medico con nessun DSL, per esempio.

Answer 3

L'intera premessa di "scientifico" in questo caso è dubbio. Semplicemente non c'è modo di garantire i criteri di "controllo" riproducibile "(" gruppo) " richiesto per uno studio empirico.

Answer 4

In generale, nella programmazione aziendale non esistono studi empirici seri sui benefici di qualcosa prima che venga utilizzato. Che si tratti di SQL, linguaggi orientati agli oggetti, linguaggi funzionali, garbage collection, ecc.

Queste cose tendono a essere decise dal mercato nel tempo.

Perché questo è il caso è probabilmente una combinazione di due motivi. Uno è che è molto costoso ottenere un buon studio empirico ed è molto più economico da un punto di vista economico provarlo. L'altra è che ogni situazione è diversa, quindi uno studio empirico dovrebbe iniziare con la limitazione molto stretta del problema in studio per avere un confronto adeguato tra l'uso di una DSL e non l'utilizzo di una, e il risultato finale dello studio non sarebbe molto utile oltre il tipo specifico di problema che è stato scelto.

Penso che possiamo dire per esperienza che nulla è un proiettile d'argento e insistere su una buona ragione per un approccio migliorerà qualsiasi soluzione, perché anche se un DSL aiuterebbe una situazione, se non sai perché lo stai facendo, non saprai se lo stai facendo bene e potresti finire per perdere l'intero vantaggio.

Answer 5

Questa è una domanda ragionevole e penso che ci siano problemi di definizione, come "cos'è un DSL"? Quando una parola d'ordine diventa "calda". diventa un'opportunità di marketing e viene divorziato dalla scienza di base, se presente.

Alcuni anni fa, ho scritto un libro (Building Better Applications, ISBN 0-442-01740-5, lungamente esaurito) in cui ho cercato di esaminare le prestazioni, non solo dei programmi, ma dei programmatori. Ho provato a guardarlo usando la teoria dell'informazione.

Mi è venuta in mente una grossolana misura di manutenibilità, in cui esiste un problema come struttura della conoscenza nella testa di qualcuno (nessun problema per dirlo a un ragazzo con intelligenza artificiale), e la sua soluzione esiste come una struttura testuale elaborata da una macchina. Quello che guardo è la relazione tra queste due strutture. Ad esempio, se si verifica una modifica nella descrizione del problema mentale, quante modifiche al codice sorgente sono necessarie per trasferirlo correttamente nel testo del programma? Un modo semplice per misurare che è diff il codice tra prima e dopo. Ora, una media che misura lo spazio dei cambiamenti che sono probabili e minore è la media, più è gestibile il codice sorgente.

La mia tesi era che più il codice mantenibile è, con questa misura, più assomiglia al modello mentale del dominio, quindi è ragionevole chiamarlo più "orientato al problema". o più "quotazioni specifiche del dominio". Una caratteristica che ho notato di tale codice è che tende ad essere più una istruzione del problema, piuttosto che una soluzione del problema. La soluzione non sta nella lingua, ma nell'implementazione della lingua, nella sottostruttura. Questa è un'eco, sebbene non un accordo diretto, con il concetto di "dichiarativo" vs. "imperativo" lingua.

Quindi, nel tentativo di rispondere alla tua domanda, direi che andiamo via da ciò che la gente potrebbe desiderare " DSL " per dire e guardare invece una definizione che sia almeno moderatamente inequivocabile.

Come parte dello sviluppo di quell'idea, mi ero imbattuto in una serie di tecniche, una delle quali è Differential Execution , che sembra fornire una buona manutenibilità per la codifica delle UI e riduce anche le dimensioni del codice sorgente di circa un ordine di grandezza. La mia teoria è che questo è un esempio riuscito di ciò che potrebbe essere un DSL.

Non sostengo che la manutenibilità possa essere raggiunta senza che il manutentore debba scalare una curva di apprendimento. Penso che la vera manutenibilità abbia un costo per i programmatori che devono imparare cose che potrebbero non essere facili da comprendere, ma una volta acquisite hanno il valore desiderato.

Answer 6

Dai linguisti Saphir e Worf, possiamo imparare, che le caratteristiche grammaticali di una lingua influenzano il nostro modo di pensare = se crei un DSL, penserai più al dominio specifico e probabilmente meno allo scopo generale. Si tratta di astrazione, proprio come i linguaggi di programmazione per scopi generali tendono ad astrarre dalla macchina, quindi siamo in grado di concentrarci maggiormente su algoritmi, strutture e design che su set di istruzioni, modalità di indirizzamento, dimensioni dei registri ecc.

Answer 7

Non sono sicuro che qualcuno abbia fatto studi nella misura in cui è necessario. La mia esperienza però è che un DSL può essere costoso da creare in primo luogo (forse 2X o più sforzo di un modello a oggetti più semplice per fare la stessa cosa). Tuttavia, una volta creati, gli sviluppatori otterrebbero benefici immediati potendo fare le cose più rapidamente con il DSL che con il modello.

Il problema con la domanda è che tratta tutti i DSL come uguali. Alcuni sarebbero più facili da implementare, altri più difficili - se uno sta facendo interfacce fluide / DSL interne o DSL esterne porterebbe a tempi / costi diversi da implementare.

L'unico vantaggio principale che potrebbe non essere coperto da tali studi è la facilità con cui un DSL può portare all'espressione e all'implementazione del codice. Può anche aiutare gli altri a comprendere l'intento del codice forse più facilmente - e poiché la fase di manutenzione del ciclo di vita dello sviluppo del software è un componente così grande dell'SDLC, ciò potrebbe portare a benefici molto più grandi (a lungo termine) di quelli inizialmente persi nella creazione del DSL .