프로그래밍 언어를 제대로 설계하자! (2024)

새 프로그래밍 언어는 여러 줄 문자열, 경로, 확장 가능한 문법처럼 이미 해법이 있는 문제를 초기에 다뤄야 함. 사용자가 생긴 뒤에는 하위 호환성 때문에 수정이 어려워짐 설정 파일의 상대 경로는 해당 파일이나 명확히 정의한 프로젝트 루트를 기준으로 삼고, 파일 확장자는 일관되게 정해 기존 편집기와 검색 도구에서 사용하기 쉽게 해야 함 개발 중 코드와 릴리스 코드는 작업 방식과 실행 환경이 다르므로, 언어와 도구가 두 흐름을 모두 존중해야 함 버전 간 코드 테스트와 라이브러리 버전 표현에는 더 나은 지원이 필요함. 버전 번호는 수학적으로 정확한 추상화가 아니라 판단이 개입하는 불완전한 소통 수단임 파일 변경 감시와 검색 도구 통합은 빌드 시스템 차원의 지원이 중요함. 파일 목록뿐 아니라 의존 관계, 파일 추가, 설정 변경까지 다뤄야 제대로 작동함 여러 줄 문자열의 들여쓰기는 초기에 해결해야 함 코드에 여러 줄 문자열을 넣을 때 현재 들여쓰기 수준을 무시하고 문자열 원문을 왼쪽 끝부터 작성해야 하는 문제는 이미 해법이 있음 Dhall은 이 문제를 상당히 잘 해결했고, Nix/Lix도 비슷한 규칙을 사용함 다만 Dhall의 이스케이프 규칙에는 아쉬움이 있음 JavaScript 템플릿 리터럴용 Ve.dedent에도 비슷한 로직이 구현돼 있음 PureScript 등에서는 소스 텍스트와 이스케이프/보간된 텍스트를 구별할 수 없어 체계적인 구현이 훨씬 어려움 언어에 내장된 해법과 달리 일부 사례에서만 작동하는 도구에 머물기 쉬움 들여쓴 여러 줄 문자열은 초기에 몇 시간을 더 들여 해결할 수 있지만, 나중에는 하위 호환성 문제가 수정을 가로막음 상대 경로와 파일 확장자는 예측 가능해야 함 파일 경로는 경로가 적힌 파일이나 명확히 정의한 프로젝트 루트를 기준으로 해석해야 함 주로 설정 파일에 해당하는 원칙이며, 실행 중인 프로그램은 보통 작업 디렉터리를 기준으로 해도 괜찮음 임포트 경로는 예측 가능해야 함 Docker Compose와 Rust Cargo의 설정 파일은 이 원칙을 제대로 따르지 않음 처음부터 올바르게 설계하거나, 나중에 바꿀 수 있는 확실한 버전 관리 방침을 마련해야 함 초기 설계에 충분히 신경 쓰지 않은 언어는 이런 변경을 감당할 버전 정책도 부족한 경우가 많음 새 언어는 기존 생태계에 들어가는 입장이므로, 확장자 한두 개를 정해 일관되게 사용해야 함 IDE와 온라인 코드 뷰어/코드 호스팅 서비스의 구문 강조는...