참고 : 나는 무엇을 배워야할지, 어느 것이 더 나은지, 또는 그와 비슷한 것을 묻는 것이 아닙니다.
나는 읽는 것이 좋을 것 같았 기 때문에 무료 버전의 SICP를 선택했다.
Scheme이 Lisp의 방언이라는 것을 알고 있습니다. Scheme과 Common Lisp의 실제 차이점은 무엇입니까?
'CL은 더 큰 stdlib를 가지고 있습니다 ... 실제 프로그래밍에 적합하지 않습니다 ..'에 대한 내용이 많이있는 것 같지만, 'CL이 이것 때문이다.
답변:
차이점은 기술적이고 (더 중요하게는 제 생각에는) 문화적이기 때문에 이것은 약간 까다로운 질문입니다. 대답은 부정확하고 주관적인 견해를 제공 할 수 있습니다. 이것이 제가 여기서 제공 할 것입니다. 일부 원시 기술 세부 정보는 Scheme Wiki를 참조하십시오 .
Scheme 은 실용적이고 학문적 인 응용 언어를 구축 할 수있는 우아하고 일관되며 잘 생각 된 기본 언어 기질을 제공한다는 원칙에 따라 구축 된 언어입니다.
순수한 R5RS (또는 R6RS) 체계로 응용 프로그램을 작성하는 사람을 거의 찾을 수 없으며, 최소한의 표준으로 인해 대부분의 코드는 체계 구현간에 이식 할 수 없습니다. 즉, 어떤 종류의 최종 사용자 응용 프로그램을 작성하려는 경우 Scheme 구현을 신중하게 선택해야합니다. 선택에 따라 사용 가능한 라이브러리가 크게 결정되기 때문입니다. 반면에 실제 애플리케이션 언어를 디자인 할 때 상대적인 자유는 Scheme 구현이 다른 곳에서는 들어 보지 못한 기능을 제공하는 경우가 많다는 것을 의미합니다. 예를 들어 PLT Racket을 사용하면 정적 타이핑을 사용할 수 있으며 언어를 매우 잘 인식하는 IDE를 제공합니다.
커뮤니티 중심의 SRFI 프로세스를 통해 기본 언어 이상의 상호 운용성이 제공되지만 특정 SRFI의 가용성은 구현에 따라 다릅니다.
대부분의 Scheme 방언과 라이브러리는 반복 대신 재귀와 같은 함수형 프로그래밍 관용구에 중점을 둡니다. OOP를하고 싶을 때 라이브러리로로드 할 수있는 다양한 객체 시스템이 있지만 기존 코드와의 통합은 Scheme 방언과 주변 문화에 크게 좌우됩니다 (예를 들어, 치킨 Scheme은 Racket보다 객체 지향적 인 것 같습니다).
대화 형 프로그래밍은 Scheme 하위 커뮤니티가 다른 점입니다. MIT Scheme은 강력한 상호 작용 지원으로 유명하지만 PLT Racket은 훨씬 더 정적 인 느낌을줍니다. 어쨌든 대화 형 프로그래밍은 대부분의 Scheme 하위 커뮤니티에서 핵심적인 관심사 인 것 같지 않으며 아직 대부분의 Common Lisps와 유사한 대화 형 프로그래밍 환경을 보지 못했습니다.
Common Lisp 는 실용적인 프로그래밍을 위해 설계된 전투 용 언어입니다. 그것은 추악한 사마귀와 호환성 해킹으로 가득 차 있습니다-Scheme의 우아한 미니멀리즘과는 정반대입니다. 그러나 그것은 또한 그 자체로 가져갈 때 훨씬 더 기능적입니다.
Common Lisp는 비교적 큰 휴대용 라이브러리 생태계를 만들어 왔습니다. 일반적으로 응용 프로그램 배포 후에도 아무 문제없이 언제든지 구현을 전환 할 수 있습니다. 전반적으로 Common Lisp는 Scheme보다 훨씬 더 균일하며, 더 급진적 인 언어 실험이 수행되면 일반적으로 완전히 새로운 언어 방언을 정의하는 대신 휴대용 라이브러리로 포함됩니다. 이로 인해 언어 확장은 더 보수적 인 경향이 있지만 결합 가능성도 더 높습니다 (그리고 종종 선택 사항).
외래 함수 인터페이스와 같이 보편적으로 유용한 언어 확장은 공식적인 수단을 통해 개발되지 않고 모든 주요 Common Lisp 구현에서 사용할 수있는 준 표준 라이브러리에 의존합니다.
언어 관용구는 기능적, 명령형 및 객체 지향 접근 방식의 거친 혼합이며 일반적으로 Common Lisp는 기능적 언어 라기보다는 명령형 언어처럼 느껴집니다. 또한 널리 사용되는 동적 스크립팅 언어 (예를 들어, 클래스 재정의는 기존 인스턴스에 적용되고 조건 처리 시스템에 상호 작용이 내장되어 있음)보다 훨씬 더 동적이며 대화 형 탐색 프로그래밍은 다음의 중요한 부분입니다. "Common Lisp 방식." 이것은 또한 Common Lisp에서 사용할 수있는 프로그래밍 환경에도 반영되어 있으며, 거의 모두 실행중인 Lisp 컴파일러와 일종의 직접적인 상호 작용을 제공합니다.
Common Lisp는 기본 제공 개체 시스템 (CLOS), 단순한 예외 처리보다 훨씬 더 강력한 조건 처리 시스템, 런타임 패치 가능성, 다양한 종류의 기본 제공 데이터 구조 및 유틸리티 (악명 높은 LOOP 매크로, 반복 포함)를 제공합니다. 하위 언어는 Scheme에 비해 너무 못 생겼지 만 말할 것도없이 너무 유용 하며 형식 문자열에서 GOTO를 지원 하는 printf와 같은 형식화 메커니즘 ).
이미지 기반의 대화 형 개발과 더 큰 언어로 인해 Lisp 구현은 일반적으로 Scheme 구현보다 운영 체제간에 이식성이 떨어집니다. 예를 들어, 임베디드 장치에서 Common Lisp를 실행하는 것은 심장이 약한 사람을위한 것이 아닙니다. Java 가상 머신과 마찬가지로 가상 메모리가 제한된 머신 (예 : OpenVZ 기반 가상 서버)에서 문제가 발생하는 경향이 있습니다. 반면에 Scheme 구현은 더 간결하고 이식성이있는 경향이 있습니다. ECL 구현의 품질 향상은이 점을 다소 완화 시켰지만 그 본질은 여전히 사실입니다.
상업적 지원에 관심이 있다면 그래픽 GUI 빌더, 특수 데이터베이스 시스템 등을 포함하여 자체 Common Lisp 구현을 제공하는 두 개의 회사가 있습니다.
요약 하면 Scheme은보다 우아하게 디자인 된 언어입니다. 주로 일부 동적 기능이있는 기능적 언어입니다. 구현은 고유 한 기능을 가진 다양한 호환되지 않는 방언을 나타냅니다. Common Lisp는 다양한 추악하지만 실용적인 기능을 갖춘 완전하고 매우 동적 인 다중 패러다임 언어로, 구현이 서로 대체로 호환됩니다. 체계 방언은 Common Lisp보다 더 정적이고 덜 상호 작용하는 경향이 있습니다. Common Lisp 구현은 설치가 더 무겁고 까다로운 경향이 있습니다.
어떤 언어를 선택하든 많은 즐거움을 기원합니다! :)
should you want to write some kind of end-user application+1
몇 가지 기본적인 실제 차이점 :
(function ...)저장된 함수를 명시 적으로 호출해야합니다.(funcall ...)nil(빈 목록)은 거짓 (예 :)으로 간주 if되며 유일한 거짓 값입니다. Scheme에서 빈 목록은 참으로 간주되고 (고유 한) #f유일한 거짓 값입니다.특히 많은 LISP 사람들이 Scheme을 LISP로 분류하기 때문에 공평하게 대답하기 어려운 질문입니다.
Josh Bloch (그리고이 비유는 그의 발명품이 아닐 수도 있음)는 언어를 선택하는 것이 지역 술집을 선택하는 것과 유사하다고 설명합니다. 그런 관점에서,
"Scheme"펍에는 많은 프로그래밍 언어 연구자가 있습니다. 이 사람들은 언어의 의미, 잘 정의되고 단순하게 유지하고 혁신적인 새 기능을 논의하는 데 많은 관심을 기울입니다. 누구나 프로그래밍 언어의 특정 영역을 탐색 할 수 있도록 설계된 고유 한 버전의 언어가 있습니다. Scheme 사람들은 LISP에서 가져온 괄호로 묶인 구문을 정말 좋아합니다. 유연하고 가볍고 균일하며 언어 확장에 대한 많은 장벽을 제거합니다 .
"LISP"펍? 글쎄 ... 나는 논평하지 말아야한다; 나는 거기에서 충분한 시간을 보내지 않았습니다 :).
계획:
일반적인 lisp :
그것은 몇 가지 요점입니다. 확실히 더 많은 것이 있습니다. 지금은 기억하지 못합니다.