Lisp 커뮤니티가 왜 그렇게 분열되어 있습니까?

Lisp 커뮤니티가 왜 그렇게 분열되어 있습니까?

---

시작하려면 언어의 두 가지 주요 방언 (Common Lisp 및 Scheme)이있을뿐만 아니라 각 방언에는 많은 개별 구현이 있습니다. 예를 들어 Chicken Scheme, Bigloo 등은 각각 약간의 차이가 있습니다.

현대적인 관점에서 이것은 오늘날 언어가 결정적인 구현 / 사양을 갖는 경향이 있기 때문에 이상합니다. Java, C #, Python, Ruby 등을 생각해보십시오. 각 사이트에는 API 문서, 다운로드 등을 위해 이동할 수있는 하나의 최종 사이트가 있습니다. 물론 Lisp는 이러한 모든 언어보다 앞서 있습니다. 그러나 다시 말하지만 C / C ++조차도 표준화되어 있습니다.

Lisp의 시대로 인해이 커뮤니티가 분열 되었습니까? 아니면 다른 문제를 해결하기 위해 다른 구현 / 방언이 의도 된 것일까 요? 나는 Lisp가 하나의 최종 구현을 중심으로 성장한 언어만큼 통합되지 않는 이유가 있다는 것을 이해합니다. 그러나이 시점에서 Lisp 커뮤니티가이 방향으로 움직이지 않아야하는 이유가 있습니까?

---

Lisp 커뮤니티는 단편화되어 있지만 다른 모든 것도 마찬가지입니다.

• Linux 배포판이 많은 이유는 무엇입니까?

• BSD 변형이 많은 이유는 무엇입니까? OpenBSD, NetBSD, FreeBSD, ... 심지어 Mac OS X.

• 스크립팅 언어가 많은 이유는 무엇입니까? Ruby, Python, Rebol, TCL, PHP 및 수많은 기타.

• 왜 그렇게 많은 유닉스 쉘이 있는가? sh, csh, bash, ksh, ...?

• 왜 Logo (> 100), Basic (> 100), C (무수), ...

• 루비에는 왜 그렇게 많은 변형이 있습니까? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?

• Python에는 메인 사이트가있을 수 있지만 CPython, IronPython, Jython, Python for S60, PyPy, Unladen Swallow, CL-Python 등 몇 가지 약간 다른 구현이 있습니다.

• C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C ++, C #, Cilk, Objective-C, D, BCPL, ...이있는 이유는 무엇입니까?

그들 중 일부는 50 개가되게하고 얼마나 많은 방언과 구현이 있는지 확인하십시오.

모든 언어가 다양하거나 다양하기 때문에 Lisp는 다양하다고 생각합니다. 일부는 단일 구현 (McCarthy의 Lisp)으로 시작하고 50 년 후에 동물원을 갖게됩니다. Common Lisp는 여러 구현으로 시작했습니다 (다른 머신 유형, 운영 체제, 다른 컴파일러 기술 등).

요즘 Lisp는 단일 언어가 아닌 언어 계열입니다 . 어떤 언어가 그 가족에 속하는 지에 대한 합의조차 없습니다. 확인할 기준 (s- 표현식, 함수, 목록 등)이있을 수 있지만 모든 Lisp 방언이 이러한 기준을 모두 지원하는 것은 아닙니다. 언어 디자이너들은 다양한 기능을 실험했고 우리는 Lisp와 유사한 언어를 많이 얻었습니다.

Common Lisp를 살펴보면 약 3 ~ 4 개의 활성 상업 공급 업체가 있습니다. 하나의 제안 뒤에 그들을 가져 오십시오! 작동하지 않습니다. 그런 다음 서로 다른 목표를 가진 여러 활성 오픈 소스 구현이 있습니다. 하나는 C로 컴파일되고, 다른 하나는 C로 작성되고, 하나는 빠른 최적화 컴파일러를 사용하고, 하나는 네이티브 컴파일을 사용하여 middlle 기반을 갖기 위해 시도하고, 하나는 JVM ... 등등. 유지 관리자에게 구현을 중단하라고 지시하십시오!

Scheme에는 약 100 개의 구현이 있습니다. 많은 사람들이 죽었거나 대부분 죽었습니다. 최소 10 ~ 20 개가 활성화되어 있습니다. 일부는 취미 프로젝트입니다. 일부는 대학 프로젝트이고 일부는 회사의 프로젝트입니다. 사용자는 다양한 요구를 . 하나는 게임을위한 실시간 GC가 필요하고, 다른 하나는 C에 임베딩이 필요하고, 다른 하나는 교육 목적으로 베어 본 구조 만 필요합니다. 개발자에게 자신의 구현을 해킹하지 못하도록하는 방법.

그런 다음 Commmon Lisp를 좋아하지 않는 사람들이 있습니다 (너무 크고, 너무 오래되고, 기능이 충분하지 않으며, 객체 지향적이지 않음, 너무 빠르다, 충분히 빠르지 않음, ...). 일부는 Scheme을 좋아하지 않습니다 (너무 학문적, 너무 작음, 확장되지 않음, 너무 기능적, 기능적 충분하지 않음, 모듈 없음, 잘못된 모듈, 올바른 매크로가 아님 ...).

그러면 누군가 Objective-C와 결합 된 Lisp가 필요하면 Nu를 얻게됩니다. 누군가 .net 용 Lisp를 해킹합니다. 그런 다음 동시성과 신선한 아이디어를 가진 Lisp를 얻으면 Clojure가 있습니다.

직장에서 의 언어 진화 입니다. 캄브리아기 폭발 (많은 새로운 동물이 나타 났을 때)과 같습니다. 일부는 죽고 다른 일부는 계속 살 것이며 일부는 새로 나타날 것입니다. 어느 시점에서 어떤 방언이 예술의 상태 (70 년대 / 80 년대 Lisp에서 함수형 프로그래밍을 사용하는 모든 것에 대한 계획, 80 년대 MacLisp와 유사한 모든 것에 대한 Common Lisp)를 선택하는 방언이 나타납니다. 이로 인해 일부 방언이 대부분 사라집니다 ( 즉 Standard Lisp, InterLisp 및 기타).

Common Lisp는 Lisp 방언의 악어입니다. 약간의 변화가있는 아주 오래된 디자인 (1 억 년)이고, 약간 무섭게 보이며, 때때로 어린 아이들을 먹습니다 ...

더 많은 것을 알고 싶다면 Lisp의 진화 (및 해당 슬라이드)가 아주 좋은 시작입니다!

---

"Lisp"는 언어에 대한 광범위한 설명이기 때문이라고 생각합니다. 내가 아는 모든 lisps 사이의 유일한 공통점은 대부분이 괄호 안에 있고 접두사 함수 표기법을 사용한다는 것입니다. 예

(fun (+ 3 4))

그러나 거의 모든 것은 구현에 따라 다를 수 있습니다. Scheme과 CL은 완전히 다른 언어이므로 그렇게 생각해야합니다.

나는 lisp 커뮤니티를 단편화라고 부르는 것은 "C like"커뮤니티를 단편화라고 부르는 것과 같다고 생각합니다. 그것은 c, c ++, d, java, c #, go, javascript, python 및 내가 생각할 수없는 다른 많은 언어를 가지고 있습니다.

요약 : Lisp는 실제 언어 구현보다 언어 속성 (예 : 가비지 수집, 정적 형식 지정)에 가깝기 때문에 많은 언어에 가비지 수집이있는 것처럼 Lisp와 같은 속성을 가진 많은 언어가있는 것은 완전히 정상입니다.

---

Lisp가 해커 문화의 정신에서 태어나고 유지하고 있기 때문이라고 생각합니다. 해커 문화는 "더 나은"에 대한 당신의 믿음에 따라 무언가를 가져와 "더 나은"것으로 만드는 것입니다.

따라서 수많은 해커와 수정 문화가있을 때 조각화가 발생합니다. 당신은 얻을 계획 , 커먼 리스프 , ELISP , 아크 . 이것들은 모두 상당히 다른 언어이지만 동시에 "Lisp"입니다.

이제 커뮤니티는 왜 단편화되어 있습니까? 글쎄, 나는 그것에 대한 시간과 성숙을 비난 할 것입니다. 언어는 50 년이되었습니다! :-)

---

LISP는 BASIC만큼 단편화되지 않습니다.

BASIC의 방언과 버전이 너무 많아서 카운트를 잃었습니다.

가장 일반적으로 사용되는 구현 (MS VB)조차도 버전마다 다릅니다.

---

Scheme 및 Common Lisp가 표준화되었습니다. SBCL은 사실상 오픈 소스 lisp처럼 보이며 사용 방법에 대한 많은 예제가 있습니다. 빠르고 무료입니다. ClozureCL도 꽤 좋아 보입니다.

PLT Scheme은 사실상 오픈 소스 체계처럼 보이며 사용 방법에 대한 많은 예제가 있습니다. 빠르고 무료입니다.

CL HyperSpec은 나에게 JavaDoc만큼 좋은 것 같습니다.

커뮤니티 분열에 관해서는 이것이 표준이나 자원이 거의 없다고 생각합니다. 나는 이것이 최근까지 비교적 작은 커뮤니티였던 것과 훨씬 더 관련이 있다고 생각합니다.

Clojure 새로운 세대의 코더를 위해 The Lisp가 될 좋은 기회가 있다고 생각합니다.

아마도 내 요점은 매우 인기있는 구현이 응집 된 커뮤니티 의 환상 을 제공하는 데 필요한 모든 것입니다 .

---

The fact that there are many implementations of Common LISP should be considered a good thing. In fact, given that there are roughly the same number of free implementations of Common LISP as there are free implementations of C++ is remarkable, considering the relative popularity of the languages.

Free Common LISP implementations include CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL and ECL.

Free C++ implementations include G++ (with Cygwin and MinGW32 variants), Digital Mars, Open Watcom, Borland C++ (legacy?) and CINT (interpreter). There are also various STL implementations for C++.

With regards to Scheme and Common LISP, although admittedly, an inaccurate analogy, there are times when I would consider Scheme is to Common LISP what C is to C++, i.e. while Scheme and C are small and elegant, Common LISP and C++ are large and (arguably) more suited for larger applications.

---

Two possible contributing factors:

Lisp languages aren't hugely popular in comparison to other languages like C/C++/Ruby and so on - that alone may give the illusion of a fragmented community. There may be equal fragmentation in the other language-communities, but a larger community will have larger fragments..

Lisp languages are easier than most to implement. I've seen many, many "toy" Lisp implementations people have made for fun, many "proper" Lisp implementations to solve specific tasks. There are far more Lisp implementations than there are, say, Python interpreters (I'm aware of about.. 5, most of which are generally interchangeable)

There are promising projects like Clojure, which is a new language, with a clear goal (concurrency), without much "historical baggage", easy to install/setup, can piggyback on Java's library "ecosystem", has a good site with documentation/libraries, and has an official mailing list. This pretty much checks off every issue I encountered while trying to learn Common Lisp a while ago, and encourages a more centralised community.

---

Having many implementations is beneficial, because each implementation is optimal in unique places. And modern mainstream languages don't have one implementation anyway. Think about Python: its main implementation is CPython, but thanks to JPython you can run Python on the JVM too; thanks to Stackless Python you can have massive concurrency thanks to microthreads; etc. Such implementations will be encompatible in some ways: JPython integrates seamlessly with Java, whilst CPython doesn't. Same for Ruby.

What you don't want is having many implementations which are incompatible to the bone. That's the case with Scheme, where you can't share libraries among implementations without rewriting a lot of code, because Schemers can't agree on how to import/export libraries. Common Lisp libraries, OTOH, because of standardization in core areas, are more likely to be portable, and facilities exist to conditionally write code handling each implementation's peculiarities. Actually, nowadays you may say that Common Lisp is defined by its implementations (think about the ASDF package installation library), just like mainstream languages.

---

My point of view is that Lisp is a small language so it is easy to implement (compare to Java, C#, C, ...).

Note: As many comment that it is indeed not that small it miss my point. Let me try to be more precise: This boll down to the entry point price. Building a VM that compile some well know mainstream language is quit hard compare to building a VM that deal with LISP. This would then make it easy to build small community around a small project. Now the library and spec may or may not be fully implemented but the value proposition is still there. Closure it a typical example where the R5RS is certainly not in the scope.

참고URL : https://stackoverflow.com/questions/2114819/why-is-the-lisp-community-so-fragmented