Clojure 대 다른 Lisps [닫힘]

93

내 질문의 의도는 없습니다 불꽃 전쟁을 시작하는 것이 아니라 각 언어가 어떤 상황에서 결정하기 위해 "작업에 가장 적합한 도구입니다."

나는 Clojure에 관한 여러 권의 책을 읽었습니다 ( Programming Clojure , Practical Clojure , The Joy of Clojure , and the Manning Early Access edition of Clojure in Action ), 환상적인 언어라고 생각합니다. 저는 현재 Common Lisp 매크로를 주로 다루는 Let Over Lambda 를 읽고 있으며, 또한 매우 흥미로운 언어입니다.

나는 하지 로 일반적으로, 함수형 프로그래밍을한다 (더 초보자의) 리스프 전문가,하지만 언어의 가족은 정말 매력적.

Clojure의 장점 (및 "기타"의 단점) :

  • JVM에서 실행됩니다.

    • JVM은 "한 번 작성하면 [거의] 어디에서나 실행"이라는 Sun의 꿈을 잘 충족시키는 매우 안정적인 고성능 언어 환경입니다. Macbook Pro에서 코드를 작성하고 실행 가능한 JAR 파일로 컴파일 한 다음 추가 테스트없이 Linux 및 Microsoft Windows에서 실행할 수 있습니다.

    • (핫스팟 및 기타) JVM은 고품질 가비지 수집과 매우 성능이 뛰어난 Just-In-Time 컴파일 및 최적화를 지원합니다. 불과 몇 년 전만해도 C로 빠르게 실행해야하는 모든 것을 작성했지만 이제는 Java로 작업하는 것을 주저하지 않습니다.

    • 표준, 단순, 다중 스레딩 모델. Common Lisp에 표준 멀티 스레딩 패키지가 있습니까?

    • 모든 사람들 괄호의 단조 로움까지 휴식 [], {}그리고 #{}, 커먼 리스프 전문가는 아마 독자 매크로와 함께, 당신은 CL에 사람들을 추가 할 수 있음을 말해 것이다 있지만.

Clojure의 단점 :

  • JVM에서 실행됩니다.
    • 꼬리 재귀 또는 연속이 없습니다. Common Lisp는 연속을 지원합니까? Scheme은 두 가지 모두에 대한 지원이 필요하다고 생각합니다.

기타 장점 (특히 Common Lisp) (및 Clojure의 단점) :

  • 사용자 정의 가능한 판독기 매크로.

  • 다른 장점?

생각? 다른 차이점?

clojure  comparison  lisp  scheme  common-lisp 
— Ralph
소스
15
개인적으로 저는 한 종류의 괄호를 좋아합니다;) "깨끗한"코드처럼 보입니다
— Moe
3
장점 목록에서 읽은 내용을 보면 Erlang을 좋아할 수도있을 것 같습니다. www.erlang.org
— Peer Stritzinger
4
Clojure는 "반복"특수 형식을 통해 명시적인 꼬리 재귀를 지원합니다. 이를 통해 명시 적으로 요청하는 경우 꼬리 재귀의 모든 이점을 얻을 수 있습니다 (유일한 예외는 현재 여러 함수 간의 상호 꼬리 재귀를 지원하지 않는다는 것입니다).
— mikera
1
Clojure는 적어도 "연속 전달 스타일"의 의미에서 연속을 지원합니다. 일등석 연속이 없다는 것이 맞습니다. stackoverflow.com/questions/1173133/continuations-in-clojure
— mikera
@mikera : 하나의 함수에 대한 꼬리 재귀. 서로를 호출하는 두 개의 함수는 "trampolining"으로 수행되어야합니다. 이것은 일종의 엉성한 (하지만 그 자체로 우아합니다. :-)).
— Ralph

답변:

52

다른 Lisps보다 Clojure를 선호하는 나의 개인적인 이유 목록 (ps 나는 여전히 모든 Lisps가 훌륭하다고 생각합니다!) :

  • JVM에서 실행-따라서 JVM 자체의 환상적인 엔지니어링에 자동으로 액세스 할 수 있습니다 (고급 가비지 수집 알고리즘, HotSpot JIT 최적화 등).

  • 매우 우수한 Java 상호 운용성-Java / JVM 언어 에코 시스템의 광범위한 라이브러리와의 호환성을 제공합니다. Clojure를 "접착제"언어로 사용하여 다른 Java 라이브러리를 좋은 효과로 연결했습니다. 또한 많은 Java 코드를 개발하기 때문에 Clojure가 Java 도구와 잘 통합된다는 점이 도움이됩니다 (예 : Clojure 개발을 위해 Counterclockwise 플러그인과 함께 Maven, Eclipse를 사용합니다).

  • 벡터 [1 2 3],지도 {:bob 10, :jane 15}및 세트에 대한 멋진 구문 #{"a" "b" "c"}-현대 프로그래밍을위한이 매우 필수적인 도구를 고려합니다 (물론 목록에 추가로!)

  • 나는 개인적으로 양식 바인딩에 대괄호를 사용하는 것을 좋아합니다. 예를 들어 (defn foo [a b] (+ a b)), 코드를 좀 더 명확하게 읽을 수 있습니다.

  • 지속적이고 변경 불가능한 데이터 구조를 사용하는 게으른 기능적 프로그래밍에 중점을 둡니다. 특히 모든 핵심 Clojure 라이브러리는 기본적으로이를 지원하도록 설계되었습니다.

  • 멀티 코어 동시성을위한 탁월한 STM 구현. 저는 Clojure가 현재 어떤 언어 중에서도 최고의 동시성 스토리를 가지고 있다고 믿습니다. Rich Hickey 자신의 자세한 비디오 ).

  • 개인적으로 선호하는 Lisp-1 (Scheme과 같은)입니다 (기능적 언어에서는 함수와 데이터를 동일한 네임 스페이스에 유지하는 것이 합리적이라고 생각합니다)

— mikera
소스
2
STM은 +1입니다. Clojure 사용을 정당화하기에 충분합니다.
— André Caron
2
여전히 CL-STM 라이브러리를 사용하여 STM을 얻을 수 있습니다.
— Mike Manilone 2013 년
2
@ AndréCaron은 필요한 경우에만.
— rightfold
간단한 웹앱을 작성하고 예를 들어 저렴한 $ 5 / 월 호스트에서 호스팅하려면 JVM으로 인해 Clojure에서 분명히 불가능합니다. 맞습니까?
— Hexatonic
@Hexatonic 나는 경험이 많지는 않지만 요즘 사용되는 기계에 JVM이 없다고 믿기 어렵습니다.
— MasterMastic
25

Clojure는 언어이자 구현입니다 (일반적으로 JVM에서). Common Lisp는 10 가지 이상의 다른 구현을 가진 언어입니다. 여기에 카테고리 불일치가 있습니다. 예를 들어 Clojure를 SBCL과 비교할 수 있습니다.

일반적으로:

  • Common Lisp 버전은 JVM : ABCL에서 실행됩니다.

  • 대부분의 다른 Common Lisp 구현은

  • 대부분의 CL 구현에는 멀티 태스킹 기능이 있으며 라이브러리는 공통 인터페이스를 제공합니다.

  • Common Lisp에는 배열 구문이 있습니다. 다른 데이터 유형에 대한 구문은 사용자가 작성할 수 있으며 다양한 라이브러리에서 제공됩니다.

  • Common Lisp는 꼬리 호출 최적화 나 연속을 지원하지 않습니다. 구현은 TCO를 제공하고 라이브러리는 일정한 형태의 연속성을 제공합니다.

— Rainer Joswig
소스
24

Clojure와 Common Lisp의 중요한 차이점은 Clojure가 함수형 프로그래밍에 대해 더 규범 적이라는 것입니다. Clojure의 철학, 관용구 및 어느 정도 언어 / 라이브러리는 기능적인 방식 (부작용 없음, 변경 가능한 상태 없음)으로 프로그래밍 할 것을 강력하게 권장하고 때로는 주장합니다.

Common Lisp는 함수형 프로그래밍을 확실히 지원하지만 변경 가능한 상태 및 명령형 프로그래밍도 허용합니다.

물론 동시성 등의 영역에서 함수형 프로그래밍에는 여러 가지 이점이 있습니다. 그러나 그 밖의 모든 것이 동일하기 때문에 각 상황에 사용할 접근 방식을 선택할 수있는 것도 좋습니다. Clojure는 명령형 프로그래밍을 완전히 금지하지는 않지만 Common Lisp보다 그 스타일을 덜 수용합니다.

— 찰리 꽃
소스
3
@Charlie Flowers : Common Lisp에서는 "순수한 기능"스타일 (영구적 데이터 구조 지원 등)으로 프로그래밍 할 수 있지만 규율이 필요합니다. 옳은?
— Ralph
2
"부작용 없음, 변경 가능한 상태 없음"에 대한 설명-Clojure는 변경 가능한 상태 (참조, 원자, 에이전트 등 모두 변경 가능)를 가지고 있지만 제어 된 방식으로 액세스해야합니다 (예 : STM 메커니즘 및 관련 트랜잭션을 통해). 의미 업데이트)
— mikera
5
@mikera : Clojure가 Java 라이브러리를 사용하여 사용할 수 있다는 점을 제외하고 모든 라이브러리에는 명령형 스타일이 필요하고 부작용이 가득합니다. Java와의 바인딩이 중독 된 선물임을 발견했습니다 ...
— André Caron
1
@Andre-물론, 변경 가능한 상태와 명령형 의미가 필요한 라이브러리를 사용하기로 결정했다면이를 관리해야합니다. 다른 언어에서 이러한 라이브러리에 액세스 한 경우와 다르지 않습니다. 그러나 두 가지 적절한 옵션이 있습니다. a) 그러한 라이브러리를 사용하지 마십시오. 순수 Clojure에서 완벽하게 좋은 코드를 작성할 수 있습니다. 또는 b) 이러한 라이브러리와 인터페이스의 복잡성을 멋진 Clojure 스타일의 기능적 인터페이스로 감쌀 수 있습니다. 매크로 또는 에이전트 등 전반적으로 Java 라이브러리를 활용하는 능력이 문제보다 훨씬 더 큰 이점을 발견했습니다.
— mikera
4
@mikera : 도서관은 이점이 있습니다. Java 라이브러리 (이는 언어에 대한 Rich Hickey의 주요 목표 중 하나)를 사용하는 것이 실제로 Clojure의 "다른 lisps보다 기능적"측면에 위배된다는 점을 지적하고 있습니다. 내 의견은 "이 라이브러리를 다시 작성 / 포장하지 않는 한 명령형 코드를 얻을 수 있으며 Clojure의 더 좋은 부분에서 이익을 얻지 못할 것입니다"를 의미합니다.
— André Caron
10

다음 은 Scheme (대부분 Racket)과 Clojure를 비교 한 좋은 비디오입니다 .

공정하게 말하면 Racket에는 데이터 유형 (#hash, #, 대괄호 등)에 대한 구문 설탕 (추가 판독기 항목)도 있습니다.

또한 Clojure가 적절한 테일 호출을 수행하는 유일한 방법은를 사용하는 것입니다 recur. 이것이 JVM으로 컴파일 할 때의 단점입니다.

참고 recurClojure의 유일한 비 스택이 소요되는 반복 구조입니다. 꼬리 호출 최적화가 없으며 알 수없는 경계의 루프를위한 자체 호출을 사용하지 않는 것이 좋습니다. recur기능적이며 꼬리 위치에서의 사용은 컴파일러에 의해 확인됩니다. ( 특수 양식 ).

— Daniil
소스
링크가 죽었다고 생각합니다.
— nawfal
1
@nawfal 나는 그것을 고정 된 생각
— 다닐
6
Link is dead (다시?)
— 계정
1
해당 링크의 비디오는 여기에서 찾을 수 있습니다 : vimeo.com/22675078 .
— GDP2
또한이 trampoline꼬리 호출.
— HappyFace
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.