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의 단점) :

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

  • 다른 장점?

생각? 다른 차이점?


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과 같은)입니다 (기능적 언어에서는 함수와 데이터를 동일한 네임 스페이스에 유지하는 것이 합리적이라고 생각합니다)


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를 제공하고 라이브러리는 일정한 형태의 연속성을 제공합니다.


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기능적이며 꼬리 위치에서의 사용은 컴파일러에 의해 확인됩니다. ( 특수 양식 ).


링크가 죽었다고 생각합니다.
nawfal

1
@nawfal 나는 그것을 고정 된 생각
다닐

6
Link is dead (다시?)
계정

1
해당 링크의 비디오는 여기에서 찾을 수 있습니다 : vimeo.com/22675078 .
GDP2

또한이 trampoline꼬리 호출.
HappyFace
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.