Qual é a "pergunta" que a teoria da linguagem de programação está tentando responder?

Estou interessado em vários tópicos como Lógica Combinatória, Cálculo Lambda, Programação Funcional há algum tempo e os tenho estudado. No entanto, diferentemente da "Teoria da computação", que se esforça para responder à questão da "computabilidade", isto é, coisas que podem / não podem ser computadas com várias restrições, estou lutando para encontrar o análogo para "Teoria da programação"

A Wikipedia descreve como:

A teoria da linguagem de programação (PLT) é um ramo da ciência da computação que lida com o design, implementação, análise, caracterização e classificação de linguagens de programação e seus recursos individuais.

É como dizer "tudo" que não é realmente específico.

A progressão comum dos tópicos é geralmente assim:

Lógica combinada> Cálculo lambda> Teoria de tipos Martin Lof> Cálculo lambda digitado> (Algo acontece aqui)> Linguagens de programação desenvolvidas - que têm muito pouca conexão com CL /$\lambda$

Eu posso ver a "matemática" subjacente envolvida com CL / e provas interessantes que surgem como resultado, incluindo o teorema de Church-Rosser, e isso é interessante. No entanto, estou lutando para entender o "objetivo final" de todo esse empreendimento? Qual é o Santo Graal da PLT, se você preferir? Por enquanto, parece apenas estar coçando uma coceira intelectual, mas não posso realmente atravessar a ponte da pesquisa / teoria para algo prático.$\lambda$

Nota: Eu o levanto até usar o -calc para provas de indecidibilidade. Mas além de sua aplicabilidade à "computabilidade", simplesmente não entendo e estou tendo dificuldades para entender a necessidade de pesquisa em PLT a partir desse ponto de vista restrito. Existem livros existentes, referências que possam esclarecer o "quadro geral" do PLT?$\lambda$

O objetivo geral do PLT é tornar a engenharia de software industrial (em um sentido geral) mais barata (também em um sentido geral), otimizando a ferramenta mais importante (linguagens de programação) e o ecossistema de ferramentas associado.

Algumas razões pelas quais a matemática está envolvida:

• Os PLs são altamente não triviais e não está claro se eles fazem a coisa certa sem provas. A matemática fornece um modelo simplificado de linguagens de programação reais. Esse modelo nos permite estudar linguagens de programação reais em uma configuração muito simplificada, removendo (espero) a maioria dos problemas que já estão no nível do modelo. Atualmente, linguagens de programação reais são matematicamente intratáveis. Em outras palavras: lambda-calculus é a mosca da fruta, a E. Coli, a vaca esférica da PLT.

• O PLT carece de métodos empíricos adequados, o que seria bom / melhor, portanto a matemática é feita como um substituto.

• A matemática é linda e profunda.

• A matemática fornece uma metodologia de pesquisa simples, testada e testada, importante para ajudar os alunos de doutorado a se formarem. Normalmente, algumas variantes de, por exemplo: Investigue o recurso PL XYZ adicionando-o ao cálculo lambda. Adicione tipos simples para XYZ e comprove a solidez do tipo. Adicione genéricos para XYZ e comprove a solidez do tipo. Prove um teorema da parametridade para genéricos XYZ. Adicione tipos dependentes para XYZ e comprove a solidez do tipo. Desenvolva uma inferência de tipo parcial para tipos dependentes de XYZ. Adicione tipos graduais para XYZ e comprove a solidez do tipo. Adicione contratos para XYZ. Cada um deles é um papel. Você pode parar se o seu aluno de doutorado ou pós-doutorado ficar sem tempo. Cada uma das opções acima é interessante e fornecerá informações sobre genéricos, parametridade, inferência de tipo etc. Esse pipeline é um ótimomaneira de navegar pelas águas difíceis de todas as linguagens de programação possíveis. Uma segunda maneira de aprender é implementar linguagens em um compilador, mas isso é menos tratável para um indivíduo.

Se PLT é necessário é uma pergunta interessante. A maioria dos programadores parece achar que não. Eles estão errados: a maioria das linguagens desenvolvidas por programadores sem experiência em PLT (por exemplo, Javascript, PHP) começa terrível e comete todos os erros que os teóricos da PL aprenderam há muito tempo a evitar. Se um PL desenvolvido por um amador atinge o mainstream, os teóricos do PL precisam de uma década ou mais para consertar as falhas óbvias (por exemplo, reformando um sistema de tipagem estática, consulte Typescript). Deixe-me resumir esta situação:

 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. ;-)

^{Além disso: Esse estado de coisas é inteiramente culpa do PLT, porque, como a maioria deles não possui experiência em programação industrial, realmente não sabe quais são os problemas dos engenheiros de software que trabalham. Em particular, por razões sociológicas, a maioria dos teóricos da PL pensa que a programação funcional pura em linguagens como a Agda é a solução para todos os problemas, o que não resiste ao escrutínio.}