어찌 보면 뜬 구름같은 분류기준이 복잡한 결정에는 지대한 도움을 주기도 한다.

Programming is Hard, Let's Go Scripting...은 스크립트에 대해 이야기 하고 있지만, 언어 설계자들이 고민했을 법한 주요 요인에 대해서 열거하고 있는 것이 눈에 띄었다. 비단 언어 설계가 아니더라도 메모해두면 영감을 줄 만한 내용이다.

모두 symmetry를 이루어 기억하기에 좋다. 애플리케이션 설계와 언어 설계의 문맥이 다른 만큼 binding, evaluation, typology의 의미는 상이하게 적용할 수 있다. 언어설계에서 binding이란 linking과 컴파일시 심볼 해석 등에 관여 되겠지만, 애플리케이션에선 조금 다르다. 순간 mapping과 혼란을 겪게 되는데, 마침 데이터 바인딩에 대해 언급한 글을 찾아서 설명을 생략한다. typology는 애플리케이션 설계에 대응시키가 어려울 수도 있다. 마지막의 둘은 binding을 애플리케이션 영역에 적용하면 등장할 법한 녀석들이 아닐까 하는 생각이 스치는데, 여튼 애플리케이션 영역에서 비스무리한 놈을 슬쩍 끼워 넣었다.


dispatch란 메시지(message)에 대해 객체(object)를 대응시키는 것이다. 애플리케이션 영역으로 확장해서 보면 multiple dispatch 사례로 멀티 쓰레드를 떠올릴 수 있다. 타입 레벨과 인스턴스 레벨로 나누어보면 또 다른 차원의 해석도 가능하다. 또한, 필터/인터셉터류의 기술을 생각해보라. 동일한 dispatch에 대해서도 상황에 따라 다른 인스턴스를 만들어낼 수 있다.¹

So basically, multiple dispatch is like democracy.
주의를 끄는 표현인데, 많은 사람들이 예상하듯이 병렬 프로그래밍이 주류로 부상하리라는 예상을 떠오르게 한다. 병렬 처리나 다중화는 이미 곳곳에 편재한다. 서버 클러스터링, 데이터 그리드, 풀링, 멀티 쓰레딩, 유얼코어, 쿼드코어, 미러링,  ...


떠오르는 생각은 많지만 커멘트는 자제하겠다. ㅡㅡ;

그 외에도 주옥같은 분류를 다수 제시하고 있다.