단순한 프로그램이 꼭 작은 것은 아니다

프로그램의 단순함은 코드나 도구의 크기가 아니라, 서로 다른 기능과 개념이 불필요하게 얽히지 않은 상태를 뜻함 Unix 파이프라인은 작은 도구를 조합하지만 sort | uniq --count처럼 집계와 정렬이 결합돼, 출력 순서만 바꾸려 해도 임시 파일과 정렬, 조인이 필요해짐 반대로 큰 프로그램도 단순할 수 있으며, Google Drive for Desktop은 방대한 내부 구현을 감춘 채 사용자에게 폴더와 저장 방식만 선택하도록 함 데이터 표현과 타입 검사의 관계도 결합의 사례로, Rust 구조체는 둘을 하나로 묶지만 Clojure와 Typed Racket은 별도의 계층으로 분리할 수 있음 자원이 부족하면 작은 프로그램이 유리하지만, 숨은 의존성을 줄이기 위해 더 큰 구현을 감수하는 편이 결과적으로 더 단순한 시스템을 만들 수 있음 작은 Unix 도구가 단순하지 않은 이유 해결에 9개월이 걸린 코드 커버리지 버그를 계기로, 복잡한 도구와 컴퓨팅 방식을 다시 생각하자는 답보다 구체적인 단순성의 기준이 필요해짐 README의 단어 빈도를 계산하는 짧은 Unix 파이프라인은 다음 단계를 조합함 cat으로 파일을 읽음 tr로 단어 경계를 줄바꿈으로 바꾸고 대문자를 소문자로 변환함 sort와 uniq --count로 빈도를 계산함 다시 정렬해 빈도순으로 출력함 같은 작업을 수행하는 Clojure 프로그램은 이름과 고차 함수를 더 사용하지만, 결과를 원래 파일에 등장한 순서대로 출력하도록 비교적 쉽게 변경할 수 있음 단어 순서열을 word_seq에 저장함 각 단어의 빈도 맵을 freq_map에 저장함 중복을 제거한 원래 순서열을 순회하며 빈도를 조회함 Bash에서 같은 변경을 구현하려면 여러 임시 파일과 불투명한 정규식, 정렬, 텍스트 파일 조인이 필요함 최초 Unix 파이프라인은 작지만 단순하지 않았기 때문에 작은 요구사항 변경에도 구현이 크게 복잡해짐 단순함은 결합되지 않은 상태 Simple Made Easy의 Rich Hickey는 simple의 어원인 sim-plex를 하나의 가닥만 가진 상태로 정의하고, 여러 가닥이 엮인 com-plex와 대비함 발표 전문도 제공됨 모호성을 피하기 위해 여기서는 복잡함을 결합(coupling) 으로 다룸 Unix 파이프라인의 핵심 결합은 sort | uniq --count에 있음 uniq는 반복 행이 인접하지 않으면 감지하지 못하므로 먼저 정렬해야 함 Unix에는 Clojur...