맥락 속에서

Lobste.rs 의견들 요약하면 Clojure에 구조 분해 기능이 추가됨. 발표에서는 대부분의 프로그래머가 현실의 활동을 추적하고 의사결정을 지원하는 ‘정보 프로그램’을 만든다고 봄. 이런 프로그램은 게임처럼 실행 도중 환경이 급변하기보다는 전제가 비교적 명확하고, 여러 프로그램이 같은 데이터 형식을 생성·조회·저장하며 함께 사용하는 경우가 많음. 정보 프로그램은 정답을 반환하는 것 외에도 형식, 올바른 절차, 전달 경로 등 챙겨야 할 것이 많음. Hickey는 정적 타입이 내부적인 작동 기제를 구현하는 데는 뛰어나지만, 이런 정보 처리에는 잘 맞지 않는다고 봄. 데이터베이스에 열 하나를 추가할 때 모든 프로그램을 고쳐야 한다면 곤란함. USB-C 위에서 다양한 프로토콜이 동작하듯, 유연한 시스템은 데이터 형식을 처음부터 맞히지 못할 가능성을 받아들이고 수정할 여지를 줌. 자연과 인터넷처럼 성공한 대규모 시스템은 동적이라는 관점임. 여러 언어와 데이터 형식을 연결해야 하는데, 해시 테이블처럼 매일 필요한 기본 수단조차 주지 않는 언어를 쓸 이유가 있을까? Clojure는 이런 불일치를 다루는 데 강점이 있음. 이후에는 과거 발표의 논점을 되짚으며, 맥락의 어원인 ‘함께 엮기’가 복잡함과 같다는 이야기도 함. :keys!로 필수 키를 검사하면 요구 사항을 명시하고 문서화할 수 있음. spec 같은 스키마 도구에 모든 누락을 오류로 판정하길 기대하기보다는, “내가 필요한 것을 제공해야 한다”는 방식으로 접근함. 해시 맵이나 테이블 전체가 바뀌어도 각 프로그램이 필요한 키와 열만 조회한다면 계속 작동할 수 있다는 뜻으로 이해함. selection 예제에서는 name, city, nickname을 바인딩하면서, 루트의 :first-name, :address, :nickname, :id와 :address 내부의 :city, :zip을 선택함. 선택하는 필드와 지역 변수로 바인딩하는 필드가 반드시 같지는 않음. 배열 언어를 통한 내 테이블 집착도 같은 생각에서 비롯됨. 다만 ‘선택’을 이야기한다면 왜 select 함수를 만들지 않을까? Rich도 거의 거기까지 온 듯함. @internet_janitor는 Decker/Lil에서 이를 잘 구현했고, 여러 곳에서 그 장점을 설득력 있게 보여줌. 영상에서 말하는 대상은 전체 프로그래머가 아니라 Clojure 프로그래머 대다수라고 이해함. 다른 종류의 코드를 작성하는 집단의 규...