프로그래밍 언어 이론이 대답하려는“질문”은 무엇입니까?

나는 Combinatory Logic, Lambda Calculus, Functional Programming과 같은 다양한 주제에 관심이 있었고이를 연구하고 있습니다. 그러나 "계산 이론"과는 달리 "계산 성", 즉 다양한 제약으로 계산할 수없는 것들에 대한 질문에 답하려고 노력하는 것과는 달리, "프로그래밍 이론"에 대한 아날로그를 찾는 데 어려움을 겪고 있습니다.

Wikipedia 는이를 다음과 같이 설명합니다.

프로그래밍 언어 이론 (PLT)은 프로그래밍 언어 및 개별 기능의 디자인, 구현, 분석, 특성 분석 및 분류를 다루는 컴퓨터 과학의 한 분야입니다.

이것은 실제로는 구체적이지 않은 "모든 것"을 말하는 것과 같습니다.

주제의 일반적인 진행은 일반적으로 다음과 같습니다.

조합 논리> 람다 미적분학> Martin Lof 유형 이론> 유형이 지정된 람다 미적분학> (여기서 일어남)> 프로그래밍 언어 개발 -CL / 와 관련이 거의 없음$\lambda$

CL / 와 관련된 기본 "수학"과 Church-Rosser 정리를 포함한 결과로 나오는 흥미로운 증거를 볼 수 있습니다. 그러나 나는이 모든 사업의 "종료 목표"를 이해하려고 애 쓰고 있습니까? 당신이 원한다면 PLT의 성배 는 무엇입니까 ? 지금은 지적 가려움증을 긁는 것 같지만 연구 / 이론에서 실제적인 것으로 다리를 건너 갈 수는 없습니다.$\lambda$

참고 : 결정 불가능한 증거로 -calc를 사용할 때까지 시작합니다 . 그러나 "계산 성"에 대한 적용 가능성을 넘어서서 나는 그것을 얻지 못하고이 좁은 POV에서 PLT에 대한 연구의 필요성을 이해하기조차 힘들었습니다. 기존 도서, PLT의 "큰 그림"에 빛을 비출 수있는 참고 자료$\lambda$

PLT의 전반적인 목적은 가장 중요한 툴 (프로그래밍 언어) 및 관련 툴링 생태계를 최적화함으로써 산업용 소프트웨어 엔지니어링 (일반적인 의미에서)을 저렴하게 (일반적인 의미로) 만드는 것입니다.

수학이 관련된 몇 가지 이유 :

• PL은 매우 사소하지 않은, 그들은 증거없이 옳은 일을 할 것을 그것은 분명하지 않다. 수학은 실제 프로그래밍 언어 의 단순화 된 모델을 제공합니다 . 이 모델을 사용하면 모델 수준에서 이미 대부분의 문제를 제거 (희망적으로)하여 훨씬 간단한 설정으로 실제 프로그래밍 언어를 학습 할 수 있습니다. 실제 프로그래밍 언어는 현재 수학적으로 다루기 어렵습니다. 다시 말해, 람다 미적분은 과일 파리, E.Coli, PLT 의 구형 젖소 입니다.

• PLT에는 적절한 경험적 방법이 없기 때문에 좋은 방법이 있습니다. 따라서 수학은 대용으로 수행됩니다.

• 수학은 아름답고 깊습니다.

• 수학은 박사 과정의 학생들이 졸업 할 수 있도록 도와주는 간단하고 시도와 시험 연구 방법론을 제공합니다. 일반적으로 일부 변형 예 : PL 특징 XYZ를 람다 미적분에 추가하여 조사합니다. XYZ에 간단한 유형을 추가하고 유형 소음을 증명하십시오. XYZ에 대한 제네릭을 추가하고 형식 사운드를 증명하십시오. XYZ 제네릭에 대한 파라 메트릭 정리를 증명하십시오. XYZ에 대한 종속 유형을 추가하고 유형 사운드를 증명하십시오. XYZ 종속 유형에 대한 부분 유형 유추를 개발하십시오. XYZ에 점진적 유형을 추가하고 유형 건전성을 입증하십시오. XYZ에 대한 계약을 추가하십시오. 그것들은 각각 종이입니다. 박사 과정 학생이나 박사후 과정이 시간이 다되면 중단 할 수 있습니다. 위의 각은 재미 있고이 파이프 라인은 추론 등이다 입력, 제네릭, parametricity에 대한 통찰력을 얻을 것입니다 큰이가능한 모든 프로그래밍 언어의 어려운 물을 탐색하는 방법. 두 번째 학습 방법은 컴파일러에서 언어를 구현하는 것이지만 개인에게는 다루기가 쉽지 않습니다.

PLT가 필요한지 여부는 흥미로운 질문입니다. 대부분의 작업 프로그래머는 그렇지 않다고 생각하는 것 같습니다. PLT 배경 (예 : Javascript, PHP)이없는 작업 프로그래머가 개발 한 대부분의 언어는 끔찍한 것으로 시작하여 PL 이론가들이 오랫동안 피하는 방법을 배운 모든 실수를 저지 릅니다. 아마추어가 개발 한 PL이 주류에 도달하면 PL 이론가들은 명백한 결함을 수정하는 데 10 년 정도가 필요합니다 (예 : 정적 타이핑 시스템 개조, 타이프 스크립트 참조). 이 상황을 요약 해 보겠습니다.

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

^{따로 : 이 상황은 대부분 PLT의 잘못입니다. 왜냐하면 대부분은 산업 프로그래밍 경험이 없기 때문에 소프트웨어 엔지니어가 실제로 어떤 어려움을 겪고 있는지 알지 못하기 때문입니다. 특히, 사회 학적 이유로, 대부분의 PL 이론가들은 Agda와 같은 언어로 된 순수 기능 프로그래밍이 모든 문제에 대한 해결책이라고 생각하며, 이는 정밀한 조사에 맞지 않습니다.}