Qual è la "domanda" a cui la teoria del linguaggio di programmazione sta cercando di rispondere?

Sono stato interessato a vari argomenti come la logica combinatoria, il calcolo lambda, la programmazione funzionale per un po 'e li ho studiati. Tuttavia, a differenza della "Teoria del calcolo" che si sforza di rispondere alla domanda di "calcolabilità", cioè cose che non possono / non possono essere calcolate con vari vincoli, faccio fatica a trovare l'analogo per "Teoria della programmazione"

Wikipedia lo descrive come:

La teoria dei linguaggi di programmazione (PLT) è una branca dell'informatica che si occupa di progettazione, implementazione, analisi, caratterizzazione e classificazione dei linguaggi di programmazione e delle loro caratteristiche individuali.

È come dire "tutto" che non è proprio specifico.

La progressione comune degli argomenti è di solito così:

Logica combinata> Calcolo lambda> Teoria dei tipi di Martin Lof> Calcolo lambda tipizzato> (Succede qualcosa qui)> Sviluppati linguaggi di programmazione - che hanno pochissima connessione con CL /$\lambda$

Riesco a vedere la "matematica" sottostante coinvolta con CL / e interessanti prove che emergono come risultato, incluso il teorema di Church-Rosser e che è pulito. Tuttavia, sto lottando per capire l '"obiettivo finale" di tutta questa impresa? Qual è il santo graal di PLT se vuoi? Per ora sembra solo graffiare un prurito intellettuale, ma non riesco davvero ad attraversare il ponte dalla ricerca / teoria a qualcosa di pratico.$\lambda$

Nota: lo ottengo fino a quando non uso il parametro -calc per prove di indecidibilità. Ma al di là della sua applicabilità alla "calcolabilità", proprio non capisco e sto facendo fatica a capire anche la necessità della ricerca nel PLT da questo stretto POV. Qualche libro esistente, riferimenti che possano far luce sul "quadro generale" di PLT?$\lambda$

Lo scopo generale del PLT è quello di rendere più economica (anche in senso generale) l' ingegneria del software industriale (anche in senso generale), ottimizzando lo strumento più importante (linguaggi di programmazione) e l'ecosistema degli strumenti associati.

Alcuni motivi per cui è coinvolta la matematica:

• I PL sono altamente non banali e non è chiaro che facciano la cosa giusta senza prove. La matematica fornisce un modello semplificato di linguaggi di programmazione reali. Questo modello ci consente di studiare veri e propri linguaggi di programmazione in un'impostazione molto semplificata, eliminando (si spera) la maggior parte dei problemi già a livello di modello. I veri linguaggi di programmazione sono attualmente matematicamente intrattabili. In altre parole: lambda-calculus è la mosca della frutta, l'E.Coli, la mucca sferica del PLT.

• Il PLT manca di metodi empirici adeguati, che sarebbe bello / meglio avere, quindi la matematica viene fatta come sostituto.

• La matematica è bella e profonda.

• La matematica fornisce una metodologia di ricerca semplice, provata e testata, che è importante per aiutare il proprio dottorando. In genere, alcune varianti di esempio: Indagare la funzione PL XYZ aggiungendola al lambda-calcolo. Aggiungi tipi semplici per XYZ e dimostra la solidità del tipo. Aggiungi generici per XYZ e dimostra la solidità del tipo. Dimostrare un teorema di parametricità per generici XYZ. Aggiungi tipi dipendenti per XYZ e dimostra la solidità del tipo. Sviluppa un'inferenza di tipo parziale per i tipi dipendenti da XYZ. Aggiungi tipi graduali per XYZ e dimostra la solidità del tipo. Aggiungi contratti per XYZ. Ognuno di questi è un documento. Puoi fermarti se il tuo dottorando o post dottorato si esaurisce. Ognuno di questi è interessante e fornirà approfondimenti su generici, parametricità, inferenza di tipo ecc. Questa pipeline è un'ottimamodo di navigare nelle acque difficili di tutti i possibili linguaggi di programmazione. Un secondo modo di apprendere è implementare le lingue in un compilatore, ma è meno trattabile per un individuo.

Se è necessario il PLT è una domanda interessante. La maggior parte dei programmatori che lavorano sembra pensare che non lo sia. Sono sbagliati: la maggior parte dei linguaggi sviluppati da programmatori che lavorano senza un background PLT (ad esempio Javascript, PHP) iniziano terribilmente e fanno tutti gli errori che i teorici del PL hanno imparato a lungo a evitare. Se un PL sviluppato da un dilettante colpisce il mainstream, i teorici del PL hanno bisogno di una decina di anni per ovviare ai difetti evidenti (ad es. Retrofitting di un sistema di tipizzazione statico, vedi Typescript). Vorrei riassumere questa situazione:

 Every successful programming language ends up being ML! Either because 
 it was designed by a PL theorist as ML from the start, or because a 
 decade of painful evolution removes all the obvious flaws, leaving ML. ;-)

^{A parte: questo stato di cose è interamente colpa del PLT perché perché la maggior parte di loro non ha esperienza di programmazione industriale, quindi non so davvero quali siano i punti deboli degli ingegneri del software di lavoro. In particolare, per ragioni sociologiche, la maggior parte dei teorici del PL ritiene che la pura programmazione funzionale in linguaggi come Agda sia la soluzione a tutti i problemi, che non regge al controllo.}