Quando è ragionevole creare il mio linguaggio di programmazione?

Esistono tipi di applicazioni killer, classi di problemi algoritmici, ecc., Dove è meglio, a lungo termine, creare la mia lingua?

PS: Per essere sicuro, intendo un nuovo linguaggio di programmazione e un compilatore, non un nuovo compilatore per un linguaggio esistente.

EDIT : grazie per le risposte. Potete fornire alcuni esempi in cui è assolutamente inutile creare un DSL o casi in cui un DSL potrebbe essere una buona idea?

È certamente rilevante che una persona scriva la propria lingua a fini educativi. Per conoscere la progettazione del linguaggio di programmazione e la progettazione del compilatore. Ma gli usi del mondo reale sono pochi e lontani tra loro.

Nello scrivere la tua lingua sei:

• Aggiungendo un'enorme quantità di complessità al tuo problema
• Aggiungendo una notevole quantità di lavoro per iscritto e mantenendo la nuova lingua e il compilatore

Quindi, se prevedi di scrivere la tua lingua per il tuo progetto, le funzionalità che prevede che altre lingue non debbano compensare i costi di cui sopra.

Prendi ad esempio lo sviluppo di giochi. Spesso hanno bisogno di mini-lingue all'interno dei loro giochi o linguaggi di scripting. Usano questi linguaggi per scrivere una grande quantità degli eventi in-game che accadono. Tuttavia, anche in questo caso, scelgono quasi sempre linguaggi di scripting esistenti e li adattano alle loro esigenze.

Vorrei solo citare Paul Vick, ex capo sviluppatore del compilatore VB e ora al lavoro sul Progetto Oslo e sul linguaggio M:

Costruire un nuovo linguaggio, incredibilmente difficile, è incredibilmente difficile, anche se in gran parte basato su uno esistente. Eppure molti programmatori pensano: "Ehi, io uso le lingue, quanto può essere difficile?" E ci provano. ... probabilmente oltre il 98% di loro non riesce mai a ottenere alcuna trazione, ma Dio benedica gli ottimisti perché senza di loro non avremmo mai il 2% delle lingue che ci riescono. Sono personalmente disposto a sacrificare i milioni di dollari e le ore sprecate in lingue che non lo fanno mai solo per poter ottenere lingue come C # e Java e Ruby e Python e così via.

Quindi il fatto che inventare una nuova lingua sia una cattiva idea non dovrebbe dissuadere le persone dallo sviluppo di nuove DSL, dovrebbe solo dare loro una pausa e, si spera, un po 'di umiltà. La chiave, penso, è iniziare in piccolo e rimanere piccoli.

DSL: Sicuramente una cattiva idea!

Quando è ragionevole?

Quando ne hai voglia!

Non ascoltare queste persone che hanno commenti sgraziati che sostanzialmente dicono:

"Non farlo perché è troppo difficile e il linguaggio X è migliore di qualsiasi linguaggio tu possa inventare".

Il fatto è che la creazione di una DSL avviene continuamente. Un framework è un DSL. Una macro è una DSL. Ogni volta che scrivi una funzione per il tuo programma, fa parte di una DSL. Certo, è entro i limiti della grammatica, ma il vocabolario fa parte di una lingua. Ecco perché le industrie spesso creano il loro vernacolo: è più efficiente!

Se "non farlo" fosse la risposta giusta, scriveremmo tutti COBOL e Fortran.

Potresti voler leggere parti del prossimo libro DSL di Martin Fowler , se stai pensando di scrivere la tua lingua.

Non riesco davvero a pensare a un business case per creare da zero un linguaggio diverso da quello di una straordinaria esperienza di apprendimento.

Modifica: per DSL ci sono molti casi aziendali, ma la chiave qui non è lasciarsi trasportare e Keep It Simple.

Suggerisco che le domande chiave siano "Quale problema sto cercando di risolvere?" e "Chi ottiene il ROI?"

Se stai cercando di sviluppare le tue abilità e la tua esperienza, procedi a tutta velocità, ma non in un sistema di produzione che dovrebbe risolvere il problema di qualcun altro.

Sembra che il motivo principale per cui vorresti una nuova lingua è che inizi a scoprire schemi 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 creati per le lingue esistenti. Passerai molto tempo a progettare e implementare il nuovo linguaggio, che è tutto il tempo che non devi dedicare al vero compito di programmazione. Ti impegnerai molto per convincere 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 schemi? Quindi, ottieni tutto il potere di una nuova lingua con tutti i vantaggi di una lingua consolidata.

Uno dei motivi potrebbe essere quello di crearlo come esperimento per conoscere la progettazione del linguaggio e la costruzione di compilatori.

Un altro motivo potrebbe essere quello di creare un linguaggio di scripting in un'applicazione quando non si ha la possibilità di aggiungere un'API di terze parti.

Non penso che tu possa programmare senza creare una nuova lingua, quindi è bene rendersi conto che è quello che stai facendo e capire i problemi.

• Che cos'è una lingua?
  Vocabolario, sintassi e semantica.

Un linguaggio standard come VB, Java, C #, ecc. È solo un linguaggio di base . Non appena aggiungi classi, metodi, ecc., Hai aggiunto il vocabolario e la semantica. Esistono molti modi per implementare le lingue: analisi e traduzione, analisi e interpretazione, macro su una lingua esistente, aggiunta di classi e metodi a una lingua esistente.

• Cosa vuoi che faccia una lingua?
  Sii buono per esprimere i problemi in modo conciso.

Come fai a sapere se l'hai fatto? La misura che utilizzo è il conteggio delle modifiche . Se arriva il requisito A di una frase, procedo all'attuazione del requisito nel codice. Quando ho finito e ho eliminato tutti i bug, controllo il codice e il repository del codice mi dà un elenco delle modifiche che ho fatto, B. Più piccola è B, migliore è la lingua. Mediata nello spazio di requisiti reali e possibili, questa misura mi dice quanto sia "specifica la lingua" della lingua.

• Perché la concisione è buona?
  Perché minimizza i bug.

Se sono necessarie modifiche al codice N per implementare il requisito 1 e talvolta si commettono errori, il numero di bug introdotti è approssimativamente proporzionale a N. Nel limite in cui N = 1, è quasi impossibile introdurre un bug senza provare.

Si noti che questa è una sfida diretta al "bloat di codice" che vediamo al giorno d'oggi.

AGGIUNTO: in risposta alla richiesta di un esempio, vedere esecuzione differenziale . Non dirò che può essere compreso rapidamente, ma riduce significativamente il codice dell'interfaccia utente.

È sempre "fattibile" usare la parola nella tua (originale) domanda, ma non è molto spesso utile e molto raramente ottimale data l'abbondanza di linguaggi e framework ben supportati e maturi che esistono.

È comunque una sfida intellettuale interessante.

Solo se il core business del tuo team sono i linguaggi di programmazione.

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 in alcun modo vicino alla velocità che qualcosa come C # o Java potrebbe - hanno team dedicati a farlo.

La lingua presto ristagnò poiché nessuno nuovo voleva assumersi il compito di migliorare il progetto animale domestico di qualcun altro.

L'architetto originale è partito. La lingua appassì e morì dopo 10 anni.

Quei 10 anni furono un inferno per chiunque avesse avuto la sfortuna di lavorare su una lingua senza uscita.

Quindi vai avanti, crea la tua lingua ma per favore non chiedere a nessun altro di usarla davvero. Per favore, non aspettarti che altri ti ringrazino 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 una specie di linguaggio macro / scripting per rendere più semplice l'esecuzione di attività ripetitive complesse. La maggior parte degli utenti non utilizzerà questa funzionalità, ma i pochi che la usano sono molto grati. Inoltre, mi assicuro che sia utile 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.

A parte questo, se devi porre la domanda, allora non lo è. Se stai cercando di capire se riesci a gestire una certa classe di algoritmo o un determinato dominio problematico meglio delle lingue esistenti, prima di tutto devi essere un esperto nell'area che stai affrontando. Saprai che è appropriato quando le tue capacità ed esperienza te lo dicono.

E potresti anche sbagliarti, ma avresti bisogno di un altro esperto per convincerti di ciò (o per dimostrarti che non sei l'esperto che pensi di essere). Una discussione vivace che sarebbe, non un semplice Q-e-A come troverai qui.

Fatta eccezione per scopi di auto-educazione, vorrei affermare che oggi non è necessario creare la propria lingua. In ogni circostanza. Mai. Indipendentemente da ciò che vuoi fare, ci sono un sacco di lingue esistenti che puoi prendere / adattare alle tue esigenze.

Dipende definitivamente dalla situazione. Come ha detto nosklo - Se hai una buona idea, un concetto nuovo di zecca 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", dai un'occhiata a: YACC & Lex

Puoi, semplicemente, non prenderti nell'anti-schema "Ricreazione della ruota quadrata".

Significa che stai ricreando ciò che è già stato fatto, solo più povero degli originali.

Wouter era noto per aver creato una nuova lingua per qualsiasi nuova idea. Puoi trarre ispirazione dal suo lavoro: la pagina del linguaggio di programmazione di Wouter .

Quando creare la tua lingua?

Quando vuoi, come un grande progetto hobby.

Per una lingua specifica del dominio. Questi possono essere abbastanza elaborati; guarda cosa succede nella community di Interactive Fiction (o avventura di testo) controllando 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 faresti tu, spero, evitare un cliché come evitarlo come la peste?

Quando deve essere la base per il continuo sviluppo di progetti reali. Avrà sempre un ritardo considerevole rispetto a ciò che è commercialmente disponibile a basso costo e paralizzerà l'ulteriore sviluppo. Ho lavorato per un'azienda con la sua versione di COBOL e non voglio mai lavorare in un'altra azienda che mantiene la propria lingua. Abbiamo visto altre versioni di COBOL ottenere migliori capacità e strumenti migliori, mentre eravamo bloccati con gli stessi problemi. (Non voglio mai più lavorare con COBOL, ma questa è un'altra storia.)

Le situazioni in cui potresti creare la tua lingua non rientrano in questo. I progetti Hobby non vengono utilizzati per un vero sviluppo. Qualcosa come Arc riuscirà (e otterrà molteplici implementazioni e ulteriore evoluzione e sviluppo) o fallirà (e nessun altro lo utilizzerà). Un linguaggio specifico per piccoli domini è solo una parte di un progetto e, poiché è piccolo, può essere migliorato nel tempo. Un linguaggio di avventura testuale viene utilizzato per scrivere singoli giochi e quei giochi, oltre ad essere progetti di hobby, non vengono quasi mai utilizzati per lo sviluppo continuo.

La mia prospettiva è che i DSL siano generalmente una "idea debole", ed è più produttivo nel lungo periodo usare un linguaggio standard e costruire le tue esigenze specifiche del dominio come libreria del "non DSL".

Tuttavia, potrebbe rivelarsi che le tue esigenze siano abbastanza personalizzate da preferire avere una DSL (non solo un'implementazione gcc o lisp leggermente modificata) per la tua azienda. Molte aziende usano drop-in delle lingue attuali che prendono di mira ciò che stanno facendo, senza scrivere / mantenere la propria lingua. Ad esempio, ho sentito che PHP ha un bel 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 questo 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 un linguaggio esistente.

Andare fino al codice macchina sta reinventando MOLTE ruote ...

Un ottimo motivo per un DSL è rappresentare i dati di dominio in modo sintetico. Ciò consente agli esperti del dominio di lavorare direttamente con i dati invece di dover passare attraverso altri. Il trucco è quindi avere i programmi risultanti in una forma facile da elaborare.

In generale, la risposta sarebbe un grande NO. Delle centinaia di lingue là fuori ce n'è di solito una adatta al tuo problema.

Tuttavia ci sono circostanze in cui è un'opzione razionale per sviluppare una nuova lingua: -

• Quando uno dei tuoi concorrenti possiede ora una delle tue principali piattaforme di sviluppo. Sto pensando all'affidamento attuale di Googles su Java e al loro sviluppo di "go", (aiuta se hai un autore della lingua di maggior successo di sempre sul libro paga!).
• Quando devi scrivere una tonnellata di codice per una nuova piattaforma e le lingue esistenti sono verbose e soggette a errori, ad esempio php per lo sviluppo web.
• Quando si incontrano problemi di scala e parallelismo che non si sono mai incontrati prima perché nessuno aveva mai avuto così tanto hardware per elaborare così tanti dati prima - ad esempio Scala e (in una certa misura GO).

In quale linguaggio è bravo è la composizionalità o l'unione degli stessi componenti in modi diversi.

Se il tuo problema di dominio richiede solo l'impostazione di un gruppo di interruttori ortogonali, una lingua probabilmente non aggiunge molto ai moduli, a un'interfaccia utente grafica o a una configurazione di testo semplice. file. (Suppongo qui che un file pieno di chiave, coppie di valori non sia ciò che intendi per "lingua".)

OTOH, se la tua configurazione è come il vero linguaggio, ad es. verbi e sostantivi possono essere messi insieme in molte combinazioni diverse (e nuove) per 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 proprio linguaggio di programmazione solo quando si comprendono altre lingue, il proprio dominio problematico specifico e il modo in cui le lingue esistenti affrontano quel dominio problematico e questa comprensione è sufficientemente approfondita da sapere che un nuovo linguaggio è ragionevole soluzione senza dover porre la domanda.

L'ultima volta che ho deciso di farlo su un progetto per hobby ho iniziato a specificare come avrei voluto che fosse la sintassi e mi sono reso conto che, a metà strada, stavo reinventando il prologo. Altre lingue che potrebbero essere adatte quando pensi di dover 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.

Uno dei motivi è a fini educativi, come già affermato. Ma ce ne sono altri. Ad esempio, ci sono molti linguaggi di ricerca come Sing#sul sistema operativo Singularity e BitCsu Coyotos che sono stati 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 saggia a questa domanda:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Riepilogo elenco (da quella pagina):

• Il linguaggio come meccanismo di astrazione sintattica: per ridurre il codice "boilerplate" ripetitivo che non può essere sottratto dall'uso dei meccanismi di astrazione integrati di un'altra lingua.
• Il linguaggio come shaper del pensiero: per indurre un cambiamento di paradigma nel modo in cui si dovrebbe strutturare il software (cambiando il "percorso di minor resistenza").
• Il linguaggio come semplificatore: ridurre un paradigma esistente solo alle sue parti essenziali, spesso per aumentare la comprensione e l'intuizione.
• La lingua come agente di legge: per far rispettare importanti proprietà o invarianti, forse per rendere più facile dedurre proprietà più utili dai programmi.

Probabilmente mai.

Lua è la scelta migliore che puoi ottenere se vuoi incorporare la lingua praticamente in qualsiasi altra lingua.

Le lingue specifiche per piccoli domini sono attualmente disponibili e ha senso in alcune applicazioni.

A parte questo, le ragioni sono principalmente accademiche.

Creare una lingua quando non è necessaria, è davvero una brutta cosa da fare a causa della complessità legata allo sviluppo e alla sua manutenzione. Ho visto molti progetti che introducono un qualche tipo di linguaggio di scripting specifico solo per quel programma, ed è stata la cosa che stava rallentando enormemente lo sviluppo della cosa base. Buoni esempi sono ad esempio i linguaggi di automazione come Phantom, AutoHotKey, AutoIt. Questi strumenti sarebbero molto meglio dell'IMO se usassero qualche lingua emigrante ben nota come Lua.

La tua "modifica" sembra essere una domanda sostanzialmente diversa ("quando dovrei costruire un DSL?" Piuttosto che la domanda originale che la gente ha inteso come "quando dovrei costruire un nuovo linguaggio di programmazione per scopi generali"). Sembra che le persone abbiano risposto a fondo alla domanda "originale", ma ci sono poche risposte che danno criteri specifici su quando usare un DSL. Quindi propongo una lista di controllo:

1. La tua base di utenti è più grande di poche persone, generalmente non tecnica e / o con accesso limitato al sistema (quindi è irragionevole aspettarsi che apprendano / utilizzino una lingua per scopi generici esistente). Se è all'interno del tuo team di sviluppo o organizzazione software potresti invece dire "basta scrivere uno script".
2. I tuoi utenti devono usarlo sufficientemente spesso, con comportamenti sufficientemente vari e mutevoli (cioè non puoi semplicemente fornire una libreria fissa di funzioni gestite da te)
3. Il comportamento che gli utenti possono specificare è troppo complicato per specificare come dati (ad es. Non è possibile ottenerlo utilizzando una tabella di database, una matrice di input dell'utente, un elenco di attività o una raccolta di valori-chiave ... riflettere attentamente perché puoi ottenere molta complessità con questi). Se riesci a ottenere il comportamento utilizzando l'input o la configurazione dei dati anziché DSL, probabilmente dovresti farlo perché sarà molto meno lavoro. Un qualche tipo di condizionalità, o componibilità / concatenamento insieme, o la modellazione di alcune diverse astrazioni possono essere segni che il comportamento necessario è troppo complesso per dati / configurazione semplici
4. Ma il comportamento è ancora abbastanza limitato da poterlo specificare in un DSL conciso. Un grande pericolo è "piattaforma gonfia", ad esempio se gli utenti iniziano a richiedere "puoi semplicemente aggiungere ...?". Se devono connettersi a Internet, leggere e scrivere dal file system o aprire e chiudere i processi, non si tratta più di un DSL. (L'ho visto accadere davvero ... agli utenti è stato permesso di incorporare piccole chiamate Python, passando gradualmente agli script Python e infine distruggendo eventuali limiti / modularità / prestazioni)

Se tutti questi sono veri, un DSL potrebbe essere appropriato.

Esistono tipi di applicazioni killer, classi di problemi algoritmici, ecc., Dove è meglio, a lungo termine, creare la mia lingua?

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 condurre ad altre strategie che includerebbero anche un linguaggio "migliore" per un determinato scenario.