Esistono tipi di applicazioni killer, classi di problemi algoritmici, ecc., dove è meglio, a lungo termine, creare la mia lingua?
PS: Giusto per essere sicuro, intendo un nuovo linguaggio di programmazione e un compilatore, non un nuovo compilatore per una lingua esistente.
EDIT : grazie per le risposte. Puoi fornire alcuni esempi, dove è assolutamente inutile creare un DSL o casi in cui una DSL potrebbe essere una buona idea?
È certamente importante che una persona scriva la propria lingua per scopi educativi. Per saperne di più sulla programmazione del linguaggio e sulla progettazione del compilatore. Ma gli usi del mondo reale sono pochi e distanti tra loro.
Nella scrittura della tua lingua sei:
Quindi, se hai intenzione di scrivere la tua lingua per il tuo progetto, allora le funzionalità che fornisce che altre lingue non hanno bisogno di compensare i costi sopra indicati.
Ad esempio, prendi lo sviluppo di giochi. Spesso hanno bisogno di mini-lingue nei loro giochi o linguaggi di scripting. Usano queste lingue per scrivere una grande quantità di eventi di gioco che accadono. Tuttavia, anche in questo caso, scelgono quasi sempre i linguaggi di scripting esistenti e li adattano alle loro esigenze.
Lasciatemi citare Paul Vick, ex capo sviluppatore del compilatore VB e ora lavoro su Project Oslo e sul linguaggio M:
It’s mind-bendingly, stupendously difficult to build a new language, even one that’s largely based on an existing one. Yet many programmers think, “hey, I use languages, how hard can this be?” and go at it. … probably over 98% of them fail to ever gain any traction at all, but god bless the optimists because without them we’d never get the 2% of languages that succeed. I’m personally willing to sacrifice the millions of dollars and hours wasted on languages that never make it just so that we can get languages like C# and Java and Ruby and Python and so on.
So the fact that coming up with a new language is a bad idea shouldn’t dissuade people from developing new DSLs, it should just give them pause and hopefully a little humility. The key, I think, is to start small and to stay small.
Quando è ragionevole?
Quando ne hai voglia!
Non ascoltare queste persone che hanno commenti sdolcinati che in pratica dicono:
"Non farlo perché è troppo difficile e la lingua X è migliore di qualsiasi altra lingua con cui puoi inventare".
Il fatto è che la creazione di una DSL avviene sempre. Un framework è un DSL. Una macro è una DSL. Ogni volta che scrivi una funzione per il tuo programma, fa parte di una DSL. Certo, è nei limiti della grammatica, ma il vocabolario è parte di una lingua. Questo è il motivo per cui le industrie spesso creano il proprio vernacolo: è più efficiente!
Se "non farlo" era la risposta giusta, scriveremmo COBOL e Fortran.
Potresti voler leggere parti del il prossimo libro DSL di Martin Fowler , se stai pensando di scrivere la tua lingua .
Non riesco davvero a pensare a un caso aziendale per creare una lingua da zero se non che è una straordinaria esperienza di apprendimento.
Modifica: per DSL ci sono un sacco di casi aziendali, ma la chiave qui non è quella di essere portato via e Keep It Simple.
Suggerisco che le domande chiave siano: "Che problema sto cercando di risolvere?" e "Chi ottiene il ROI?"
Se stai cercando di costruire le tue abilità e la tua esperienza, allora avanti tutta, ma non in un sistema di produzione che dovrebbe risolvere il problema di qualcun altro.
Sembra che il motivo principale per cui desideri una nuova lingua sia che inizi a scoprire pattern nel tuo codice che le lingue esistenti non gestiscono bene. Ma ci sono un sacco di problemi con la creazione della tua lingua. Ti perderai tutte le librerie e i framework che sono stati creati per le lingue esistenti. Trascorrerai molto tempo a progettare e implementare la nuova lingua, che è tutto il tempo che non devi spendere per il vero compito di programmazione. Passerai un sacco di sforzi a convincere gli altri sviluppatori che dovrebbero usare la tua lingua. E avrai difficoltà a reclutare e formare nuovi sviluppatori.
Perché non scrivere in una lingua come Lisp che ti consente di estendere la lingua mentre scopri nuovi pattern? Quindi, ottieni tutta la potenza di una nuova lingua con tutti i vantaggi di una lingua consolidata.
Un motivo potrebbe essere quello di crearlo come esperimento per conoscere la progettazione del linguaggio e la compilazione del compilatore.
Un altro motivo potrebbe essere quello di creare un linguaggio di scripting in un'applicazione quando non hai la possibilità di aggiungere un'API di terze parti.
Non penso che tu possa programmare senza creare un nuovo linguaggio, quindi è bene rendersi conto di quello che stai facendo e capire i problemi.
Un linguaggio comune come VB, Java, C #, ecc. è solo una lingua di base . Non appena aggiungi classi, metodi, ecc., Hai aggiunto vocabolario e semantica. Esistono molti modi per implementare le lingue: parsing & traduzione, parsing & interpretazione, macro su una lingua esistente, aggiunta di classi e metodi a una lingua esistente.
Come fai a sapere se l'hai fatto? La misura che uso è modifica numero . Se arriva il requisito di una frase A, procedo a implementare il requisito nel codice. Quando ho finito & ho eliminato tutti i bug, controllo il codice e il repository del codice mi fornisce un elenco delle modifiche apportate, B. La B più piccola è, migliore è la lingua. Mediata nello spazio di reale e amp; requisiti possibili, quella misura mi dice quanto sia "specifica di dominio" la lingua.
Se occorrono modifiche al codice N per implementare 1 requisito e qualche volta si commettono errori, il numero di bug introdotti è approssimativamente proporzionale a N. Nel limite dove N = 1, è quasi impossibile da introdurre un bug senza provare.
Si noti che questa è una sfida diretta al "code bloat" che vediamo oggigiorno.
AGGIUNTO: in risposta alla tua richiesta di un esempio, vedi esecuzione differenziale . Non dirò che può essere compreso rapidamente, ma riduce in modo significativo il codice UI.
È sempre "fattibile", usare la parola nella tua domanda (originale), ma non è molto spesso utile e molto raramente ottimale data l'abbondanza di linguaggi e strutture ben supportati e maturi che esistono.
È comunque una sfida intellettuale interessante.
Solo se il core business del tuo team è la programmazione dei linguaggi.
Ho lavorato su un linguaggio di programmazione creato in una società finanziaria.
Chiaramente, per l'architetto stesso questa è stata una grande sfida e ha migliorato le sue capacità.
Inevitabilmente, il linguaggio non poteva crescere o migliorare a un ritmo simile a quello che poteva fare C # o Java - hanno team dedicati a farlo.
Il linguaggio si è presto ristabilito dal momento che nessuno dei nuovi voleva assumersi il compito di migliorare il progetto per gli animali domestici di qualcun altro.
L'architetto originale è andato via. Il linguaggio è appassito e muore dopo 10 anni.
Quei 10 anni sono stati un inferno per chiunque avesse avuto la sfortuna di lavorare su un linguaggio senza uscita.
Quindi vai avanti, crea la tua lingua, ma per favore non chiedere a nessun altro di usarla effettivamente. Per favore non aspettarti che nessun altro ti ringrazi per questo.
Progettare le lingue può essere divertente. Ma non devi limitarti ai linguaggi di programmazione.
Se creo un'applicazione moderatamente complessa, mi piace aggiungere un tipo di linguaggio di macro / scripting per rendere più facile l'esecuzione di attività ripetitive complesse. La maggior parte degli utenti non utilizzerà questa funzionalità, ma i pochi che lo utilizzano sono molto grati. Inoltre, mi assicuro che sia prezioso per le persone di supporto aiutarli a risolvere i problemi dei clienti.
È del tutto ragionevole se fatto per estendere le tue abilità e per imparare.
Oltre a questo, se devi fare la domanda, allora non lo è. Se stai cercando di capire se puoi gestire una certa classe di algoritmi o un determinato dominio problematico meglio delle lingue esistenti, per prima cosa devi essere un esperto nell'area che stai affrontando. Saprai che è appropriato quando le tue capacità e esperienza te lo dicono.
Potresti sbagliarti anche tu, ma avresti bisogno di un altro esperto per convincerti di quello (o per mostrarti che non sei l'esperto che pensi di essere). Una discussione vivace che sarebbe, non una semplice Q-and-A come la troverai qui.
A parte gli scopi di autoistruzione, vorrei affermare che oggi non è assolutamente necessario creare la tua lingua. In ogni circostanza Mai. Indipendentemente da ciò che vuoi fare, esistono dei carichi di navigazione delle lingue esistenti che puoi adottare / adattare alle tue esigenze.
Dipende definitivamente dalla situazione. Come diceva nosklo - Se hai una buona idea, un nuovo concetto o qualcosa del genere ti consiglio vivamente di farlo.
In generale, suggerirei di fare affidamento su una tecnologia consolidata.
Ma se sei interessato a creare la tua "lingua" da provare: YACC & Lex
Puoi, semplicemente, non prenderti con l'anti-pattern "Ricreare la ruota quadrata".
Significa che stai ricreando ciò che è già stato fatto, solo più povero dell'originale / i.
Wouter era noto per aver creato un nuovo linguaggio per qualsiasi nuova idea. Puoi trarre ispirazione dal suo lavoro: pagina della lingua di programmazione di Wouter .
Quando creare la tua lingua?
Quando vuoi, come un grande progetto per hobby.
Per un linguaggio specifico del dominio. Questi possono essere abbastanza elaborati; guarda cosa succede nella community di Interactive Fiction (o avventura testuale) verificando l'archivio .
Quando i tuoi obiettivi sono molto ambiziosi e pensi di poter fare un vero progresso, come il progetto Arc di Paul Graham.
Inoltre, in qualsiasi linguaggio sufficientemente adattabile (forse C ++, sicuramente Common Lisp) nel processo di sviluppo di costrutti di basso livello.
Quando evitarlo come vorresti, spero, eviti un cliche come evitarlo come la peste?
Quando deve essere la base per lo sviluppo continuo di progetti reali. Arriverà sempre in ritardo rispetto a ciò che è commercialmente disponibile a buon mercato, e paralizzerà lo sviluppo ulteriore. Ho lavorato per un'azienda con una propria versione di COBOL e non voglio mai lavorare in un'altra azienda che mantiene la propria lingua. Abbiamo visto altre versioni di COBOL avere migliori funzionalità e strumenti migliori, mentre eravamo bloccati con gli stessi problemi. (Non voglio più lavorare con COBOL, ma questa è un'altra storia.)
Le situazioni in cui potresti creare la tua lingua non rientrano in questo. I progetti di hobby non sono usati per lo sviluppo reale. Qualcosa come Arc avrà successo (e otterrà molteplici implementazioni e un'ulteriore evoluzione e sviluppo) o fallirà (e nessun altro lo userà). Un linguaggio di dominio limitato è solo una parte di un progetto e, dato che è piccolo, può essere migliorato nel tempo. Un linguaggio di avventura testuale è usato per scrivere singoli giochi, e quei giochi, oltre ad essere progetti di hobby, non sono quasi mai usati per lo sviluppo continuo.
La mia prospettiva è che i DSL sono generalmente una "idea debole", ed è più produttivo a lungo termine utilizzare un linguaggio standard e costruire le esigenze specifiche del dominio come una libreria del "non-DSL".
Tuttavia, è possibile che le tue esigenze siano abbastanza personalizzate da preferire un DSL (non solo un'implementazione gcc o lisp leggermente modificata) per la tua azienda. Molte aziende utilizzano i drop-in delle lingue correnti che hanno come obiettivo quello che stanno facendo, senza scrivere / mantenere la propria lingua. Ad esempio, ho sentito che PHP ha un buon drop-in; Lua è progettato per essere un drop-in, ModelView utilizza Python e AutoCAD ha AutoLISP come script.
Non c'è niente di sbagliato nello scrivere il tuo linguaggio di programmazione se puoi sfruttare gli strumenti esistenti. Nel mondo di oggi ciò significherebbe che lo si definisce in una sintassi utilizzabile in un linguaggio esistente (come Java o C #) o si scrive un piccolo sistema di trasformazione (macro expander) che genera codice in una lingua esistente.
Il passaggio al codice macchina sta reinventando un sacco di ruote ...
Un buon motivo per un DSL è rappresentare i dati del dominio in modo succinto. Ciò consente agli esperti di dominio di lavorare direttamente con i dati invece di dover passare attraverso gli altri. Il trucco è quindi di avere i programmi risultanti in un modulo facile da elaborare.
In generale, la risposta sarebbe un grande NO. Tra le centinaia di lingue là fuori c'è di solito una che si adatta al tuo problema.
Tuttavia ci sono circostanze in cui è un'opzione razionale sviluppare una nuova lingua: -
La lingua più adatta è compositionality o mette insieme gli stessi componenti in modi diversi.
Se il tuo problema di dominio ha solo bisogno di impostare un gruppo di interruttori ortogonali, una lingua probabilmente non aggiunge molto ai moduli, un'interfaccia grafica o una configurazione di testo diritta. file. (Suppongo qui che un file pieno di coppie di valori chiave non sia che cosa intendi per "lingua".)
OTOH, se la tua configurazione è come un vero linguaggio es. verbi e nomi possono essere messi insieme in molte (e nuove) combinazioni a qualsiasi grado di complessità, quindi un linguaggio diventerà quasi inevitabile, perché l'esplosione combinatoria del tentativo di specificare ciò che si desidera con qualsiasi altro metodo travolge.
A parte gli esercizi di apprendimento, è ragionevole creare il tuo linguaggio di programmazione solo quando comprendi altre lingue, il tuo specifico dominio problematico e il modo in cui le lingue esistenti affrontano quel dominio problematico e questa comprensione è abbastanza approfondita da sapere una nuova lingua è una soluzione ragionevole senza la necessità di porre la domanda.
L'ultima volta che ho deciso di farlo in un progetto per hobby ho iniziato a specificare ciò che volevo che la sintassi fosse simile e ho realizzato a metà che stavo reinventando il prologo. Altre lingue che potrebbero essere una buona idea quando pensi di aver bisogno di inventare una lingua sono lisp, lua o qualcosa come Haskell. Fondamentalmente, tutte quelle lingue che hai ignorato al college perché pensavi che non sarebbero mai state utili.
Una ragione è per scopi educativi, come già affermato. Ma ce ne sono altri. Ad esempio, esistono molti linguaggi di ricerca come Sing# sul sistema operativo Singularity e BitC su Coyotos progettati perché le lingue esistenti non offrono le funzionalità richieste ( ad esempio la verifica a livello di lingua).
Tom Van Cutsem ha recentemente scritto una risposta a questa domanda:
Riepilogo puntata (da quella pagina):
Probabilmente mai.
Lua è la scelta migliore che puoi ottenere se vuoi incorporare la lingua in qualsiasi altra lingua.
Al momento sono presenti lingue specifiche per domini di piccole dimensioni, e ha senso in alcune applicazioni.
Altrimenti, le ragioni sono principalmente accademiche.
Creare un linguaggio quando non è necessario, è davvero una brutta cosa da fare a causa della complessità implicata nello sviluppo e nel mantenerlo. Ho visto molti progetti che introducono una sorta di linguaggio di scripting specifico solo per quel programma, ed è stata la cosa che stava rallentando lo sviluppo della base di una quantità enorme. Buoni esempi sono ad esempio i linguaggi di automazione come Phantom, AutoHotKey, AutoIt. Questi strumenti sarebbero IMO molto meglio se usassero alcuni linguaggi di emarginazione conosciuti come Lua.
La tua "modifica" sembra essere una domanda sostanzialmente diversa ("quando dovrei creare un DSL?" invece della domanda originale che la gente capiva come "quando dovrei creare un nuovo linguaggio di programmazione generico"). Sembra che le persone abbiano risposto esaurientemente alla domanda "originale", ma ci sono poche risposte che forniscono criteri specifici per quando utilizzare un DSL. Quindi propongo una lista di controllo:
Se tutte queste sono vere, un DSL potrebbe essere appropriato.
Are there types of killer applications, classes of algorithmic problems, etc., where it is better, in the long run, to create my own language?
Dipende.
Prendiamo il nostro cervello. Sembra essere un casino così complesso che incontriamo confini con QUALSIASI linguaggio di programmazione (almeno ora). Quindi forse per virtualizzare realmente il nostro cervello abbiamo bisogno di altri approcci e quindi di altre semantiche e sintassi.
In generale, ci sono ancora argomenti così complessi che potrebbero portare ad altre strategie che includano anche una lingua "migliore" per un determinato scenario.
Leggi altre domande sui tag programming-languages dsl