메아리 저널

유행에 좀 뒤쳐진 감이 있지만 메아리에 서서히 HTML5를 적용하고 있다. 일단 저널에서 article, footer, hgroup 따위를 쓰게 바꾸고 메타데이터 정비하고… 하는 정도인데, 좀 제대로 들여다 봐야 겠다.

원래 HTML5는 인터넷 익스플로러 6이 망할 즈음에 적용을 하려고 미루고 있었지만 이번에 레딧에 영문 글도 올리고 하다 보니까 자바스크립트로 런타임에 메시지 번역을 할 필요성을 느꼈고, 그런데 그렇다고 다국어 메시지를 HTML 컴파일러 단에도 넣고 자바스크립트에도 중복으로 넣는 건 뭐해 보여서 생각하다가 HTML5의 data-* 속성이 생각나서(…) HTML5 적용을 날치기로 결정했다. 기본적으로 정적 HTML 파일로만 구성되는 메아리 메인의 특성상 전체적으로 적용하려면 먼저 저널 등에서 잘 도는지 확인하고 컴파일을 한 번에 해야 해서¹ 메인 사이트까지 전파되는 데는 좀 시간이 필요할 듯.

내가 카이스트에 몇 년동안 살면서 느끼는 건데, 카이스트 네트워크는 카이스트 이름값을 전혀 하질 못하는 것 같아. 내가 학교 네트워크에 무슨 six sigma 가용성을 요구하는 것도 아니고 그냥 “조금 덜” 죽어 줬으면 좋겠는데, 아직도 학교 네트워크는 비만 오면 핑 로스가 눈에 띄게 늘어나고 덕택에 카이스트 FTP도 영향을 받았지. 무슨 니네가 항공업계냐? 폭우 오면 연착하게?

그래도 여기까지는 참을 수 있어. 뭐 비 오면 텔레비전도 잘 안 나오고 사람도 나른해지니까 뭐 그러려니 할 순 있다고. 근데 최근에 무슨 보안 소프트웨어 강제 설치한다고 윈도에서 브라우저 켜면 강제로 접속한 사이트를 프레임에 가두고 팝업을 띄우더라고? 그래서 팝업 차단을 걸면 팝업 안 열었다고 원래 사이트도 접속 못 하게 막고. 이게 무슨 짓이야, 나는 윈도에서 Avast! 깔아서 쓰는데 또 보안 소프트웨어를 깔라고? 심지어 방화벽도 내가 직접 설정하는데 그만 좀 띄우라고 내가 설정하면 그만 띄워 줄 수는 없는 거니? 응?

좋아, 여기까지는 내가 가급적이면 윈도에서 도메인으로 바로 접속하는 걸 피해서¹ 버틸 수 있었어. 하지만… 내가 기숙사에서 아래 글을 쓰다가 글을 한 번 날릴 뻔 한 적 있거든? 그게 하도 이상해서 좀 확인해 봤는데, 이렇게 나오더라.

…그러니까 지금 ||, from, 별표, set이 글에 순서대로 들어 가면 패킷을 친절하게 날려 준다는 거지?² 내가 SQL injection 공격 막는다고 서버 단에서 mod_security 따위 쓰는 건 봤어도 프락시에서 친절하게 막아 주는 미친 놈들은 처음 봤다. 그럼 내가 phpMyAdmin으로 외부에 데이터베이스 접속해서 관리하려고 하는데 저런 패턴이 들어 가면 날아가는 거야? 그런 거야?

아오썅 더 이상 못 참겠다. 내일 정보통신팀 두고 봐라. 내 소중한 다섯 시간을 이거 추적하느라 감쪽같이 날려 줬어. 개새끼들.

Mac OS X’s strftime(3) function has a significant problem with timezones. Intriguingly this very problem is traced back to FreeBSD and tzcode, from which the code in question originates, and due to this problem tzcode fails to process its companion database, tzdata! I’m going to report this bug anyway but it would make a good journal entry…

Start with tzdata. Tzdata is a public-domain timezone database used in the most operating systems including Linux, FreeBSD and Mac OS X. It is kept up to date, and it even tries to record even obscure historic timezone data: for instance you can see solar87 through solar89 files in tzcode, which reflects a Saudi Arabian policy of using mean solar time from 1987 to 1989. (To be exact, it is not in tzdata since it was too large and obsolete.) The ubiquity of tzdata means an error in tzdata file leads to the disaster.

…아는 사람은 알겠지만 아래 글은 IRC에서 누가 이 얘기를 꺼내길래 오후 11시 25분에 “이거 저널로 써야지ㅋ”라는 생각으로 쓴 것이다. (뒤따르는 반응은 “근데 자정 얼마 안 남았는데?” “헐퀴”) 그런 고로 원래 쓰려고 했던 내용이 좀 빠져 있는데(…) 마저 쓰기로 하자…

옛날 언어 이름이 두문자어, 두문자어에서 유래한 이름(FORTRAN 따위를 생각해 보라) 또는 한 글자짜리 이름(…)이었던 반면, 요즘 언어 이름은 두문자어가 아니면서 적절한 의미를 가지는 이름이 폭발적으로 증가한 것 같다. 가장 큰 이유는 역시 “구글에서 검색했을 때 이것만 나와야 한다”라는 조건일테고¹ 그러면서도 읽기 좋아야 한다는 것일텐데, 안타깝게도(?) 짧은 이름을 가진 언어 이름은 이미 많이 선점된 상태라 최대한 창의성을 발휘해야 하는 것 같다. (난해한 프로그래밍 언어 중에 TMMLPTEALPAITAFNFAL이라는 거지같은 이름을 쓰는 경우는 있긴 한데…) 이보다 좀 더 어려운 문제를 고르자면 언어 소스 코드의 확장자가 있겠는데, 이를테면 내가 만드는 나루의 경우 일단 .n을 잡고 있지만 이 확장자는 사실 Nemerle에서 잘 쓰고 있는 확장자라 쓰기가 꺼려진다. 읔. 그냥 포기하고 .na를 쓸까.

비단 언어 이름 뿐만 아니라 프로젝트 이름을 정하는 데도 비슷한 문제가 있는 것 같다. 나 같은 경우 내부적으로 몇 개의 이름 풀(naming pool)을 만들어서 쓰고는 있는데² 프로젝트 성격과 아예 관계 없는 이름을 쓰는 것도 좀 애매해서 여전히 어려운 일로 남아 있다. 실제로 이번에 논문 쓰고 있는 주제는 QuickCheck를 Fortress에 포팅하는 얘긴데 (지금 생각해 보면 Fortress도 잘 지은 이름이다!) 창의적인 이름을 생각해 낼 수 없어서 결국 FortressCheck이라는 이름으로 귀결될 예정이다. 생각해 보니 스칼라쪽 포팅도 Scalacheck이었지만… orz

C 같이 이름이 한 글자인 프로그래밍 언어들에 대한 얘기가 KLDP에서 나온 적이 있었는데 이 참에 좀 제대로 정리해 보기로…

• A: 일단 기괴한 문자 집합으로 유명한 APL(1964)이 원래는 A programming language이라는 책에서 출발했다는 건 유명. 또한 APL의 변종 중에 A+(1988)이 존재하고 이 언어가 옛날에는 A라고 불렸다고 한다. (A stands for “aggressive extensions”) 그 밖에 A++(2001), A#(Ada의 .NET 포트) 따위가 있다고.
• B: C 언어의 선조격인 B 언어(1969)가 있다. 좀 더 말하자면 C 언어는 B에서 유래했고, B는 BCPL(1966)에서, 그리고 BCPL은 다시 CPL(1963)에서 유래했다.
• C: 우리가 잘 알고 있는 C 언어(1972). 여기서 유래한 언어들이 C에 뭔가 기호를 막 붙인 경우가 꽤 있는데 이를테면 C++(1983), C-​-(1997; GHC의 저수준 IL 등으로 쓰임), C#(2001), Cω(2003, C#의 concurrent extension) 따위가 있다. 왠지 C@ 같은 것도 보이지만 눈의 착각이겠지…
• D: 이 이름을 가진 언어가 몇 개 있지만 가장 널리 알려진 것은 월터 브라이트의 D 언어(1999)일 것이다. 이 언어는 C++의 reengineering으로 시작되었다.
• E: 왠지 Erlang이 생각나는 이름인데 사실 이 이름을 가진 E 언어(1997)가 실제로 distributed computing을 위한 언어이다. 같은 이름을 가진 하드웨어 검증 언어(1992)도 있다.
• F: Fortran 95의 부분집합으로 정의된 F 언어가 존재한다. 하지만 ML의 .NET 포팅인 F#(2002)가 이 쪽에서는 더 유명하지 않을런지.
• G: LabVIEW(1986)의 원래 이름이 G(“graphical” language라서 그런 듯)였다고 한다.
• J: 일단 APL의 후손인 J 언어(1990)가 존재하고, 마이크로소프트에서 만든 자바 계열 환경 및 언어인 J++과 J#(2002)도 있다.
• K: 마찬가지로 APL의 후손인 K 언어(1993)이 여기에 속한다.
• L: 위키백과에 따르면 이 이름을 가진 언어들이 꽤 있다고 하는데 (TCL 계열 언어도 하나 있고, distributed language도 있고, C++의 확장도 있다) 별로 들어 본 기억이 없다.
• M: 포트란만큼이나 오래된 MUMPS(1966) 언어를 M이라고 보통 많이 부른다. (이 언어의 이름이 진짜로 뭐인지에 대해서는 여전히 논란이 있는데, 표준화 과정에서는 MUMPS라고 했다.) 한편 마이크로소프트의 오슬로 프로젝트에서 사용하는 M 언어(2008)도 있다.
• P: 난해한 프로그래밍 언어 계열 중에 P(2005)라는 이름을 가진 게 있다. 또한 Brainfuck(1993)과 거의 똑같은 계산 모델인 P”(1964)도 있다. (그러나 이 유사성은 순전히 Brainfuck이 너무 단순해서 그런 거지 실제로는 Brainfuck 쪽에서 영향을 받은 건 아닌 것 같다.)
• Q: Term rewriting을 기반으로 만들어진 함수형 언어 Pure(2008)의 옛 이름이 Q였다. 놀랍게도 Q는 “eQuational”에서 나왔다고… 그 밖에 K에서 유래한 APL 계열의 언어(2003)도 같은 이름을 가진다.
• R: 통계 분야에서 많이 쓰이는 R 언어(1993)가 여기에 속한다. 특허 때문에 망했다는 전설의 R++ 언어도 있다.
• S: 앞에서 말한 R 언어가 원래는 S 언어(1975)의 현대적인 버전으로 출발했다. (당연히 S는 Statistics의 약자일 듯… 왜 이름이 이따구야.)
• T: 스킴(1975)의 구현을 테스트하기 위한 목적으로 만들어진 언어가 T 언어였다고 한다. 스킴과 다른 점은 객체지향적이고(CLOS를… 끼얹나?) 느긋한 계산법을 일부 지원한다고.
• U: TinyMUD 계열의 머드 구현체 중 UberMUD라는 것이 쓰는 스크립팅 언어(1990?)가 이 이름을 가진다고 한다. (이름 하나 정말 더럽게 못 짓는다.) 그런데 이거 말고 뒤지다 보니까… 글쎄 이런 게 나오더라!
• V: 난해한 프로그래밍 언어 계열에서 V(2007?)랑 V—(2007)라는 이름을 가진 게 있긴 하다. 구글 코드를 뒤지니 결합형 언어 하나가 튀어나오기도 하는데, 많이 쓰이는 이름은 아닌 것 같다. 그리고 한 글자 이름은 아니지만 Vvvv(1998)라는 이름의 언어도 있다(…)
• W: 이 이름을 가진 잘 알려진 언어는 없지만, 이것 같이 그나마 언어 스럽게 생긴 것들이 존재하기는 한다.
• X: C# 계열의 임베디드 언어 이름 중 X++라는 것이 있다고 한다. 역시 JVM/CLR의 목표는 언어 갯수를 폭발적으로 늘리려는 것임이 틀림 없어
• Y: SIGPLAN에 이 이름을 가진 언어(1981)가 등장했었던 모양. 난해한 프로그래밍 언어 중에서도 하나 눈에 띈다.
• Z: 일단 Z 표기법(1977)이라 불리는 명세 언어가 존재하고 (어떤 의미에서는 강력한 선언형 언어로 볼 수 있을 듯), FOLDOC에 따르면 시뮬레이션 언어 중에서도 같은 이름을 가진 게 있다고 한다.

대강 찾아 봤을 때 안 나오는 이름은 H, I, N, O, X 정도였다. 어차피 구글에서 검색하기도 힘든데 이런 이름은 피하는 게 좋을 듯.

요즘 들어서 위키백과(엔진)와 엔하위키(분위기)의 영향을 심하게 받은 백과사전 위키들이 심하게 늘어나고 있다는 느낌이 든다. 나는 오락실 위키나 토끽누 위키¹ 같이 특정 주제에 특화된 위키가 만들어지는 건 긍정적으로 생각하는데, 문제는 스레디키나 자유인사전 같이 굉장히 어중간한 목적을 가진 사이트들도 존재한다는 거다. (물론 소속 사이트들에 대한 문서가 많이 올라오긴 하지만 일반 목적의 글들도 많이 올라 오고 있다.)

공동 참여를 목표로 한다면 명확한 목표가 있어야 한다는 게 내 생각이다. 스레디키는 스레딕에서 일어나는 사건이나 용어 중심으로 정리하고 아닌 것들은 위키백과나 엔하위키로 soft redirection을 해도 충분한 것이다. 자유인사전도 마찬가지고 (이 쪽은 내가 그 커뮤니티의 분위기를 몰라서 사실 잘 모르겠다). 내가 가장 우려하는 사태는 엔하위키 같은 목표를 가진 사이트가 여러 개 나타나서 각자 중복된 정보를 미친듯이 올려대는 건데, 다행(?)히도 이들 사이트들의 규모가 아직은 작아서 그걸 염려해야 할 정도는 아닌 듯 하지만 걱정되는 건 어쩔 수 없다. 그런 주제에 문서 수 700을 넘으면 위키백과 위키 목록에 등재될 수 있다²라는 황당한 얘기가 나오고 있으니… 어쩌란 말이냐.