다른 JVM Lisps보다 Clojure가 필요한 이유 : Kawa, Armed Bear 또는 SISC?

다른 JVM Lisps보다 Clojure가 필요한 이유 : Kawa, Armed Bear 또는 SISC?

---

JVM은 Clojure가 현장에 도착하기 전에 이미 세 개의 Lisps를 가지고있었습니다 : Kawa , Armed Bear 및 SISC .

Clojure 는 그 Lisps가 남긴 간격을 어떻게 채우나요?

---

Kawa, ABCL 및 SISC는 상당히 긴 기존 언어를 다시 구현 한 것입니다. 어떤 이유로 든 JVM에서 표준 Scheme 또는 표준 Common Lisp를 사용하려는 경우 우수합니다.

Clojure는 새로운 언어입니다. 간격을 채우지 않습니다 . 완전히 새로운 가능성을 추가합니다. 순전히 기능적인 접근 방식을 선호합니다. Scheme과 CL은 모두 다중 패러다임입니다. Clojure는 다양한 FP 언어 (ML, Haskell)의 디자인에서 많이 차용합니다.

그리고 예, 다른 Lisps에 동시성 지원을 추가 할 수 있지만 그 점이 완전히 누락되었습니다. Clojure는 처음부터 동시 언어로 설계되었습니다. 동시 프로그램을 작성하는 것은 비 기능적 언어 (Scheme, CL 제외되지 않음)에서와 같이 로켓 과학이 아닌 Clojure에서 사소한 일입니다. 이 방법을보십시오 :

사람들은 C를 사용하면 기본적으로 빠른 프로그램을 작성할 수 있다고 말합니다.

Clojure를 사용하면 기본적으로 동시 프로그램을 작성할 수 있습니다.

---

1. "Clojure는 이전 버전과의 호환성에 제약을받지 않는 Lisp입니다"(Clojure 웹 사이트에서 가져온 것임). 새로운 시작입니다. 진행 중입니다. Lisp / Scheme을 강력하게 만드는 아이디어를 사용하되 Java 플랫폼 에 대해 다시 생각해보십시오 .

2. Clojure는 항상 가장 최근의 Clojure입니다. JVM에 이식 된 다른 언어를 사용하면 JVM 버전이 항상 따라 잡을 수 있습니다. Java 플랫폼이 필요하지 않은 경우 다른 Scheme보다 SISC를 사용하는 이유는 무엇입니까? 그렇다면 특별히 설계된 Lisp (Clojure)를 사용하지 않으시겠습니까?

3. 동시성을 염두에두고 설계되었습니다.

---

제가 생각해 낼 수있는 가장 간단한 대답은 Clojure가 Common-Lisp가 아니라는 것입니다. Clojure는 다른 Lisps의 역사에 제약을받지 않습니다. 그것은이다 새로운 언어에 내장 된 JVM을 위해.

---

나는 Clojure에게 심각한 이점 인 (사람들이 내가 발견 한 충분한 소음을내는) 그것들을 단순히 인식하지 못했습니다. Clojure가 나열한 목록에서 보지 못한 가장 큰 것은 Software Transactional Memory 입니다.

Clojure는 다른 언어를위한 계층이 아니라 JVM 용으로도 설계 되었기 때문에 상호 운용을해야 할 때 다른 언어가 될 것이라고 생각하는 것은 좀 더 "Java-y"입니다.

---

clojure.org의 근거 페이지는 다음과 같이 설명합니다.

왜 또 다른 프로그래밍 언어를 작성 했습니까? 기본적으로 내가 원했기 때문에 :

• Lisp
• 함수형 프로그래밍 용
• 확립 된 플랫폼과 공생
• 동시성을 위해 설계

하나를 찾을 수 없습니다.

언급 한 3 개 언어 (Kawa, ABCL 및 SISC)가 이러한 요구 사항을 충족합니까? 그들은:

• Lisps (CL 또는 Scheme 방언) ✓
• 함수형 프로그래밍 ✓
• 기존 플랫폼 (JVM)과 공생 ✓

그러나 그들은 (STM) 동시성을 위해 설계 되지 않았습니다 . 그러나 공정하고 완전하기 위해 아직 언급되지 않은 CL에 대해 찾은 STM 라이브러리가 2 개 이상 있습니다.

1. STMX
   • ABCL 작업을 테스트했습니다. 활발한 개발 중입니다.
2. CL-STM
   • 죽은? 마지막 변경은 2007 년이었습니다.

흠 ... 그럼 왜 새로운 Lisp를 만드나요? 주로 이것들이 라이브러리 이기 때문 입니다. clojure.org의 근거 페이지는 계속됩니다 (강조 추가됨) :

표준 Lisps (Common Lisp 및 Scheme)는 어떻습니까?

• 표준화 후 느리거나 혁신 없음
• 핵심 데이터 구조는 확장 가능하지 않고 변경 가능
• 사양에 동시성 없음
• JVM (ABCL, Kawa, SISC 등)에 대한 좋은 구현이 이미 존재합니다.
• 표준 Lisps는 자체 플랫폼입니다.

그것은이다 언어 동시 설계 다른 언급으로, 문제를 해결합니다.

또한 JVM에서 멈추는 이유는 무엇입니까? Clojure CLR 지원은 현재 개발 중 입니다.

Those are the 2 gaps it fills, from my perspective. You should use Clojure if it meets your needs. Don't worry about losing your skills if Clojure drops off the map. Your Lisp skills, but more importantly your way of thinking, will carry over to other Lisp dialects.

---

If I were being cynical, I'd say it's because Clojure's got a nicer website and a sexier name.

---

I should also add that Clojure is a relatively new language, implemented by one person, with good marketing skills and a lot of energy. He's investing a lot of time and hype into clojure ... sometimes, the hype is a self-fulfilling prophecy in that if you can convince enough people that it's the latest greatest thing, then you can get enough support and momentum to make it actually work.

I suspect the implementers of Kawa etc. don't have as much at stake, hence are not hyping their product. Besides, what's there to hype? "We've got a great language .. it's called Lisp" It's a harder marketing sell.

I think Java is a prime example of this. It had some very serious deficiencies, but because it was marketed and hyped so heavily it achieved a lot of momentum which meant support from hardware/software vendors, producers of tools, investment by industry, etc. Either way, it achieved a certain degree of success, although I hated programming in it. Clojure might achieve a similar success where other Lisps have not.

---

The advantage of Clojure is that it gives you access to all the java libraries/code out there, and multi-threading support because it's based on the JVM. In addition it was designed with concurrency in mind, something not generally designed into lisp, although because of the mapping primitives it probably wouldn't be hard to design a lisp that would support concurrency well.

That being said, I tried Clojure and hated the syntax and the pain in the butt factor that seems to go along with anything Java-connected.

---

Clojure is "a lisp", it's not any lisp you already know. I've spent the last couple days reading the material and viewing the videos, and I'm impressed. Its premise is that functional programs (based on immutable data) are the best way to manage concurrency. Clojure implements a lisp-like system based on JVM to provide it.

---

We don't have to have one more answer (and I don't expect votes for this one), but here are some small enhancements to several other answers.

Newer is not necessarily better. Newer and poorly designed is not good, newer and not maintained is not good, and newer without a larger (or at least growing) user community is not good. (New languages come out regularly, but most of them fall by the wayside because of disuse.)

I love Common Lisp. Part of its beauty is its quirkiness, which comes from the fact that it was designed by committees with a goal of backward compatibility to several incompatible dialects.

I love Scheme. It's a beautiful, elegant language. Nevertheless, its development depends on committees, and perhaps that has slowed it down at times. In any event, its goals are different from Clojure's.

Common Lisp and Scheme have emphases such as tail recursion that are not well-suited to efficiency on the JVM. Clojure was designed from the start to map well onto the JVM, and to interoperate (fairly) well with Java. (I'm not sure what that means about the Clojurescript and CLR dialects.)

The fact that Clojure was developed, initially, by one person, Rich Hickey, and is controlled by him along with a small team, does not necessarily make it better than a language controlled by committees. If that one person made bad decisions, Clojure would not be a good language.

However, and this is the important point: Hickey designed a language that is well thought out, elegant, and that from the start included a systematically related suite of functions that make it easy to do a lot with a little. That goes for the basic JVM interop as well as the rest of the language. The folks who control Clojure continue to be strict about sticking to the language's goals, so far.

This is a big part of what I love about Clojure: It is well designed both as a whole and in its details. That means that once you get used to it, it's a pleasure to program in it.

It would only be a little bit of an overstatement (or understatment?) to say that Clojure has the power of Common Lisp with the elegance of Scheme. Common Lisp has lots and lots of what you need built into the language, but it's a mess (I say that with love), and when you need something more than what's in the language, there are sometimes several incompatible libraries with different tradeoffs. Scheme by design is small, although there are libraries available. Clojure has a growing body of standard libraries (unlike CL) that are more or less parts of the language. A nice illustration of this is the core.matrix project, which provides a common interface to several different matrix implementations. This is important, because there are different matrix implementations that are best for occasional use of small matrices, or for extensive use of huge matrices, for example.

None of this is intended to say that Clojure is better than Common Lisp or Scheme; it's not. The three languages have different virtues.

---

It's new! Which means not a lot of old lispers will use it since the traditional lisp community is well, traditional, but it also means that people with no previous lisp experience will pick it up as the new thing.

Imho, Clojure is to older Lisps what Ruby was to Smalltalk. Not necessarily better, but good enough. And crucially, it's more acceptable to your employer because it has momentum and is viewed as a language on the rise, much like Ruby once was.

참고URL : https://stackoverflow.com/questions/1413390/why-clojure-over-other-jvm-lisps-kawa-armed-bear-or-sisc