리스프는 왜 읽기 어려운가에 대한 반론 — 사람의 적응력은 생각보다 뛰어납니다

AI 요약

리스프(Lisp)는 괄호가 많아 읽기 어렵다는 평가를 자주 받습니다. 이 글은 그 어려움이 괄호 자체의 문제라기보다 낯선 문법에 익숙하지 않은 데서 비롯한다고 반박합니다. 저자는 인지과학을 공부한 경험과 오랜 리스프 사용 경험을 바탕으로, 사람이 새로운 언어나 표기법에 적응하면 처음에는 의식하던 요소를 나중에는 거의 보지 않게 된다고 설명합니다.

괄호보다 들여쓰기를 읽습니다

저자는 리스프를 처음 보는 사람은 닫는 괄호가 이어지는 코드에서 괄호 수를 의식하지만, 익숙한 리스프 프로그래머는 괄호를 하나씩 세지 않는다고 말합니다. 구조를 파악할 때는 들여쓰기에 크게 기대며, 괄호가 모두 맞아도 들여쓰기가 엉망이면 코드를 읽기 어렵습니다. 반대로 괄호가 일부 어긋나도 들여쓰기가 적절하면 의도한 구조를 알아볼 수 있다고 설명합니다. 이는 리스프 코드의 실제 읽기 방식이 괄호 맞추기보다는 시각적 구조 파악에 가깝다는 주장입니다.

인수 사이의 간격과 표현식의 모양도 읽기에 영향을 줍니다. 저자는 리스프 예시를 적절히 줄바꿈하면 각 인수가 눈에 들어오며, 같은 중첩 호출도 C 표기보다 괄호가 있는 리스프 표기에서 인수 구분이 분명하다고 봅니다. 조건식의 경우에도 리스프 독자는 괄호를 눈여겨보기보다 if 뒤에 조건, 참일 때 값, 거짓일 때 값이 오는 구조를 익혀 읽는다고 설명합니다. 다만 잘못된 들여쓰기와 깊은 중첩은 리스프에서도 읽기 어려운 문제라고 인정합니다.

괄호가 편집을 돕습니다

글은 함수형 스타일의 중첩이 작업 기억에 부담을 줄 수 있다는 점을 짚으면서, 리스프의 스레딩 매크로(threading macro)를 쓰면 데이터가 처리되는 순서에 맞춰 코드를 배치할 수 있다고 설명합니다. 반환값을 중심으로 안쪽부터 읽는 방식과, 입력을 받아 처리하는 순서대로 읽는 방식 가운데 선택할 수 있다는 취지입니다. 리스프가 함수형 프로그래밍에만 쓰이는 언어도 아니라고 덧붙입니다. Common Lisp는 절차형, 객체지향, 메타프로그래밍 등 여러 방식으로 사용할 수 있습니다.

괄호의 실용성은 편집기에서도 드러납니다. Emacs에서 코드 블록을 붙여 넣고 Tab을 누르면 문맥에 맞춰 들여쓰기가 정리됩니다. 블록을 잘라 다른 위치에 붙여도 구조에 맞게 다시 정렬할 수 있습니다. 저자는 편집기가 괄호를 바탕으로 코드 구조를 파악하기 때문에 이런 작업이 가능하다고 봅니다. 괄호는 매크로에서 코드와 데이터를 같은 구조로 다루게 해주는 요소이기도 합니다.

저자는 독자에게 리스프를 반드시 쓰라고 권하지는 않습니다. 취업이나 수입에 도움이 된다고 장담하지도 않습니다. 다만 익숙하지 않은 문법에 적응할 수 있다는 점을 강조하며, 리스프를 배우면 코드를 줄이나 블록이 아니라 트리와 표현식으로 바라보는 관점도 얻을 수 있다고 말합니다. 다른 언어가 리스프처럼 편집하기 좋은 구조를 원한다면 괄호를 쓰거나, 괄호를 희미하게 표시하는 편집기 기능을 제공하는 방안도 제안합니다.

Reddit 반응

• @u/initial-algebra — 중복 괄호가 외부 코드를 편집기에 붙여 넣고 서식을 정리하기 편하게 만드는 용도뿐이라면, 오히려 단점이라고 보겠습니다. 들여쓰기로 코드를 읽어야 한다면 들여쓰기가 언어 문법에 포함되어야 합니다.
  • @u/digikar — 이를 대신할 문법은 여러 차례 제안됐습니다. 편집기 확장으로 서로 전환하거나, 한 표기법에서 다른 표기법으로 변환하는 기능도 만들 수 있습니다. 개인적으로는 그런 대안 대부분보다 리스프, C, 파이썬을 읽고 싶습니다. Dylan은 괜찮은 대안이고 Wisp와 sweet expressions도 흥미롭습니다. 괄호가 제공하는 편집 기능도 더 많이 다루지 못했습니다.
  • @u/thehenkan — 리스프 문법을 좋아하지는 않지만 그 주장에는 동의하지 않습니다. 일반 텍스트 편집기에서 코드를 대충 잘라 붙인 뒤 자동 서식을 적용해도 의도한 의미가 유지되지 않는다면, 그 문법은 너무 취약합니다.
  • @u/stylewarning — 문법 자체를 프로그래밍할 수 있는 경우에는 그 방식이 대단히 번거로워집니다. 리스프는 실제로 문법을 프로그래밍할 수 있습니다.
  • @u/initial-algebra — 왜 그런가요? 중요한 들여쓰기와 줄바꿈을 괄호 삽입으로 해석하면 결과는 같을 수 있습니다. 매크로와도 무관합니다.
  • @u/stylewarning — 매크로와 관련이 있습니다. LOOP 같은 일부 DSL은 키워드 중심의 작은 언어라서 (연산자 피연산자...) 형식을 따르지 않습니다. 이런 DSL에서 보이지 않는 괄호가 임의로 생기지 않도록 별도 문법을 추가하지 않으면 읽기 좋은 코드를 쓰기 어렵습니다. 문자 입력을 읽을 때 무엇이 리스프 목록인지, 들여쓰기된 형식이 앞의 기호에 속하는지 어떻게 알 수 있을까요? 재귀적인 읽기나 사용자 정의 리더 매크로와는 어떻게 맞물릴까요? 단일 원소 목록은 어떻게 표현할까요? 해결할 수는 있겠지만 번거롭고 오류가 나기 쉬우며, 어휘 규칙의 예외가 많아집니다. 준인용(quasiquotation), cons나 벡터 같은 비목록 리터럴도 다시 만들어야 합니다. sweet expressions 같은 방식은 수십 년 동안 시도됐지만 Common Lisp에서 더 나은 선택임을 입증하지 못했습니다.
  • @u/digikar — 계속 반복해서 시도해 볼 수도 있습니다.
  • @u/church-rosser — Common Lisp를 오래 써 온 사람으로서 말하자면, 괄호는 대체로 미학에 관한 설계 선택입니다. 가장 큰 이유는 괄호가 시각적으로 중첩을 잘 나타내기 때문입니다. 존 매카시도 그렇게 말했습니다. 그와 별개로 괄호는 Lisp의 S-expression이 처음 의도한 것보다 훨씬 많은 일을 합니다. Lisp는 괄호 문법 덕분에 동형성(homoiconic)을 띠며, 사람과 런타임 모두 코드를 데이터처럼 다루기 쉽습니다.
  • @u/dgkimpton — 이 글을 보고 저만 그런 생각을 한 게 아니군요. 결국 대부분의 괄호는 빈약한 문법과 파서의 목발일 뿐이라고 전달한 셈입니다.
• @u/FransFaase — 십 대 때 LISP를 많이 쓰면서 닫는 괄호가 몇 개 필요한지 머릿속으로 세는 습관이 생겼습니다. 코드의 특정 지점에서 필요한 닫는 괄호 수를 그냥 알게 됐습니다.
  • @u/hugogrant — 저에게는 그게 사실상 들여쓰기 단계였습니다. 닫는 괄호를 맞출 때도 먼저 들여쓰기를 했습니다.
• @u/L8_4_Dinner — 반론까지 쓸 필요는 없습니다. Lisp를 좋아하는 사람이 있고, 괜찮습니다.
  • @u/omegafixedpoint — 저는 문법이 미적으로 마음에 듭니다. 제가 이상한 건가요?
  • @u/omegafixedpoint — S-expression을 보면 추상 구문 트리(AST)를 거의 그대로 보는 점이 좋습니다.
  • @u/L8_4_Dinner — 컴파일러라면 도움이 되겠죠. 70년도 넘게 지나도록 널리 퍼지지 않은 데는 이유가 있습니다.
  • @u/stylewarning — Common Lisp와 Clojure는 여전히 상업적으로 쓰이고, Racket은 학교에서 가르칩니다. 꾸준히 도구를 개발하는 오픈소스 생태계도 있습니다. Lisp가 2026년의 Python은 아니지만, 70년 동안 이어져 왔고 역사책의 각주로만 남은 것도 아닙니다. Lisp 매크로는 보통 작은 DSL을 위한 작은 컴파일러라고 볼 수도 있습니다.
  • @u/extraordinary_weird — 이 논의는 Lisp에만 국한된 건 아니지 않나요? 다른 언어도 이 문법을 도입해야 한다는 주장일 수 있습니다.
• @u/Clementsparrow — 사람들이 적응할 수 있다는 말은 수십 년간 사용성이나 인간-컴퓨터 상호작용(HCI/UX)을 무시할 때 되풀이됐습니다. 적응은 가능하지만 많은 사람이 힘들어하고 그 과정에는 비용이 듭니다. 다른 선택지가 없다면 모를까, 사용자에게 그 부담을 지우면 안 됩니다. 문법에는 ‘터무니없이 멍청한 괄호’보다 나은 선택지가 있습니다.
• @u/poralexc — 같은 맥락에서 표현식 트리의 순서를 바꾸는 법에 적응하는 것보다, Forth처럼 후위 표기(postfix)로 바로 쓰는 편이 제 마음에는 더 쉽습니다.

원문: Reddit / 번역·요약: Trawling