Lisp로 가는 길: 왜 Lisp인가

 (scotto.me)
10P by GN⁺ | ★ favorite | 댓글 2개
  • Lisp는 괄호 문법보다 언어를 문제에 맞게 확장하는 사고방식이 핵심이며, REPL·패키지·심볼·조건·재시작까지 익혀야 진가가 드러남
  • 코드와 데이터가 모두 리스트로 표현되는 동형성 덕분에, 매크로는 평가 전 코드를 데이터처럼 다뤄 새 제어 구조와 문법 추상화를 만들 수 있음
  • Common Lisp에 없는 while도 defmacro로 추가할 수 있지만, 함수로 흉내 내면 인자가 즉시 평가되어 body가 코드가 아니라 값이 되는 차이가 생김
  • Lisp 개발은 실행 중인 프로세스에 코드를 계속 평가하는 REPL 주도 개발에 가까워, 함수·매크로·변수를 재정의하며 프로그램을 중단 없이 진화시킬 수 있음
  • 언어 확장성과 라이브 시스템이 결합되면 내부 DSL을 사용자에게 노출하는 확장 가능한 소프트웨어를 만들 수 있고, AutoLISP와 Emacs가 대표 사례임

Lisp가 요구하는 다른 프로그래밍 감각

  • Lisp를 처음 접한 프로그래머는 괄호가 많은 문법, 독특한 들여쓰기, format의 첫 번째 인자로 표준 출력을 지정하는 방식에서 낯섦을 느낌
  • Lisp를 익히려면 코드 읽기뿐 아니라 패키지와 심볼, 프로젝트 생성, 라이브러리 가져오기, REPL, 조건과 재시작까지 다뤄야 함
  • 더 큰 변화는 알고리듬을 구성하는 방식에서 나타남
    • Lisp는 다른 언어에서 하기 어려운 일을 가능하게 만들고, 알고리듬의 형태도 달라지게 함
    • 문제에 맞춰 언어를 먼저 키운 뒤, 그 언어로 프로그램을 작성하는 흐름으로 이어짐
  • Blub paradox는 덜 강력한 언어만 써 본 프로그래머가 Lisp의 강점을 알아보기 어려운 이유를 설명하는 개념임

확장 가능한 언어

  • Lisp는 스스로를 확장할 수 있으며, Lisp 전문가들은 이를 programmable programming language라고 부름
  • 핵심 도구는 macro임
    • C, Rust, Swift의 매크로처럼 반복 코드 제거에만 머물지 않음
    • Lisp 매크로는 언어의 일부가 되는 새 구성 요소를 만들 수 있음
  • Common Lisp에는 기본 while 연산자가 없지만, defmacro로 직접 추가 가능함
(defmacro while (condition &body body)
  `(loop while ,condition do
     (progn ,@body)))
  • 이 while 매크로는 condition이 참인 동안 body의 여러 명령을 실행함
    • loop는 복잡한 반복을 작성하는 매크로임
    • progn은 여러 표현식을 순서대로 실행하고 마지막 표현식의 결과를 반환함
  • 결과적으로 (loop while ... do (progn ...)) 대신 (while ...) 형태를 쓸 수 있어, 코드가 짧아지고 C의 while과 비슷한 구조가 됨

매크로와 함수의 결정적 차이

  • 같은 동작을 함수 fake-while로 만들면 실패함
(defun fake-while (condition body)
  (loop while condition do
    (funcall body)))
  • fake-while 호출에서는 인자가 먼저 평가됨
    • condition은 참값 t가 됨
    • progn 내부의 (print counter)가 실행되고 (decf counter)가 2를 반환함
    • body는 코드 블록이 아니라 값 2가 됨
  • 이후 funcall은 함수를 기대하지만 2를 받기 때문에 The value 2 is not of type FUNCTION 같은 타입 오류가 발생함
  • 반면 매크로 while은 condition과 body를 즉시 평가하지 않고 보존함
    • macroexpand-1로 확장 결과를 확인할 수 있음
    • 컴파일러는 확장된 (LOOP WHILE ... DO (PROGN ...)) 형태의 코드를 받음
  • 매크로는 함수와 달리 인자를 미리 평가하지 않고 순수한 데이터로 다루기 때문에 이런 변환이 가능함

리스트, s-expression, 동형성

  • Lisp 프로그램은 symbolic expression, 즉 s-expression의 연속으로 구성됨
  • s-expression은 두 가지로 나뉨
    • 원자(atom): 숫자, 문자열, 심볼 같은 데이터 단위
    • 리스트(list): 원자나 다른 리스트를 담는 컬렉션
  • Lisp라는 이름은 LISt Processing에서 왔고, 프로그램을 구성하는 명령들도 리스트로 표현됨
  • Lisp에서 리스트는 주요 자료구조이면서 코드 작성 방식이기도 함
    • 코드와 데이터가 모두 리스트로 표현되는 성질을 동형성(homoiconicity) 이라고 함
  • 같은 (+ 1 2) 리스트도 평가 여부에 따라 다르게 동작함
    • (+ 1 2)는 코드로 평가되어 3을 반환함
    • '(+ 1 2)는 평가되지 않고 데이터 리스트 그대로 반환됨
  • Lisp는 Polish notation을 사용해 함수 이름을 리스트의 첫 요소에 두고, 뒤에 인자를 둠
  • 코드와 데이터의 경계가 얇기 때문에 매크로는 소스 코드를 변환할 수 있고, 프로그램을 쓰는 프로그램을 만들 수 있음

매크로가 만드는 코드 추상화

  • 언어를 확장하면 특정 프로그램 영역에 더 표현력 있는 새 구성 요소를 만들 수 있음
  • 반복되는 보일러플레이트는 커스텀 매크로로 대체해 코드를 줄이고 시간을 절약함
  • 새 제어 구조를 만들어 리소스 접근과 폼 평가를 제어할 수 있음
  • 매크로는 코드를 생성하고 성능을 개선하며, 복잡하고 오류가 나기 쉬운 코드를 감추는 문법 추상화를 제공함

Lisp는 라이브 시스템

  • Lisp는 단순한 프로그래밍 언어라기보다 실행 중인 라이브 시스템으로 다뤄짐
  • 일반적인 언어에서는 에디터에서 코드를 작성한 뒤 컴파일하고 실행해 관찰·테스트·디버깅하는 흐름이 많음
  • Lisp에서는 먼저 Lisp 프로세스를 시작하고, REPL에 붙인 뒤, 프로젝트를 그 프로세스 안에 로드함
  • REPL은 Read-Eval-Print Loop의 약자로, 코드를 평가하고 즉시 결과를 보는 대화형 환경임
    • 현재 프로그램을 실행 중인 Lisp 프로세스를 들여다보는 창 역할을 함
  • Lisp 개발자는 실행 중인 프로세스 안에서 코드를 계속 평가하고 결과를 REPL에서 바로 확인함
    • 개별 함수 테스트
    • 데이터베이스 질의
    • 변수 검사
    • 디버깅 같은 작업도 REPL에서 수행 가능함
  • Lisp 프로세스는 멈출 필요가 없어 몇 주 동안 살아 있을 수 있음
  • 함수, 매크로, 변수는 내부 메모리인 환경(environment)에 계속 정의·재정의되며, 이런 흐름을 REPL 주도 개발이라고 부름

Lisp에서의 핫 리로딩

  • 웹 프런트엔드에서는 파일 저장이나 페이지 새로고침을 통해 JavaScript 코드가 핫 리로드되는 경험이 흔함
  • 일반적인 핫 리로딩은 파일 감시, 변경 모듈 재컴파일, 웹소켓을 통한 변경 주입 같은 별도 도구와 기법에 의존함
  • 모든 소프트웨어 스택이 같은 수준의 핫 리로딩을 제공하지는 않음
    • 일부 백엔드 프레임워크는 재컴파일이 필요함
    • 데스크톱과 모바일 개발 환경은 상황이 섞여 있음
    • 저수준 언어는 매번 전체 컴파일이 필요함
  • Lisp에서는 핫 리로딩이 별도 도구가 아니라 라이브 환경에서 코드를 평가할 때 자연스럽게 따라옴
    • 심볼을 재정의하면 함수, 데이터, 매크로 모두 새 정의를 사용함
    • 멈추고 컴파일하거나, 테스트를 별도로 실행하거나, 특수한 디버거를 쓸 필요가 줄어듦
  • Lisp 프로그래밍은 프로그램을 조립한다기보다 진화시키는 방식에 가까움

확장 가능한 소프트웨어

  • 언어 확장성과 라이브 시스템은 Lisp에서 확장 가능한 소프트웨어를 만들기 쉽게 함
  • 일반적인 데스크톱 프로그램은 플러그인이나 스크립팅 언어를 통해 확장됨
    • 개발자는 확장 시스템을 설계하고 유지해야 함
    • 사용자는 플러그인이나 확장 작성을 위한 특정 API를 배워야 함
  • Lisp에서는 매크로로 동작을 캡슐화하고 재사용하기 쉽게 만들면서 자연스럽게 DSL을 작성하게 됨
  • 소프트웨어를 확장 가능하게 만들려면 내부에서 만든 DSL을 사용자에게 쓰게 하면 됨
  • CMS 서버 예시에서는 서버 사이드 웹페이지 생성을 위한 html 매크로를 사용자에게 노출할 수 있음
    • 사용자는 Lisp 변수, dolist 반복, format 문자열 포매팅을 그대로 함께 사용할 수 있음
    • 전통적 템플릿 언어처럼 {{ user_name }}이나 {% for %} 같은 별도 문법을 배울 필요가 없음
  • 이 DSL은 Lisp의 조건문, 재귀, 고차 함수, REPL 단계별 디버깅 능력을 그대로 물려받음
  • 수학 그래프 소프트웨어 예시에서는 수식과 그리기를 위한 DSL을 노출해, 사용자가 곡선과 점을 적은 코드로 그릴 수 있음

실제 사례와 Lisp의 위치

  • AutoCAD는 반복 작업 자동화와 복잡한 기하 생성에 AutoLISP를 사용함
  • Emacs는 자체 Lisp 방언으로 대부분 구현되어 높은 확장성을 확보한 텍스트 에디터임
    • PDF 리더
    • 웹 브라우저
    • 이메일 클라이언트
    • RSS 리더
    • 터미널 멀티플렉서
    • Git 클라이언트
    • 음악 플레이어
    • 채팅 클라이언트
    • 스프레드시트
    • IRC 클라이언트
    • 데스크톱 창 관리자까지 확장된 사례가 나열됨
  • R. M. Stallman은 Lisp를 강력하고 우아한 프로그래밍 언어의 의미를 이해하게 해주는 언어로 평가함
  • Lisp가 언젠가 기본 언어처럼 널리 쓰일 것이라는 기대는 실현되지 않았고, 앞으로도 그럴 가능성은 낮아 보임
  • 그럼에도 Lisp는 1960년대부터 살아남아 Fortran 다음으로 오래된 현역 프로그래밍 언어가 됨
  • Lisp의 가치는 확장성, 대화형 환경, REPL 같은 개별 기능 하나가 아니라 그 조합에서 나옴

함께 보면 좋은 글 β

geesecross   [-]

이 글을 보니 전에 갈무리해 둔 글이 생각나서 업로드해 봅니다.
양극성 LISP 프로그래머

답변달기
GN⁺   [-]
Hacker News 의견들

  • 프로그래밍은 라이트 사이드와 다크 사이드 사이의 긴장 위에 있음
    라이트 사이드는 프로그래머가 실수하지 못하게 막는 쪽임: goto를 없애고, 정적 타입을 넣고, 버그를 표현할 수 없게 만드는 식임
    다크 사이드는 프로그래머에게 힘을 주는 쪽임: 매크로, 연산자 오버로딩, 자기 수정 코드, 여러 줄 정규식까지 마음껏 허용함
    Lisp는 프로그래머가 무엇이든 할 수 있다는 점에서 분명 다크 사이드인데도, 라이트 사이드 프로그래머들에게도 존경받는 점이 흥미로움. 언어의 단순함이 플라톤적이고 거의 타락 불가능해 보이게 하는 것일 수도 있고, 혹은 Lisp가 너무 순수해서 프로그래밍 우주를 낳은 신처럼 양쪽을 모두 품는 것일 수도 있음

    • 동적 타입과 정적 타입 논쟁에서 본 적 있는 말을 바꾸면, 허용적인 언어는 혼자 개발하는 프로그래머에게 힘을 주지만 팀 개발에는 더 제한적인 언어가 필요함
      같이 일할 사람을 고를 수 없고, 팀 안의 실력도 고르지 않음. 덜 숙련된 동료가 실수를 만들 때, 언어가 더 허용적일수록 그 결과가 커짐
      그래서 코드 리뷰가 필요하지만, 그러면 숙련된 프로그래머를 교사로 바꾸게 됨. 다른 프로그래머의 실력을 올리는 데 쓰는 시간이 일부 낭비되는 이유는 프로그래머가 언제든 들어오고 나갈 수 있기 때문임. AI가 이 구도를 바꿀 수도 있음
      결국 핵심은 작고 숙련된 팀을 유지하는 것이지만, 회사 정치 때문에 쉽지 않음. 예를 들어 버스 팩터 고려나 출시 기간 단축을 위해 개발자를 더 붙이는 방식이 자주 나옴
    • Lisp는 대체로 정확한 가비지 컬렉션을 갖고 있으니 라이트 사이드에 가깝다고 볼 수도 있음. 런타임 타입 검사를 타입 안전성으로 친다면 꽤 타입 안전하기도 함
      고신뢰 시스템은 Erlang으로도 작성되는데, 눈을 가늘게 뜨고 보면 또 다른 Lisp 방언처럼 볼 수 있음. Lisp풍 Erlang인 LFE라는 S-표현식 기반 버전도 있음
      Erlang의 신뢰성 핵심은 예외적인 수준의 오류 예방이 아니라 오류 복구에 있음. 라이트/다크 분류 자체는 마음에 듦
    • Lisp의 큰 특징은 가변 변수 대입을 빼면 기본적으로 선언형이고, 명령형 패러다임이 아니라는 점이라고 봄
      정적 타입이 없고 매크로가 난장판이 될 수 있어도, 선언형·함수형 사고의 기준선이 훨씬 강해서 프로그램을 더 명확하게 생각하고 추론하는 출발점이 좋음
    • Malbolge는 어느 쪽에 넣을지 궁금함. Python, Haskell, Idris, Clean, C, K는 또 어느 쪽인가?
      라이트/다크 구분은 너무 단순화한 것처럼 보임. 프로그래밍 언어의 균형은 매우 복잡하고 흥미로운 주제임
      여러 언어를 수년간 실험해 보니 결국 사용 맥락, 개인 취향, 목표의 문제였음. “역대 최고의 프로그래밍 언어” 같은 것은 없고, “라이트 사이드 프로그래밍에 최고”나 “다크 사이드 프로그래밍에 최고”도 없음
      예술 회화에도 라이트/다크 사이드 같은 것은 없음. 분명 더 위대한 그림들은 있지만, 모든 사람이 다른 모든 그림과 비교해 가장 아름답다고 느낄 “최고의 그림”은 없음
      https://en.wikipedia.org/wiki/Malbolge
      https://en.wikipedia.org/wiki/Clean_(programming_language)
      https://en.wikipedia.org/wiki/K_(programming_language)
    • 라이트와 다크를 뒤섞은 것 같음. 창조자가 최고로 안다는 식의 구속과 규율이 다크 사이드이고, 사람에게 힘을 맡기는 쪽이 라이트 사이드임

  • 최근 몇 달 사이 훌륭한 새 편집기와 도구들이 나왔으니 놓치지 말아야 함
    Mine은 단일 다운로드 앱으로, 핫 리로딩과 즉석 디버깅을 포함해 대화형·증분 개발 흐름을 경험하는 데 필요한 모든 것을 제공함. CL과 Coalton용임
    https://coalton-lang.github.io/20260424-mine/
    OLIVE는 VSCode용 수제 플러그인이고, ICL은 터미널과 브라우저용 새 REPL이며 고급 기능을 제공함. 보너스로 JSCL 기반 JupyterLite 커널도 있어서 100% 브라우저에서 실행됨
    모두 여기에서 볼 수 있음: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

    • mine의 소스를 못 찾겠음. 링크가 있나?

  • 웹사이트에 구문 강조 버그가 있는 것 같음. 본문에 포함된 코드 조각이 검은색으로 나오고, 마우스로 선택하면 실제 텍스트를 볼 수 있음
    데스크톱 Chrome과 iPad Safari에서 같은 버그가 보임

    • 배경색을 바꿀 때는 항상 전경색도 함께 지정해야 하는 고전적인 사례임. 안 그러면 검은 배경에 검은 글자 블록이 생김. 브라우저가 다크 모드이면 아마 정상적으로 보일 것임
      우회 방법은 브라우저 디버거에서 코드 요소 하나를 열고 :not(pre) > code 스타일에 color: white를 추가하는 것임
    • 댓글을 읽자마자 오류를 고쳤음
    • MacOS Chrome인가? Linux의 Firefox, Chromium, Brave에서는 코드 블록이 정상으로 보임. 아마 모두 Qt를 쓰는 것 같음
    • Firefox와 Chrome 둘 다에서 같은 현상이 나타남
    • 처음엔 글이 검열된 줄 알았음

  • Lisp의 장점을 찬양하는 글은 많음. Lisp와 그 아이디어, 그리고 언어 생태계에서의 위치를 차분하게 비판하는 글도 보고 싶음
    이런 글이나 여기서 참조하는 PG 글들은 결국 “아는 사람은 안다”에 가까움. 매력도 이해하고, 이 글이 명시적·암묵적으로 하는 주장도 이해함
    컴퓨터 프로그래밍은 지난 60년 동안 꽤 성숙해졌음. 더 숙고된 검토가 담긴 글을 더 보고 싶음

    • 언어로서 Lisp는 훌륭하지만 생태계는 제한적임. 결점은 두 가지가 있음. 하나는 너무 개방적이라 재능과 규율이 없으면 재미있는 Lisp 해킹의 토끼굴에 빠져 실제 일을 끝내지 못할 수 있다는 것임. 다른 언어에도 이런 문제가 있지만 Lisp가 더 심하다고 봄
      두 번째 결점은 충분히 유능한 사람들의 시간을 몇 년씩 잡아먹는데, 결과가 그 투자 시간을 정당화하지 못한다는 점임. Python 같은 것도 충분함. Lisp에 들인 시간 대부분을 다른 데 썼으면 좋았겠다고 생각함
    • “프로그래밍이 꽤 성숙했다”는 표현은 Lisp가 과거 어딘가에 멈춰 있었다는 뜻처럼 들림
      Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton은 비교적 최근 언어이고 지금도 발전 중임. 지금 떠오르는 것만 이 정도이고 훨씬 더 많음
      Lisp는 어떤 의미에서는 프로그래밍 언어가 아니라 아이디어임. 오늘날 우리가 쓰는 거의 모든 프로그래밍 언어에 영향을 줬고 지금도 그러함. 아이디어를 “차분하게” 비판하기는 어렵고, 군론을 비판하는 것과 비슷함. 다만 그 아이디어의 특정 구현이 가진 장단점은 논의할 수 있음
    • Lisp의 저주: https://www.winestockwebdesign.com/Essays/Lisp_Curse.html
    • 오늘날 언어라면 표준화된 동시성은 기본 조건임. CL에는 표준화된 async/await나 동시성 모델이 없음. 표준은 1995년 이후 갱신되지 않았으니 앞으로도 일어나지 않을 것임
    • Lisp에는 일종의 손잡이 방향 같은 게 있는 듯함
      어떤 사람들에게는 정신적으로 매력적으로 느껴짐. 정말 틈새적인 음악 장르에 비유하고 싶음. 좋아하는 사람은 적지만, 그 사람들은 매우 강렬하게 좋아함. 프로그래밍계의 Stockhausen 같은 것임
      기본적으로는 팬덤임. 놀라울 정도로 오래 지속되는 팬덤이지만, 널리 뚫고 나온 적은 없고 앞으로도 그럴 가능성은 낮음. 지금은 위치가 더 나빠졌음. LLM을 무장하고 코드 자체에 별 관심이 없다면, 왜 굳이 Lisp로 작성하라고 시키겠나?

  • Lisp를 너무 오래 해 와서 그 기능들을 제대로 고마워하지 못하게 됨. 그러다 대중적이고 경제적으로 덜 위험한 언어들에서 사람들이 스스로를 망치는 모습을 충격과 공포 속에 보면, 갑자기 다시 Lisp의 가치를 느끼게 됨

  • 상업 현장에서 도메인 특화 언어는 안티패턴임. 누군가 문서가 부족하고 자기만 이해하는 도메인 특화 언어를 만들고 떠나버림
    뒤따라오는 프로그래머들은 이 이상한 언어를 해독하려고 애써야 함. 거의 항상 표준 언어 구조와 기능을 쓰는 편이 더 낫다. 코드는 쓰는 것보다 읽는 일이 더 많음

    • 함수 하나를 만들 때마다 해당 도메인에 특화된 자기만의 언어를 만들고 있는 셈임
      실제로 반대하는 것은 참조 투명성 부족일 가능성이 큼. 공정하게 말하면 Lisp를 포함해 많은 언어에서 문제가 됨
    • Lisp에서는 뒤따라오는 프로그래머들이 그냥 매크로 확장을 보면 됨. 현대 도구로는 원하면 편집기 안에서, 같은 소스 파일의 대체 텍스트로, 살아 있는 Lisp 환경에 연결된 상태에서 볼 수도 있음
      좋은 예가 Common Lisp 자체의 LOOP 매크로임. 누군가의 사용법이 이해하기 어렵다면 Lisp에게 더 장황한 비-LOOP 기본 호출로 확장해 달라고 하면 되고, LOOP를 전혀 이해할 필요가 없음. 실제로 LOOP 폼을 확장된 코드로 교체할 수도 있음
      이는 대부분의 다른 언어에서 도메인 특화 언어 코드가 실제로는 해석되는 자료 구조인 경우와 다른 핵심 차이임

  • Lisps에는 정말 강력하고 독특한 점들이 있지만, 이런 글들이 REPL과 핫 리로딩을 계속 포함하지 않았으면 함
    REPL은 인터프리터 언어들, 심지어 일부 컴파일 언어에서도 이미 오래전부터 기본 조건이었음. 핫 리로딩은 독특하지도 않고 특별히 널리 쓰이지도 않음. 상태와 패치를 다뤄야 하므로, 추론을 쉽게 하려고 전체를 재설정하는 것이 모범 사례로 여겨지는 데는 이유가 있음

    • Clojure를 배우던 시절에는 나도 그렇게 생각했음. 훨씬 나중에야 Lisp 사람들이 말하는 REPL은 보통 명령을 쉽게 평가하는 대화형 CLI라기보다, 실행 중인 애플리케이션의 문맥에서 텍스트 편집기 안의 폼을 빠르게 평가할 수 있도록 프로그램을 살아 있는 세션에 연결하는 능력을 뜻한다는 걸 깨달음
      그래서 다른 인터프리터 언어보다 훨씬 더 대화형 개발이 가능해짐
    • Dart/Flutter에서는 핫 리로드가 매우 널리 쓰임. 반응형 스타일 프레임워크로 UI 코드를 작성하고, UI 렌더링이 “각 프레임마다 새 UI를 처음부터 생성”하는 것처럼 보이는 경우에는 무엇이 다시 로드되고 무엇이 아닌지 직관을 갖기가 더 쉬움
      물론 완벽하지는 않음. 하지만 사용자 경험을 반복 개선할 때 하는 종류의 변경에는 아주 잘 작동함
    • 대체로 동의함
      다만 핫 리로딩의 고급 부분 상당수가 Common Lisp에서 이미 다뤄졌다는 점은 강조할 만함. REPL도 직접 타이핑하는 곳이라기보다, 실행 중인 이미지와 도구가 상호작용하는 매우 강력한 인터페이스로 주로 쓰인다는 점도 마찬가지임
      그래도 이것들이 존재한다는 사실만으로는 오늘날 그리 특별하지 않다는 데 동의함
    • 모든 Lisp 방언이 잘 발달한 핫 패치 시스템을 갖고 있는 것은 아님. 객체 지향 시스템은 이를 위해 신중하게 설계되어야 함
      클래스 정의가 리로드로 대체됐는데 기존 인스턴스가 남아 있으면 어떻게 할 것인가? Common Lisp 방언은 이런 질문에 유용한 답을 갖고 있지만, 마주치는 모든 Lisp가 꼭 그렇지는 않음
      Bash도 핫 리로딩을 지원함. 다음처럼 source해서 제자리에서 갱신되는 모듈을 개발해 본 적 있음
      $ . /path/to/script.sh
    • 일반적으로 핫 패치 처리의 고통은 코드베이스 구조와 핫 패치를 하려는 이유에 크게 좌우됨. 배열 구조 아키텍처나 런타임 논리 오류 수정이라면 별일이 아님
      유용성은 제한적이지만, 많이 쓸 것이라는 관점에서 시작하면 그 제한은 꽤 빠르게 사라지기 시작함

  • 개인적으로는 이런 단계를 넘어섰음. Common Lisp, Forth, Haskell을 써 봤고, 『On Lisp』와 『Let Over Lambda』를 즐겁게 읽었음
    지금은 최고의 프로그래밍 언어가 Barry Jay의 Triage Calculus라고 생각함. 조합 논리나 비타입 람다 계산에 가까움
    하지만 람다 계산과 달리, Triage Calculus에는 Lisp의 CAR와 CDR과 비슷한 내장 인용과 내성이 있어서 타입 검사를 쉽게 추가할 수 있음. 그래서 TC에서는 올바른 추상화를 만들기만 하면 원하는 어떤 문법이든 가질 수 있음. 진정한 궁극의 프로그래밍 언어임
    TC는 프로그래밍 언어 기능과 문법 한편, 표준 라이브러리나 사용자 코드의 함수/API 정의 다른 한편 사이에 있는 구분이 거짓 이분법임을 보여줌. 재사용을 의도한 코드를 작성할 때마다 언어에 무언가를 추가하는 것임. 이 모두는 TC의 어떤 항으로 표현 가능함
    모든 문법 논쟁은 습관의 문제임. 다만 TC에서 정말 원하는 문법 기능 하나는 let over lambda 추상화인데, 조합자를 손으로 정렬하는 일이 다소 귀찮기 때문임

  • 잘 쓴 글임
    예전에는 언젠가 모두가 Lisp를 쓰고, 훌륭한 도구와 라이브러리가 갖춰지면 모든 것이 멋져질 거라고 생각했음. 실제로 은퇴 후 계획도 이 과정을 앞당기기 위해 Lisp 언어용 고품질 라이브러리를 만드는 것이었음
    AI의 부상이 이 꿈을 끝내는 걸까? 또다시 더 많은 잡동사니를 추가해서 문제를 해결한 셈인가? 초지능 AI가 가능한 최고의 프로그래밍 언어로 코드를 쓰는 대신, 그냥 Python 코드를 잔뜩 뿌려서 될 때까지 밀어붙이게 되는 걸까?
    이게 중요한지 모르겠음. 그냥 우아함이 있는 세계를 원했음

    • 최초의 “Interface Builder”가 어떻게 됐을지 늘 궁금했음
      “Jean-Marie Hullot은 INRIA에서 일하던 중 Macintosh용으로 Lisp로 작성한 ‘SOS Interface’를 만들었고, 이것이 최초의 현대적 ‘interface builder’였다”
      https://denninginstitute.com/itcore/userinterface/GUIHistory...
      이것이 NeXT로 넘어가 Objective-C와 함께 쓰이는 대신, 주류 Mac 제품이 됐다면 어땠을까 싶음
      LISP는 나에게 잘 맞았음. 대학의 비교 언어 수업에서 LISP 과제를 모두 해낸 사람은 나뿐이었고, LISP를 배운 것은 TeX를 쓰는 데도 큰 도움이 됨
      바라는 것은 오픈소스인 괜찮은 네이티브 또는 크로스플랫폼 GUI 툴킷과, 프로젝트를 독립 실행 컴파일 코드로 쉽게 배포하는 방법임
    • 언어는 결코 답이 아님. Lisp가 Visual Basic보다 우월한 것은 아님. 둘 다 튜링 완전함
      인간은 둘 모두로 좋은 아이디어를 표현할 수 있음. 언어를 도구로 생각하는 편이 낫다. 임팩트 드릴이 단순 회전 드릴보다 우월한 것은 아님. 데크를 만들 때는 임팩트 드릴이 더 잘 맞겠지만, 둘 다 일을 해낼 수 있음

  • 이 글이 https://web.archive.org/web/20120106121645/http://wiki.alu.o...일 줄 알았음
    comp.lang.lisp를 따라가던 기억이 떠오름. 일종의 드라마 같기도 했음. 프로그래밍 마법뿐 아니라 개성 강한 인물들과 사건도 많았음

답변달기