25년 전 대부분의 프로그램은 GUI를 통한 설정 기능과 도움말을 제공했음. 설정은 ini 파일이나 윈도우 레지스트리에 저장되었으며, 수동으로도 편집 가능했음. 현재는 87MB 크기의 바이너리 형태의 프로그래밍 언어를 사용하여 설정 파일을 생성해야 하며, 이 언어 자체를 실행하기 위해서도 설정 파일을 수동으로 만들어야 함. 이러한 상황에서 500GB 프레임워크가 필요하게 될 것 같은데, 이는 설정 파일을 생성하는 프로그래밍 언어를 위한 것임. 현대 개발자들이 문제를 만드는 데에 종사하는 것처럼 보임.
Pkl은 애플에서 내부적으로 사용되던 최고의 도구 중 하나였으며, 이제 오픈소스로 공개되어 기쁨. 한 팀은 여러 kloc의 k8s 설정을 pkl로 성공적으로 마이그레이션했으며, pkl을 사용하여 두 가지 모니터링 도구를 위한 설정, 정적인 문서 사이트를 생성하고 모두 연결하는 경고 정의를 작성함. 이 도구를 추천하고 싶으며, 다시 사용할 수 있게 되어 흥분됨.
Pkl은 GraalVM Truffle 프레임워크를 사용하여 구축되었으며, Futamura 투영을 사용한 런타임 컴파일을 지원함. 애플과 함께 이 작업을 오랫동안 진행해왔으며, 드디어 소스 코드를 볼 수 있게 되어 매우 기쁨. (GraalVM 개발자의 말)
HTTP 리소스를 가져오고 파일 시스템에서 파일을 읽는 기능과 튜링 완전성은 설정 언어에서 예상치 못한 기능임. 이러한 복잡성이 정당화되는지 궁금함.
문서를 조금 읽어본 결과, 스키마 정의와 최소값 전달자로서의 언어를 만들고자 하는 아이디어에 너무 몰두한 것 같음. 과도한 사용으로 인한 예상치 못한 실패 모드가 우려됨. 그러나 이것이 핵심 기능일 수도 있음: pkl을 소프트웨어에 추가하는 모든 사람은 결과적으로 생성될 설정 괴물에 참여하게 됨. 구조가 없는 혼란보다는 통일된 시스템이 덜 나쁠 것이라는 가정에 기반함.
IntelliJ, Visual Studio Code, Neovim용 플러그인과 확장 기능을 제공하며, 곧 Language Server Protocol 지원이 추가될 예정임. 왜 LSP를 먼저(또는 유일하게) 구현하지 않았는지 이해할 수 없음. 모든 편집기가 LSP를 내장 지원하므로 별도의 구현이 필요하지 않았을 것임.
설정 언어에 대해 오랫동안 고민한 결과, 스키마와의 사랑/증오 관계를 겪은 후, 설정에서 풍부한 타입을 원하지 않는다는 결론에 도달함. 정적 타입의 프로그래밍 언어를 사용하며, 설정 언어에서는 문자열, 배열, 해시맵만을 타입으로 사용하고 모든 타입 검증을 파싱 단계로 밀어내고 싶음.
Cue와 비슷하지만 더 원시적이고, 원칙이 덜하며 Java로 작성되었음.
Pkl이 해결하려는 문제를 이해하는 데 어려움을 겪음. 제목을 읽고 나서 Pkl이 TOML과 같은 새로운, 더 나은 설정 언어라고 생각했지만, 기사를 읽고 나니 Pkl이 설정을 _생성_하기 위한 언어라는 인상을 받음. Pkl은 설정 파일 자체가 아니라, 설정을 더 표준화된 방식으로 구축하고 재사용하는 데 도움이 되는 추상화된 도구로 보임. 예를 들어, 여러 프로젝트에서 공유하거나 반복하고자 하는 Terraform이나 Cloudformation 설정이 있을 때, 가장 쉬운 방법은 다른 프로젝트에서 복사하여 붙여넣고, 몇 줄을 변경하여 프로젝트에 맞게 수정하는 것임. Pkl은 이러한 문제를 해결하는 데 도움이 되는 것인지, 아니면 다른 것을 놓치고 있는 것인지 궁금함.
Hacker News 의견