LispM의 CommonLisp 공부 조언 ¶
Lisp을 배울 수 있는 책은 안타깝게도 구하기가 어렵다. 특히 한글로 된 책은 전무한 실정이다. 원서의 경우는 (다른 프로그래밍 언어 책과는 달리) 대부분 읽어볼 가치가 있다.
프로그래밍을 처음 배우는 사람을 위한 책으로는 David Touretzky의 Common Lisp: A Gentle Introduction To Symbolic Computation을 권할 만하다. 저자는 CMU 인문학 학생들에게 프로그래밍을 가르치기 위해 썼다고 밝히고 있는데, 그래서 그런지 많은 그림과 더불어 프로그래밍을 조금 해본 사람에게는 자칫하면 지루할 수 있다. 프로그래밍에 경험이 있는 사람은 짧은 시간 내에 읽을 수 있을 만한 책이다. 비 전공자를 위한 책이라고는 하지만, 전부 읽고 소화한다면 웬만큼 CommonLisp을 사용할 수 있게 될 것이다. 아쉽게도 CLOS, LOOP, Stream, Package 등등에 대한 언급이 없고, 매크로를 충분히 다루지 않는다. 책이 절판되었는지는 확인해보지 않았다. 도서관에서 대여해서 보기를 권한다.
프로그래밍 경험이 있는 사람에게는 Paul Graham의 ANSI Common Lisp, Sonya Keene의 Object Oriented Programming in Common Lisp, Paul Graham의 On Lisp: Advanced Techniques for Common Lisp, 그리고 Peter Norvig의 Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp 을 차례로 권한다.
Paul Graham의 첫번째 책은 CommonLisp에 대해 약간의 개념만 생기면 없어도 큰 불편이 없는 책이다. 그의 두번째 책은 내용의 거의 반 이상이 CommonLisp 매크로를 가르친다. 매크로 Wizard가 되려면 꼭 있어야 할 책이다. 아쉽게도 On Lisp은 절판된 상태인데, 다행히 그의 웹사이트에 가면![[http]](/ns/imgs/http.png)
웹버젼이 있다.
Sonya Keene의 책은 CLOS - Common Lisp Object System - 를 가르치는 책인데, 아쉽게도 절판되었다. 오래 전에 "대영사"에서 수입한 적이 있었는데 혹시 모르니 전화해 보라(전화번호 바뀌었을 지도 모름). 전화는 393-0417 혹은 392-1424로, 옛날 책이라 헐값에 팔았었다. 전 세계적인 절판이기 때문에 가능하면 많이 사쟀다가 (진지하게) Lisp 프로그래밍 하는 사람을 만났을 때 선물로 주면 무지하게 좋아한다. 개인적으로 친분있는 한 Lisp 프로그래머는 이 책을 Kent Pitman이라는 Wizard급 Lisp 프로그래머에게 직접 선물 받았다고 자랑했던 기억이 난다.
Peter Norvig의 책은 이미 있는 리뷰를 참조하기 바란다.
Paul Graham의 첫번째 책은 CommonLisp에 대해 약간의 개념만 생기면 없어도 큰 불편이 없는 책이다. 그의 두번째 책은 내용의 거의 반 이상이 CommonLisp 매크로를 가르친다. 매크로 Wizard가 되려면 꼭 있어야 할 책이다. 아쉽게도 On Lisp은 절판된 상태인데, 다행히 그의 웹사이트에 가면
웹버젼이 있다.Sonya Keene의 책은 CLOS - Common Lisp Object System - 를 가르치는 책인데, 아쉽게도 절판되었다. 오래 전에 "대영사"에서 수입한 적이 있었는데 혹시 모르니 전화해 보라(전화번호 바뀌었을 지도 모름). 전화는 393-0417 혹은 392-1424로, 옛날 책이라 헐값에 팔았었다. 전 세계적인 절판이기 때문에 가능하면 많이 사쟀다가 (진지하게) Lisp 프로그래밍 하는 사람을 만났을 때 선물로 주면 무지하게 좋아한다. 개인적으로 친분있는 한 Lisp 프로그래머는 이 책을 Kent Pitman이라는 Wizard급 Lisp 프로그래머에게 직접 선물 받았다고 자랑했던 기억이 난다.
Peter Norvig의 책은 이미 있는 리뷰를 참조하기 바란다.
CommonLisp을 배우려는 사람에게는 표준 스펙이 또한 필요하다. 과거에는 Guy Steel Jr.의 CLtL2(Common Lisp the Language 2nd ed.)를 사용했으나 이제는 Kent Pitman의 Common Lisp HyperSpec(CLHS) 하나면 충분하다.
대부분의 CommonLisp 프로그래머들은 CLHS를 화면 한쪽에 띄워놓고 Emacs 에디터로 프로그래밍 한다. Emacs 에디터와 브라우저를 연결시켜서 에디터에서 커서를 함수나 매크로위에 대고 키를 누르면 브라우저가 해당 CLHS 페이지를 보여주기도 한다. 필수!
Common Lisp HyperSpec(CLHS) 하나면 충분하다.대부분의 CommonLisp 프로그래머들은 CLHS를 화면 한쪽에 띄워놓고 Emacs 에디터로 프로그래밍 한다. Emacs 에디터와 브라우저를 연결시켜서 에디터에서 커서를 함수나 매크로위에 대고 키를 누르면 브라우저가 해당 CLHS 페이지를 보여주기도 한다. 필수!
웬만큼 CommonLisp에 경험이 쌓이고, CLOS가 지원하는 이상의 OOP가 필요하게 되면 또 한권의 책이 필요하다. 보통의 프로그래밍 언어에서는 지원하는 OOP에 불만이 있다고 해서 프로그래머가 그 언어 자체에 대한 프로그래밍, 즉 MetaLevelProgramming 하는 것이 불가능 하다. 하지만, CLOS는 MetaObjectProtocol(MOP)을 지원하기 때문에 자신만의 확장을 할 수 있다. 예를 들면, 관계형 DB를 OODB로 사용하고 싶을 때 이 MOP으로 Object를 자연스럽게 만들 수 있다. 바로 AspectOrientedProgramming에서 추천한 AMOP이 필요하다. 만일 Sonya Keene의 책을 구하지 못할 시에는 이책을 그 대용으로 사용해야 하는데, Lisp을 잘 모르는 상태에서는 더 큰 혼란을 초래할 수도 있으니 주의해야 한다.
위에서 말한 책들 이외에도 대부분의 Lisp관련 책들은 읽어볼 가치가 있다.
인터넷에서도 한글로 된 Lisp 관련 자료는 찾아보기 어렵다. comp.lang.lisp은 매우 활발히 토론이 이루어 지는데, 자주 Wizard급 Lisp 프로그래머들의 글을 읽어볼 수 있다. 반면 han.comp.lang.lisp은 거의 토론이 이루어지지 않고 있다. 그외 웹사이트로 Cliki, lisp.org 등이 있다.
Lisp을 처음 접할 때 올 수 있는 공포(?)를 덜기위한 팁을 몇자 적는다.
처음 Lisp을 대할 때 나타날 수 있는 생소함은 괄호에 대한 문제가 있다. 괄호는 문법을 이해하는 에디터를 사용함으로써 해결할 수 있다. Emacs 에디터를 추천한다.
CommonLisp 구현은 여러가지 있지만(FreeSoftware로는 CMU CL이 있다) 어떤 구현을 사용하든지 Emacs에 ILisp 패키지를 이용할 것을 권한다. 이렇게 하면 나중에 다른 구현을 사용하더라도 동일한 환경을 유지할 수 있다. 단, Emacs는 Windows에서는 그다지 안정되지 않았기 때문에 시간과 노력을 아끼기 위해서 Unix계열에서만 시도하기 바란다.
CommonLisp 구현은 여러가지 있지만(FreeSoftware로는 CMU CL이 있다) 어떤 구현을 사용하든지 Emacs에 ILisp 패키지를 이용할 것을 권한다. 이렇게 하면 나중에 다른 구현을 사용하더라도 동일한 환경을 유지할 수 있다. 단, Emacs는 Windows에서는 그다지 안정되지 않았기 때문에 시간과 노력을 아끼기 위해서 Unix계열에서만 시도하기 바란다.
괄호와 관련된 또다른 생소함은, Lisp에는 문장(statment)이 없고 수식(expression)만 존재한다는 것이다. 이런 종류의 프로그래밍 언어를 처음 대하면 대입(assignment)을 무분별하게 사용하게 되는데, 되도록 함수 위주의 프로그래밍을 연습하여 익숙해지는 것이 좋다. Lisp에서도 대입이 가능하지만 꼭 필요할 때만 사용하는 것이 바람직하다.
Lisp에서는 수식을 보통 폼(form)이라고 하는데, 폼의 첫번째로 오는 것은 연산자 역할을 하고 나머지는 인자(arguments)가 된다. 인자들은 그 자체가 폼의 형태가 될 수있는데, 최상위 폼(top-level form)이 평가(evaluate)되기 전에 모든 하위 폼들이 평가된다. 이것이 Lisp의 전형적인 폼이다. 그외에 스페셜 폼(special form)이 있는데, 이것은 앞에서 말한 평가 규칙을 따르지 않는 폼들이다. 대표적으로 if, cond, defun 등등이 있다. 모든 함수는 평범한 폼이다. 이것을 잘 기억하면, Lisp 문법은 반나절이면 다 이해하게 된다(C와 같은 프로그래밍 언어에서는 문법을 구성하는 문들이 모두 스페셜 문이라고 할수 있다!).
또 하나 함수 위주이면서 인터랙티브 환경을 갖고 있는 프로그래밍 언어를 처음 사용하는 사람이 겪게되는 어려움 중에는 출력에 대한 것이 있다. 예를 들면, Lisp 프로그래머에게 HelloWorld 프로그램을 Lisp에서 어떻게 작성하느냐 물으면 함수 하나를 달랑 던져주고 끝내기 일쑤이다.
(defun hello-world () "Hello World!")즉, 문자열을 리턴하는 함수를 작성해주고 끝낸다. 사이드 이펙트(side effect) - 한글로는 무엇이죠? DeleteMe 부작용입니다. - 에 너무 많은 관심을 두지 않는 것이 좋다. 만일 처음부터 출력에만 관심이 있는 사람이라면 CLHS에서 format 함수를 참조하라. CommonLisp에서 두가지 자체 언어를 갖고 있다고 불리는 폼들이 있는데, format과 loop가 그것이다. 이 두가지를 100% 이해하고 활용하는 사람을 찾기는 쉽지않다.
Lisp을 배워서 다른 프로그래밍 언어로 프로그래밍 하는 수준이 되기까지는 그다지 오랜 시간이 걸리지 않는다(한달 혹은 두달?). Lisp 답게 프로그래밍 하기까지가 시간이 걸릴 수 있는데, 이것은 생소함, 기존에 알고 있었던 프로그래밍 언어에서 배운 불필요한 잔재, 새로운 프로그래밍 개념에 대한 충격 등등이 원인이 아닐까 생각한다.
테스트와 관련해서는 특별한 테스트 유틸리티가 없다. 그 이유는 테스트용 언어나 확장을 그다지 어렵지 않게 만들 수 있기 때문이 아닐까 생각한다. 개인적으로 회사에서는 실제로 그렇게 확장된 언어로 테스트를 작성한다. 예를들면,
(질문: 어떤 프로그래밍 언어에서 어떤 테스트 패키지가 가장 좋다고 알려졌나요? 한번 그 스펙을 보고 타당하다면, SourceForge 같은 곳에서 FreeSoftware 테스트 패키지를 개발해 보는 것도 괜찮을 것 같은데...)
(deftest "Basic Database test"
...
(test-assert (string= (name obj1) (name obj2))) ;; 이름이 같은가 체크
(ensure-exception-raised
:form (save-object obj2)) ;; 같은 이름의 객체를 저장할 때 예외가 일어나나 체크
:expected-condition duplicated-name
:assertion t
:addendum "Cannot save - duplicated name")
(test-passes))
와 같이 한다. 위의 테스트를 실행하기 위해서는 (run-all-tests), (run-test "Basic Database test"), (run-test 1) 등과 같은 인터페이스를 사용합니다(마지막 것은 테스트를 일단 수행한 후 보이는 테스트 번호를 이용한 실행으로, 테스트가 문제를 발견했을 때 프로그램을 수정하고 해당 테스트만 실행할 때 주로 씁니다).(질문: 어떤 프로그래밍 언어에서 어떤 테스트 패키지가 가장 좋다고 알려졌나요? 한번 그 스펙을 보고 타당하다면, SourceForge 같은 곳에서 FreeSoftware 테스트 패키지를 개발해 보는 것도 괜찮을 것 같은데...)
Dear LispM ¶
초등학교때 수업을 빠지고-_- 호주와 뉴질랜드에 꽤 오랫동안 놀러다녔던 기억이 있는데.. .png ":)")
환영합니다.
프로그래밍언어 Lisp를 뜻하나요? --영후
안녕하세요 HaskellLanguage 쓰레드에서 왔습니다. Lisp에 흥미를 느껴서 여기서는 구하기 힘들었던 책들을 도서관에서 몇권 대여해서 복사했던 기억이 납니다..png ":-)")
Lisp-Machine은 이제까지 경험해본적이 없습니다. CLisp(?)만을 이용했던 적이 있었는데 예전에 어떤 글을 보니 Lisp-Machine이 이상적인 개발환경이라고 들었었습니다. 어떻게 구성되어 있는지 설명을 부탁드려도 될까요? --씨엔
최초의 Lisp Machine이 나온 것이 1976년이니까 OO UI, Hypertext가 대중화되기 10년 전이었군요. Smalltalk나 DougEngelbart의 NLS 등이 그 선조가 되겠네요. --김창준
환영합니다.프로그래밍언어 Lisp를 뜻하나요? --영후
안녕하세요 HaskellLanguage 쓰레드에서 왔습니다. Lisp에 흥미를 느껴서 여기서는 구하기 힘들었던 책들을 도서관에서 몇권 대여해서 복사했던 기억이 납니다.
Lisp-Machine은 이제까지 경험해본적이 없습니다. CLisp(?)만을 이용했던 적이 있었는데 예전에 어떤 글을 보니 Lisp-Machine이 이상적인 개발환경이라고 들었었습니다. 어떻게 구성되어 있는지 설명을 부탁드려도 될까요? --씨엔Lisp-Machine은 Lisp 혹은 비 폰노이만식 프로그래밍 언어에 적합하도록 만든 하드웨어로 AI winter와 함께 사라졌습니다. 한때 Xerox, TI, Symbolics, LMI 등에서 제작했었죠. 제가 아는 것은 Symbolics인데, Low level부터 모두 Lisp으로 작성된 Genera OS를 사용합니다. Lisp 프로그래밍 환경으로는 최고로 알려져 있지만, 지금의 컴퓨터에 비하면 사용못할 정도로 속도가 느립니다. 개발환경은 OS 버그도 런타임에 고칠 수 있을 정도로, OS 커맨드라인, 에디터, 디버거, 도큐먼드 시스템 등이 모두 연결되어 움직입니다. 아직까지도 많은 이들이 이보다 나은 개발환경은 없다고들 합니다. 특히, OO Windows User Interface, Hypertext document system은 당시 10년 이상을 앞섰다고들 했던 과거속에 사라진, 전설로만 남은 머신입니다. 개인적으로는 구할 수 있다면 동작하는 Symbolics MacIvory III는 한번쯤 탐내볼만 하다고 생각합니다. --LispM
| Symbolics Lisp Machine |
최초의 Lisp Machine이 나온 것이 1976년이니까 OO UI, Hypertext가 대중화되기 10년 전이었군요. Smalltalk나 DougEngelbart의 NLS 등이 그 선조가 되겠네요. --김창준
위에 나온 머신들은 Symbolics 3600 계열 같군요. 제게는 3640와 MacIvoryIII가 있는데. Symboilics에서 마지막으로 나온 모델들은 Ivory 칩을 사용하는 XL과 MacIvory가 있었습니다. MacIvory는 맥킨토시 Nu-bus에 daughter board로 끼우는 식으로 XL이나 다른 3600계열 머신들보다 간편하고 지금 쓰기도 상대적로 좋습니다(다른 머신들은 크기나 무게자체가 어마머마하고 팬돌아가는 소리도 크고 전용 콘솔이 필요하거나 구형 디스크를 구하기가 쉽지 않습니다) 시간나면 언제 그림을 첨부하도록 하죠. --LispM
CommonLisp 의 ANSI 표준 이후로 진행되고 있는 표준화 노력에 대해 궁금합니다. 시간이 꽤 지났거든요. --서상현이후 MOP에 대한 표준화는 스펙에는 없지만 실제 유저들의 요구로 사실상 표준화 된 것이나 거의 다름없습니다. 표준화된 FFI에 대한 요구가 유저들에게서 꾸준히 나오고 있습니다. CLIM에 대한 표준화는 끝내 마무리 되지 못하고 사라진듯 합니다. 애석하게도 CommonLisp 업계가 이전처럼 여러 벤더들이 협력할 만한 다양성이 점점 사라지고 있습니다. 거의 2-3개의 CommonLisp 벤더들이 시장을 나누어 갖고 있고 유저들 역시 한 제품에 익숙해지면 바꾸지 못하는 문제점 때문에 각 벤더들은 표준화 필요성을 느끼지 못하는 듯 합니다. 이미 각 벤더들은 자신들의 확장으로 실제 응용 프로그램 작성에는 큰 문제가 되지 않는 다고 생각하는 하며, 공식적인 표준화 움직임을 기대하기는 당분간 어려울 듯 합니다.
KLDP의 어떤 번역문에서 Lisp는 훌륭한데 CommonLisp는 나쁘다라는 글을 읽었던 적이 있습니다. LispM님은 CommonLisp와 그외의 Lisp에 대해서 어떻게 생각하시나요? --씨엔음. CLIM(Common Lisp Interface Manager)이 죽었나요... FFI는 UFFI 이야기가 주로 나오더군요. 아직 CLOS를 심각하게 시작하지 않아서 MOP는 모르니 패스. Makefile 이랄까 subsystem 를 load 하는 쪽은 이것 저것이 있는 것 같은데 어느 것이 널리 쓰이는지 모르겠어요. --서상현
UFFI 이야기가 주로 나오더군요. 아직 CLOS를 심각하게 시작하지 않아서 MOP는 모르니 패스. Makefile 이랄까 subsystem 를 load 하는 쪽은 이것 저것이 있는 것 같은데 어느 것이 널리 쓰이는지 모르겠어요. --서상현죽은것은 아니고 성장을 멈추었습니다. 벤더들은 CLIM을 제공하기는 하지만 버그 픽스이외의 더이상 발전은 없습니다. defsystem 은 표준화 안되었지만 벤더마다 서로 조금씩 다른 것을 지원합니다. MK defsystem인가가 개중에 많이 사용되었었는데, 지금은 잘 모르겠군요. 개인적으로는 벤더가 제공하는 defsystem을 사용합니다.
Lisp이 훌륭하면 CommonLisp도 훌륭합니다. 해당 문서가 폴 그래험의 글이라는 가정하에...
Lisp의 역사를 보면 처음에 하나의 Lisp이 있었고, 그 Lisp에 매료된 여러 사람들이 dialects를 만들어 내기 시작했습니다. 역사상 이렇게 많은 dialects를 갖고 있었거나 갖고 있는 프로그래밍 언어는 아마 이후에도 찾아보기 어려울 것입니다. CommonLisp으로 표준화 된 이후에도 적지 않은 확장이나 시도들이 있었습니다.
Lisp 이라고 할때는 두가지중 하나의 의미가 있습니다. 하나는 모든 Lisp dialects의 집합을, 또 다른 하나는 현대적인 Lisp 표준인 CommonLisp 입니다. CommonLisp은 표준화 이전 많은 dialects에서 common한 부분을 위주로 표준화 한 것입니다(즉, 모든 Lisp dialects의 평균 정도 되겠죠). 그래서 (한 집합으로써의) Lisp이 훌륭하면 CommonLisp도 훌륭하다고 생각합니다. 물론 CommonLisp의 과거의 짐을 벗지 못했을 수도 있습니다만, 필요한 때가 오면 가장 유리한 형태로 스스로 변화할 것을 확신합니다(이제껏 그랬습니다. CLOS가 한 예인데, CLOS는 다양한 Lisp OO dialects를 모두 지원할 것을 염두하면서 설계하였기 때문에 결국 MetaObject Protocol - MOP - 을 갖게 되었습니다).
폴 그래험과 같이 현 상태의 CommonLisp을 부정하고 새로운 Lisp dialect를 제작했던 시도는 이미 있었습니다. 한때 애플에서 주축이 되어 개발했던 Dylan 이라는 프로그래밍 언어가 한 예인데, 결국 상업적으로는 실패하고 말았습니다. 개인적으로 어떤 프로그래밍 언어의 일부가 마음에 안들면 그 일부를 바꿔야지, 새로 프로그래밍 언어를 만드는 것은 낭비이고 성공해도 대가가 보잘것 없는 모험이라고 생각합니다. (물론, 폴 그래험처럼 경제적으로 넘치게 되면 넘치는 돈갖고 한번쯤 대가가 보잘것 없는 모험도 할 수 있겠죠)
호응이 크지는 않네요. 그래도 CommonLisp의 위키는 만들어져야 한다고 봅니다. 공부를 하고 싶어서 Lisp를 검색하는데 오히려 AutoCad의 Lisp나 Emacs의 Lisp보다도 더 자료가 적더군요. 커뮤니티 사이트가 없는 것도 가장 큰 문제인 것 같은데요. --씨엔Lisp의 역사를 보면 처음에 하나의 Lisp이 있었고, 그 Lisp에 매료된 여러 사람들이 dialects를 만들어 내기 시작했습니다. 역사상 이렇게 많은 dialects를 갖고 있었거나 갖고 있는 프로그래밍 언어는 아마 이후에도 찾아보기 어려울 것입니다. CommonLisp으로 표준화 된 이후에도 적지 않은 확장이나 시도들이 있었습니다.
Lisp 이라고 할때는 두가지중 하나의 의미가 있습니다. 하나는 모든 Lisp dialects의 집합을, 또 다른 하나는 현대적인 Lisp 표준인 CommonLisp 입니다. CommonLisp은 표준화 이전 많은 dialects에서 common한 부분을 위주로 표준화 한 것입니다(즉, 모든 Lisp dialects의 평균 정도 되겠죠). 그래서 (한 집합으로써의) Lisp이 훌륭하면 CommonLisp도 훌륭하다고 생각합니다. 물론 CommonLisp의 과거의 짐을 벗지 못했을 수도 있습니다만, 필요한 때가 오면 가장 유리한 형태로 스스로 변화할 것을 확신합니다(이제껏 그랬습니다. CLOS가 한 예인데, CLOS는 다양한 Lisp OO dialects를 모두 지원할 것을 염두하면서 설계하였기 때문에 결국 MetaObject Protocol - MOP - 을 갖게 되었습니다).
폴 그래험과 같이 현 상태의 CommonLisp을 부정하고 새로운 Lisp dialect를 제작했던 시도는 이미 있었습니다. 한때 애플에서 주축이 되어 개발했던 Dylan 이라는 프로그래밍 언어가 한 예인데, 결국 상업적으로는 실패하고 말았습니다. 개인적으로 어떤 프로그래밍 언어의 일부가 마음에 안들면 그 일부를 바꿔야지, 새로 프로그래밍 언어를 만드는 것은 낭비이고 성공해도 대가가 보잘것 없는 모험이라고 생각합니다. (물론, 폴 그래험처럼 경제적으로 넘치게 되면 넘치는 돈갖고 한번쯤 대가가 보잘것 없는 모험도 할 수 있겠죠)
제 짐작이 맞다면, Paul Graham의 에세이 중에 하나를 번역한 것을 읽으신 것 같습니다. (아마 http://www.paulgraham.com/popular.html 요게 아닐까 하는...) Paul Graham씨가 Arc라는, Lisp family에 속하는 새 언어를 만들면서 쓴 글이라 Common Lisp에 대한 단점-unpopular하게 된 이유들-을 들면서, Arc를 개발하는 정당성을 주장한 것 같습니다. 개인적으로는 Common Lisp이 popular하지 않은 이유가 언어 자체에 있다기 보다는 가지고 놀만한 환경이 부족하기 때문이라고 봅니다. 지금의 interactive shell은 python의 shell에 비해서 너무 불친절/불편합니다. (그래도 전 lisp이 좋아요~)--지원
(그래도 전 lisp이 좋아요~)--지원어떤 환경을 갖고 있는지 자세히 말해보세요. Emacs+ILisp 혹은 Emacs+Slime과 같은 환경인가요? CommonLisp은 Listener(쉘)와 개발환경이 동일하지 않습니다. Lisp 프로그래밍시 개발환경의 유무에 의한 개발 편의성 차이는 천국과 지옥의 차이만큼이나 큽니다.
emacs를 쓰려고 몇번 시도해 보았지만, vim에 너무 익숙한지라, 잘 안되더군요. lisp을 배우면서, 이참에 다시 emacs에 익숙해 지려고 했지만 - ilisp도 한번 깔아보고, slime도 깔아보고... - 역시 설정 등을 잘 못하겠어서 포기. 그냥 cmucl의 interactive shell만 사용하고 있습니다. ^^; --지원
Lisp이 대중적이지 못한것은 대중을 위한 프로그래밍 언어가 아니라 해커를 위한 프로그래밍 언어이기 때문이라고 나름대로 생각합니다. 너무도 많은 자유를 제공하기 때문에 그것을 누리기 위해서는 적지않은 노력을 해야하는데 대중은 그렇지 못합니다. 기존의 것을 부정하고 자신의 것을 새로 지을수 있는 자유보다는 굴레와 틀에 얽매여서 프로그래밍 언어가 제공하는 것 이외에는 생각조차 할수없는 사람들, Lisp은 불행하게도 그런 사람들을 위한 프로그래밍 언어가 아니기 때문에 대중적이지 않습니다. 자바 프로그래머들에게 질문해 보세요. 웹프로그래밍 어떻게 해야 하나요? 한가지 답밖에 없죠? Servlet(+ Struts)써야죠! Lisp 프로그래머들에게 물어보세요. 대답이 모두 틀릴겁니다.CommonLisp의 Listener와 Python의 개발환경을 비교하는 것은 무의미 하겠죠? 개발환경끼리 비교한다면 Python 개발환경이 CommonLisp 개발환경에 비해 아직 갈길이 먼 것 같군요. 대부분의 Lisp 프로그래머들은 이상적인 개발환경이 어떤 것인지 이미 알고 있고 한때 실제로 존재했었기 때문에 어떤 길로 가야할지 역시 명확한데, Python은 그것부터 부족한 듯 합니다. Slime이 큰 버그없이 CMU CL/SBCL이외의 CL 지원만 잘 한다면, ILisp을 대신할 듯 합니다.
마음은 그렇지만 현실은 그렇게 호락호락 하지 않습니다. 노스모크를 보면 잘 알 수 있지 않습니까? 당장 운영비와 관리 문제가 있습니다. 초기에 운영비에 대한 문제는 개인적으로 부담할 수도 있겠지만, 영구히 그렇게 하기는 어렵습니다. 관리는 특정인 혼자 하기는 더더욱 어렵습니다. 결국 최소한 10명 정도가 최초 관리에 대한 모든 책임을 나누어야 한다고 생각합니다. 후에는 공동체를 위한 사업이랄까 - 예를들면, 그 공동체의 내용을 상업적 목적으로 사용할 수 있게 한후 이익금의 10% 정도를 기금으로 받아 운영비로 충당한다 - 이런것도 가능하겠죠. 그외 기부금을 받는다든지 하는 것도 가능하겠죠(노스모크와는 달리 프로그래밍 공동체의 구성원들은 공동체를 통한 학습으로 부터 상대적으로 경제적 이익을 얻을 수 있는 가능성이 크기 때문에 기부금도 어느 정도 있으리라 예상합니다) 이런 것들이 잘 되기 위해서는 최초 발기인들이 '한국 리습 사용자 그룹'과 같은 것을 만들어 최소한의 인원이 하나가 되어 위키를 운영하는 것이 어떨까 합니다. 비상업적인 공동체는 단지 한두사람에게 의지하지 않고 대다수에 의해 발전해야 한다고 생각하기 때문에 더더욱 최소한의 인원으로 부터 동참의 의사가 있어야 한다고 믿습니다. 내부사정을 자세히는 모르지만 한국브라이트넷 역시 이런식으로 진행 하고 있지 않나요?
KLDP.org로 입주를 건의해보세요 --고무신
찬/반(?) 을 물어보시는 이유를 잘 몰라서 가만히 있었는데, 위 말씀을 들어보고나서는 저도 찬성에 이름을 올렸습니다. KLDP.org로 입주를 건의해보세요
--고무신감사합니다. 알아보고 있습니다.
--지원KLDP의 반응은 어떤가요? 처음 CommonLisp 공동체가 만들어 질때 트래픽과 같은 문제는 크지 않으리라 생각합니다. cafe24등에 phpbb나 moniwiki로 입주를 하고 시작하는 것은 어떨까요? 저도 프로그래밍 언어 공동체에 관심이 있기때문에 적은 비용은 지불할 수 있습니다. 물론 KLDP측이 긍정적이라면 그 곳에서 시작하는 것이 가장 낫겠지만요. --씨엔
I got a reply this morning. They are very positive. Now, it's time to start Lisp community!
--