문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 LISP (문단 편집) == 이야기거리 == 리스프와 관련된 격언(?)으로 Greenspun's tenth rule이라는 게 있다.[* Greenspun의 10번째 법칙. Greenspun의 말에 의하면, 1-9번째 법칙이 있지는 않고 그냥 10번째 법칙이라 하면 기억에 잘 남을 것이라 생각했다고 한다. [*출처 [[http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tgU]] ]] >Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. 설명하자면, 커먼 리스프의 여러가지 강력한 기능들은 프로그램이 어느정도 복잡해지면 어딘가에 반드시 필요하게 되고, 그런 기능을 갖고있지 않은 C와 같은 언어로 그런 복잡한 프로그램을 만들면, 결국 본인도 모르는 사이에 커먼 리스프의 그런 기능을 C 언어로 구현하고 있게 되며, 당연히 그런 즉흥적(?) 구현은 오랜 시간에 걸쳐 잘 디자인된 커먼 리스프에 비해 질적으로 떨어질수밖에 없다는 소리. ~~뭔가 오만한 것 같은데, 리스프 책 몇 권 보면 정말 리스프 프로그래머들의 콧대는 하늘을 뚫는 것을 쉽게 알 수 있다~~ 리스프의 특징과 초기의 설계목적(새로운 언어 기능의 실험) 때문에 리스프는 처음에는 산술 연산 같은 것을 빠르고 가볍게 처리하지 못했다. ~~먼저 태어난 포트란은 애초부터 이런 쪽으로 [[먼치킨(클리셰)|먼치킨]] 이었고, 지금도 그렇다. 그리고 이 때는 컴퓨터의 성능이 한참 구리기도 했다.~~ 이는 동적 타이핑과 특정 위치의 데이터를 검색하는데에 효율적이지 못했던 리스트형 자료구조 위주로 사용하던 초기의 문제였다. 그러나 곧 많은 능력자들에 의해 리스프 컴파일러 및 인터프리터가 꾸준히 개량되고, 언어 자체도 리스트가 아닌 여러가지 자료구조를 탑재하고 타입 지정이 가능하도록 개량되면서, 절차형 언어에 비해 근본적인 한계가 있음에도 이런 문제가 어느 정도 해결되었다. 이런 측면 덕분에 리스프 프로그램 개발과정은 좀 독특한데, 먼저 [[스크립트 언어]]처럼 동적 타이핑과 사용하기 편리한 리스트형 자료구조 위주로 빠르게 프로토타입을 뽑아낸 뒤에 프로토타입이 다 완성되면 타입지정과 함께 사용된 자료구조들을 보다 효율적인것들로 바꿔주는식으로 최적화하여 완성하게 된다. 그래서 최종적으로 완성된 리스프 프로그램은 리스트형 자료구조가 전혀 사용되지 않은 경우도 있다. 프로토 타입의 성능은 보통의 스크립팅 언어에 가깝고, 최적화가 완료된 프로그램의 성능은 컴파일 언어에 가까워진다고 보면 된다. 인터프리터에서 파트별로 쉽게 테스트 가능한 함수형 패러다임을 완벽에 가깝게 지원하며, 대부분의 리스프 인터프리터는 프로그램 실행도중에 코드를 변경하고 즉석에서 적용하는게 가능하기때문에 개발 자체는 생각보다 많이 편리한편. 대부분의 오래된 언어들이 그렇듯, 점점 인기가 사그라드는 것이 일반적인데, 리스프는 오히려 2000년대 들어 고전의 향수를 느끼려는(?) 젊은 프로그래머들과, 기존 OOP와 절차형 프로그래밍 언어의 한계를 느낀 개발자들에 의해 인기를 끌고 부활하였다. 그 인기의 중심에는 실용성을 중심으로 [[C++]]처럼 언어를 엄청나게 거대하게 키운 커먼 리스프와 함수형 프로그래밍에 중점을 둔 작은 언어인 스킴(Scheme)이 있다. 보통 실제 프로젝트에서는 커먼 리스프가 주로 사용되었고, 대학이나 기타 교육 목적으로는 스킴이 많이 사용되었다. 하지만, 근래들어 커먼 리스프는 여전히 강력하긴 하지만 좀 낡았다는 평가를 받고있 고, 최근의 함수형 언어 붐~~(이라기는 좀 힘들지만)~~에 힘입어 스킴 쪽에 관심이 상당히 쏠린 편인데, 스킴은 실용적인 목적으로 사용하기엔 작아도 너무 작기 때문에[* 그래서, 기존에도 스킴 컴파일러들은 표준적인 부분 이외에 다들 나름의 꽤 커다란 확장을 같이 탑재해서 배포했었다. 이런 경향이 반영된 탓인지, 최근의 표준인 R6RS부터는 더이상 작다고 보긴 힘들어졌는데, 스킴 위원회쪽에서 이런 경향에 반발세력도 꽤 있던 탓인지, 이제는 아예 small scheme, large scheme 두 가지 표준을 운영하는식으로 바뀌어 버렸다.] 요즘엔 스킴을 이리저리 확장시키고 모던한 기능들을 추가한 스킴 방언이 많이 나오고 있는 편이다. 이 새로운 스킴 방언의 대표적인 예로 저수준 매크로로 언어의 확장성을 크게 높여 여러가지 다른 언어로 쉽게 변신이 가능한 라켓([[Racket]])이 있다. 이와 별도로 2007년에 갑툭튀하여 [[Java Virtual Machine]] 위에서 돌아가도록 만들어져 자바의 라이브러리를 그대로 끌어다 쓰면서 자바보다 높은 생산성을 자랑하는 클로저(Clojure)가 있다. 리스프는 너무나 많은 사투리를 가지고 있기 때문에, 보통 "리스프 커뮤니티"라고 부를 수 있는 것이 존재하지 않으며, 대신 "커먼 리스프 커뮤니티", "스킴 커뮤니티", "래킷 커뮤니티" 등 많이 쓰이는 사투리의 커뮤니티가 따로 존재한다. 당연하게도, 인터넷에서 검색해서 찾을 수 있는 자료 또한 이 항목과 같이 리스프 전반에 대해 설명하는 것이 아니라면, 이런 식으로 특정 방언에 속하는 리스프에 대한 것이 대부분이다. 하지만 한국에서 리스프 계열 언어는 매우 마이너한 언어에 속하며, 따라서 "리스프 커뮤니티"라는 제목 아래에 리스프의 여러 사투리에 대해 논의되는 커뮤니티가 극소수 존재한다. 영문권 리스프 프로그래머들은 예/아니오 구문인 P를 일상생활에 이용하는 경우가 많았다고 한다. 예를 들어: >Q: "Foodp" (밥먹을래?) >A: "T" (True = 응.) >A: "NIL" (False = 아니.)저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기