• 간결하게 자기 생각을 표현할 수 있는 게 프로그랭밍의 재미.
• 컴퓨터 1세대인 저자의 아버지가 OS를 만들 때만 해도 쓸 만한 언어가 별로 없었다.
  • FORTRAN, 어셈블리 정도가 있었겠지 그 때는. 어쩌면 C 도 쓰였을는지?
  • 하긴. MSX 에서 돌아가는 MSX-C를 처음 분 게 디스크 드라이브를 산 1991년이었으니까.
• 이 책 저자의 아버지는 어찌어찌 Lisp 을 알게 되고 열심히 그걸로 프로젝트를 진행핬다.... 그런건가?
  • 제대로 글을 읽었는지 모르겠지만 일단 1980년대 초만 해도 BASIC 이 주류였고, Turbo Pascal이 나온 건 1983년 정도였을 테니. 그나마 MS-DOS나 MSX-DOS 정도에서나 가능했을 테니까.
• 오늘날(!)—그래, 진부한 표현이지만 그래도 좋다.— 신박한 언어들이 많고 Lisp의 기능도 다 포함하고 있는데 그래도 Lisp을 배워야 할까? 그럴 이유가 있을까나?
• 자기 아빠가 Lisp 열심히 했는데도 자기는 고등학교때 까지 프로그래밍 공부 열심히 못했고, 대학에 와서야 웹도 공부하고 Java 도 하고 그러다가 C , Python 도 했단다. 근데 신기한 게 남들이 잘 안하는 Smalltalk 나 Eiffel, Beta 같은 희한한 언어도 다루었다고 하니 놀랍다.
• 필자가 꽤 많은 언어들을 다루어 본 것 같은데, 자기 생각을 실제로 구현하기에 Lisp이 제일 빨랐다고.
  • 그도 그럴 것이 자기 아빠가 Lisp 쓰는 걸 맨날 봐왔을 테니... 영향이 어디 가겠어? 남들 안 쓰는 비주류 언어가 있다는 걸 안다는 것 자체가 신기. 그래. 나도 Forth 를 몰랐다면 언제까지나 Algol 방계의 언어들만 보면서 세상에 그게 전부인 줄 알았겠지.
• 이 책 23장에 쓰인 라이브러리에 대한 이야기인데, java로 짤 때 몇 년이 걸렸고 결과물도 생각보다 별로였는데 Lisp으로 짜니 이틀이면 충분했다고. 그리고 작성한 라이브러리는 재사용도 쉬웠다고. 언뜻 보면 파서인 것 같은데,...
  • 이거 정말 믿어도 되는 말인가? 직접 체험해봐야 알 것 같긴 하다. 그래. Java라면 아무리 클래스를 잘 조직해도 그것들은 '그때의 문제를 풀기 위한 부품'이라느 인식이 더 강하니까. Lisp에서는 이를 어떻게 처리할지 궁금하기는 하다.

왜 Lisp인가?

• 필자의 머리가 이상한 건지, 필자 아버지에게서 물려 받은 것인지, Lisp을 써서 문제가 잘 풀렸다고 그게 나에게도 적용될지는 모를 일아다. 과연 Lisp에 시간을 투자할 가치가 있나?

  • 신기하게도 이런 의구심을 딱 찝어서 말하니 글을 참 잘 쓰는구만. 그래. 나도 그렇게 생각했어.

• 모든 언어는 배워둘 만한 가치가 있지. 저수준의 C, 크로스 플랫폼의 Java도 있고, 업체에서 많이 쓰는 C++도 있고. 또 언어가 추구하는 철학(이나 모토?)에 따라서도 달라지는데 Perl이랑 Python 역시 거진 반대되는 철학이 있으니까. 그럼 왜 Lisp일까?

  • 나는 처음 어떤 언어를 접ㅎ 때 "이 언어는 이렇게 좋으니 다른 언어는 꼬졌어" 같은 논지를 굉장히 많이 봤다. 철모를 땐 나도 그런 생각을 했었다. 하지만 지금은 필자의 위의 말이 더 설득력이 있다고 인정한다. 모든 언어는 다 쓰임이 있고 가 나름의 장점이 있다. 그래서 취미로라도 개발을 하지 않는 내가 이렇게 여러 언어를 기웃거리는 것일 지도?

• Lisp의 철학:

  The Programmable Programming Language

• 필요한 것이 있으면 내가 만들어서 쓰면 된다. Lisp에 없다면 만들어서 넣으면 된다. 다른 언어들 처럼 언어 명세가 확장되거나 언어의 발매사들이 이를 지원해줄 때까지 기다릴 필요가 없다. 그냥 Lisp에 더하면 된다. "좋은 포로그래머는 좋은 사용자이다."

  • 사실 Forth 를 처음 접했을 때 충격을 받았던 왜 Forth가 그렇게 대단한가? 라는 글에서도 이런 말을 들었다. 철도를 때 Forth에 푹 빠지게 했던... 하지만 실상은, 필요한 걸 내가 만들 실력이 없다면 결국 다른 사람들이 만들어주어야 하는데, Forth를 쓰는 사람들이 책도 없이 적어서 결국은 망했어요 ㅠㅠ.

    C 를 쓰면 C가 제일 좋은 프로그래밍 언어인 것 같습니다. Forth를 쓰면 내가 제일 좋은 프로그래머인 것 같습니다.

  • 그래서 사실 Lisp의 이런 공언이 그렇게 혹하지 않다. 다만 한 가지 다행인 건, 적어도 Lisp이 Forth보다는 큰 커뮤니티를 가지고 있고, 21세기임에도 여전히 다시금 주목을 받는 언어이기 때문아ㄷ. 그래, 이 책도 2000년도에 나왔을 테니.

• 언어가 지정하는 무언가에 내 생각을 맞출 필요가 없다. 내 생각과 실제 프로그램의 갭이 줄어든다.

• Lisp은 "탐색적 프로그래밍"을 하기에 좋다. 프로그램이 어떻게 돌아갈지 잘 모르겠다면 일단 앉아서 코드를 쓰고 대화식으로 이걸 천천히 키워나갈 수 있다.

  • Smalltalk를 하면서 이게 정말 얼마나 좋은지 알게 되었다. Forth는 이게 부족했지만, Smalltalk에는 워낙 많은 브라우저가 있었고, 특히 Smalltalk 자신이 대부분 Smalltalk로 쓰여있었다. 그래서 언어의 예시는 그 언어 구현에서 찾아볼 수 있다. 그래, 이게 Lisp에도 가능하다는 건가?
  • 대화식으로 코드를 짜는 게 이제는 특별한 것도 아니다. Python과 같은 스크립트 언어는 말할 것도 없고, Swift는 아예 Playground까지 있으니까. 꽤 오래된 컴파일 언어 중에 Haskell 이 REPL을 지원한다는 건 지금 생각하면 굉장히 놀라운 일이다. 음, C나 Rust 는 이런 대화식 기능을 제공하지는 않지만 워낙 IDE 지원이 강력해서 나쁘지 않다. —그래도 확실히 Playground가 있는 게 좋다.—

• Lisp은 동적 자료형 언어이기 때문에 일단 코드를 쓰고 에러 처리는 대화식으로 할 수 있다.

  • 이게 결코 좋아보이지 않는다. 결국 Python도 그랬고 JavaScript도 TypeScript를 도입한 것처럼, 이제는 정적 자료형 언어가 결코 유연성이 나쁘지 않다. 깐깐하기로 소문난 Haskell이지만 이제는 자료형 추론 덕분에 굉장히 탄탄하게 프로그램을 짤 수 있다. Lisp이 어떤 특성이건 추가할 수 있다면 이런 정적 자료형 시스템도 추가되어 있을까?

• 언어에 대한 변화가 전체에 파급될 수 있도록 할 수 있다....OOP도, FP도 심지어 AOP(Aspect-)도 언어에 기능을 추가하는 라이브러리로 이게 가능하다는 뜻.

  • 그러니까 언어 명세를 수정할 필요 없이 언어가 동작하는 방법을 수정하거나 새로운 방법을 만들게 되면 기존의 소스 코드를 많이 수정하지 않고도 기능을 확장할 수 있다는 말 같다. CLOS라는, Common Lisp Object System이 원래는 없었는데 Common Lisp에 이게 추가된 이후로 굉장히 편해졌다 뭐 그런 느낌인 듯. 결국 이런 특성 때문에 1956년에 만들어진 케케묵은 언어에 OOP와 FP가 가능한 건지도 모릐ㅈ.

어디서 났죠? (Lisp의 역사)

• 1956년 존 맥커시가 Lisp 개발. List Processing의 약자였다고.