일부 언어 커뮤니티 (예 : Ruby 및 Python)는 단편화를 방지하는 반면 다른 언어 (예 : Lisp 또는 ML)는 그렇지 않았습니다.

"Lisp"(또는 "Lisp-like")라는 용어는 Common Lisp, Scheme 및 Arc와 같은 다양한 언어의 우산입니다. ML과 같이 다른 언어 커뮤니티에서도 비슷한 조각화가 있습니다.

그러나 Ruby와 Python은 언어 자체를 변경하는 대신 PyPy 또는 YARV와 같은 구현에서 혁신이 더 많이 발생하는 이러한 운명을 피할 수있었습니다.

Ruby와 Python 커뮤니티는 언어 조각화를 방지하기 위해 특별한 작업을 수행 했습니까?

루비와 파이썬은 모두 독재자 에게 독재자 입니다. 실용적 우려에 깊이 뿌리를 둔 언어입니다. 이들은 아마도 조각화를 억제하는 가장 중요한 요소 일 것입니다. 반면에 Lisp와 ML은 이론적 인 목적으로 학계에서 고안된 "위원회 별 디자인"언어와 비슷합니다.

Lisp는 John McCarthy에 의해 컴퓨터 프로그램을위한 실용적인 수학적 표기법으로 원래 설계되었습니다. 그는 그것을 실제 프로그래밍 언어로 구현하지 않았다. 첫 번째 구현은 Steve Russell에 의해 개발 되었지만 자비로운 독재자는 아닙니다. 시간이 지남에 따라 다양한 다른 Lisp 구현이 나타났습니다. 일반적인 Lisp은이를 표준화하려는 시도였습니다.

Lisp는 언어의 "가족"에 가깝습니다. ML도 Lisp와 비슷한 진화 경로를 따랐습니다.

가능한 요인 중 하나는 단순히 나이입니다. Lisp 및 ML은 Python 및 Ruby보다 훨씬 오래되었습니다.

• 리스프 : 1958

• ML : 1973

• 파이썬 : 1991

• 루비 : 1995

Lisp와 ML은 분명히 하드웨어 기능의 변화, 컴퓨터 과학의 추세 및 작업 할 무언가를 찾는 훨씬 더 많은 박사 과정 학생들을 보았습니다.

그들은 본질적으로 모든 구현 정의 언어입니다

기존 코드와 대체로 호환 되는 새로운 언어 구현을 만드는 것이 쉬운 경우 해커는 해커이므로 계속 진행합니다. 누구나 어느 시점에서 Lisp 구현을 작성합니다. ML 컴파일러는 언어 디자인 분야의 대학원생에게는 거의 필수입니다. 언어는 모두 잘 문서화되어 있습니다.

반면에 특별 언어와 구현 정의 언어가 있습니다. 또는 너무 복잡한 언어는 실행 가능한 대체 구현을 생성하는 데 큰 장애가됩니다.

• 루비; 펄; python-실행 가능한 대안을 생성하기 위해 너무 구현 정의 됨
• ghc haskell과 erlang-잘 정의되어 있지만 사람들이 일반적으로 귀찮게하지 않는 ghc (또는 erlang)와 경쟁하는 것은하기가 어렵습니다.

실행 가능한 대안을 만들기에는 너무 어려운 언어 인 것처럼 보이는 단점은 막대한 단점이 있습니다 . 개발자 자원이 하나의 실제 구현에 집중되어 있지 않습니다.

역사적으로, Haskell 커뮤니티의 몇몇 사람들은 개발 커뮤니티의 파편이 우리가 성공하지 못할 것이라는 것을 인식하면서 합병과 개발 노력의 집중을 적극적으로 추구했습니다. GHC가 선택되어 챔피언이되었습니다.

한 가지 요소가 정의 플랫폼 이라고 말할 수 있습니다 . Haskell의 경우 플랫폼은 Haskell 표준과 GHC입니다 (상상). Ruby의 경우 Ruby 개발 플랫폼을 "정의한"Ruby on Rails였습니다. C에게는 유닉스였습니다.

언어와 같은 언어를 정의한 독창적 인 플랫폼이없는 Lisp와 비교해보십시오. 올바르게 기억한다면 각 Lisp 기계는 모델과 제조업체에 따라 약간의 차이가있었습니다. 일반적인 Lisp은 어떤 이유로 정의되지 않았습니다. 다른 플랫폼으로의 이동에 대한 경쟁과 주저가 너무 많기 때문일 수 있습니다.

이것은 물론 내 입장에서 전적으로 추측됩니다. 의견은 Harvey의 답변에 대한 의견 답변에서 비롯되었습니다. 그러나 정의 플랫폼은 여러 형태로 제공되는 것으로 보이지만 공통적 인 속성은 인기를 얻는 것입니다.

언어의 발달을 이끄는 문화의 무게를 잊지 마십시오

또한 파이썬 / PHP 개발이 활발히 진행되고 있다는 사실을 강조합니다. 모든 사람이 자유롭게 이용할 수있는 표준 사양을 정립 한 개인 그룹이 있습니다.

W3C가 HTML / CSS 표준을 사용하는 것과 매우 유사합니다. 당신은 언어가 성취하도록 설계된 것에 대한 세부 사항을 통제하는 작은 동기 부여 개인 그룹을 가지고 있습니다. 공개하기 전에 모든 것이 명확하게 정의 된 사양으로 들어갑니다.

OTOH, LISP와 같은 언어는 언어의 '최상의 사용'에 대한 그들의 견해가 옳다고 믿는 교수 또는 다른 개인에 의해 닫힌 문 뒤에 갈려 있습니다. 일부 구현은 특정 사항에서 훌륭하기 때문에 동시에 동시에 옳고 그름 일 수 있습니다. 모든 것이 최고는 아니지만.

다양성이 혁신을 일으키기 때문에 반드시 나쁜 것은 아닙니다. LISP와 같은 언어는 이해의 한계를 뛰어 넘기 때문에 학습과 연구를위한 훌륭한 언어로 남아 있습니다.

그러나 혁신에 좋은 환경을 만드는 자질이 반드시 안정성에 도움이되는 것은 아닙니다. 반대로, 안정을 위해 환경을 만드는 자질이 창의성을 위해 반드시 좋은 것은 아닙니다.

개발이 활발한 협업을 기반으로 할 때 개인은 더 큰 이익을 위해 인정해야 할 때가 있습니다. 연구에 좋지 않다 / 일관성에 좋다.

사실, 우리는 여전히 프로그래밍 언어 개발의 서부에 살고 있습니다. '이상적인 언어'를 설계하는 문제는 엄청난 노력에도 불구하고 그 언어를 해결하는 사람이 아무도 없었습니다.

연구 / 학계 부문에는 여전히 개선과 혁신의 여지가 많이 남아 있습니다. 실제 응용 분야에서 사용되는 소프트웨어가 기하 급수적으로 증가하는 상업 부문에서 추진력은 단순성과 일관성입니다.

일부 언어는 전자를, 일부 언어는 전자를 전문으로합니다. 둘 다 전문화하려는 사람들은 대개 잘하지 못하고 죽습니다.

두 가지 모두 VB / C # / Java와 같은 모 놀리 식 언어를 의미합니다. 말하기에는 너무 이르지만 10 년 후 C #과 Python의 모습을보고 싶습니다. 현재 속도에서 C #은 기능과 불일치를 점점 더 어둡게 보이게하고 있습니다. 훌륭한 문서화에도 불구하고, 언어에 포함 된 모든 미묘한 세부 사항과 단점을 기억하는 것은 너무 고통 스럽습니다. 독창적 인 스타일로 더 많은 개발자를 투입하자마자 코드베이스의 불일치가 커지고 품질이 저하되며 아무도 이길 수 없습니다. Perl이 프로덕션 환경에서 제공하는 어려움에서 많은 것을 배워야한다고 생각합니다.

파이썬과 루비와 같은 언어가 조각화되지 않았다고 말하는 것이 옳지 않다고 생각합니다. 이미 일부 조각화 효과가 나타나기 시작했습니다. 예를 들어, Python 3은 Python 2와 완전히 역 호환되지 않으므로 두 버전을 모두 유지 관리해야하며 기존 코드는 Python 2에서만 작동합니다. PyPy를 포함하여 일부 Python 스핀 오프도 있습니다.

또 다른 요소는 언어의 시대입니다. 조각화가 가장 많이 이루어지는 언어는 구 언어이므로 진화와 수정의 압력을받습니다. Lisp는 수십 년 전에 발명되었으므로 일부 아이디어를 취하여 새로운 언어로 통합 할 수있는 충분한 시간이있었습니다. C는 조각난 언어의 또 다른 예입니다. C는 언어 자체에 대한 주요 개정 사항이 하나만 있었지만 (K & R에서 ANSI로) C ++, Not C는 물론 C와 유사한 구문을 공유하는 다른 것들도 포함되어 있습니다.

루비 자체는 이전 언어의 "조각화"입니다. C, Smalltalk 및 Perl (다른 것들 중에서)의 아이디어를 통합하고 있기 때문에 현재 는 조각화를 수행 하는 언어 입니다. 미래에 다른 언어와 Ruby가 더 이상 컨볼 루션되지 않는 이유를 모르겠습니다.

리스프는 사상 가장 놀라운 언어 인 강력한 모델이기 때문에 조각난 것입니다. 오늘날 대부분의 언어는 Lisp에서 처음 구현 된 것을 빌려주므로 모든 언어가이 특정 조각화의 일부라고 말할 수 있습니다. 스몰 토크는 예를 들어 리스프에서 큰 영감을 받았으며 루비는 스몰 토크에서 큰 영감을 받았습니다. 자바 스크립트는 Lisp 등의 Lisp입니다. 모든 언어가 연결되어 있으며 모든 언어 개발자가 다른 언어에서 좋아하는 작품을 선택합니다.

또 다른 요소는 Lisp가 아마도 구현하기 가장 쉬운 프로그래밍 개념 일 것입니다. 이것이 반복해서 반복되는 이유입니다.

리스프와 유사한 언어는 너무 기본적이고 이론적으로 대폭 변경 될 수 없습니다. 문법적인 변화 (명령의 이름 만 바꾸는 것은 아닙니다)는 기능 프로그래밍 이론에 적합하지 않습니다.

그러나 lisp 와 같은 언어가 있다는 사실은 어쨌든 "변경"이 이미 lisp하도록 만들어 졌음을 보여줍니다. 다시 말해서, lisp에서 영감을 얻은 사람들이 만든 언어가 있거나 그 뒤에있는 이론이 있으며 비슷한 새로운 언어를 만들어 냈습니다.

파이썬에서 영감을 얻은 많은 언어도 있습니다. 예를 들어 Julia, CoffeeScript 등은 공백에 민감한 객체 지향 언어 제품군을 형성합니다.

파이썬과 같은 언어의 기본은 절대 변하지 않을 것이라고 생각합니다. 파이썬은 객체 지향적이므로 C ++ 및 Java와 유사하지만 동적이며 많은 스크립트 언어와 유사합니다.

누가 실제로 언어에 관심이 있습니까? 목적은 무엇입니까? 프랑스어는 라틴어와 비슷하지만 프랑스어를 이해하는 소녀는 더 뜨겁습니다.)