La programmazione orientata al linguaggio è pratica?

Ho letto questo articolo sulla programmazione orientata al linguaggio. Sottolinea alcune debolezze nei moderni approcci procedurali / OOP alla programmazione e suggerisce un nuovo paradigma di programmazione che li risolverà

Sono tutto per parti di programma piccole e vagamente accoppiate: è molto meglio imparare molte piccole cose, tutte che userete, piuttosto che un paio di cose grandi, di cui usate solo frammenti.

Leggendo l'articolo, ho avuto l'impressione che l'autore stesse promuovendo una delle due cose:

• Una moltitudine di linguaggi di scripting facilmente creabili
• Un unico linguaggio facilmente estensibile che può riscrivere se stesso per soddisfare le esigenze del programmatore

Se sta suggerendo il secondo, risponderei con "Già fatto!" e dare Lisp come esempio. Come suggerisce Paul Graham, le lingue sembrano comunque muoversi continuamente verso questo .

Per quanto riguarda il primo, penso che sia una buona idea, se esiste un linguaggio di fondo che li lega tutti insieme. Questo mi sembra essere il punto debole: la comunicazione tra le lingue. Utilizzeresti le chiamate, che è un concetto procedurale o passaggio di messaggi, che mi ricorda la comunicazione tra processi? Gradirei l'opportunità di lavorare con linguaggi specifici per piccoli domini, se è facile usarli tutti contemporaneamente. Questo approccio (LOP) sarebbe pratico?

Ho sostenuto i DSL per molto tempo, ma mi preoccupo di ciò che accade a Good Ideas quando diventano bandwagons. Vengono creati prodotti che pubblicizzano The Good Idea, promettendo che tutto ciò che devi fare è ottenerne uno e sarai nel gruppo, senza dover pensare molto attentamente a ciò che significa.

Che cos'è una lingua? È un vocabolario e una sintassi in cui i significati possono essere comunicati, giusto? Ogni volta che dichiari una variabile, scrivi una funzione, definisci una classe, stai costruendo una nuova lingua, aggiungendo nomi e verbi a una lingua esistente. Ora puoi dire cose che prima non potevi.

Penso che ciò che rende un linguaggio specifico del dominio sia la misura in cui esprime naturalmente i concetti mentali che vengono comunicati, e penso che ci sia una semplice misura di ciò. Fondamentalmente, se esiste un semplice requisito indipendente X, che potrebbe essere incluso nel programma o meno, la sua corretta implementazione richiede una serie di inserimenti di codice, eliminazioni e sostituzioni Y. È possibile visualizzare un semplice diff prima e dopo Y. Il numero N di tali modifiche è una misura della specifica lingua del dominio. La N più piccola è, per esigenze tipiche, la migliore.

Non dipende necessariamente dalla sintassi elaborata, dalle strutture di controllo, dal passaggio dei messaggi o da ciò che hai. Da cosa dipende è in che modo implementa il requisito in modo conciso. Molti strumenti affermeranno di farlo, ma le affermazioni non sono effettive. Deve essere reale .

A volte è necessaria una tecnologia insolita . Ecco il mio esempio preferito. Quando lo è, illustra il punto che potrebbe essere necessario uno sforzo da parte dei programmatori per capirlo. Quindi la specificità del dominio (e la manutenibilità) non è affatto la stessa cosa della leggibilità .

Quindi sono d'accordo con il secondo approccio, secondo cui una buona lingua è quella che consente facilmente di costruire le lingue necessarie su di essa. (Questo è quello che mi è piaciuto di Lisp.) Ma è ancora più importante che i programmatori debbano sapere come costruire lingue per abbinare i domini in cui stanno lavorando ed essere disposti a scalare le curve di apprendimento di tali lingue.

Non lo vedo davvero. Invece sono bloccati nei "programmi = algoritmi + struttura dei dati", o "i nomi diventano classi e i verbi diventano metodi" trasformano le modalità di pensiero. Non stanno lavorando in termini di come prendere domini di pensiero e linguizzarli per la massima concisione.

Questo è piuttosto l'approccio Ruby.

• Mantieni il linguaggio di base semplice ed estendi tramite gemme
• Crea dialetti di Ruby per domini specifici tramite patch scimmia. Ruby on Rails.

Non so se sia meglio, ma immagino sia molto pragmatico.

L'approccio LOP è estremamente pratico. Tieni presente che non devi necessariamente implementare "linguaggi di scripting": la metodologia è applicabile anche agli eDSL e sono generalmente compilati in modo efficiente. Sto usando questo approccio letteralmente in tutto il mio lavoro di sviluppo.

Vedremo molto di più sui linguaggi specifici di dominio in futuro, a giudicare dalle persone che ne parlano adesso. Ho notato che Martin Fowler ne parla molto e alcuni articoli interessanti attraverso Lambda The Ultimate sull'argomento, tra gli altri.

Ciò mi suggerisce che questa è sicuramente una direzione in cui soffia il vento per quanto riguarda la progettazione del linguaggio di programmazione e le piattaforme di programmazione. In un certo senso lo è già da un po 'di tempo - uno dei vantaggi di Ruby (come alcuni già osservato) è che semplifica la creazione di DSL ma in realtà ce ne sono molti in giro nelle applicazioni e nelle librerie di programmazione che già utilizziamo.

Sto usando LOP ogni volta che programmo da solo. Ho scoperto che in alcuni progetti non esiste altro modo per rispettare il programma. In una semplice allegoria, si può equiparare l'uso del LOP agli utensili elettrici. Se lavori da solo in officina, non puoi fare le cose manualmente e rispettare la scadenza. Se ci sono altre persone con te, coordinare l'uso di tali elettroutensili è essenziale per l'efficienza e la sicurezza.
In modalità squadra, LOP richiede una preparazione organizzativa per evitare un disastro della Torre di Babele.