2010년 7월 24일
…아는 사람은 알겠지만 아래 글은 IRC에서 누가 이 얘기를 꺼내길래 오후 11시 25분에 “이거 저널로 써야지ㅋ”라는 생각으로 쓴 것이다. (뒤따르는 반응은 “근데 자정 얼마 안 남았는데?” “헐퀴”) 그런 고로 원래 쓰려고 했던 내용이 좀 빠져 있는데(…) 마저 쓰기로 하자…
옛날 언어 이름이 두문자어, 두문자어에서 유래한 이름(FORTRAN 따위를 생각해 보라) 또는 한 글자짜리 이름(…)이었던 반면, 요즘 언어 이름은 두문자어가 아니면서 적절한 의미를 가지는 이름이 폭발적으로 증가한 것 같다. 가장 큰 이유는 역시 “구글에서 검색했을 때 이것만 나와야 한다”라는 조건일테고1 그러면서도 읽기 좋아야 한다는 것일텐데, 안타깝게도(?) 짧은 이름을 가진 언어 이름은 이미 많이 선점된 상태라 최대한 창의성을 발휘해야 하는 것 같다. (난해한 프로그래밍 언어 중에 TMMLPTEALPAITAFNFAL이라는 거지같은 이름을 쓰는 경우는 있긴 한데…) 이보다 좀 더 어려운 문제를 고르자면 언어 소스 코드의 확장자가 있겠는데, 이를테면 내가 만드는 나루의 경우 일단 .n을 잡고 있지만 이 확장자는 사실 Nemerle에서 잘 쓰고 있는 확장자라 쓰기가 꺼려진다. 읔. 그냥 포기하고 .na를 쓸까.
비단 언어 이름 뿐만 아니라 프로젝트 이름을 정하는 데도 비슷한 문제가 있는 것 같다. 나 같은 경우 내부적으로 몇 개의 이름 풀(naming pool)을 만들어서 쓰고는 있는데2 프로젝트 성격과 아예 관계 없는 이름을 쓰는 것도 좀 애매해서 여전히 어려운 일로 남아 있다. 실제로 이번에 논문 쓰고 있는 주제는 QuickCheck를 Fortress에 포팅하는 얘긴데 (지금 생각해 보면 Fortress도 잘 지은 이름이다!) 창의적인 이름을 생각해 낼 수 없어서 결국 FortressCheck이라는 이름으로 귀결될 예정이다. 생각해 보니 스칼라쪽 포팅도 Scalacheck이었지만… orz
