Crea un DSL vs. Incorpora una lingua esistente

Question

Questo spesso si presenta: la tua applicazione è diventata sufficientemente estesa da consentire di aggiungere un po 'di programmabilità per renderla flessibile. Un esempio potrebbe essere un'applicazione finanziaria: vuoi aggiungere un editor di formule in modo da poter creare le tue formule personalizzate senza dover ricompilare il codice.

Devi fare una scelta: crei il tuo tokenizzatore, parser e catena di interprete / compilatore, qualcosa che potrebbe richiedere molto tempo e potrebbe essere fatto in modo errato? O hai appena incorporato un altro linguaggio di scripting, che ha il problema che probabilmente gonferà il tuo codice ed esponerà la tua app a vulnerabilità di sicurezza.

Come bilanceresti i compromessi e prendere questa decisione?

Answer 1

Non ci sono svantaggi: incorporare un interprete accuratamente testato e ben documentato. Altrimenti, finirai con un abominio come MAXScript.

Answer 2

Che ne dici di un sistema plug-in? Ci sono alcuni vantaggi:

• Consenti agli sviluppatori clienti di svilupparsi nell'ambiente in cui è sviluppata l'app di origine.
• In sviluppo moderno. piattaforme, acquisisci molto controllo e sicurezza attraverso contratti software.
• Se progettato correttamente, è possibile attribuire correttamente colpa e malfunzionamento al plug-in che lo ha causato, come Chrome fa quando Flash o un altro plug-in di terze parti si arresta in modo anomalo.
• Facile aggiungere ulteriore sicurezza tramite licenze / certificati.
• È facile unire un plug-in con l'app se è fantastico e vuoi che tutti i tuoi clienti lo abbiano.

Answer 3

A meno che il DSL non sia abbastanza semplice da far sì che il parser / interprete si adatti a una singola pagina, consiglierei di incorporare un linguaggio di script esistente.

Di recente ho trascorso diversi mesi a lavorare su un progetto che ho ereditato che conteneva un linguaggio di scripting completamente sviluppato in casa. Ho investito molto tempo nella comprensione del parser & amp; interprete, in modo da poter correggere i bug, renderlo sicuro, estenderlo, ottimizzarlo. Inoltre, c'è stato il tempo di imparare e comprendere le stranezze di questo nuovo linguaggio di scripting che ha risvegliato quasi come, ma non proprio lo stesso, di altri che già conoscevo.   Avrei preferito piuttosto usare quel tempo per incorporare una lingua esistente come Ruby o Lua e sintonizzarla per adattarla alle nostre esigenze.

L'utente avrebbe beneficiato di una lingua in cui era più facile programmare, con meno stranezze e gotcha. Avrei beneficiato di una più profonda comprensione degli interni di un & amp; ben progettato linguaggio popolare, invece di acquisire conoscenze esperte relativamente inutili in "myScript".

Answer 4

Vorrei creare il mio interprete usando un generatore di parser esistente (come ANTLR o i combinatori di parser di Haskell / Scala). Non è poi così difficile, e per le lingue semplici, è davvero abbastanza facile. Creo l'implementazione per un DSL diabolicamente semplice in un pomeriggio e ha funzionato perfettamente la prima volta (senza bug).

Detto questo, non devi progettare il tuo linguaggio Turing Complete. Se le tue esigenze sono così sofisticate, probabilmente dovresti incorporare un linguaggio di scripting. Se fai parte della JVM, JRuby e Clojure sono candidati eccellenti per questo genere di cose, in particolare dati i loro punti di forza nell'area dei DSL interni.