구성표와 공통 리스프 : 프로젝트에서 어떤 특성이 차이를 보입니까? [닫은]

StackOverflow와이 사이트 모두에 모호한 "Scheme vs Common Lisp"질문이 없기 때문에이 질문에 더 집중하고 싶습니다. 문제는 두 언어로 코딩 한 사람들을위한 것입니다.

Scheme에서 코딩하는 동안 Common Lisp 코딩 경험의 어떤 특정 요소가 가장 그리웠습니까? 또는 Common Lisp로 코딩하는 동안 Scheme에서 코딩에서 무엇을 놓쳤습니까?

언어 기능 만 의미하는 것은 아닙니다. 다음은 질문과 관련하여 놓칠 수있는 모든 유효한 사항입니다.

• 특정 라이브러리.
• SLIME, DrRacket 등과 같은 개발 환경의 특정 기능
• C 코드 블록을 Scheme 소스에 직접 쓸 수있는 Gambit의 기능과 같은 특정 구현의 특징.
• 물론 언어 기능도 있습니다.

내가 기대하는 답변의 예 :

• "공통 리스프에서 X를 구현하려고했는데, Scheme의 일류 연속체가 있다면 Y 만했을 것입니다. 대신 Z를해야만했습니다."
• "소스 트리가 커지고 점점 더 많은 C 라이브러리에 연결되면서 Scheme 프로젝트의 빌드 프로세스 스크립팅이 점점 더 어려워졌습니다. 다음 프로젝트에서는 Common Lisp로 돌아갔습니다."
• "저는 기존의 많은 C ++ 코드베이스를 보유하고 있으며, Gambit Scheme 코드에 C ++ 호출을 직접 포함시킬 수 있다는 것은 SWIG 지원 부족을 포함하여 Scheme이 Common Lisp와 비교했을 때의 단점 중 하나입니다."

그래서 "스키마는 더 단순한 언어"등과 같은 일반적인 감정보다는 전쟁 이야기를 기대하고 있습니다.

학부 학위는인지 과학과 인공 지능이었습니다. 그로부터 나는 한 코스의 Lisp에 대한 소개를 받았습니다. 나는 언어가 흥미 로웠다고 생각했지만 ( "우아한"에서처럼) 나중에 그린스펀의 10 번째 규칙을 만날 때까지는 그렇게 많이 생각하지 않았다.

충분히 복잡한 C 또는 Fortran 프로그램에는 Common Lisp의 절반을 임시로, 비공식적으로 지정하고, 버그를 해결하며, 느리게 구현 한 임시 프로그램이 포함되어 있습니다.

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

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

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

얼마 후 웹 기반 프로젝트 작업을 시작했을 때 여러 언어를 오디션했습니다. 나는 믹스에 Lisp와 Scheme을 포함시켰다. 결국 나는 Scheme 구현 -Chez Scheme을 선택했다 . 나는 결과에 매우 만족했다.

웹 기반 프로젝트는 고성능 "선택 엔진" 입니다. 데이터 처리에서 데이터 쿼리, 페이지 생성에 이르기까지 다양한 방식으로 Scheme을 사용합니다. 많은 곳에서 우리는 실제로 다른 언어로 시작했지만 아래에서 간략하게 설명 할 이유로 Scheme으로 이주했습니다.

이제 귀하의 질문에 답변을 드릴 수 있습니다 (적어도 부분적으로).

오디션 동안 우리는 다양한 Lisp 및 Scheme 구현을 살펴 보았습니다. Lisp 측면에서 Allegro CL, CMUCL, SBCL 및 LispWorks를 살펴 보았습니다. Scheme 측면에서 우리는 Bigloo, Chicken, Chez, Gambit을 믿었습니다. (언어 선택은 오래 전에 이루어 졌기 때문에 약간 흐릿한 이유입니다. 중요한 경우 메모를 파낼 수 있습니다.)

우리는 a) 기본 스레드와 b) Linux, Mac 및 Windows 지원을 찾고있었습니다. 이 두 가지 조건이 모두에게 영향을 미쳤지 만 Allegro와 Chez는 모두 제압했습니다. 따라서 평가를 계속하려면 멀티 스레딩 요구 사항을 완화해야했습니다.

우리는 작은 프로그램들을 모아서 평가와 테스트에 사용했습니다. 그것은 많은 문제를 드러 냈습니다. 예를 들어, 일부 구현에는 일부 테스트가 실행되지 못하게하는 결함이있었습니다. 일부 구현은 런타임에 코드를 컴파일 할 수 없었습니다. 일부 구현에서는 런타임 컴파일 된 코드를 사전 컴파일 된 코드와 쉽게 통합 할 수 없었습니다. 일부 구현에는 가비지 수집기가 있었으며 다른 가비지 수집기가 다른 것보다 분명히 더 좋았습니다 (또는 더 나빴습니다). 기타

Allegro, Chez 및 Lispworks의 3 가지 상용 구현 만 주요 테스트를 통과했습니다. 세 가지 중 Chez만이 비행 색상으로 모든 테스트를 통과했습니다. 당시 나는 Lispworks가 어떤 플랫폼에서도 네이티브 스레드를 가지고 있지 않다고 생각합니다 (지금은 그렇게 생각합니다). Allegro는 일부 플랫폼에서만 네이티브 스레드를 가지고 있다고 생각합니다. 또한 Allegro는 "좋아요"런타임 라이센스 요금을 받았는데 그다지 마음에 들지 않았습니다. 나는 Lispworks에 런타임 비용이 없었고 Chez는 간단하고 매우 합리적인 배열을 가지고 있다고 생각합니다 (그리고 컴파일러를 런타임에 사용한 경우에만 시작되었습니다).

Lisp와 Scheme에서 상당히 중요한 코드 덩어리를 생성 한 것은 여기에 몇 가지 비교 및 ​​대조 점이 있습니다.

• Lisp 환경은 훨씬 더 성숙합니다. 당신은 돈을 더 강타합니다. (단, 코드가 많을수록 버그가 더 많다고합니다.)

• Lisp 환경은 배우기가 훨씬 더 어렵습니다. 능숙 해지려면 더 많은 시간이 필요합니다. 커먼 리스프는 거대한 언어이며, 상용 구현이 추가 된 라이브러리에 도달하기 전에 있습니다. (Scheme의 구문 사례는 Lisp의 어떤 것보다 훨씬 미묘하고 복잡하다고 말했다.)

• Lisp 환경은 바이너리를 생성하기가 다소 어려울 수 있습니다. 불필요한 비트를 제거하기 위해 이미지를 "흔들어야"하며, 해당 프로세스 중에 프로그램을 올바르게 실행하지 않으면 나중에 런타임 오류가 발생할 수 있습니다. . 이와 대조적으로 Chez를 사용하면 필요한 다른 모든 파일이 포함 된 최상위 파일을 컴파일합니다.

나는 우리가 원래 의도하지 않은 여러 곳에서 Scheme을 사용했다고 말했다. 왜? 나는 머리 꼭대기에서 세 가지 이유를 생각할 수 있습니다.

먼저 Chez (및 개발자 인 Cadence)를 신뢰하는 법을 배웠습니다. 우리는 도구에서 많은 것을 요청했으며 지속적으로 제공했습니다. 예를 들어, Chez는 역사적으로 사소한 결함이 거의 없었으며 메모리 관리자는 매우 훌륭했습니다.

둘째, 우리는 Chez의 성능을 사랑하는 법을 배웠습니다. 우리는 스크립팅 언어처럼 느껴지는 것을 사용하고 있었고, 네이티브 코드 속도를 얻었습니다. 문제가되지 않았지만 결코 아프지 않았으며 때로는 많은 도움이되었습니다.

셋째, 우리는 추상화 체계가 제공 할 수있는 추상화를 사랑하는 법을 배웠습니다. 난 그냥 매크로를 의미하지는 않습니다. 클로저, 람다, 테일 콜 등과 같은 것을 의미합니다. 일단 이러한 용어로 생각하기 시작하면 다른 언어는 비교에 의해 다소 제한적으로 보입니다.

구성표가 완벽합니까? 아니; 트레이드 오프입니다. 첫째, 개별 개발자의 효율성을 높일 수는 있지만 대부분의 언어 (예 : 루프)에 대한 푯말이 Scheme에 없기 때문에 개발자가 서로의 코드를 이해하기가 더 어렵습니다 (예 : 백만 가지 방법이 있음) for 루프). 둘째, 훨씬 더 작은 개발자 풀과 대화하고, 채용하고, 빌릴 수 있습니다.

요약하면 Lisp와 Scheme은 다른 곳에서는 널리 사용할 수없는 일부 기능을 제공합니다. 이 기능은 트레이드 오프이므로 특정 경우에 적합한 기능이 더 좋습니다. 우리의 경우 Lisp 또는 Scheme과 함께 갈 것인지의 결정 요인은 언어 또는 라이브러리 기능에서보다 기본 기능 (플랫폼 지원, 플랫폼 스레드, 런타임 컴파일, 런타임 라이센싱)과 더 관련이 있습니다. 다시 말하지만, 우리의 경우에도 절충안이었습니다. Chez를 사용하면 원하는 핵심 기능을 얻었지만 상업용 Lisp 환경에서 보유한 광범위한 라이브러리를 잃었습니다.

또한 우리는 오래 전에 여러 가지 리스프와 구성표를 살펴 보았습니다. 그들은 모두 진화하고 개선되었습니다.

나는 보통 답변으로 링크를 붙여 넣는 것을 좋아하지 않지만, 이것에 관한 블로그 기사를 썼습니다. 철저하지는 않지만 몇 가지 주요 사항이 있습니다.

http://symbo1ics.com/blog/?p=729

편집 : 다음은 기본 요점입니다.

1. 존재 : 두 개의 리스프는 다른 리스프의 무리를 따랐습니다. 계획은 최소한의 공리 경로를 취했습니다. CL은 바로크 길을 갔다.
2. CASE : 일반적으로 Scheme은 대소 문자를 구분합니다. CL은 아닙니다 (그렇지만). 이것은 때때로 놓쳐 지지만, 실용성은 (나에 의해) 토론된다.
3. 이름 : CL의 기호 이름은 여러 번 이상하고 혼동됩니다. TERPRI, PROGN등. 스킴은 일반적으로 매우 합리적인 이름을 갖습니다. 이것은 CL에서 놓친 것입니다.
4. 기능 : CL에는 별도의 함수 네임 스페이스가 있습니다. 이것은 Scheme에서 놓치지 않습니다 . 단일 네임 스페이스를 사용하면 일반적으로 CL에서 어렵거나 어색한 매우 깨끗한 기능 프로그래밍이 가능합니다. 그러나 비용이 많이 듭니다. 때때로 계획에서 list" lst"에서 " " 와 같은 이름을 난독 화해야합니다 .
5. 매크로 : 나는 Scheme에서 가장 낮은 수준의 더티 매크로를 그리워합니다. 네, syntax-rules정말로 해킹하고 싶을 때까지는 모두 훌륭하고 멋집니다. 반면 CL에서 위생적인 ​​매크로가 누락되는 경우가 있습니다. 표준 방법이 없으면 바퀴를 다시 발명해야합니다.
6. 이식성 : 그것은 종종 CL이 두 언어가 표준화에도 불구하고, 이식성 인 경우입니다. CL은 더 크므로 외부 라이브러리없이 사용할 수있는 표준 기능이 더 많습니다. 또한 더 많은 구현 의존적 인 작업을 이식 가능하게 수행 할 수 있다는 의미입니다. 또한 Scheme은 1 조의 구현으로 어려움을 겪고 있으며 대부분 호환되지 않습니다. 이것은 CL을 매우 바람직하게 만듭니다.
7. 라이브러리 : 마지막 요점과 매우 관련이 있습니다. 체계에는 SRFI가 있지만 보편적으로 인정되지는 않습니다. 라이브러리로 작업하는 휴대용 방법은 없습니다. 반면에 CL에는 방법이 있습니다. 그리고 Quicklisp은 신 (Xach)이 제공 한 일종의 라이브러리 저장소입니다.
8. 구현 : Scheme은 구현이 너무 많습니다. 실제 정식 구현은 없습니다. 반면에 CL은 매우 우수한 고성능 또는 특정 용도 구현을 가지고 있습니다 (고성능 : SBCL, 상업용 : Allegro, 임베디드 : ECL, 이식 가능 : CLISP, Java : ABCL, ...).

첫 번째 사람에게 조금만 이야기했지만, 내가 놓친 것과 그렇지 않은 것이 분명해야합니다.

[이것이 너무 일반적이라면 사과드립니다. 좀 더 구체적인 내용을 원할 것 같습니다. 게시물에 몇 가지 구체적인 내용이 있습니다.]

최근에 C 버전과 Java 버전의 라이브러리를 사용하여 홈 프로젝트를 시작했습니다. 프로젝트에 Lisp를 사용하고 싶었고 Common Lisp, Scheme 또는 Clojure를 사용하는 데 약 한 달이 소요되었습니다. 나는 장난감 프로젝트에 대해서만 경험이 있습니다. 나는 내가 어느 쪽을 선택했는지 알려주기 전에 그들 각각에 대한 나의 경험에 대해 조금 이야기 할 것이다.

PLT Racket에는 편집기에서 표현식을 평가할 수있을뿐만 아니라, parens 대신 괄호를 입력하여 적절한 경우 parens로 다시 전환 할 수있는 멋진 IDE가 있습니다. 라켓은 또한 설치가 가능하고 다운로드 할 수있는 더 큰 라이브러리 세트를 가지고 있습니다. 시각적 디버거도 도움이됩니다.

내 공통 Lisp 구현 (SBCL)에는 IDE가 없지만 Emacs 및 SLIME을 사용하는 오픈 소스 CL 구현이 일반적입니다. 이 조합은 매우 효율적일 수 있습니다. 소스 파일에 표현식을 입력 할 때 표현식을 평가하는 기능과 함께 emacs의 모든 편집 명령을 사용할 수있는 REPL도 있으므로 코드 복사가 두 가지 방식으로 효율적으로 진행될 수 있습니다. REPL 버퍼에 표시된 개체도 복사하여 붙여 넣을 수 있습니다. Alt+(와 Alt+)일치하는 괄호 및 들여 쓰기를 처리하는 효율적입니다.

Clojure에서도 위의 모든 Emacs 기능을 사용할 수 있습니다. Clojure에 대한 저의 편집 경험은 Lisp와 비슷합니다. Java interop은 정상적으로 작동했으며 Clojure 프로젝트가 성숙되면하고 싶습니다.

세 가지 (Common Lisp, Racket 및 Clojure)를 모두 사용하여 라이브러리에 액세스 할 수 있었지만 프로젝트에 Common Lisp를 선택했습니다. 결정적인 요소는 FFI가 Common Lisp에서 사용하기 훨씬 쉽다는 것입니다. CFFI에는 예제 코드와 각 방법에 대한 자세한 설명이 포함 된 설명서가 있습니다. 오후에 20 개의 C 함수를 래핑 할 수 있었고 이후 코드를 건드릴 필요가 없었습니다.

다른 요인은 Clojure 또는 R6RS Scheme보다 Common Lisp에 더 익숙하다는 것입니다. 나는 Practical Common Lisp와 Graham의 저서 대부분을 읽었으며 Hyperspec에 익숙합니다. 아직 "거대한"코드는 아니지만 더 많은 경험을 쌓으면서 변경 될 것이라고 확신합니다.

CL과 라켓 모두에서 프로그래밍합니다.

저는 현재 Common Lisp에서 웹 사이트를 개발 중이며, Racket의 이전 고용주를위한 사내 프로그램 제품군을 작성했습니다.

사내 코드의 경우 고용주가 Windows 상점이므로 라켓 (PLT 체계라고도 함)을 선택했으며 LispWorks에 대한 비용을 지불 할 수 없었습니다. Windows를위한 유일한 훌륭한 오픈 소스 CL 구현은 프로세서에서 SSE 지원이 필요한 CCL (그리고 여전히)입니다. 값이 싼 고용주는 석기 시대 하드웨어를 사용하고있었습니다. 고용주가 괜찮은 하드웨어를 가지고 있더라도 Common Lisp의 유일한 GUI 결과 라이브러리는 Unix에서만 작동하는 McCLIM입니다. Racket에는 유닉스와 Windows 모두에서 작동하는 좋은 GUI 라이브러리가 있으며 이는 프로젝트의 성공에 중요했습니다.

나는 원시 DrRacket 편집기를 꾸미는 데 1 년 이상을 보냈습니다. EMACS는 MrEd로 알려진 Racket의 GUI 버전을 Windows에서 열등한 이미지로 바꿀 수 없었습니다. 한 번의 키 입력으로 커서의 표현식을 평가할 수 없었습니다. 대신 수동으로 S- 표현식을 선택하여 복사 한 다음 REPL 창을 클릭하고 (키 스트로크가 없기 때문에) S- 표현식을 붙여 넣어야했습니다. 또한 사용중인 함수 또는 매크로의 예상 인수를 보여줄 수있는 편집기없이해야했습니다. DrRacket은 SLIME을 대체하지 않습니다.

고용주는 복잡한 XML API가 포함 된 독점 데이터베이스를 사용하고 있었으며 SELECT 쿼리 버전에 응답 할 수있는 불필요한 정보가 많이 필요했습니다. HTMLPrag를 사용하여 XML을이 API로 내보내고 응답을 구문 분석하기로 결정했습니다. 잘 작동했습니다.

SQL처럼 보이는 양식을 입력하여 지나치게 복잡한 XML API와 상호 작용할 수있는 매크로를 작성하려면 Racket의 지나치게 복잡한 "구문 사례"매크로 시스템을 배워야했습니다. 내가 처분 할 때 DEFMACRO를 가지고 있다면이 부분은 훨씬 쉬웠을 것이다. 그러나 더 많은 노력을 기울 였지만 최종 결과는 여전히 매끄 럽습니다.

또한 Common Lisp의 LOOP 매크로없이해야했습니다. 라켓은 대부분의 코드를 작성한 후에 만 ​​대안을 제공하기 시작했으며 대안은 여전히 ​​LOOP와 비교할 때 빠릅니다 (라켓의 개발 팀이 더 나은 것을 주장하지만 단순히 잘못되었습니다). "car"와 "cdr"을 사용하여 목록을 반복하는 많은 LET 양식을 작성했습니다.

자동차와 CDR에 대해 말하면 Scheme의 (car '())를 오류로 해석하는 것보다 더 실망스러운 것은 없습니다. Racket의 대 / 소문자 구분을 활용하여 Common Lisp의 의미를 가진 CAR 및 CDR을 구현했습니다. 그러나 '()와 #f를 분리하면'()를 기본값으로 반환하는 것이 훨씬 덜 유용합니다.

또한 UNWIND-PROTECT를 다시 구현하고 Racket이 남긴 간격을 메우기 위해 자체 재시작 시스템을 발명했습니다. 라켓 커뮤니티는 재시작이 매우 유용하고 구현하기 쉽다는 것을 알아야합니다.

라켓의 let-values ​​형식은 너무 장황했기 때문에 MULTIPLE-VALUE-BIND를 구현했습니다. 라켓 은 사용 여부에 관계없이 생성 된 모든 값 을 수신 해야 하기 때문에 반드시 필요한 작업 입니다.

나중에 Common Lisp에 eBay XML API 클라이언트를 작성하려고 시도했지만 HTMLPrag와 같은 것이 없다는 것을 알았습니다. HTMLPrag는 놀랍습니다. 라켓에서 그 프로젝트를 끝냈습니다. 나는 Racket의 Literate Programming 시설을 실험 해 보았는데, 내가 평범한 코드보다 편집하기 어려운 글쓰기 코드를 작성하기 어려운 지구상의 유일한 프로그래머이거나 잘못 작성된 "과도한 주석"글쓰기 코드를 발견 한 유일한 프로그래머라는 것을 알게되었습니다.

저의 새로운 프로젝트는 Common Lisp에서 이루어 졌는데, Racket 커뮤니티는이 프로젝트에 필수적인 병렬 처리를 믿지 않기 때문에 올바른 선택이었습니다. 내가 라켓에서 놓쳤다 고 생각한 유일한 것은 연속이었습니다. 그러나 재시작을 사용하여 필요한 작업을 수행 할 수 있었으며, 간단히 살펴보면 간단한 클로저로 수행했을 수 있습니다.

체계는 별도의 컴파일을 염두에두고 설계되었습니다. 결과적으로 매크로의 힘은 제한적이고 위생적인 ​​매크로 시스템 대신 Common Lisp 스타일 defmacro를 허용하는 확장 기능을 사용하더라도 심각하게 제한됩니다. 다음 코드 줄에서 즉시 사용하기 위해 다른 매크로를 정의하는 매크로를 정의하는 것이 항상 가능한 것은 아닙니다. 그리고 이러한 가능성은 효율적인 eDSL 컴파일러를 구현하는 데 필수적입니다.

필자의 메타 프로그래밍 스타일이 위생에 적절하게 변환 될 수 없기 때문에 R5RS 위생 매크로 만 사용한 Scheme 구현은 나에게 유용하지 않다는 것은 말할 필요도 없다.

다행히도 그 제한이없는 Scheme 구현 (예 : Racket)이 있습니다.