Lisp는 왜 읽기 어려울까?

Lisp가 읽기 어려운 이유는 단순히 익숙함의 문제만이 아니라, 괄호 배치가 시각적 그룹화와 작업 기억에 주는 부담에도 있을 수 있음 C 스타일의 함수(인자)는 관련 요소를 가까이 묶지만, Lisp의 (함수 인자)는 함수 이름까지 괄호 안에 넣어 괄호 사이가 멀어지고 구조를 한눈에 파악하기 어려워질 수 있음 중첩이 깊을수록 머릿속에 기억해야 할 구조가 늘어남. f(a)(b)(c)처럼 괄호를 겹치지 않고 호출을 이어 쓰는 표기는 이 부담을 줄일 수 있음 읽는 순서와 실행 순서가 다르면 식을 거꾸로 읽거나 바깥 호출을 기억해야 함. 메서드 체인과 Clojure의 스레딩 매크로는 작업 순서대로 코드를 읽게 해줌 읽기 좋은 문법은 괄호가 적은 것만으로 결정되지 않으며, 관련 요소의 거리, 코드의 시각적 모양, 중첩 깊이와 읽는 순서를 함께 고려해야 함 익숙함을 넘어 괄호 배치 살펴보기 Lisp의 괄호 중심 문법은 Python, Java, C보다 읽기 어렵다는 인식을 받아왔고, 채택을 돕기 위한 대체 표기법도 여러 차례 만들어졌음 Lisp 개발자들은 흔히 익숙해지면 괄호를 의식하지 않게 된다고 말하지만, 인간의 지각과 기억을 함께 살펴보면 더 읽기 편한 문법을 설계할 단서를 얻을 수 있음 일반적인 Lisp 코드는 문장, 표현식, 함수 호출을 모두 (operation arguments...) 형태로 작성함 Scheme과 JavaScript의 재귀 팩토리얼 함수를 비교하면, Lisp에는 n == 1 같은 중위 표기, else 같은 키워드, {} 같은 별도 구분자가 없음 이런 차이도 가독성에 영향을 주지만, 익숙함을 제외하면 (- n 1)이 (n - 1)보다 명백히 열등하다고 보기는 어려움 비교의 중심은 일반 함수 호출에서 operation(arguments...)와 (operation arguments...)의 차이임 C 스타일 언어의 다양한 표기 형태가 주는 효과는 중요할 수 있지만, 별도의 후속 탐구 대상으로 남겨둠 인간 지각의 ‘하드웨어 가속’ 인간 지각은 모든 입력을 똑같이 처리하지 않음. 스트루프(Stroop) 효과에서는 글자의 색과 적힌 색 이름이 다르면 실제 표시 색을 말하는 데 시간이 더 걸림 팝아웃 효과(pop-out effect) 를 활용하면 데이터 속 이상치를 훨씬 빨리 찾을 수 있음 일반 데이터에서의 탐색은 약 O(n), 시각적으로 두드러지게 만든 데이터에서는 O(1)에 비유할 수 있음 서로 다른 모양...