Greenspun의 10 번째 규칙, 모든 큰 프로젝트에는 Lisp 통역사가 포함됩니까? [닫은]

Greenspun의 10 번째 규칙 (실제로 유일한 규칙)은 다음과 같이 말합니다.

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

내 기억은 아마도 볼랜드의 Quattro (스프레드 시트) 프로젝트와 다른 것들에 대한 주제에 관한 논문이 있다는 것입니다. Google은 도움이되지 않습니다. 올바른 검색어가 마음에 들지 않을 수 있습니다. 이 주장을 뒷받침하는 논문이나 기사를 찾고 있습니다.

그 진술은 과장된 것입니다. 그러나 다른 언어로 된 Lisp 부러움의 명백한 징후가 있습니다. C #과 그것이 실제로 어떻게 기능을 향상시키는 지 살펴보십시오. 프로그램을 변경하지 않고도 시스템을 프로그래밍 할 수 있도록 다양한 비즈니스 프로세스 관리, 워크 플로우 및 EAI 프레임 워크를 살펴보십시오.

Martin Fowler의 Domain Specific Languages에 관한 책이 있는데, 객체 지향 언어로 메타 프로그래밍을 수행하는 방법에 대해 설명합니다. 쌍곡선에는 진실이 있습니다.

Paul Graham은 Lisp 와 함께 제공되는 첫 번째 목록을 보면서 가장 강력한 언어 인 Lisp라고 불렀 습니다.

열 번째 규칙을 따르는 방법은 폴리 글 로트 프로그래밍입니다. 하나의 언어 / 프레임 워크가 황금 망치가 아니라는 것을 깨닫습니다. 그런 다음 Lisp를 잘못 임시 구현하는 대신 Lisp를 사용할 수 있습니다.

그린스펀의 "열 번째 규칙"은 커프스 오프 비트 스나크입니다. 충분히 확장하면 "모든 스크립팅 또는 구성 시스템"을 다루는 경우 구성은 사소한 프로그램이 어느 정도 필요로하는 스크립팅이므로이 질문에 대한 대답은 "예"여야합니다. 복잡도를 높이면 약간 덜 일반적입니다.

반면 Naughty Dog가 게임 프로그래밍을 위해 발명 한 Lisp 변형 인 GOAL을 살펴보십시오 . 그것은 "클래식"리스프처럼 보이지 않습니다. 객체 지향 기능, 인터프리터 없음, 가비지 수집에 대한 최소한의 지원 (런타임 수준 정리 기능에 의존) 및 인라인 어셈블리에 대한 광범위한 지원을 제공하는 매우 필수적인 스타일의 시스템입니다.

다시 말해, 그들이 충분히 복잡한 프로젝트에 Lisp를 사용하려고 시도했을 때, 그들은 유용한 언어를 사용하기 위해 언어를 임시로 C ++의 절반으로 구현 된 임시로 구현해야한다는 것을 알게되었습니다! ;) (그리고 GOAL을 디자인 한 사람이 코드를 이해하지 못했기 때문에 결국에는 사용을 중단해야했습니다.)

흥미롭게도이 질문에 대한 답은 이미 프로그래머 SE에 있습니다.

관련 부분을 인용하려면 :

Greenspun의 요점은 많은 복잡한 프로그램에 내장 된 통역사가 있다는 것입니다. 인터프리터를 언어로 작성하는 대신 이미 인터프리터 (또는 컴파일러)가 내장 된 Lisp와 같은 언어를 사용하는 것이 더 합리적이라고 제안했습니다.

당시 나는 사용자 정의 언어에 대한 사용자 정의 인터프리터를 사용하여 사용자 정의 계산을 수행하는 다소 큰 앱을 작업했습니다. Lisp에서 핵심 실험을 대규모 실험으로 다시 작성하기로 결정했습니다.

대략 6 주가 걸렸습니다. 원래 코드는 ~ 10 만 줄의 델파이 (파스칼 변형)입니다. Lisp에서는 ~ 10,000 줄로 줄었습니다. 그러나 더욱 놀라운 것은 Lisp 엔진이 3-6 배 더 빠르다는 사실입니다. 그리고 이것이 Lisp neophyte의 작품이라는 것을 명심하십시오! 그 모든 경험은 저에게 아주 눈에 띄었습니다. 처음으로 단일 언어로 성능과 표현성을 결합 할 수있는 가능성을 보았습니다.
- 마이클 레나 한

그 부분을 더 명확히하기 위해 Michael은 다음과 같은 의견에 답변했습니다.

Lisp 구현보다 3-6 배 느리게 수행했다면 정말 끔찍한 델파이 코드 였을 것입니다! "맞습니다. 저는 그것을 더 잘 설명하지 못한 실패로 간주 할 것입니다. 사소한 쉬운 프로세스 인 Lisp 표현식에 사용자 표현식을 입력 한 다음 Lisp 표현식을 원시 코드로 컴파일 (완전히 최적화)하여 Greenspun의 10 번째 규칙의 의미입니다.
– Michael Lenaghan

이 답변은 다른 사람의 답변으로 구성되어 있으므로 커뮤니티 위키입니다.

규칙은 농담이지만 ​​약간의 진실이 있습니다. 복잡한 시스템에는 수많은 해석 된 부분이 포함됩니다 (모든 패턴을 점보 점보로 믿는 사람들 사이에서 "통역사 패턴"이 어떻게 사용되는지 참조). 복잡한 시스템은 구성 및 해석되는 구성 수단을 제공해야합니다.

복잡한 시스템은 빌드 프로세스 ( mocQt 또는 tablegenLLVM 과 같은 것) 에서 몇 가지 코드 생성 단계와 다양한 맞춤형 전처리기를 가질 가능성이 높습니다 .

많은 시스템이 Common Lisp의 라이브러리 기능과 매우 유사한 (거의 항상) 잘못 설계된 트리 워킹 및 변형 도구 세트를 사용하여 복잡한 트리와 유사한 데이터 구조를 다루고 있습니다.

이러한 모든 것들은 Lisp와 함께 무료로 제공되며, 대부분의 경우 계획되지 않은, 완전히 구현을 통해 생각하지 않은 모든 것은 완전히 열등 할 것입니다.

충분히 복잡한 시스템에는 작업중인 언어의 추상화로 표현하기가 매우 어려운 도메인 별 개념과 요구 사항이 있습니다. 이로 인해 프로그래머는 프로그래밍 언어 사이의 시맨틱 갭을 메우기위한 부담을 덜기 위해 도메인 별 추상화를 작성해야합니다. 그리고 특정 도메인. 이러한 추상화가 충분하면 기본적으로 도메인 특정 언어의 통역사가 있습니다. 이것은 불가피한 소프트웨어 개발 부분입니다.

"동적 인 동작을 구현하려면 모든 대규모 소프트웨어 기반 시스템이 필요하기 때문에"규칙이 더 정확하고 재미있을 수 있습니다.

이는 두 가지 방법으로 수행 할 수 있습니다.

1. 수십 개의 매개 변수와 수백 개의 정의가있는 대규모 복합 구성 파일.

2. AD-HOC 스크립트 언어

"sendmail"은 아마도 "1"유형의 표준 예일 것입니다. Warcraft / LUA 또는 Netscape / Javascript와 같은 "실제"스크립팅 언어를 포함하지 않는 "2"유형의 좋은 예는 생각할 수 없습니다.

문제는 몇 가지 매개 변수의 경우 구성 파일로 빠르고 간단하게 수행 할 수 있지만이 솔루션은 실제로 확장되지는 않습니다. 그러나 구성 파일에 하나 또는 두 개의 옵션을 추가 할 때 스크립트 접근 방식에 따라 구성 파일을 덤프하는 것이 경제적이지 않습니다. 따라서 구성 파일을 해석하는 코드는 실제로 잘못 작성된 해석기입니다.

다른 사람들이 언급했듯이 많은 프로그램은 구성 가능성이 필요하므로 다양한 lisp와 같은 해석기가 포함되어 있습니다.

그러나이 진술은 또한 프로그램을 만들기 위해 필요한 것은 Lisp이고 다른 모든 언어는 그보다 열등하다는 능숙 함을 의미합니다.

그러나 그것은 잘못입니다. Lisp는 표현력이 뛰어나지 만 너무 추상적입니다. 플랫폼의 세부 사항을 숨기려고 시도하고 컴퓨터 세계에는 목록 만있는 척합니다.

고성능 프로그래밍의 현실은 때때로 비트와 바이트를 다루고 OS 특정 작업을 수행해야하므로 명령문이 암시하는 것처럼 Lisp 만 사용하여 모든 것을 수행 할 수는 없다는 것입니다.

그것은 당신이 발명 한 언어의 복잡성, 영리함 또는 정교함에 관계없이 다른 방법 일뿐입니다. 결국 모든 것은 어셈블리를 작성하는 또 다른 방법 일뿐입니다.

진지하게 받아 들여 졌는지 여부에 관계없이 내가 작업 한 가장 큰 C 및 C ++ 프로젝트에 해당됩니다.

사실이 아닌 것은 사용자 지정 스크립팅 언어가 Common Lisp와 유사하다는 것입니다. 똑똑한 설계자들은 자신의 언어를 발명하는 대신 Guile, SpiderMonkey 및 Lua를 통합했기 때문에 긍정적 인 예는 Scheme과 비슷합니다.

또 다른 예 (그린 스프링으로 계산되는지 확실하지 않지만 확실히 WTF로 계산되는지는 확실하지 않음)는 범용 스크립팅에 사용되는 XSLT 인터프리터입니다. 출력이 두 번째로 XSLT 변환되는 피드백 루프를 추가함에 따라 이는 Lisp와 유사했습니다. 이제 매크로를 효과적으로 사용할 수 있습니다.
여기서의 동기는 lispy 기능에 액세스하는 것이 아니라 회사의 코드 QA 절차를 회피하는 것이 었습니다 (모든 버그 수정에 3 주간의 대기 시간이 추가되었습니다. XML은 "데이터"로 간주되어 프로세스에서 제외되었습니다.)

불행히도!

실제 lisp (y) 인터프리터 (Javascript 또는 lua alos는 훌륭한 작업)를 포함시키는 것이 최선이지만, 프로젝트에 4brew를 추가하면 전체 크기가 줄어들면서 유연성이 향상됩니다.

"모든 것을 코딩"하는 프로젝트는 모듈 수가 훨씬 많고 다루기 힘들고 융통성이 없습니다.