왜 리습(Lisp)인가?

chanwooyoo의 이미지

블로그에 올리려고 쓴 글인데.. 리습에 관심있는 분들이 많이 생기셨으면 해서.. 여기에도 한 번 옮겨 봅니다. KLDP에 사실 별로 와 본 적이 없고 처음 써 보는 글이라 좀 긴장되네요. 분류도 여기가 맞는지도 잘 모르겠구요. ㅠㅠ 썼던 걸 그대로 옮겨서 말투가 반말투이니 이해해주세요;

-------------------------

리습은 특별하다. 여러 가지 언어들이 자신은 특별하다고 주장하지만, 리습은 그런 모든 언어들이 가질 수 없는 점을 가졌다는 점에서 특별하다. 아마 프로그래밍 언어를 크게 가른다면, '리습 / 그 외의 언어들'로 가를 수 있을 것이다. 허무맹랑한 주장이라고 생각하는가? 한 번 그 이유를 들어보기 바란다.



몇 가지 비유를 들어보겠다.



만일 요술램프의 지니가 당신에게 한 가지 소원만 들어준다고 했다고 하자. 당신은 어떤 소원을 빌겠는가? 예쁜 여자친구? 어마어마한 돈? 영원한 생명? 글쎄. 나 같으면 어떤 소원이든 들어주는 반지를 달라고 하겠다.



무협지에서 어떤 사람의 내공이 가장 강한가? 오랫동안 수련한 사람? 글쎄. 북명신공을 지녀서 다른 사람의 내공을 흡수하는(악랄할 수도 있지만) 능력을 가진 녀석의 내공이 시간이 지남에 따라 가장 강해지지 않을까?



드래곤볼에서 어떤 종족의 특성이 가장 좋다고 생각하는가? 재생이 되는 나메크인? 변신이 되는 프리더의 종족? 단연 샤이어인이다. 전투를 거듭할 때마다 상대만큼 강해지는 녀석들이기 때문이다.



마찬가지다.



어떤 언어가 한 가지 특성을 마음대로 가질 수 있다면 어떤 특성을 가지는 게 좋을까? 다른 언어의 어떤 장점이든 가져올 수 있는 특성이 제일 좋지 않겠는가? 그리고 이게 바로 리습이 가진 능력이다.



C를 보라. 객체 지향 프로그래밍을 하기 위해서는 구조체와 함수포인터를 사용해서 흉내내는 수 밖에 없다. define_class 라는 추상화를 만들어낼 능력이 없기 때문이다.



자바를 보라. foreach 라는 추상화를 사용하기 위해 자바 프로그래머들은 1.5 버전까지 기다려야만 했다. 언어에서 foreach 라는 추상화를 만들어 낼 능력을 가지고 있지 못하기 때문이다.



리습은 '매크로'라는, C의 매크로와는 매우 다른, 추상화 능력을 가지고 있다. 그리고 이 매크로를 통해 객체 지향 프로그래밍, lazy evaluation, continuation, 하스켈에서 자랑으로 여기는 monad 등등의 개념들을 라이브러리로 흡수해 왔다. 언어 자체는 전혀 변경하지 않고서! 이것은 이렇게 할 수 있다는 주장이 아니라, 역사적인 사실을 말하는 것 뿐이다. 1980년대 후반, 객체 지향 개념이 유행하자 리습에서는 OOP를 라이브러리로 추가했다. OOP를 라이브러리로 추가한다는 게 무슨 말인지 이해가 안 간다면, 다음과 같은 예가 도움이 될 것이다. 당신이 수학에 관한 라이브러리를 사용한다면 sin, cos 같은 추상화를 사용할 수 있게 된다. 그렇지 않은가? 마찬가지로 OOP에 관한 라이브러리를 사용한다면 define_class 라는 추상화를 사용할 수 있게 되는 것이다.



다른 언어에서 어떤 매력적인 개념이 등장하든지 리습은 바로 그 개념을 흡수할 수 있다. 그 개념은 라이브러리 형태로 추가되기 때문에 언어의 코어는 전혀 커지지 않고, backward compatibility도 완벽하게 유지된다. 라이브러리가 추가되면 언어에 새로운 문법이 추가될 거라고 생각하는가? 어떤 사람들은 리습의 매크로가 새로운 문법을 추가하는 거라고 생각하는데 이는 착각이다. 리습에는 operator 뒤에 operand 들이 온다는 문법 - 예를 들면 (operator operand1 operand2 ...) - 외에 다른 문법이 없다. 방금 당신은 리습에 존재하는 모든 문법을 배운 것이다.



foreach와 같은 새로운 제어 구조를 만들어내는 것은 Smalltalk와 Haskell도 할 수 있다. 하지만, 어떤 개념/추상화든지 가져올 수 있는 능력을 가진 것은 리습 뿐이다. 리습, 스몰토크, 하스켈이 신의 언어라고 불리는 세 가지 언어지만, 리습은 언어 자체를 변경시키지 않고도 어떤 개념이든 흡수할 수 있다는 점에서 다른 모든 언어들과 근본적으로 다르다. 그리고 이런 차이를 만들어내는 것은 다음 세 가지이다. 어떤 언어가 리습인지를 판단할 때 다음과 같은 세 가지를 만족한다면 리습이라고 할 수 있을 것이다.



1. 데이터와 코드의 형태가 같다(homoiconicity). 리습이 어떤 개념이든 쉽게 흡수할 수 있는 것은 단지 매크로 때문만은 아니다. 여기서 나열하는 1번과 2번 특성이 매크로의 작성을 극도로 쉽게 만들어 준다.



2. 문법이 (하나밖에) 없다. Paul Graham 같은 사람들은 ‘리습에는 문법이 없다.’라고 말하기도 한다. (operator operand1 operand2 ...) 이게 리습 문법의 전부다.(이것이 다른 메타 프로그래밍이 가능한 언어들과 리습을 차별화하는 요소이다. 리습에는 파서가 없다. 리습의 코드 자체가 트리 형태로 되어 있기 때문에 메타 프로그래밍을 통해 조작해야 하는 abstract syntax tree가 어떤 형태일지 고민할 필요가 없다. 코드 그대로가 곧 그것이기 때문이다. 프로그래머는 늘 보던 코드 형태 그 자체를 조작하면 되기 때문에 메타 프로그래밍을 통해 어떤 결과가 나올지를 예상하는 것이 아주 쉽다. 반면에 '파서가 있는' 다른 언어들의 경우에는 코드가 파싱된 결과물인 트리를 조작한 후 그 트리가 unparse된 결과가 자신이 의도한 코드가 되도록 메타 프로그래밍을 해야 한다. 평소에 익숙히 봐오던 프로그램 코드이지만 파싱된 결과물이 어떤 구조의 트리로 바뀌는지 알게 뭐란 말인가? 이 같은 작업은 매우 '비직관적이고', '어려운' 일이다. 프로그래머가 평소에 봐오던 코드와 최대한 비슷한 형태로 코드를 데이터처럼 다루기 위해서 스트링을 사용할 수도 있지만, 이 같은 방법을 사용할 경우 inadvertent variable capture를 피할 수 있는 방법을 보통 제공하지 않기 때문에 구멍난 추상이 되기도 쉽고, 결정적으로 스트링은 트리처럼 구조적으로 다루기가 용이하지 않기 때문에 조금이라도 복잡한 메타 프로그래밍을 제대로 하기란 쉽지 않다.)



3. 매크로를 가지고 있다.



if 문, 가비지 콜렉션, REPL(대화형 셀)을 이용한 interactive programming, functional programming 등등은 모두 리습에서 처음 등장한 개념들이다. 다른 언어들이 이 같은 개념을 흡수하며 자신을 acceptable Lisp, 또는 alternative of Lisp이라고 광고한다. 파이썬이나 루비 같은 언어들이다. 하지만 위에서 나열한 리습의 가장 핵심적인 특성 세 가지는 이상하게도 어떤 언어도 흡수하지 못하고 있다. 왜라고 생각하는가? 저 특성들을 흡수하고 나면 그 언어는 리습이 되어버리기 때문이다.



예전에 다른 포스트에서 리습을 배우면 여러 가지 언어에 존재하는 개념들을 한 번에 배울 수 있다고 말한 적이 있다. 이제 그 이유가 왜인지 알았으리라 생각한다. 리습은 다른 언어가 장점으로 내세우는 개념을 손쉽게 흡수해버리기 때문에 멀티 패러다임 언어가 되기 쉽다. ‘리습으로는 함수형 프로그래밍을 해야 하고 객체 지향 프로그래밍은 못할 거야’라던가, ‘리습에서는 반복을 위해 재귀를 사용해야만 하고 루프문 같은 건 사용하지 못하겠지’와 같은 생각들은 모두 착각이다. 당신이 어떤 라이브러리를 사용하는지에 따라 리습은 어떤 모습의 언어도 될 수 있다. OOP 라이브러리를 사용한다면 객체 지향 방식으로 프로그래밍 할 수 있는 것이다.



하스켈에서 내세우는 monad 라는 개념을 배우고 싶은가? 루비나 파이썬, 스몰토크를 살펴봐서는 알 수 없을 것이다. 그렇다고 모나드가 무엇인지 배우기 위해 하스켈을 익힐 필요는 없다. 리습을 아는 사람이라면 리습을 통해 http://onclojure.com/2009/03/05/a-monad-tutorial-for-clojure-programmers-part-1/]로 이동합니다." target="_blank" href="http://onclojure.com/2009/03/05/a-monad-tutorial-for-clojure-programmers-part-1/">모나드의 개념을 익힐 수도 있고, 실제로 모나드 라이브러리를 사용할 수도 있다.



라이브러리의 수? 좋은 IDE? 약간 더 좋은 표현력? 이런 것들은 다 피상적인 것으로 금방 따라잡힐 수 있는 것들이다. 실제로 모든 C/C++ 라이브러리는 Common Lisp에서 호출 가능하고, 모든 자바 클래스는 Clojure라는 리습에서 사용 가능하다.(Clojure는 JVM 위에서 돌아가는 리습으로, 자바 코어나 자바 라이브러리들을 번거로운 절차 없이 바로 호출 가능하다. 속도도 파이썬이나 루비와는 비교할 수 없을 정도로 빠르다.)



요약하면, 리습의 무서움은 그 잠재력에 있다. 이 글을 읽고 리습에 관심이 생겼다면 http://clojure.org/]로 이동합니다." target="_blank" href="http://clojure.org/">Clojure라는 리습을 한 번 살펴보기 바란다. 내가 아는 한 가장 아름답고, 강력한 언어다. Erlang의 강점인 concurrent programming을 위한 특성까지도 가지고 있다. http://pragprog.com]로 이동합니다." target="_blank" href="http://pragprog.com">pragprog.com에서 http://pragprog.com/titles/shcloj/programming-clojure]로 이동합니다." target="_blank" href="http://pragprog.com/titles/shcloj/programming-clojure">책도 나와 있으니 공부하기도 어렵지 않다. 가장 최근에 나온 리습 dialect이기 때문에 기존의 Common Lisp이나 Scheme이 가지고 있는 단점들이 없고 정말 말끔한 느낌을 주는 언어다.



마지막으로 리습에 관련된 일화를 간단히 소개하며 끝낼까 한다. ILC 2002(International Lisp Conference 2002)중에 있었던 일이라고 한다. 출처는 다음과 같다. http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html]로 이동합니다." target="_blank" href="http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html">http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html



http://norvig.com/]로 이동합니다." target="_blank" href="http://norvig.com/">Peter Norvig이 ILC 2002 키노트 스피치를 맡았을 때였다. 그는 스피치에서 '파이썬이 리습이다'라는 주장을 했다고 한다.(아마도 파이썬이 리습의 대용으로 충분하다 라는 주장이었을 것으로 생각된다.) ILC 에서 키노트 스피치를 맡아 '파이썬이 리습이다'라는 주장을 펼친 것은 마치 마틴 루터가 부활절 바티칸 미사를 맡아 진행하다가 개신교를 선언한 것 마냥 놀라운 행동이라고 할 수 있다. Peter가 스피치를 마치고 질문을 받았을 때, 그 자리에 있던 http://www-formal.stanford.edu/jmc/]로 이동합니다." target="_blank" href="http://www-formal.stanford.edu/jmc/">John McCathy(리습의 창시자)가 물었다고 한다. "파이썬은 코드를 데이터처럼 다룰 수 있습니까?" Peter의 대답은 "아니오"였고 Peter는 John이 계속해서 질문하기를 기다렸지만 John은 더 이상 아무 말도 하지 않았다.



John McCathy는 루비가 리습으로부터 많은 영향을 받았다는 얘기를 듣고 루비에 대해서도 같은 질문을 한 적이 있다. 대답은 역시나 "아니오"였고, 그는 "루비가 코드를 데이터로 다루지 못한다는 점에 있어서 루비는 리습이 이미 1960년에 도달했던 지점을 아직도 따라잡지 못하고 있다."라고 말했다.



리습을 제외한 모든 언어에 물어보라. "그 언어는 코드를 데이터로 다룰 수 있습니까?" 대답은 언제나 "아니오"일 것이다. 그리고 이것이 리습이 그토록 특별한 이유이다. 코드를 데이터로 다룰 수 있다면? 당신은 어떤 추상화(OOP, monad와 같이 아래로부터 위로 쌓아올려지는 개념을 말하는 것이다. 당신이 함수 하나를 짰다면, 일련의 프로시저를 하나의 함수로 추상화한 것이다.)도 할 수 있는 능력을 갖게 된다. 그게 뭐 그리 중요하냐고? 자바 프로그래머들에게 묻고 싶다. 당신은 자바 1.5 이전에 파이썬의 for와 같은 foreach문을 만들어서 직접 사용할 수 있었는가? 할 수 없었다. Sun이 foreach를 자바에 추가해줄 때까지 기다려야만 했다. 당신은 foreach문이 무엇인지 머릿속에서 알고 있었다. 알고 있는 개념을 왜 만들거나 사용할 수 없단 말인가? 언어의 한계 때문이다. 리습에는 그런 한계가 없다. 리습은 프로그래머가 생각하는 어떤 개념도 추상화할 수 있도록 무한한 자유를 부여하는 유일한 언어다.



정말 마지막으로 ^^; 한 가지만 더 얘기하면 리습을 공부하기 위해 '컴퓨터 프로그램의 구조와 이해 (Structure and Interpretation of Computer Programs)'를 보는 사람들이 있는데, 저 책을 읽으면 그냥 프로그래밍 공부는 되겠지만, 리습의 강점인 'homoiconicity(코드와 데이터의 형태가 같음)와 매크로'를 이해하는 데는 아무 도움도 되지 않는다. 책이 그런 내용을 전혀 담고 있지 않기 때문이다. 한 마디로 저 책은 프로그래밍 공부를 위한 책이지, 리습이 가지는 고유한 특성이나 개념을 알려주는 책은 아니라는 것이다.



혹시 이 주제와 관련하여 궁금한 것이나 다른 나누고 싶은 얘기가 있다면 chanwoo.yoo@gmail.com 으로 메일을 보내주기 바란다.

feanor의 이미지

Io도 homoiconicity와 code as data를 지원합니다. Lisp에서는 코드가 리스트로 표현되지만 Io에서는 메시지 객체로 표현됩니다.

http://www.iolanguage.com/

익명 사용자의 이미지

2011년 최근에 리습 LISP 으로 진행되고 있는 주목할만한 "프로젝트"는 무엇이 있을까요? (AutoLISP 같은 류의 '좀비 리습'은 제외하고...)

다즐링의 이미지

이런글은 토론보다는 블로그쪽 카테고리에 어울리는 것 같습니다. =)

좋은 내용이네요.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

익명 사용자의 이미지

리습 LISP, 사실상의 화석언어.

imyejin의 이미지

정적 타입(static type)

@ 근데 파이썬이 리습이라 주장한 건 정말 안습이군요 ㅋㅋㅋ

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

gurugio의 이미지


LISP를 배우려면 어떻게 해야하는지를 소개해주시면 좋겠습니다.

SICP 책을 보다가 LISP과는 별로 상관이 없는것 같아서 미뤄두었는데
글의 마지막 부분을 보니 LISP 공부에 대해서 다시 시도해보고 싶네요.

코드를 데이터로 다룬다는 것이 C에서 코드 섹션을 데이터처럼 복사하거나
수정하는 것과는 다른 것이겠지요?

----
섬기며 사랑하면 더 행복해집니다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr

imyejin의 이미지

리습에선 primitive(심볼, 수, 배열 등)빼고 거의 모든 게 다 리스트입니다.

그런데 프로그램이 바로 리스트랑 문법이 똑같고 실제로 리스트로 처리를 한단 말씀입니다.

예를 들면 1,2,3,4의 합을 구하는 프로그램이 (+ 1 2 3 4) 인데 거기 앞에다 따옴표 하나만 박아넣으면 '(+ 1 2 3 4) 원소가 다섯개인 리스트 데이타가 됩니다. 원한다면 이렇게 데이타화된 코드를 예를 들면 eval 같은 함수(이름이 정확히 기억이 안납니다)로 실행해 버릴 수가 있습니다. (eval '(+ 1 2 3 4)) 의 결과는 (+ 1 2 3 4)를 한 것과 같습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

magingax의 이미지

폴그라함의 Ansi Common Lisp 을 보시면 됩니다. 명저입니다.
리습의 고수가 되시려면 Peter Norvig 님의 PAIP (Pradigm of Artificial Intelligence Programming)
을 보시면 되고요..
더 많은 자료를 원하시면

http://cafe.naver.com/lisper

에 놀러 오십시요.

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

chanwooyoo의 이미지

/feanor
코드를 데이터로 다룰 수 있는 다른 언어가 있었다니, 새로운 걸 알았네요. ^^ 한 번 살펴봐야겠습니다. 알려주셔서 감사합니다.

/다즐링
분류를 블로그로 어떻게 바꾸는지를 모르겠더라구요. ㅠㅠ

/imyejin
리습에 static typing은 있답니다. ^^ 커먼 리습과 Clojure 모두 타입을 선택적으로 명시할 수 있죠. 속도 최적화를 위해 많이들 사용하구요.

/gurugio
글에 적어놓은 Clojure 라는 리습에 대한 책이 저는 제일 좋다고 생각해요. 링크는 http://pragprog.com/titles/shcloj/programming-clojure 이구요, 리습을 배우면서 functional programming, concurrent programming 등에 대한 개념들도 모두 배울 수 있게.. 책이 괜찮게 쓰여진 것 같아요. 저 책은 온라인으로 사면 pdf로 책을 볼 수 있답니다. 돈 주고 사는 게 싫으시면, practical common lisp이라는 책은 온라인에 무료로 공개되어 있는데, 그 책을 보시는 것도 괜찮지만, 책이 양이 좀 많아요; 자세한 건 아래 주소의 제 블로그에 '커먼 리습 가이드'라고 적어 놓은 글을 참고하시면 좋을 것 같아요. ^^;

아 그리고 코드를 데이터로 다룬다는 건, 달리 말해 코드와 데이터의 형태가 같다는 건, 예를 들면 이런 거예요. 루비에서 배열을 나타내기 위해 [1, 2, 3]과 같이 표현하죠? 그렇다면 루비에서 코드와 데이터의 형태가 같다는 건 루비 코드가 [def, hello, "hello", end]와 같이 표현된다는 거겠죠. 저런 게 코드와 데이터의 형태가 같은 건데, 그렇게 되면 무슨 장점이 있냐면, 우리가 배열을 여러가지 오퍼레이터를 써서 손쉽게 조작하듯이, 코드를 배열 다루듯 손쉽게 조작할 수 있는거죠. 반면에 eval을 가진 다른 언어들은, 코드를 스트링으로 조작해야 하는데, 그게 굉장히 귀찮고, 추상화에 구멍도 많이 뚫리는 방식이랍니다. eval을 사용하는 건, 매크로를 사용하는 것에 비해 여러가지 단점도 많구요. 간단히 설명드리지 못해서 죄송하지만, 리습을 공부하시면 확실히 알게 되실 거예요. ^^;

lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

그건 static type 이 아닙니다. 걍 컴파일러에 추가로 힌트를 주는 것에 불과합니다. 아무도 리습이나 Clojure가 static type을 갖고 있다고 주장하지는 않아요. dynamic language를 오히려 장점이라고 내세우죠. 그리고 Clojure 홈페이지에 대문에서 dynamically programming language 라고 소개하고 있어요. 커먼 리습도 마찬가지고요. static type이 필요하면 리습은 선택사항에서 제외됩니다.

참고로, 요즘 자바스크립트 컴파일러도 기술이 좋아져서 항상 정수로만 쓰이는 변수 (예를 들면 루프 인덱스) 같은 걸 어느 정도 유추할 수는 있거든요. 하지만 그걸 갖고 자바스크립트가 정적 타입을 지원한다고 할 수는 없습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

chanwooyoo의 이미지

예 물론 기본적으로는 dynamic typing이 맞구요, 그래서 '선택적으로'라고 쓴 건데.. ^^; 타입을 정적으로 명시하는 목적이, 타입 에러를 컴파일러가 잡게하고, 필요없는 공간 및 속도 낭비를 막고자하는 거라고 생각해요. 커먼 리습과 Clojure 모두에서 예진님께서 말씀하신대로 타입 힌트를 명시할 수 있고, 그 결과로 저 두 가지 목표를 달성하게 되죠. 제가 static typing의 개념을 정확히 모르는 것 같기도 하지만, Haskell에서도 형을 기본적으로 명시하지 않으면 컴파일러가 형을 유추해서 끼워맞추지만, 형을 명시할 수도 있죠. 리습에서도 기본적으로 형을 선언하지 않지만, 형을 선언할 수도 있답니다. 코드 도중에 힌트를 주는 게 아니라 독립적인 expression 으로 선언할 수 있구요. 하스켈이 static typing language이면서, 형을 선택적으로 선언하는 것과, 리습이 dynamic typing language이면서 형을 선택적으로 선언하는 것이 예진님 말대로 어떤 근본적인 차이가 있는 것인데 제가 모르는 건지도 모르겠네요.

lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

근본적이라고 표현할 정도로 거창한 개념이 아니고요, 컴파일을 위해 모든 타입을 정확히 알아야 하면 정적 타입 언어이고 컴파일하는데 모든 타입을 다 알 필요가 없으면 동적 타입 언어입니다. 말씀하셨듯이 "알면 좀더 효율적으로 컴파일할 수 있는 것" 즉 "선택적"인 거죠.

하스켈이나 ML은 "모든" 타입을 정확히 알아야 컴파일이 됩니다. 컴파일러가 똑똑해서 사람이 일일이 안 써줘도 대부분의 타입을 스스로 알아낼 수 있을 뿐입니다. 하지만 타입을 정확히 알아낼 수 없는 프로그램이 들어오면 컴파일을 거부하고 컴파일 에러를 냅니다.

정적 타입 언어에서 사람이 "일일이 다 써 주지 않아도 된다"는 거(타입 유추)하고, 동적 타입 언어에서 컴파일러가 "타입을 일일이 다 알 필요 없다"는 거하고는 완전히 다른 이야기입니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

chanwooyoo의 이미지

다만, 정적 타입 선언에서 얻을 수 있는 유익(타입 에러 체킹이라던가 퍼포먼스와 같은)을 리습에서 얻을 수 없는 건 아니고, 리습에서도 형을 명시적으로 선언함으로써 저런 유익을 얻는 것이 가능하다는 얘기를 하고 싶었던 것 같아요. ^^

lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

리습이나 scheme에도 eval 이라는 함수가 있죠. 보통 많이 쓰는 스크립트 언어와 리습이 다른 점은 문자열이 아니라 프로그램에서 기본 데이타 구조로 사용하는 리스트를 처리한다는 게 다른 점입니다.

코드를 데이타화시켜서 코드 자체를 프로그램으로 자연스럽게 생성해 내는 기법을 meta-programming 이라고도 부르는데요, 말하자면 리습의 매크로가 하는 일을 말합니다. 정적 타입이 있는 언어에서도 정적 타입이 주는 안전성의 장점을 유지하면서도 메타프로그래밍을 편리하게 하기 위한 시도가 계속되고 있고 그 중에서 실제로 개발에 쓰일 정도로 구현이 안정되어 가는 것도 있습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

chanwooyoo의 이미지

좀 대강 말한 것 같기도 하지만.. 리습의 매크로와 비슷한 일을 하기 위해 다른 스크립트 언어에서 eval과 스트링을 대용품으로 사용하는데 그게 좀 안좋다.. 는 얘기를 하려다보니 저렇게 쓴 것 같네요. ^^;

lisp.tistory.com


--------------
lisp.tistory.com

chanwooyoo의 이미지

메타 프로그래밍이 가능한 여러 가지 방법과, 언어들이 있지만, 리습은 글에서 말씀드린 특성들 때문에, 메타 프로그래밍이 다른 것들에 비해 굉장히 '쉽고', '안정적인 추상을 만들 수 있다'는 점에서 차별성을 가지는 것 같아요. 소위 '파싱'이 필요한 언어는 뭐든지 언어의 형태와 파싱되어 다뤄야 하는 트리의 형태가 다르기 때문에, 개발자가 메타 프로그래밍을 통해 만들어내야 하는 트리의 형태를 연상하기가 어렵죠.. 반면에 리습은 파서가 아예 없기 때문에 평소에 다루는 코드가 바로 조작해야 하는 트리라, 메타 프로그래밍이 참 쉬운 것 같아요. 그런 리습의 특성이 리습의 매크로를 다른 파싱이 필요한 언어의 메타 프로그래밍 수단들보다 강력하게 만드는 게 아닐까 싶어요.

lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

그건 맞습니다. 평소에는 괄호 때문에 보기 힘들어도 (익숙해지면 괜찮다고는 하지만 ...) 매크로로 코드 조작할 땐 오히려 편하죠. 다른 언어의 경우 메타프로그래밍을 할 때 기본적으로 문법을 분석한 나무 형태로 따로 다뤄야 하기 때문에 오는 불편함이 생깁니다. 하지만 간단한 활용예의 경우는 문법을 조금만 확장하면 코드 형태 거의 그대로를 보면서 직관적으로 사용할 수 있는데요 (물론 이것도 리습의 quote quasiquote 등에서 다 비롯된 아이디어들이죠), Meta ML이나 Template Haskell 예제들을 보시면 간단한 것의 경우엔 리습 매크로보다 오히려 보기 쉽습니다. 다만 복잡한 걸 하려면 결국 별도의 나무 형태로 된 식을 건드려야 한다는 게 문제죠.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

mykldp의 이미지

Pure programming language 와 비교해보시면 어떨까요?

http://code.google.com/p/pure-lang/

http://kldp.org/node/104884

"On the surface, Pure is quite similar to other modern functional languages like Haskell and ML. But under the hood it is a much more dynamic language, more akin to Lisp"

라고 합니다.

chanwooyoo의 이미지

글에 '유일한' 이라고 적어놓은 게 부끄러워지네요. 공부해볼게요~ ^^

lisp.tistory.com


--------------
lisp.tistory.com

magingax의 이미지

개인적으로 가장 충격과 공포(?)였던 MOP (Meta-Object Protocol) 소개가 없내요.
암튼 오랜만에 LISP관련 예기가 나와서 반갑기 그지 없습니다.

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

chanwooyoo의 이미지

MOP 얘기는 예전 포스트 쓸 때 쓴 것 같아요. 음.. 근데 사실 MOP는 CLOS(Common Lisp Object System)안에, 즉 OOP 개념 안에 이미 포함되어 있는 것 같아요. ^^;

lisp.tistory.com


--------------
lisp.tistory.com

neocoin의 이미지

웹프로그래밍이나, 게임 쪽에서는 어떻게 쓰이는지 못봤습니다.
Auto-CAD용이나 eLisp의 존재는 알고 있는데 제가 그외에 사용처를 모릅니다.

사용하는 여러 분야 중 시작할 만한 곳이 있는지 알고 싶습니다.
사용처를 잘 몰라서 수련이나 학습 용도 외에는 접근을 해보지 못했습니다.

Lisp은 사용 분야가 어떻게 되나요?

johan의 이미지

Live coding performance? http://www.vimeo.com/2502546

chanwooyoo의 이미지

Practical Common Lisp이라는 책의 내용을 그대로 붙여봅니다. ^^;

One of the most commonly repeated myths about Lisp is that it's "dead." While it's true that Common Lisp isn't as widely used as, say, Visual Basic or Java, it seems strange to describe a language that continues to be used for new development and that continues to attract new users as "dead." Some recent Lisp success stories include Paul Graham's Viaweb, which became Yahoo Store when Yahoo bought his company; ITA Software's airfare pricing and shopping system, QPX, used by the online ticket seller Orbitz and others; Naughty Dog's game for the PlayStation 2, Jak and Daxter, which is largely written in a domain-specific Lisp dialect Naughty Dog invented called GOAL, whose compiler is itself written in Common Lisp; and the Roomba, the autonomous robotic vacuum cleaner, whose software is written in L, a downwardly compatible subset of Common Lisp. Perhaps even more telling is the growth of the Common-Lisp.net Web site, which hosts open-source Common Lisp projects, and the number of local Lisp user groups that have sprung up in the past couple of years.

lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

Orbitz도 리습으로 개발한 줄은 몰랐네요. 참고로 Orbitz는 미국에서 거의 제일 많이 쓰는 온라인 비행기표 판매 사이트로 알고 있습니다. 구글에서 airline ticket으로 검색하면 두번째로 나옵니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

johan의 이미지

gracesky의 이미지

장점이라고 할 수만은 없지 않을까요?
Lisp으로 상용 프로그램을 작성한다고 했을 때 스타일이 서로 다른 서너명의 개발자가 각자 편한 스타일로 개발해놓고 퇴사하면 나중에 들어온 유지보수 프로그래머가 어려움을 겪을 가능성은 없는지요? 아니면 이런 경우를 방지할 수 있는 방법이 있는지 궁금하네요.

gracesky의 이미지

장점이라고 할 수만은 없지 않을까요?
Lisp으로 상용 프로그램을 작성한다고 했을 때 스타일이 서로 다른 서너명의 개발자가 각자 편한 스타일로 개발해놓고 퇴사하면 나중에 들어온 유지보수 프로그래머가 어려움을 겪을 가능성은 없는지요? 아니면 이런 경우를 방지할 수 있는 방법이 있는지 궁금하네요.

imyejin의 이미지

이건 어느 언어로 짜나 마찬가지 아닌가요?

어차피 핵심 라이브러리를 공유할 테고, 코딩 컨벤션이 있으면 다른 언어에 비해 문제가 될 건 아닙니다.

괄호가 너무 많은 건 제 취향은 아닙니다만, 리습이 다른 언어보다 더 많이 문제가 된다는 건 아닌 거 같습니다.

Perl로도 수많은 오픈소스 프로젝트가 진행되는 걸 보면 ... -_-;;

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

chanwooyoo의 이미지

글에서 말씀드린 것처럼 문법이 늘어나는 건 아니구요, 다른 언어로 비유해서 설명하면, 그냥 라이브러리 함수가 많이 추가된다고 생각하시면 되요.. ^^; 어떤 프로젝트에서 함수를 많이 사용했다고 나중에 들어오는 개발자들이 힘들어하지는(물론 어떤 함수인지 알아보려면 힘들 수도 있겠지만, 함수가 아니라 함수의 내용이 다 풀어헤쳐진 내용이 써 있다면 읽기가 더 힘들지 않을까요?) 않을 것 같아요. 다른 언어의 개념을 가져온다는 것이 리습에서는 문법의 변화를 가져오진 않는답니다. 다만 오퍼레이터가 추가되는 것 뿐이죠. 아마 잘 납득이 안 가실지도 모르지만.. 실제로 한 번 사용해보시면 아실 수 있답니다. ^^;; 음.. 조금 더 부연하면, foreach라는 걸 자바에서 만들었다면 새로운 문법이 생기는 거겠지만 리습의 매크로로 foreach를 만든다면, 그저 foreach라는 함수(엄밀하게는 operator지만 이해를 돕기 위해)를 하나 만든 것 뿐이지, 새로운 문법이 생기는 건 아니랍니다. 즉, 말씀하시는 것 같은 '새로운 각자의 스타일'같은 게 새로 생겨날 수가 없다는 거죠. ^^;

lisp.tistory.com


--------------
lisp.tistory.com

hongminhee의 이미지

얼마 전까지 한국 Io 사용자 모임을 운영하다가 똥망해서 포기해버린 사람입니다. 위에 Io 얘기가 나왔는데, 좀 더 자세히 적어보겠습니다.

Io> add := method(a, b, a + b)
==> method(a, b,
    a + b
)
Io> add(1, 2)
==> 3

위와 같이 메서드를 정의합니다만, method는 키워드가 아니라 일반적인 메서드입니다. 메서드를 만드는 메서드라고 할 수 있습니다. 그 사실을 알고 저 코드를 보면 유추 가능한 특성이 많습니다. 예를 들면, ab 같은 변수는 정의되지 않았는데 에러는 내지 않죠. 전달되기 전에 표현식이 평가되지 않기 때문입니다. 따라서 a + b도 계산되지 않습니다. Io의 메서드는 기본적으로 Lisp의 매크로와 동등합니다.

Io> takeMessage := method(call)
==> method(
    call
)
Io> takeMessage(a, b)
==>  Call_0x88aa360:
Io> takeMessage(a, b) message
==> takeMessage(a, b) message
Io> takeMessage(a, b) message arguments
==> list(a, b)

이런 식입니다.

Io> msg := takeMessage(a + b) message arguments at(0)
==> a +(b)
Io> msg type
==> Message

Lisp과 마찬가지로 연산자가 따로 없습니다. receiver method(arguments)가 Io의 유일한 형식(form)인데, a + ba +(b)와 같습니다. (다만 런타임에 정해진 메서드의 평가 우선순위를 조정하는 OperatorTable라는 것이 있습니다.) 그리고 위에서 서상현 님이 말씀하셨듯이, 코드는 Message라는 객체로 취급됩니다. Lisp의 primitive가 리스트라면, Io의 primitive는 객체입니다.

doMessage라는 메서드로 메세지(코드 데이터)를 평가할 수 있습니다.

Io> doMessage(msg)
 
  Exception: Object does not respond to 'a'
  ---------
  Object a                             Command Line 1

이렇게 하니 그제서야 a가 존재하지 않는다고 예외가 납니다. ab를 정의해주면 잘 작동하죠.

Io> a := 1; b := 2
==> 2
Io> doMessage(msg)
==> 3

Io나 Lisp이나 저도 정말 좋아합니다만, 만족하지 못하는 부분이 있어서 결국 혼자 삽질하며 언어를 만들고 있습니다; 이러시는 분들이 저 말고도 계실 것 같은데, 그런 분들은 LangDev에도 놀러와주시면…

kasworld의 이미지

농담입니다만..
리습을 공부하다
이건 튜링머신이나 기계어를 배우는거같아 ㅠㅠ
라고 좌절했습니다.

너무 비슷한 느낌을 주더라구요.
그리고 튜링머신/기계어 모두 코드/데이터의 구별이 없지요 ^^

bootmeta의 이미지

문법 개념이 약한 비 정형적인 특성으로 인해 발생되는 문제점

* 뭔가 하려면 기본 lisp만으로 부족
* DSL 형태로 사용되는 경향
* 밑바닥부터 구현하는 경향
* 구현 library(utility)나 DSL 폭주 및 그 품질이 천차 만별
* 다른 사람이 작업한 code를 이해하기 어려움
* 표준화의 어려움
* 표준화되더라도 하위 추상화 level에만 집중되는 경향으로 인해 하위 단계 기능들과 utility들만 비대(lisp 표준화가 그 예 --;)

ps)
모든 것이 가능하다는 것은 어찌보면 "가능하게 하려면 먼저 만들어라"가 선행되거나, 언어 자체가 지저분하거나 비대하다는 의미일 수도 있다는 생각이 듭니다.
개인적으로 lisp가 학계나 다른 언어를 위한 meta언어가 아닌, 실무적으로 적용되기 힘들다고 생각하는 결정적인 이유
1. 뭔가 써먹을만한 것을 만들어 내기까지 오랜 학습
2. emacs나 lisp전용 편집기가 아닌, 일반 text 편집기로 작업은 불가능에 가까움

imyejin의 이미지

Visual Studio 없이 규모가 큰 윈도우즈 애플리케이션 개발 프로젝트 가능한가요?
Java를 이클립스나 전용 에디터 없이 텍스트 날코딩 하는 사람 몇이나 있나요?

그리고 실무적으로 못쓴다니, 이미 쓰고 있는데 ... 실제로 쓰고 있는데도 안될 것 같다 하시면 ... 음 ...

이 글타래에서 Orbitz 같은 웹사이트 구축의 예도 이미 나왔고요, 리눅스의 여러 프로젝트에서 스크립팅 언어로 쓰고 있는 리습 사투리인 그럼 guile 은 뭔가요? 오토캐드 스크립팅은 뭘로 하게요?

그리고 DSL 형태로 사용되는 것은 장점이지 단점이 아니지 않나요? 결국 프로그래밍을 하는 이유는 궁극적으로 DSL을 만들어 쓰자는 거 아닙니까? 라이브러리가 예술의 경지에 이른 것이 DSL인데 그걸 만들기 쉽다는 건 엄청난 장점이면 장점이지 단점은 아닐텐데요.

그리고 파이썬 라이브러리들이나 펄 CPAN에 올라오는 라이브러리 패키지가 지나치게 많고 품질이 천차만별이라서 실무적으로 못쓰나요?

이유들이 잘 납득이 안갑니다 -.-;

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

bootmeta의 이미지

ide없이 vi로만 개발하는 사람들은 골 내실듯

100줄 짜리 c code는 vi나 메모장으로 편집이 가능한 반면, 100줄 짜리 lisp code를 emacs없이 편집할 생각하면 답이 안보입니다. --;
최소한 c, java syntax coloring은 웬만한 text 편집기에선 지원이 됩니다만, lisp code의 ()depth는 추가로 ()괄호 depth별 coloring이나 high-lighting이 필요합니다. lisp 전용 편집기 외에 대중적으로 사용되는 범용 편집기는 emacs가 유일하지 않을까요?

해당 개발자들이 lisp에 전부 익숙하거나, 실무 작업 역량이 될 정도로 학습이 보장이 된다는 가정만 충족된다면 실무적으로 가능하겠죠.
더우기 lisp 인력 pool이 작은 이유도 있으나, 다른 언어와 달리 표준화의 문제로 인해 lisp에 익숙하더라도 특정 library나 DSL에 익숙치 않으면 상호 소통에 문제가 있습니다.

솔직히 scheme 사촌 guile은 개인용이 아닌 team 단위로 작업에 사용한 경우를 못 들어봤습니다. (제가 잘몰라서 자신이 없군요. ^^;)

DSL이 궁극적인 목적이긴 합니다만, 잘만들어진 DSL 단계까지 가면 lisp은 meta언어로 봐야하지 않을까요?
macro와 극단적인(?) 추상성과 문법이 없다시피한 lisp의 강점으로 인해 DSL 개발과 사용에 유리한 반면, 바로 그 이유 때문에 lisp code와 DSL 간 간극도 크다는 생각이 듭니다.
상대적으로 ruby에서 만들어진 DSL은 DSL 자체로는 lisp에 비해 떨어질지 몰라도, DSL을 구성한 ruby code를 이해하기 쉽습니다.

방대한 파이썬, 펄 라이브러리들의 성능이 천차만별이어도 상대적으로 code 분석이 용이합니다.
그러나 솔직히 다른 사람이 개발한 lisp code를 분석하다 보면, 높은 자유도로 인해 기본 제어조차 재정의된 경우가 많아 새로운 언어를 배우는 기분이 드는 경우도 있습니다.

개인적으로 cad와 lisp이 궁합이 잘맞는다고 생각합니다만, autocad에선 autolisp외에 ms window 추세따라 vba가 가능한 것으로 압니다.
lisp 배우는 것에 대한 사용자들의 불만이 꽤(?)있어서 vba를 채택하게 됬다는 뜬소문도 있습니다.

ps) sicp로 유명한 MIT조차 프로그래밍 초급 과정을 scheme에서 python으로 바꾼다고 하는군요.
http://siabard.egloos.com/4136796

imyejin의 이미지

표준화 문제, 더 넓게는 구심점이 분명하고 역동적인 개발자 커뮤니티를 구성하지 못했다는 점에는 동의합니다. 저는 그 점이 bootmeta님께서 지적하신 다른 모든 문제보다 크다고 생각합니다. 역사적으로 리습의 탄생이 너무 일러서 사람들이 그동안 "새로움"으로 인한 흥미를 잃어버린 이유도 있는 것 같습니다.

Perl이야 꽤 오래 된 언어라 치더라도 Python이라던가 요즘 나온 스크립팅 언어들은 개발자 커뮤니티에서 라이브러리를 모아 놓은 저장소를 키워나가면서 자연스럽게 커뮤니티를 키워 나가는 데 성공한 모범적인 사례죠.

함수형 언어들 중에서는 OCaml이나 이나 Haskell이 OCaml Batteries ( http://batteries.forge.ocamlcore.org/ ) 라든가 Hackage ( http://hackage.haskell.org/ ) 같은 프로젝트 페이지를 한곳으로 집중해서 사용자들이 편하게 라이브러리를 검색하여 사용하고 또 공헌할 수 있도록 틀이 갖춰 나가고 있는 데 반해, 리습은 http://common-lisp.net/projects.shtmlhttp://www.cl-user.net/asp/$htU/sdataQ0rLQSxLnQgjDQjr-br28xqk8yBX8yBX8oQ5Ss9v-ujg$Np5/sdataQu3F$sSHnB== 등 여러 개가 공존하고 있고, 배포판 꾸러미 개수가 모든 것을 말하는 것은 아니지만 (glibc 는 일당백, 아니 일당 천의 공헌도일지도 -_-) 데비안 꾸러미만 봐도 유구한 역사를 자랑하는 Common Lisp이 젊은 꼬꼬마 함수형 언어인 OCaml이나 Haskell에 개수로 따져서 밀리는 상황입니다. OCaml과 Haskell은 Python, Ruby, PHP 등과 함께 현재 별도의 데비안 꾸러미 분류가 존재하는 데 반해, Common Lisp은 "인터프리터 언어" 분류에 같이 들어가 있는 등 섬세한 관리가 잘 되지 않고 있는 듯한 인상을 받습니다.

@ Off-topic 이지만 재밌는 건 http://common-lisp.net/projects.shtml 에서도 darcs를 사용하고 있더군요.

@ 하지만, 프로그래밍 교육용으로는 DrScheme 만한 환경을 찾기가 쉽지 않죠. 또 리습이나 스킴 언어 자체는 프로그래밍을 배우면서 꼭 배워볼만 합니다. 정적 타입 시스템을 제외하면 지금 존재하는 프로그래밍 언어의 여러 가지 아이디어들 중에 리습에 없었던 것이 과연 있을까 싶고, 또 그런 것을 minimal한 디자인으로 구현했다는 것 자체가 교육적 가치가 크죠.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

lifthrasiir의 이미지

사족입니다만, 글을 잘 읽어 보시면 6.001에서 스킴 대신 파이썬을 쓰는 근본적인 이유가 툴의 변화라고 쓰여 있습니다.

Quote:

It just so happens that the robotics substrate software that comes with the system they’re using is programmed in Python. Similarly, the mobile software environment is based on Python. (Or, at least, the original plan was to use such a substrate, although it may have changed for various business reasons.)

물론 시대가 바뀐 건 맞습니다 -- 하지만 그렇다고 스킴을 못 쓸 이유는 없습니다. 어쩌면 스킴으로 만들어진 저런 종류의 소프트웨어가 잘 알려져 있지 않다는 이유 때문일 수도 있죠.

bootmeta의 이미지

돌 날라와도 할말이 없습니다.

bacchusf의 이미지

MIT undergraduate course 6 커리큘럼의 변화로 인해서
CS intro 과목인 6.001은 없어졌습니다.
비슷한 수업으로 6.00가 생기고 python을 쓰지요..
그리고 새로 생긴 6.01, 6.02, 6.006(intro algorithm)도 다 python을 씁니다.
6.034도 scheme에서 python으로 넘어 왔구요..

스킴이 좋은 언어이고, 문법이라고 할게 별로 없으니 (let, car, cdr, etc?)
프로그래밍 경험이 없는 친구들에게도 좋은 시작이 되긴 합니다.
하지만 이후 과목에서 전혀 쓰지 않고 (6.001빼고는 전혀 쓰지 않습니다. 6.034에서 썼으나 2년 전부터는 파이선을 쓰지요)
현실적으로는 쓸일이 별로 없는 언어이죠..

파이선도 좋은 언어이고, 문법이라고 할게 별로 없으니 (물론 있습니다만.. 복잡하진 않죠)
프로그래밍 경험이 없는 친구들에게도 좋은 시작이 되겠죠.
반면에 매우 현실적인 언어지요.

커리큘럼이 이제 파이선을 처음부터 배워서 상위 과목(알고리즘, ai) 등에서 모두 사용하는 걸로 바뀌고 있네요.

bacchusf의 이미지

MIT undergraduate course 6 커리큘럼의 변화로 인해서
CS intro 과목인 6.001은 없어졌습니다.
비슷한 수업으로 6.00가 생기고 python을 쓰지요..
그리고 새로 생긴 6.01, 6.02, 6.006(intro algorithm)도 다 python을 씁니다.
6.034도 scheme에서 python으로 넘어 왔구요..

스킴이 좋은 언어이고, 문법이라고 할게 별로 없으니 (let, car, cdr, etc?)
프로그래밍 경험이 없는 친구들에게도 좋은 시작이 되긴 합니다.
하지만 이후 과목에서 전혀 쓰지 않고 (6.001빼고는 전혀 쓰지 않습니다. 6.034에서 썼으나 2년 전부터는 파이선을 쓰지요)
현실적으로는 쓸일이 별로 없는 언어이죠..

파이선도 좋은 언어이고, 문법이라고 할게 별로 없으니 (물론 있습니다만.. 복잡하진 않죠)
프로그래밍 경험이 없는 친구들에게도 좋은 시작이 되겠죠.
반면에 매우 현실적인 언어지요.

커리큘럼이 이제 파이선을 처음부터 배워서 상위 과목(알고리즘, ai) 등에서 모두 사용하는 걸로 바뀌고 있네요.

lifthrasiir의 이미지

제가 답글을 살짝 잘못 썼네요. 6.001이 바뀐 게 아니라 6.001이 6.01로 바뀌면서 파이썬을 쓰게 된 게 맞습니다.

magingax의 이미지

일반적은 LISP 에 대한 견해들을 정리해 주신것 같습니다.
저는 Franz 의 Allegro CL을 사용해서 실시간 시스템 프로그램을
LISP 으로 개발하고있습니다.
그에 대한 저의 극복 노력들을 정리해보면..

1. 뭔가 하려면 기본 lisp만으로 부족
--> 그건 C도 마찮가지지 않을까요. 결국 구현에따라 특화된 라이브러리들을 많이 사용하게 됩니다.
SQL, DCOM 등등도 이용하기위한 라이브러리가 충분히 있습니다.
또 FFI (Foregin Function Interface) 를 사용하면 웬만한 라이브러리는 붙여서 사용할수있습니다.
C용으로 배포된 라이브러리 같은것도 아주 잘붙습니다.

2. DSL 형태로 사용되는 경향
--> 응? 저는 다른사람 소스쓸일 있으면 그냥 붙여서 컴파일하거나, fasl 파일을 그냥 붙여씁니다만.

3. 밑바닥부터 구현하는 경향
--> C 보다는 훨씬 덜합니다.:) 기본제공되는 함수들만 봐도, sort, hash 등등..왠만한 자료구조들은 기본적으로 쓸수있고.
이부분은 동의하기가 어렵습니다.

4. 구현 library(utility)나 DSL 폭주 및 그 품질이 천차 만별
--> 동의합니다. 인터넷에 떠도는 고수분들의 코드를 보면..이해는 못하겠지만 굉장한 성능으로 작동하는것들도 많고..

5. 다른 사람이 작업한 code를 이해하기 어려움
--> 그렇지요. 처음에 프로토 타입을 만들땐 setf 남발로 거의 C 처럼 만들지만. 조금 최적화하고 , consing 없앤다고 변수들 없애기 시작하면.
주석없인 만든나도 읽기 어렵다능..

6. 표준화의 어려움
--> Common LISP 으로 정리 된거 아닐런지. 뭐 수많은 dialect 가 있지만 그래도 ansi 표준을 따르는게...

7. 표준화되더라도 하위 추상화 level에만 집중되는 경향으로 인해 하위 단계 기능들과 utility들만 비대(lisp 표준화가 그 예 --;)
--> 제가 이해를 못하겠다는 :)

8. 뭔가 써먹을만한 것을 만들어 내기까지 오랜 학습
--> 생각보다 오래걸리지않습니다. 요즘 사용제품들은 IDE 도 좋고, 사용법도 쉬워서.
ACL 같은경우 델파이 비슷한 개발환경을 제공해서. 시험용 프로그램 개발에 5분정도면 됩니다.

9. emacs나 lisp전용 편집기가 아닌, 일반 text 편집기로 작업은 불가능에 가까움
--> 그렇지요..:) 그런데 말을 바꾸면 좋은 편집기를 쓰면 괄호로 인한 불편은 전~혀 없습니다.

아무튼 리습 예기가 많이 나와서 기쁠뿐이고..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

neogeo의 이미지

제일 궁금한건 lisp 이 태생도 아주 오래된 언어이고, 배우기도 쉽고, 유지보수도 쉬우며 자연스럽고 장점도 많은데

아직까지 상용 appilcation 은 대부분 C/C++/JAVA 로 이루어지고 있으며

lisp 가지고 만든 OS나 컴파일러나 각종 core 에 해당하는 유명한 상용제품이 드문건지 이해가 가지 않습니다.

수많은 소프트웨어 책들은 프로그램을

'유지보수하기 쉽게 짜라'
'사람이 이해하기 쉽게 짜라'
'재활용 가능하게 짜라'

라고 줄기차게 주장해 왔는데 이런 사람들은 왜 lisp 으로 뭔가 구현해두질 않은걸까요?

마치 공산주의처럼 이론상으론 자본주의보다 매우 우월하다 라고 주장하지만 실질적으로 적용해보면 밥숟가락만 들고있고 전부 쟁기질은 안하게 되는 상황이 되어버리는 느낌이 드는건 왜 일까요?

제 생각이지만 lisp 이 널리 퍼지기 위해선 좋다 좋다 이래서 좋다를 설명하기 보단

'lisp 으로 만드는 os 가 이런 하드웨어에서 이런 성능을 보이면서 잘 돈다. 이 os를 오픈소스화 하겠다!' 라는게 훨씬 보급이 빨라질 것 같습니다.

뭐 어떤 분은 emacs 를 os 다! 라고 주장도 하시지만... 여하튼 emacs 하나 만으로는 언어의 임팩트가 상당히 떨어져 보입니다...

Neogeo - Future is Now.

Neogeo - Future is Now.

bootmeta의 이미지

emacs와 SBCL만으로 탄력받기엔 힘에 부치는 상황이라 안타깝습니다.

chanwooyoo의 이미지

어떤 것이 정말 좋다면 왜 그것보다 나쁜 것이 더 많이 사용되는 걸까? 라는 질문에 대한 답은 아마 다음과 같은 비유들을 생각해 보면 얻을 수도 있을 것 같습니다.

일단 여기가 KLDP이니 리눅스와 윈도우의 관계를 생각해보면 어떨까요? 리눅스가 더 좋은 운영체제라면 왜 더 윈도우에 비해 극도로 작은 점유율만을 가지는 걸까요? KLDP에 계신 분들은 리눅스에 친숙하시니 '리눅스 사용되는 데 꽤 많아!'라고 하시겠지만 ^^; 사실 리습에 익숙한 사람들도 '리습 의외로 사용되는 데 꽤 많아!'라고 말한답니다. 윈도우 사용자 수가 더 많은 건 플랫폼에 매이면 벗어나지 못하는 악순환이 반복되기 때문이죠. 프로그래밍 언어도 마찬가지입니다.

신자의 수가 제일 많은 종교가 가장 좋은 종교이고 참 진리일까요? 그건.. 아니겠죠. 어떤 종교는 매우 좋지만 사람들이 접해볼 기회 자체가 없었기 때문에 신자의 수가 적을 수도 있습니다. 신자의 수가 많은 종교는 포교하는 사람의 수도 많고, 그러면 빈익빈 부익부 현상이 가속되는 거죠. 프로그래밍 언어도 마찬가지입니다.

마지막으로 다수가 지지한 MB가 최고의 솔루션이었을까요?

위 세 가지를 가만히 살펴보면, 셋 모두에 정치적, 문화적, 그리고 운적 요소가 작용했다는 것을 알 수 있습니다. 어떤 것이 절대적으로 좋고 나쁨이 지지자의 수를 결정할 수는 없다는 것이죠. 제 개인적인 생각입니다. ^^;

--------------
lisp.tistory.com


--------------
lisp.tistory.com

neogeo의 이미지

제 생각은 지극히 다릅니다.

일반 유저가 보기엔 윈도우즈가 Linux 보다 월등한 OS 입니다. 애초부터 윈도우즈는 사용하기가 쉬웠지요. ( 지금은 많이 비슷해졌죠? )
일반 사용자들의 PC 플랫폼에서 그냥 설치가 잘 되었습니다. ( 지금은 리눅스도 드라이버 많이 따라온 수준이긴 합니다만, 여전히 ATI 가... 이것도 참 정치적 , 경제적 여러가지 문제가 꼬였습니다만 결과적으로 사용자들에게는 불편한 사항입니다. ) 사용자들은 분명히 반쯤은 타의에 의해서 Windows 를 사용해 오고 있지요. 그래도 Linux 보단 Windows 가 겪는 문제가 훨씬 적을겁니다. ( 보통의 컴퓨터 사용자에겐 말이죠.. )

그리고 windows 가 Linux 보다 나쁘다라는 의견도 그다지 현실성이 없다고 생각합니다. OS 의 저변은 돌아가는 application 의 품질로 결정됩니다. ( os 자체가 물론 뻗지 않고 하드웨어 성능을 잘 뽑아줘야 하는것도 중요합니다만 지금의 windows 에선 그런 점도 충분히 충족한다고 생각합니다. 그건 os 의 기초일뿐이지요... ) 그게 돈으로 밀었던 뭘로 해서 나쁜짓으로 독점을 했던간에 결과적으로 일반 사용자는 자신에게 좋은 물건을 고르는 거지요. 다만 그 독점적 지위를 남용하는걸 견제하는게 매우 중요하겠죠. ( 결과적으로 그게 일반사용자에게 피해가 되니까요. )

프로그래머라면 분명히 일로 언어를 다루는 일이 많습니다. 그럼 똑같은 일을 할때 더 효율적인 녀석을 선택하는게 당연하지 않겠습니까?

Linux , Windows 와는 다르게 Lisp 은 C++ / JAVA 보다 훨씬 먼저 태어났고 먼저 선택받을 확률도 높았습니다. 그럼에도 불구하고 대다수의 프로그래머들은 아직도 C++ / JAVA 를 선택해서 배웁니다.
결국 일하는데 있어서는 Lisp 보단 C++ / JAVA 가 더 효율적이라는 이야기입니다.( 사실이 아니어도 프로그래머들에겐 그렇게 보인다는거죠. )

좋고 나쁘고를 논한다기 보단, Lisp 이 퍼지려면 C++ / JAVA 보다 일하는데 더 효율적임을 확실히 보여야 할 것 같습니다. 지금같은 이론상의 장점을 늘어놓는것보다 open source 로 멋진 산출물을 보여주면 누구라도 자연스럽게 따를것 같습니다. 결국 더 효율적이 되기 위해선 그 이해하기 쉽다는 라이브러리와 확장이 쉽다는 언어로 진짜 필요한 app 를 이렇게 빠른 시간에 만들 수 있음을 보여야 겠지요. 그게 절대적으로 중요합니다. 몇몇의 상용 application 에서 쓰일정도로 안정적이다 수준으로는 그다지 메리트가 없습니다. 이미 JAVA / C++ 에 익숙해진 유저를 빼앗기 위해서는 혹은 신생 프로그래머들이 자연스럽게 lisp 을 첫번째 언어로 꼽게 하기 위해서는 JAVA / C++ 보다 훨씬 좋은 품질의 소프트웨어를 훨씬 빠르고 쉽게 제작하는 것이 가능하다는것을 실질적으로 보여야 하지 않는가 입니다. emacs 수준의 application 이 넘쳤다면 지금쯤 세상은 lisp 이 지배하고 있겠지요.

다수가 지지했다고 최고의 솔루션 이라고는 절대 생각하지 않습니다. 비디오 테이프 포맷이 그랬고, 파일시스템도 그러했으며, 여러가지 기술 표준도 항상 그래왔죠. ( 심지어 TCP / IP 를 보십시오. OSI layer 대로 구현한게 아닌데도 표준입니다. ) 그러나 일반적인 사람들이 볼때는 분명히 lisp 보다 C++ / JAVA 쪽이 훨씬 나은 솔루션으로 보인다는게 문제입니다. 이점을 뛰어넘으려면 단지 언어의 장점을 말로만 늘어놓는건 아무 필요가 없다고 생각합니다. Lisp 은 다른 신생 functional language 와는 다르게 분명히 역사와 전통이 매우 오래되고 그 장점이 여러 언어로 흡수된 상태입니다.따라서 실질적인 라이브러리묶음을 보여주던가 몇몇 중요한 시장에서 엄청난 개척을 이루어내야 그 지위가 바뀔 수 있을 것 같습니다. 장점을 알리는건 매우 좋지만, 마치 공산주의 처럼 결국 실질적으로는 쓸게 못 된다 라는 수준을 벗어나는게 중요할 것 같습니다.

이점을 박살내지 않는 이상 Lisp 이 major 언어가 되기는 매우 힘들 것 같다는게 제 의견입니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

bookgekgom의 이미지

제가 궁금했던 점을 콕 집어서 대답해 주셨군요.

그래도 함수형 언어를 배워보는것이 좋겠죠?

어느 정도는 구현할줄 알아야 하겠지요?

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

neogeo의 이미지

제가 자꾸 공산주의 운운하는게 다 그런맥락이었습니다. 인류가 엄청나게 발전하면 결국은 공산주의로 가게 될 확률이 높다고 생각합니다.

마찬가지로 소프트웨어 공학이 엄청나게 발전하면 아마 core 는 다 lisp 으로 된녀석이 차지하지 않을까 라고 생각합니다. ( 제약이 거의 없으니까요. )

그렇지만 그런 세상이 언제올지 아무도 모른다는게 문제지요.

그리고 그 세상이 오기만 마냥 기다릴 수도 없죠. 그런 좋은게 빨리 자리를 잡으려면 여하튼 실질적으로 뭘 할 수 있다를 보여야하는게 아닌가 생각합니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

bookgekgom의 이미지

하지만 함수형언어를 배우는데 걸리는 시간이

현제 존재하는 자바나 씨쁠쁠같은 언어들을 배우는 시간과

비슷하거나 혹은 더욱 짧아지지 않는다면 회사에서 채택을 할까요?

제가 바보인지 모르겠으나

함수형 언어는 매우 가독성이 떨어지고 배우기 힘든 언어라고 생각하는데요.

자바와 씨샾이 퍼진것이 그것이 무언가를 할수있는가? 때문이 아닌

더 짧은 시간안에 무엇을 더 많이 생산할수있는가? 때문이 아닐까요?

제가 놓치고 있는점을 말씀해주시면 감사하겠습니다.

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

neogeo의 이미지

배우기 힘들다는건 lisp 쓰는 사람들이 주장하는 바와는 좀 대치된다고 생각합니다.

( 가독성은 확실히 떨어진다고 생각합니다만 그것도 익숙해지기 나름이지요. )

언어가 주는 제약이 궁극적으로 소프트웨어 발전을 언젠간 막을겁니다. ( 다른 언어로는 한계에 닿을거란 이야기 이지요. )
그 상황이 오면 lisp 이 자연스럽게 대안이 될 확률이 높다고 생각합니다. ( lisp 은 일단은 제약이 없는 언어에 가깝습니다. 물론 , 이론적으로 들어가면 엄청 복잡해 지지만 다른 언어에 비해 낫다고 생각합니다. )

배우기 힘들다고 퍼지지 않는다면 C++ 은 처음부터 망했어야 합니다. C++ 같이 지저분하고 복잡하고 숨은거 많고 side effect 많은 언어는 세상에 찾아보기 힘듭니다. 다만 C++ 로 만든 수많은 app, lib 들이 C++ 위치를 더욱 공고히 해주는것이지요.

그리고 말씀하신대로 현시점에선 분명히 C++/JAVA 가 lisp 보다 일반적인 프로그래머에겐 생산성이 훨씬 높다고 단언할 수 있겠습니다. 그점을 빨리 박살내는게 소프트웨어 공학의 발전에 매우 중요할 것 같습니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

bookgekgom의 이미지

lisp 가 말하는 제약이 없는 언어라는 점이 참으로 입맛을 다시게 합니다.

배우기 위해 노력해야 할듯 하군요.

답변 감사합니다.

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

chanwooyoo의 이미지

리습이 널리 쓰이기 위해서는 실제적인 킬러 어플리케이션으로 그 장점을 증명하는 것이 필요하다는 말씀에는 동의합니다.

과거 리습이 C++/Java보다 먼저 존재했는데 왜 선택받지 못했는가? 라는 질문에는 약간의 변명이 필요할 것 같네요. 간단히 말하자면 앞서 말했던 빈익빈부익부(다수의 신자를 가진 쪽이 포교력이 더 좋은, 사람들이 모든 대안을 살펴보고 좋은 것을 판단하기에는 너무 많은 코스트가 들기 때문에 빠른 판단을 위해 대세를 따라가는, 또는 기존 플랫폼 위에 구축된 것이 너무 많아 어쩔 수 없이 그것을 선택해야 하는) 악순환 때문이라고 생각합니다.

언어의 줄기를 크게 나눌 때 Algol 계열과 Lisp 계열로 나눠볼 수도 있겠죠. 리습이 나오기 시작했을 당시 리습이 가진 가비지 컬렉션 같은 개념을 감당할 만큼 하드웨어의 성능이 받쳐주지 못했죠. '사람이 힘들고 하드웨어가 편한 언어(퍼포먼스 중시 언어)/사람이 무엇인가를 표현하기 편한 대신 퍼포먼스를 희생하는 언어(추상화 수준과 퍼포먼스는 어느 정도 트레이드 오프 관계에 있는지라 어쩔 수 없죠)' 사이에서 전자가 선택되고 쓰일 수 밖에 없었습니다. 그리고 Algol 계열의 언어들이 주로 전자에 속하는 것 같구요.

주류로 쓰였던 언어들의 흐름을 보면, PL/1 -> C -> C++ -> Java/C# 뭐 이 정도인 것 같습니다. 뭔가가 느껴지시지 않나요? 예 Algol 계열 syntax의 언어에 익숙하다 보니 계속 그 엇비슷한 언어만 사용하게 되고, 그런 스타일의 언어만 성공을 거두게 된 거죠. 특정한 문법에 익숙해지다 보니 사람들이 s-expression 스타일을 볼 때 받는 느낌은 '무슨 이런 괴물같은 스타일이 다 있어?'가 되 버린 거구요.

요약하면, 과거에 퍼포먼스 문제 때문에 Algol 계열 syntax의 언어가 선택되어 사용되었고, 그걸 시작으로 빈익빈 부익부 현상, 익숙한 것을 벗어나기 어려운 관성같은 것들 때문에 계속해서 그런 스타일의 언어만 성공을 거두고 있다는 것이죠.

사실, 리습이 그렇게 느린 언어는 아닙니다만,(여러가지 알고리즘들로 벤치마킹을 해서 실행시간의 평균을 낸 결과를 보면, C와 C++을 대략 1로 봤을 때, 리습과 자바는 1.6에서 2 정도로 비슷한 수준이고, 파이썬은 18, 루비는 60 정도였죠.) 하드웨어 성능이 좋아질수록, 리습을 포함한 표현력과 추상화 수준이 높지만 퍼포먼스가 떨어지는 언어들에 기회가 오고 있지 않나 라는 생각을 해 봅니다. 근데, 뭐 s-expression에 대한 편견과 기존 algol 계열 syntax에 대한 관성이 너무 강해 기회가 올 수나 있을려나 모르겠습니다. ㅠㅠ 다른 글타래에서도 썼지만 s-expression과 xml은 흔히 equivalent하다고 표현할 정도로 동일한 것인데, 한쪽은 성공해서 널리 쓰이고 있고 다른 쪽은 천시를 받고 있으니, 좀 착잡하네요. ^^;

--------------
lisp.tistory.com


--------------
lisp.tistory.com

winner의 이미지

만일 XML과 Lisp이 그렇게 동일하다면 Lisp->XML 변환기 작성이 어렵지 않을테고, Lisp으로 작성하시고, 남들에게 줄 때는 XML로 주면 될테니까요.

저도 XML과 Lisp이 유사하다고 생각한 적이 있습니다. 그렇다면 각괄호를 쓰는 XML보다는 소괄호를 쓰는 Lisp이 좋다고 생각했죠. 실제로 data로 활용될 때 Lisp과 유사한 언어를 쓰는 경우는 많이 있습니다. 대게 연구용일 때인데 그러니 XML만 성공해서 널리 쓰이고 있고, Lisp은 천시받고 있다고 생각할 필요는 없지요. Lisp 논쟁에서 언제나 반대편에 서는 Algol 계열의 "Worse is Better" C언어에서도 우리가 많이 쓰는 gcc는 최적화 단계에서 내부적으로 Lisp과 유사한 언어로 변환하는 것으로 알고 있습니다.

oppor의 이미지

SICP 보다가 손 놓았는데 더욱더 어려운 세계가 있네요.

chanwooyoo의 이미지

뭔가 사람들의 글을 읽다보면.. '이건 오핸데..'라고 느껴지는 부분이 너무 많아 어디서부터 얘기를 해야 될지 잘 모르겠다는 생각도 듭니다. ㅠㅠ

일단 커먼 리습 코딩은 emacs, vi, 이클립스에서 모두 가능하구요, 마치 visual studio와도 같은 매우 잘 만들어진 리습 전용의 IDE도 두 개나 있답니다. 흐음.. 특정한 에디터를 타는 편은 아닌 것 같아요.

리습의 학습 커브는 ㅠㅠ 정말 짧습니다. 어떤 프로그래밍을 전혀 모르시는 분이 있다고 합시다. 그 분은 아마 프로그램을 짜기 위해 두 단계를 거쳐야 할 겁니다.

1) 일단 그 언어의 문법을 익혀야 합니다. *, ;, {}, [], #, <<, @, $ 등의 기호가 무엇을 의미하는지 알아야 하고, 키워드들의 precedence 규칙 등에 대해 익혀야 할 겁니다.

2) 문법을 다 익혔다면 자신이 원하는 함수나 라이브러리들을 찾아서 사용할 수 있을 겁니다. 사용할 수 있는 라이브러리 함수나 메써드들이 어떤 것인지 알아보는 것을 새로운 언어를 배운다고 하지는 않습니다. 그렇죠?

보통 언어를 배운다는 것은 1)의 단계를 말합니다. 그렇지 않나요? 리습에서는 1)의 단계가 거의 없다고 보시면 됩니다. 2)의 단계만 있을 뿐입니다. 라이브러리로 존재하는 dsl을 익힌다는 것 역시 리습에서는 2)의 과정입니다.

리습의 코어와 dsl의 차이는 크지 않은 정도가 아니라 거의 전혀 없다고 할 수 있습니다. 누군가에게 dsl과 리습의 코어 코드를 주고 어떤 것이 코어 리습이냐고 묻는다면 구분할 수 없을 겁니다. 왜일까요? 리습에서 강조하는 얘기 중 하나는(물론 스몰토크와 하스켈도 마찬가지이지만), 'built-in과 추가된 library간의 질적인 차이는 없다'라는 것이기 때문입니다. 둘의 문법은 완전히 동일할 겁니다. operator의 이름만 차이가 있을 뿐이지요.

그리고 기본적인 정의를 재정의함으로써 나타나는 혼란은 오히려 MOP를 사용하는 언어들인 루비나 스몰토크의 문제입니다. 하지만 저 문제는 저 언어들에서도 그다지 문제가 되지 않습니다. 왜냐면 제정신 박힌 사람들이 언어의 코어를 재정의하는 일을 남발하지는 않기 때문입니다. 리습에서도 마찬가지입니다. 매크로의 장점은 코어를 건드리지 않고 내가 원하는 기능을 확장할 수 있다는 것이고, 물론 코어를 건드릴 수도 있지만, 그리고 저도 많은 리습 코드를 보아 왔지만 기본적인 control structure를 재정의하는 코드는 보지 못했습니다. 그러기보다는 차라리 추가적인 control structure를 정의해서 라이브러리로 사용하겠지요.

코드의 분석 및 가독성 문제에 대해서는.. PL 강의노트에 있는 's-expression이 다른 언어들의 형태에 비해 가독성이 좋다'는 문구에 대해서 후배가 저에게 왜냐고 물어본 적이 있습니다. s-expression이 읽기 쉬운 이유는 극도로 uniform한 형태를 지니고 있기 때문입니다. 그저 순서대로 코드를 읽어가면 될 뿐입니다. 어디서부터 코드를 읽어야 할지 모르는, 또는 시선이 여기저기로 왔다갔다 해야 하는 그런 사태가 발생할 수가 없다는 것이죠.

--------------
lisp.tistory.com


--------------
lisp.tistory.com

bootmeta의 이미지

chanwooyoo님 말씀대로 lisp core 자체가 작고, 문법이라고 부를만한 것 별로 없을 정도라 기본 core 학습 curve는 짧을 수도 있습니다.
그러나 lisp core 자체가 작은 만큼 써먹을 만한 결과를 내기 위해선 core를 확장한 부분이나 library, utility, DSL을 배워야합니다.
이 추가 부분이 학습 curve를 꽤 잡아먹습니다.
다른 언어들의 경우 상대적으로 경직된 문법이 어느정도 공통 DSL의 역할을 해줍니다.
더우기 chanwooyoo님이 언급했듯이 DSL과 lisp core와 구별이 불가능하다고 이야기 했듯이 언어 자체에서 지원하는 keyword과 기능인지, DSL인지 구별 불가능한 정도로 통합이 잘되버리는 바람에 lisp 언어의 범주를 어디로 봐야하는가 하는 문제도 고려해야합니다.
("loop" macro처럼 원 lisp에 워낙 잘 녹아들어간 경우처럼)

그나마 oop의 경우 CLOS가 비공식적인 표준입니다만, 그외 기능은 구현의존적 요소가 많은 만큼 표준화된 학습 corse를 정의하기 힘듭니다.
또 이전 댓글에서 언급했듯이 lisp 표준화 위원회의 삽질(?)과 오랜 전통으로 인해 lisp 표준 함수들은 너무 비대해져 버렸습니다.
이 점때문에 개인적으로 다른 사람들이 lisp을 배운다면 common-lisp으로 처음부터 시작하는 것보다 scheme으로 먼저 익숙해지고, 실무에 사용하는 경우 common-lisp를 배우는 것이 좋다고 생각됩니다.
제가 "기본 제어조차 재정의된 경우가 많다"고 언급한 부분은 확실히 잘못된 부분입니다.(^^;)

ps)
1. 객관화하기 어려울지 몰라도 개인적으로 lisp 학습의 주 복병은 이질적 용어들이었습니다.
유구한 전통과 논리학처럼 학계에서 유래한 용어들로 인해 직관적으로 받아들여지지 않는 경우가 많았습니다. (심지어 최근 사용되는 용어들과 1대1 대응되는 경우에도)

2. 논란의 여지가 있습니다만, 가독성 면에서 evaluation 순서대로 나열하는 (ruby등에서 볼 수 있는) method chain이 우아한 s-expression보다 적절하다고 봅니다.

(func1
  (func2 
    (func3 data))))
 
data.func3()
    .func2()
    .func1()
imyejin의 이미지

수학에서 f (g (h (x)) 이렇게 쓰지 x.h().g().f() 이렇게 쓰지 않죠.
워낙에 x.h() 같은 걸 많이 봐서 익숙해졌다면 몰라도
프로그래밍 처음 배운다면 당연히 전자가 가독성이 높을걸요.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

bootmeta의 이미지

아래처럼 func1과 func3 사이에 수십라인이 걸쳐 있다면, 머리 속 stack의 압박이 ...
물론 이런 극단적인 경우는 드물겠습니다만,

(func1 
  ....
 
  func3)))
winner의 이미지

저는 그렇지가 못해서...

sblade의 이미지

후자는 데이터 x 가 h, g, f 를 차례대로 통과하는 듯한 느낌을 주죠. :-)
그리고 수학에서도 f(g(h(x))) 가 사실은 f . g . h : x -> z 로 정의된 composite function 의 z 값을 이야기하는 것이란걸 생각하면, 후자는 그것을 단지 거꾸로 읽는 것 뿐이니 관점에 따라서는 역시 자연스럽습니다.

jick의 이미지

일례로 대수학에서는 f(g(h(x)))로 쓰면 쓰는 순서와 operation을 적용하는 순서가 반대라서 헷갈린다고, xHGF처럼 쓰는 경우도 있습니다. (Reference: Topics in Algebra by Herstein)

imyejin의 이미지

reduction (또는 evaluation) strategy에 따라 다릅니다. 함수를 적용(함수 인자로 넘어온 식을 함수 몸체의 해당 변수와 치환)하는 연산을 안쪽부터 실행해야만 하는 건 아니죠. f(g(h(x)))를 normal order reduction (또는 lazy evaluation)으로 계산해 나갈 경우 바깥쪽에서부터 즉 f부터 풀어나가면서 치환합니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

dreamstorm의 이미지

CLOS 는 ANSI 공식 표준이고 MOP 가 비표준(이지만 대부분 구현체들이 지원하려하는)이라고 알고있습니다.

언급하신 대로 common lisp 이 덩치가 크다는건 정말 치명적인 문제라고 생각합니다.
C++ 처럼 멀티패러다임을 지원하는 몇안되는 언어이면서
C++ 보다 좀더 각각의 패러다임을 잘 지원하고(특히 함수형쪽.. 게다가 OOP 는 다중상속에 멀티메서드까지 헐!)
사용자가 원하면 새로운 패러다임을 추가구현할수도 있습니다. (CLOS 표준화 전에 여러개의 OOP 구현체들이 있었다고 합니다.. 놀랍게도 특별한 언어확장없이 macro 레벨에서 올렸다더군요 헐.. common lisp 이 궁극의 언어라는말은 부인할수가 없죠)

common lisp 의 가독성은.. s-expression 이 신택스를 파악하기 쉽다는건 이해가 가지만 시맨틱을 알기는 정말 어려울거라고 생각합니다...
macro 가 뜨면 이게 언제 평가되는지, 순차적인 흐름이 맞긴 한건지.. 일단 macro 가 뜨면 그야말로 모든게 가능하기 때문에
특별히 남의코드를 안쪽까지 따라들어가야 한다면 지옥이 될것 같네요.
물론 대부분의 경우 문서화가 잘되있어서 그럴필요는 없겠지만요.

dreamstorm의 이미지

음 멀티패러다임에 대해 링크 추가합니다.
사실 요즘 멀티패러다임 언어야 흔한거죠...

http://en.wikipedia.org/wiki/Multi-paradigm_programming_language

Oz 는 8개 패러다임을 지원한다니.. 놀랍기도 하고 끔찍하기도 하네요.

M.W.Park의 이미지

lisp 초창기에 s-expression이 어렵고 불편하다고 판단하고, m-expression이라는 것도 쓸 수 있게 한 적이 있었습니다만...
실제 사용자들이 조금 익숙해지자 s-expression을 자유자재로 써서 지원이 중단되었다는 내용의 글을 본 적이 있습니다.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

winner의 이미지

무엇을 중점에 놓고 생각하고, 다른 것을 거기에 맞추는가.

사실 Python과 Ruby 역시 code를 data로 쓸 수 있습니다. 다만 Lisp보다 어려울 뿐이지요.
만일 meta programming이 권장된다면 Lisp은 성공했을지도 모르겠습니다. 또는 Algol 계열에서 meta programming이 유리한 다른 언어가 성공했을지도 모르지요. 예를 들면 Javascript...

Lisp을 중요시여기는 사람들은 Lisp의 극도의 minimal 함에 찬사를 보냅니다만 사실 사람들은 좀더 다양한 것을 원하는 것일지도 모르지요.

Meta programming이 사람들의 피곤함을 덜어줄 수 있지만 많은 사람들이 programming 하는 즐거움을 뺏어왔을지도 모릅니다.

우리들은 언어를 쓸 때 언제나 해당 문화와 관련되어서 생각할 수 밖에 없습니다. 우리들의 크리스마스와 미국의 크리스마스는 다르지요. 문법이 문맥에 영향을 주는 것을 프로그래밍 언어학자들은 싫어합니다만 그 둘을 분간하지 못하는 사람들은 동일하게 생각하는게 나을지도 모르지요. 나중에 필요하면 분간하겠죠.

많은 사람들이 programming을 즐기고 필요하게 된다면 저는 사람들이 그때 다시 Lisp을 돌아볼 거라고 봅니다. 혹은 programming을 하는 인공지능들이 Lisp을 사용할지도 모르지요.

dl3zp3의 이미지

그런데 누가 주장하는 것처럼 Mathematica언어는 거의 리습이라는 게 사실인가요? Mathematica의 언어는 1,2,3번 조건을 모두 만족하나요?

Mathematica가 Maple보다 더 좋은 거 같은데 값이 너무 비싸다는.... 백만장자가 Wolfram회사 인수해서 Mathematica를 그냥 공짜로 확 풀어버렸으면...

sblade의 이미지

최소한 학계에서는 사용처를 잃어가는 것은 맞는 것 같습니다.

John McCarthy 가 LISP 을 창안할 당시의 AI 의 주된 흐름은 논리 기반 AI 였습니다. LISP 을 정말 한마디로 정의하자면, John McCarthy가 새로운 언어인 LISP 의 디자인을 주창했던 논문 제목인 "Recursive Functions of Symbolic Expressions and Their Computation by Machine" 이 정말 적절한데, 이게 딱 symbolic, logical AI 분야에서 문제 해결을 바라보는 키워드죠... 또한 Emacs 가 확장 언어로 LISP을 이용하는 것도 이해가 될 수밖에 없는게 당시 MIT AI lab 에서 모두들 그걸 썼기 때문 (그래서 매크로를 다들 LISP 으로 썼기 때문)이 아마 가장 클 겁니다. RMS 본인이 논리, 모델 기반 AI 로 대학원 생활을 했구요. LISP 과 논리 기반 AI 패러다임은 뗄래야 뗄 수가 없죠.

그런데 문제는 논리 기반 AI 가, 현재의 deterministic turing machine 을 써서는 할 수 있는게 그다지 없다는 게 밝혀지면서 사실상 죽었다는 겁니다. 이젠 AI, robotics 등을 한다는 사람들이 모두 Java, Python, MATLAB... 어쩔 수 없을 때만 c/c++.. 을 쓰고, LISP 의 최대 강점인 미니멀리즘은 빨리 rapid prototyping 을 해서 다양한 방법을 실험해봐야 하는 요즘과 같은 경우 (대학원생들과 회사원에게 있어서) 단점이 되고 말았죠.

6.001 이 scheme 에서 Python 으로 바뀐 이유도 비슷하다고 생각합니다. LISP/scheme 이 미니멀할지언정 이제 더 이상, CS 필드에서조차도, 연구자들이 문제 해결을 위해 사고하는 방식이 아닙니다. 아름답지만.. 낡았죠.

bacchusf의 이미지

요즈음은 statistical machine learning을 많이 하고 있죠..
특히나 데이터를 매트릭스에 저장하고 계산하는건 아무래도 matlab이 lisp보단 비교할수 없을 정도로 편하니깐요..

죠커의 이미지

rapid prototyping이 힘들다는 것이 동의하기 힘듭니다. 여러 성공적인 lisp 프로젝트는 지속적으로 빠르게 개선되었습니다. 최근의 XP에도 적합하다고 생각됩니다.

- 죠커's blog / HanIRC:#CN

hongminhee의 이미지

제가 위에서 Io에 대해서 얘기했는데, Lisp의 특징(단일 문법, 데이터로서의 코드와 매크로)을 모두 가지고 있는 언어로 Factor가 있습니다. 다만 문법이 S-expression이 아닙니다. 이것은 Factor가 Forth를 계승한 concatenative programming language이기 때문입니다. 하지만 어찌되었든 단일 문법이라는 점에서(혹은 “문법이 없다”는 점에서) Lisp과 동등합니다.

찾아보면 Lisp의 정신을 이어받으면서 좀더 현대적인 언어가 생각보다 많습니다. (Ruby나 Python처럼 스스로는 alternative lisp, acceptable lisp을 주장하는데 실제로는 Lisp의 핵심 조건을 만족하지 않는 대부분의 스크립트 언어들을 말하는 것이 아닙니다.) ‘Lisp의 특징에 매력을 느끼지만 괄호만은 내게 acceptable하지 않다!’하시는 분들은 Io나 Factor 같은 언어들을 시도해보세요.

ageldama의 이미지

Factor에 대한 좋은 소개 감사.

정말로 제게는 Factor가 acceptable lisp인듯.
sexpr이 없고, 대신 concatenative하다는게 더 유연하다는걸 느끼게 해주죠.

----
The future is here. It's just not widely distributed yet.
- William Gibson

----
The future is here. It's just not widely distributed yet.
- William Gibson

ds5pnz의 이미지

chanwooyoo님의 멋진 글에 혹해서 Programming Clojure 책 부터 질렀습니다. (사실 lisp는 잘 모르지만... 죽기 전에는 써 봐야 할 언어 같네요.)

chanwooyoo의 이미지

사람들이 다른 언어의 dsl과 메타 프로그래밍에 대한 인식 때문인지 매크로가 뭔가 엄청나게 복잡하고 두려운 것이라는 생각을 하는 것 같습니다.

리습의 입장에서 매크로라는 건 그저 '함수'일 뿐입니다. 단, 인자의 평가 여부를 조절할 수 있는 함수이죠. 그리고 리스트를 받아 조작 후 리스트를 리턴하는 함수입니다.

어레이를 받아서 어레이를 리턴하는 루비 함수를 하나 짰다고 할 때, 그것을 특별하게 복잡한 것으로 여기고 다른 함수와 달리 생각해야 될 이유가 있을까요?

그리고 댓글을 보면 어떤 분들은 리습이 극도의 minimalism을 가지고 있어 빠른 프로토타이핑이 어렵다고 하고, 어떤 분은 언어 자체가 너무 크다고 하시는데, 여기서 뭔가 모순이 있는 것 같지 않나요? ^^;

스몰토크 커뮤니티에서 스몰토크를 소개하는 글을 읽어보면, '무언가를 빠르게 짜는 도전을 감히 스몰토크 사용자에게 하지 말라.' 라는 얘기를 합니다. 단, 단서가 붙죠. '리습과 하스켈 사용자를 제외한다면'이라고. 리습의 프로토타이핑은 매우 빠릅니다. 라이브러리 면에서도 그 수에서는 파이썬과 펄보다 작겠지만, 필요한 라이브러리가 있는데 그걸 못 구해서 뭔가를 못 짜는 경우는 전혀 없습니다.

그리고 학습 커브에 대해서는, 리습 기본 언어 자체가 미니멀하고 추상화 수준이 낮아서 뭔가 쓸만한 루프라던가 파일을 다루는 유틸리티 등을 사용하려고 하면 dsl이나 라이브러리를 봐야 한다라고 생각하시기도 하는 것 같은데, 그렇지 않습니다. ㅠㅠ 루비의 경우에 루프를 쓰기 위해서는 for 문이나 .each를 알아야겠죠. 그리고 저건 언어에 기본적으로 포함되어 있습니다. 파일 입출력을 위해서는 File 클래스나 Dir 클래스를 봐야 할테고 저건 기본 라이브러리입니다. 리습도 for나 loop, 또는 파일 입출력이 언어에 기본으로 포함되어 있습니다. 글에서 말씀드렸듯이 언어가 미니멀해서 반복을 위해서는 재귀같은 걸 써야 할 거야라는 건 선입관이고, 객체 지향 시스템이나 매우 추상화 수준이 높은 루프 및 제어 구조, 패키지, 파일 입출력, 해쉬나 dictionary, 어레이와 리스트 등의 자료 구조, 자바보다 훨씬 정교하고 수준이 높은 exception handling, 스몰토크와 루비 뺨 치는 MOP등이 언어의 코어에 기본으로 들어가 있습니다. 루비가 프로그래머를 즐겁게 하는 언어라고 광고하지만, 무엇인가를 표현하고자 할 때 루비 기본 언어가(루비 built-in 라이브러리를 제외할 때) 제공하는 것 대부분을 리습에서 제공합니다. 그만큼 무언가의 표현이 쉽죠. xml이나 네트워크 관련 프로그래밍, 단위 테스트를 하는 경우에, 루비는 기본으로 라이브러리에 저런 것들을 위한 라이브러리가 포함되어 있죠. Clojure라는 리습도 contrib이라는 기본 라이브러리에 저런 것들이 다 포함되어 있습니다. 커먼 리습의 경우에는 asdf(루비의 rubygem과 같은 것이라고 생각하시면 됩니다.)를 통해 설치한 후, 라이브러리 문서를 살펴봐야 할테지만, '기본 라이브러리로 포함되어 있다/확장 라이브러리 형태로 존재한다'의 형태가 다를 뿐이지 양쪽 경우에 xml 파서라면 해당 라이브러리의 인터페이스를 살펴봐야 하는 학습 노력은 완전히 동일하지 않을까요?

그리고 리습의 특징은 'built-in과 확장되는 부분 사이의 질적인 차이가 없다.'라는 것입니다. 커먼 리습이 거대한 언어라고 하셨지만, 맞습니다 스킴보다는 큰 언어죠, 하지만 수많은 라이브러리들을 기본으로 포함하고 있는 루비보다는 훨씬 작은 언어일 겁니다. 만일, 기본 라이브러리는 언어의 코어에 해당하지 않는다고 생각하고 라이브러리는 빼고 얘기하자 라고 하신다면, 그 경우에도 리습의 코어는 루비보다 작습니다. 리습 코어의 대부분은 13개 정도의 special operator위에 모두 쌓아올려진 것이고, 소위 '쌓아올려진' 부분은 '완전히 라이브러리가 만들어지고 추가되는 방식과 같기' 때문이죠. 그렇다고 리습 코어가 13개의 operator만으로 되어 있다고 말하는 것은 맞지 않습니다. C의 가변인자는 C의 매크로로 구현되어 있는데 그러면 가변인자 부분은 C의 코어가 아닐까요? 보통 그렇게 말하진 않죠.

혼란스럽게 말을 했지만, 리습은 언어의 경계가 여기까지다라고 말할 수 있는 언어가 아니라는 겁니다. 언어의 문법이 없기 때문에, 언어를 살펴보기 위해 해야 되는 일은 그저 '이 (라이브러리) 함수가 뭐 하는 함수지?' 라는 걸 살펴보는 게 전부라는 것이고, 이것은 프로그래머들이 늘상 할 수 밖에 없는 일이죠. 앞에서도 얘기했지만 매크로 역시 그저 인자의 평가 여부를 조절할 수 있는 '함수'일 뿐이니 매크로를 살펴보는 일도 함수를 살펴보는 일과 크게 다르지 않습니다.

그리고 루비와 파이썬도 코드를 데이터로 다룰 수 있다고 하셨는데, 물론 스트링과 eval을 쓰면 가능하긴 하지만, 리습에서 code as data라는 말은 코드와 데이터의 형태가 같다는 말입니다. 그게 루비에서는 안 되기 때문에 코드 자체를 인자로 받는 my_class Person < Animal 과 같은 형태의 my_class를 정의하는 것이 불가능하고 my_class "Person < Animal"과 같은 형태밖에 불가능할 뿐더러, 스트링이 아니라 블록으로 코드를 받는다 하더라도, 블록으로 받은 코드를 리스트처럼 iteration하며 조작하는 것은 불가능하죠. 따라서 스트링이나 블록을 사용할 경우 단지 조금 불편한 정도가 아니라 복잡한 코드 조작은 거의 힘들게 됩니다. 커먼 리습의 gensym과도 같은 variable capture를 피할 수 있는 수단도 없구요.

이번 글을 올리고 나서 느낀 건, 리습에 관한 선입관이 생각했던 것보다 훨씬 강하다는 것이었습니다. 마치 윈도우 사용자에게 맥 OS 운영체제의 우수성을 얘기해 보지만(제가 맥을 쓰지만, 정말 아무리 오랫동안 리붓같은 걸 안 해도 속도가 느려진다거나 하는 게 없습니다.), 맥 OS는 영 쓸 게 못된다는 얘기를 듣는 기분과 흡사하다고나 할까요? ^^;

--------------
lisp.tistory.com


--------------
lisp.tistory.com

imyejin의 이미지

Common Lisp 표준은 1000 페이지가 넘습니다. 분량으로는 C++ 표준을 능가하죠.

Scheme 등 minimal한 리습 사투리들이 있지만 Common Lisp은 작은 언어와는 거리가 멉니다.

물론, 그래도 언어의 알맹이(core)는 작고 모든 게 라이브러리나 마찬가지야 이런 주장이야 가능할 수 있겠습니다만 ...

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

chanwooyoo의 이미지

페이지 수가 많은 것은 모든 built-in 라이브러리에 대한 스펙을 포함하고 있기 때문입니다. spec을 보면 sin, cos, tan 같은 수학 함수나 파일 IO 라이브러리 등에 대한 명세를 모두 포함하고 있습니다.

만일 루비 언어의 모든 built-in 라이브러리의 클래스들에 대한 인터페이스를 페이지를 따로 할당해 스펙을 만들었다면 어떨까요? CLHS보다 훨씬 많은 양이 될 겁니다.

언어가 크다는 것이 문제가 되는 건 그 언어를 배우는 데 노력이 많이 들기 때문이겠죠. 하지만 우리가 루비라는 언어를 배울 때 File 클래스나 String 클래스의 모든 인터페이스를 익혀야 루비를 익혔다고 하진 않습니다. 마찬가지로 리습을 배우기 위해 CLHS의 모든 내용을 봐야 할 필요는 없죠. 그 부분이 필요할 때 찾아보면 그만인 것이죠. 모든 built-in 라이브러리에 대한 내용을 포함하고 있는 문서의 페이지가 많다고 해서 그 언어를 크다고 할 수 있을까요? 물론 커먼 리습이 스킴과 같이 minimal한 언어라는 것은 아니지만, 적어도 루비나 파이썬, 자바 등의 현대적인 언어보다는 작은 언어라고 생각합니다. 그 언어들은 커먼 리습이 기본으로 포함하고 있지 않은, 예를 들면 네트워크 관련의, built-in 라이브러리까지 가지고 있기 때문에 거기에 대한 스펙을 CLHS를 만들 듯, 동일한 방식으로 다 만든다면 커먼 리습에 대한 스펙보다 훨씬 클 겁니다.

--------------
lisp.tistory.com


--------------
lisp.tistory.com

lifthrasiir의 이미지

저도 그렇게 리습(커먼리습이랑 스킴 모두...)에 익숙하지도, 그렇다고 아주 모르는 것도 아니라서 말을 꺼내기가 좀 망설여집니다만, 아무래도 제가 하고 있는 생각과 비슷한 얘기는 한 번도 나온 것 같지 않으니 그냥 얘기를 해야 겠습니다.

프로그래밍 언어를 평가할 때는 몇 가지 중요한 요소가 있습니다. 기능, 즉 언어의 표현력이 하나고, 가독성 또는 작성의 용이함이 하나고, 표준 라이브러리나 다른 라이브러리가 하나고, 사용자 커뮤니티와 문화가 하나겠죠. 기능에 있어서는 정도의 차이는 있지만 다른 프로그래밍 언어에 비해 뛰어남(homoiconicity를 달성한 언어가 몇 개나 될까요? :)을 부정하신 분은 많지 않아 보입니다. 가독성 및 작성의 용이함은 뭐 주관적이기도 하고, Brainfuck이나 Malbolge 같은 언어보다 좋기만 하면 전 그렇게 상관은 안 합니다. 라이브러리야 커먼리습은 엄청나게 거대(?)하기로 유명하고요, (솔직히 개인적으로는 위원회를 좋아하지 않아서 사용자들이 대규모로 참여하는 Perl 같은 스타일을 선호하긴 합니다만) 사용자 커뮤니티도 크게 늘어나는 건 아니지만 꾸준히 유지되고 있으니 큰 문제는 없어 보입니다.

근데 그렇다고 리습이 다 좋은 건 아닙니다. 쓰레드에서 많이 보셨듯이 사람들이 리습에 가지고 있는 "선입관"은 생각보다 뿌리깊어서, 사실 그게 선입관이 아닐 가능성도 적지 않다고 생각합니다. (단지 리습을 자주 사용하는 사람들은 그게 선입관이라 생각할 뿐) 예를 들어 괄호 때문에 생기는 가독성 및 작성의 문제는 선입관이라고 여기기에는 어느 정도 일리가 있는 말이고요.

제가 생각하기에 리습의 가장 큰 문제는 한 문장으로 요약할 수 있을 것 같습니다. "Worse is better." 사실 이건 한 20년 전 쯤에 나온 얘기를 재탕하는 거에 가까운데, 다른 점이라면 저건 커먼리습의 설계를 비판하는 거지만 저는 리습 전체의 설계를 비판하는 겁니다. 지나친 일반화는 모자란 일반화보다 못 하듯이 리습의 큰 장점으로 선전?되는 homoiconicity와 작은 코어 코드는 매우 간명하다는 장점이 있습니다만 그걸로 좋다 나쁘다를 논할 수 있는 것이 아닙니다. 리습의 homoiconicity는 S-expression이라는, 사람들을 종종 짜증나게 하는 문법 구조 위에 얹어진 것입니다. 작은 코어 코드를 통해 만들어진 매크로는 (마치 C 매크로처럼!) 사람들이 아무 때나 매크로를 쓰게 하는, 별로 달갑지 않은 결과를 낼 수도 있습니다. 물론 제가 이런 얘기들을 모두 증명할 수 있는 건 아니고 그냥 예시를 들어서 하는 말입니다만, 여하튼 기능이 많다고 모두 좋을 수는 없습니다. 심지어 파이썬이나 루비 등에서 지원하는 eval을 통한 동적인 코드 실행이 리습의 homoiconicity에는 뒤떨어질 지 몰라도 실제로는 사용자에게 더 편하게 느껴질지도 모를 일입니다. (예를 들어 루비의 block eval은 거의 idiom화되어 잘 쓰이고 있지요.)

좋다 나쁘다의 기준은 사람마다 다를 수 있습니다. 하지만 제 지금까지의 경험과 이 쓰레드의 내용을 종합해 봤을 때, (모든 논거가 주어진다 해도) 모든 사람이 리습을 좋다고 생각할 수는 없을 것 같습니다. 따라서 chanwooyoo 님께서 이를 "선입관"이라고 주장하시는 데 저는 동의하지 않습니다. 또한 비슷한 이유로, 저는 리습이 영원히 살아 남을 것이요 앞으로도 꾸준히 다른 언어에 큰 영향을 미칠 것임에 동의하지만, 리습 자체가 그 용도로 흔히 사용되는 일은 근미래에 보기 힘들 것이라 생각합니다. 뭐, 언어 치고 영원히 살아 남아 영향을 미친다는 것 자체로도 리습은 가치가 있는 언어이기는 합니다만.

(Worse is better에 대한 제 생각은 suckless.org에서 주장하는 것과 다소 비슷합니다. 물론 저기만큼 급진적인 건 아니지만요. 그나저나 제 맥북 프로는 오래 쓰면 느려지던데 어떻게 해야 하나요... O<-<)

chanwooyoo의 이미지

XML은 어떻게 생각하시는지요? XML의 재미있는 별명 하나는 's-expression을 두려워하는 사람들이 s-expression이 아니라고 생각하면서 사용하는 s-expression'입니다. 실제로 XML과 s-expression은 완전히 동일한 것이라 XML로 이루어진 리습이 있다고 해도 아무도 놀라지 않을 겁니다.

s-expression을 싫어하시는 분들이라 해도 여러 부분에서 XML은 많이들 사용하실 거라 생각합니다. XML은 사실 조금 더 가독성이 떨어지는 s-expression(참조: http://www.defmacro.org/ramblings/lisp.html)이죠.

사실은 동일한 두 형식이 하나는 굉장히 많이 쓰이고 있고, 하나는 사람들이 싫어하는 대상이 되고 있으니 아이러니가 아닌가 하는 생각이 듭니다.

--------------
lisp.tistory.com


--------------
lisp.tistory.com

lifthrasiir의 이미지

저는 XML을 매우 싫어합니다. ;)

부연 설명: 리습에 대한 평가와는 별개로 S-expression이 계층적 구조를 컴팩트하게 표현할 수 있다는 것은 굳이 부정하지 않습니다. 단지 XML은 S-expression보다 복잡하니 문제죠. 저는 요즘 짜는 XML이라고는 XHTML 문서 밖에 없고 그마저도 요즘은 줄이려고 노력 중입니다.

winner의 이미지

TeX? Microformat? reST?

magingax의 이미지

XML은 그리들 잘쓰면서 s-exp가 어렵다는게 이해 안됩니다.
개인적으론 XML 이 10배 복잡하다고 생각합니다.

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

winner의 이미지

XML이 programming 언어 논쟁까지 오고 수고가 많은 것 같습니다.

magingax의 이미지

이해를 돕기위해 예를 들면..
..
..

;-- Detect any change in inspector window
(defmethod (setf mop:slot-value-using-class) :after (val (class standard-class) (wnd |inspector|) slotd)            
  (declare (ignore-if-unused val wnd slotd))  
  (when (value *view*) (setf (updated (value *view*)) t))  
  )

inspector 라는 클래스가 있고, 프로그램 내에 inspector 인스턴스 A 가 있는 경우를 생각해봅시다.
큰 프로그램 여기저기에서 그 A내에 수많은 멤버변수중 일부를 읽거나 쓰는경우, 그걸 자동으로 캐치해서 뭔가를 해야한다면?
LISP에서는 위의 메소드를 하나 등록해 버리면. 이거하나로 전부 처리할수있습니다.
만일 이걸 다른 언어로 처리하라고 하면..좀 힘들지 않을런지..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

AOP라고 들어보셨습니까? ;-)

johan의 이미지

AOP라면 CLOS 주 설계자인 Gregor Kiczales가 Java에서 뭔가 해보려고 한 그것으로 아는데, 한 컨퍼런슨가에서 Lisp 프로그래머들이 왜 MOP보다 못한 물건을 만들었을까 의아하며 질문 했다는 이야기를 4-5년 전에 읽어본 것 같네요. 한때 참 대단한 사람이었는데, 좀 안타깝더군요. 그사람의 책 AMOP을 읽으면서 소스코드 위주의 책이 이렇게 흥미로울 수도 있구나 하고 절로 감탄이 나왔더랬는데...

magingax의 이미지

위에 적용한게 MOP 고..MOP를 만든(?) gregor kiczales 가 나중에 만든게 AOP
라고 알고있습니다. 아마 비슷하지 않을까요? 아무튼 AMOP 란책은 정말 감동이었습니다.
그래도 최강은 PAIP 라는..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

winner의 이미지

아시겠지만...

johan의 이미지

Lisp은 이를테면 대량학살 무깁니다. 대부분의 일에 필요치 않으며, 사용하고 있더라도 부적절하게 사용하고 있을 가능성이 많습니다.

어떤 프로그래밍 언어는 언어자체의 한계나 복잡성 때문에 툴에서 많은 것을 해줘야 합니다(Smalltalk, Java + Eclipse 등). Lisp은 그러한 것을 프로그래밍 언어 자체로 할 수 있습니다. 하지만 프로그래밍을 도와주는 툴을 만들려면 Lisp에서 자연스럽게 벌어지는 Meta level programming을 할 줄 알아야 합니다. 결국 그런 툴을 만드는 Lisp을 사용하지 않는 프로그래머들은 비록 Lisp 프로그래머는 아닐지라도 이미 Lisp에서 사용하는 개념이나 테크닉을 사용하는 것이 대부분입니다.

Lisp을 사용하는 프로그래머는 드물지라도 그것은 Java와 같은 프로그래밍 언어에서 그 언어를 자유자재로 사용할 수 있는 프로그래머 수가 적은 것과 마찬가집니다.

대부분의 프로그래밍 일에 Lisp은 그리 바람직 하지 않습니다. 파리를 잡는데 핵무기를 사용하는 것과 비슷하다고나 할까요?

Lisp은 너무 일찍 나왔기 때문에 빛을 못본 프로그래밍 언어라고 봅니다. 예를들면, 지금 Eclipse에서 보는 기능이나 개념과 유사하거나 조금 앞선 것들이 8,90년대에 Lisp에서 구현되거나 실험되었던 것들이 많습니다.

두어달 전, Eclipse로 프로그래밍 하다가 Lisp이 문득 생각났습니다. Lisp보다 못한 프로그래밍 언어라 하더라도 툴에서 도와주면 어떤 면에서는 Lisp으로 프로그래밍 하는 것 보다 낫다는 생각이 들더군요. 이런 "덜 강력한 프로그래밍 언어 + 강력한 툴"의 조합으로 Lisp이 앞으로도 빛을 보기는 어렵겠다고 생각했는데, 의외로 이런 글들이 튀어나오는 것을 보면 어쩌면 곧 다시 한번 기회가 오는게 아닐까 생각해 봅니다.

툴 개발자가 되려면 Lisp을 배우는 것이 큰 도움이 되겠지만, 그냥 툴 유저라면 그럴 필요까지 있겠습니까?

dreamstorm의 이미지

http://c2.com/cgi/wiki?LispIsTooPowerful

딴나라에서도 lisp 에 대한 토론은 항상 flame 거리가 되며
아무도 lisp 이 후지다고는 감히 말 못하지만 대부분 완곡한 표현으로 lisp 은 좋긴 한데 난 못써먹겠다!
라는 의미의 말씀들 하시더군요.

PCL 의 저자가 아버지에 이어 2대째 리습개발자인것으로 아는데
리습은 정말 대를 이어갈 인류의 문화유산이라고 생각됩니다 :)

dreamstorm의 이미지

http://lukewelling.com/2006/08/03/java-programmers-are-the-erotic-furries-of-programming/

예전에 reddit 에서 봐둔건데 이번글을 보며 생각이 났네요.
그때 보면서 상당히 공감을 느꼈었는데 말이죠

페이지