2010년 11월 24일 프로그래밍 언어를 설계한다는 것
공부하는 겸 만드는 거면 아무래도 상관 없지만, 현실적으로 프로그래밍 언어를 만들려면 그게 다른 언어랑 비교했을 때 무슨 장점을 가지는가에 대해서 숙고할 필요가 있다.
학계에서 만들어지는 양산형 연구용 언어들은 보통 정확히 한 가지 특출난 기능을 가진 것이 보통인데, 이런 언어들은 해당하는 기능에 대해서는 분명 특출나지만 다른 것들은 구려서 사용하기는 어려운 것들이 꽤 있다. 반대로 업계에서 필요에 따라 만들어지는 언어들은 유명하면 유명할 수록 특출나지 않는 경우가 많은데, 이는 학계에서 연구되는 새로운 기능들과 개념들이 잘 다듬어지지 않은 건 둘째치더라도(사실 모르는 경우가 더 많지) 여러 개의 서로 상충될 수 있는 기능을 조율하다 보면 특출난 기능들이 점차 깎여 나가기 때문에 그런 것이다. 어느 쪽이 더 만들기 어려운지는 사람들의 취향에 따라 다르지만 적어도 나는 후자가 더 어려운 것 같다.
물론 연구용 언어가 이미 기존에 잘 자리잡힌 언어를 확장하는 식으로 구성되면 많은 문제가 해결된다. 예를 들어서 Typed Scheme같이. 하지만 이 역시 기능들이 서로 상충되는 문제를 해결하기에는 역부족이다(Typed Scheme은 애초에 동적 타이핑이던 것에 타입을 추가한 것이므로 상관 없었지만). 이 때문에 자바 같이 언어는 구리지만(?) 굉장히 넓은 베이스를 가진 언어를 확장하는 식으로 구성된 연구용 언어가 참 많다—대표적인 예를 들자면 역시 스칼라가 아닐까 싶다. 이 관점으로 보면, JVM과 CLR 같은 괜찮은 추상화된 환경이 널리 퍼져서 그냥 얘네랑 호환되게만 만들어도 웬만한 잇점을 다 가져갈 수 있다는 게 얼마나 큰 축복인지 현대의 프로그래밍 연구자들은 절실히 느끼고 있을 것이다.
왜 내가 이런 얘기를 하냐 하면, 내가 처음으로 프로그래밍 언어에 손을 댔을 적에는 나도 굉장히 뜬구름잡는 목표로 언어를 설계했었기 때문이다. 시간이 지나면서 이런 목표를 특정한 기능의 집합으로 재구성해야 한다는 것을 깨닫고, 기능들이 서로 충돌이 나지 않게 하는 게 얼마나 어려운 일인지 느껴 왔으며 지금도 잘 느끼고 있다(…). 거꾸로, 언어의 개별 기능이 아니라 전반적인 언어 설계에 대한 연구도 분명 진행되었을 법 한데 왜 나는 못 찾는 건지 모르겠다. 아무튼 언어 설계에 대한 괜찮은 해결책이 나오지 않는 한, 프로그래밍 언어 개발에 관심을 가진 모든 독자들에게 나는 구체적인 기능 하나를 먼저 설계해 볼 것을 권하는 바이다. 내가 옛날에 그랬듯 “좀 더 편리한 언어” 같은 두루뭉술한 목표 말고 말이다.
