Quando dovrei usare una lingua specifica del dominio? [chiuso]

Question

Vorrei alcune indicazioni pratiche su quando dovrei usare un Lingua specifica del dominio . Ho trovato risorse su vantaggi e svantaggi, ma che tipo di progetto ne giustificherebbe l'utilizzo?

Sembra che ci sia un grande investimento in tempo per creare e mantenere un DSL, quindi in quale spazio di applicazione otterrei un ritorno di produttività sul mio investimento di tempo?

Modifica: Sembra che l'uso più comune di DSL sia per formati di file per lo stato dei dati persistente, che ne dici di usare un DSL per la logica e la struttura del programma (forse la generazione di codice)? Quando è possibile?

Modifica n. 2 Mi chiedo principalmente quando vale la pena creare un DSL specifico. Ovviamente dovremmo usare DSL esistenti il ??più possibile per risparmiare tempo.

Answer 1

Ci sono pochissime buone ragioni per creare un altro DSL. Il mondo è grasso con linguaggi speciali.

Pensa insieme a queste linee.

1. Risolvi il problema con un linguaggio generico come Python, Java, C ++ .. qualunque.

2. Ottimizza quella soluzione per scomporre le caratteristiche comuni e creare una libreria di classi davvero gradevole, davvero elegante, davvero estensibile.

3. Ottimizza quella libreria di classi per enfatizzare "ortogonalità". Assicurati che tutte le funzioni funzionino bene insieme, senza problemi.

4. Se hai bisogno di semplificare solo la sintassi, crea un wrapper di scripting attorno alla tua bella libreria di classi. Questo è il tuo DSL. Per Python, questo è facile: è già un linguaggio dinamico. Per Java, ci sono cose che puoi sfruttare. Per C ++ può essere un po 'complicato costruire questo ambiente di scripting flessibile.

5. Se hai ancora bisogno di ulteriore ottimizzazione, considera la possibilità di scrivere un compilatore per il tuo DSL.

Answer 2

L'articolo ACM Computing Surveys Quando e come sviluppare linguaggi specifici del dominio fornisce consigli su proprio questo argomento, così come il libro di Martin Fowler del 2010 Lingue specifiche del dominio .

Answer 3

In primo luogo, vorrei utilizzare un DSL quando il dominio problematico contro cui stai sviluppando è un dominio ampiamente noto, e alcuni esperti aziendali di quel dominio hanno già attraversato grandi fare di tutto per costruire un DSL in modo tale che non dovresti fare tutto da solo per risolvere tutti i problemi che hanno già capito.

Se stai pensando di creare un DSL, lo prenderei in considerazione se la tua attività viene svolta in un'area molto particolare e spendi la maggior parte delle tue tempo focalizzato in un dominio specifico del problema. Se vai in giro facendo applicazioni per più domini problematici, allora non consiglierei di adottare questo approccio.

Ad esempio, se la tua azienda si occupa esclusivamente della creazione di applicazioni fiscali, potrebbe essere una buona idea creare un DSL del sistema fiscale. Ciò consentirebbe alla tua lingua non solo di essere utilizzabile da te nelle tue varie applicazioni fiscali, ma sarebbe anche commerciabile (utilizzabile) da altre aziende del tuo settore che vogliono fare cose simili che stai realizzando.

Ovviamente, devi ponderare i costi / benefici della costruzione di una DSL rispetto a un framework sopra una lingua già esistente.

Answer 4

Una situazione che viene in mente è quando i requisiti richiedono un livello molto alto o improbabile di personalizzazione / configurazione . Quindi forniresti invece una specie di modello di scripting contro un DSL.

Prende un assemblaggio di auto " arm " ad esempio, fornire un modello di configurazione per supportare varie configurazioni di fabbrica sarebbe impossibile. (rileva questo, non rilevarlo, quando ciò accade, fallo ... ecc.)

Ma compilare una nuova applicazione con una logica specializzata per ogni cliente non è probabilmente un buon modo di procedere. Quindi, in questo caso, crei un piccolo framework che diventerebbe una specie di DSL e quindi per ogni braccio robotico che vendi, scrivi una piccola app nel tuo DSL e la salvi insieme al software principale che compila ed esegue il tuo DSL script invece. O meglio, gli strumenti per programmare la DSL sono inclusi insieme al braccio robotico in modo che il cliente possa "programmare". il braccio stesso nel DSL che hai creato.

Un esempio del mondo reale che viene in mente è Yahoo Pipes (si potrebbe pensare ad esso come un DSL) o la direttiva robots.txt per il crawler web automatizzato, ad esempio. Potrebbero non essere una DSL in piena regola, ma dimostrano dove la DSL potrebbe essere utile.

Answer 5

Beh, qualcuno deve dirlo, quindi ecco qui:

Lisp è considerato da alcuni come la lingua specifica del dominio per qualsiasi dominio. Un DSL ben supportato e molto estensibile a questo.

In alcuni casi, la creazione di un DSL da Lisp (o un linguaggio simile come Haskell) potrebbe effettivamente fornire molta potenza con il minimo sforzo, e quindi varrebbe la pena. Le DSL non devono sempre comportare grossi oneri di manutenzione.

Answer 6

Il più ovvio è che dovresti assolutamente usarli quando la lingua esiste già ed è ben supportata. I primi esempi di questo sono UIL per lo sviluppo di GUI basati su Motif e creano build di software.

Se devi crearne uno tuo, direi che cercare domini è una grande quantità di sforzo nel solo specificare le cose correttamente e dove il tuo compilatore non riesce davvero a trovare la maggior parte degli errori, ma un compilatore specifico del dominio potrebbe . Le GUI sono un ottimo esempio, poiché la maggior parte del lavoro consiste nell'impostare il layout e in genere ci sono molti modi per effettuare chiamate C ++ sintatticamente valide che non hanno alcun senso per il tuo sistema di GUI sottostante (EG: cercare di incorporare un'intera finestra di dialogo widget all'interno di un pulsante).

Trovo che UIL sia particolarmente utile per lo sviluppo della GUI perché un compilatore UIL può trovare errori in una specifica della GUI che sembrano proprio un normale codice compilabile normale per un compilatore C ++. Il fatto che sia ben supportato significa che il codice è facile da trasferire tra le piattaforme e persino i costruttori della GUI.