Code Metaphor

psql에서 \dT+라고 치면 아래 표가 나온다.

네트워크 주소를 저장하는 용도인 cidr, inet, macaddr 같은 것도 있고, box, circle, line, path, point, polygon 같은 기하학적 값들을 위한 자료형도 존재한다.

눈여겨 볼 것은, regclass나 regtype 같은 고차 자료형(higher-order types)—자료형을 담는 자료형, Ruby의 Class 객체나 Python의 type 객체 같은 것들—도 존재한다는 사실. regoper, regproc 같은 자료형을 보면 알 수 있겠지만, 연산자나 프로시져를 값으로 사용할 수 있기도 하다. regoperator, regprocedure 자료형은 부분 적용(partial application)된 연산자, 프로시져를 담는다.

이 얼마나 강력하고 유연한 ORDBMS인가.

Delicious를 2주일 정도 사용하면서 생긴 사용 패턴 같은데,

• 그냥 북마크의 경우 완전히 Delicious로 대체. 회사에서는 Mozilla Firefox에 Delicious Bookmarks 확장 설치해서 사용하고, 집에서는 Safari에 DeliciousSafari 설치해서 사용한다. 남들한테 공개하기 힘든 URL도 비공개 북마크가 가능하니 문제 없다. (심지어 평소 사려고 했던 옷들의 옥션, 지마켓 URL 같은 시시콜콜한 것들도 모두 Delicious로 관리!)

• 그렇지만 내 주변 사람들에게 정말로 공유하고 싶은 URL이 있다면 Delicious에도 북마크하고, 미투데이에도 올린다. 내가 원하는 공유라는 것은 단순히 노출이 아니라, 좀더 적극적으로 읽기를 권유하는 것을 뜻하기 때문이다.

• 따라서, 남들에게 읽게 해주고 싶지만, 나는 이미 잘 아는 내용이라면 Delicious에 북마크는 하지 않고, 미투데이에만 올리는 경우도 종종 생긴다. (예를 들어, “웹 표준의 필요성” 같은 내게는 진부한 주제를 누가 굉장히 글로 잘 써놨다면, 북마크는 하지 않고 미투데이에만 올린다.)

더불어 북마크 외에 글쓰기 패턴도 있다.

• 영속적이고, 길고, 너무 전문적인 이야기는 보통 이곳 블로그에 쓴다.
• 인스턴트한 감정의 표현 찌꺼기들은 미투데이에 모아둔다.

미투데이는 마이크로블로그(microblog)니 당연한 것이 아니냐고 할 수도 있지만, 꼭 그렇지만도 않다. 미투데이는 낙장불입(落張不入)의 세계. 인스턴트(instant)한 내용들을 퍼머넌트(permanent)한 공간에 올린다는 것은 꽤나 재미있는 패턴이 아닐까.¹

거의 2년만에 디자인을 갈았다. 대충 만들어져 있는 것을 쓸까 하다가, 보이는 건 상관 없어도 마크업이 죄다 마음에 들지 않아서 이번에도 직접 만들었다. 쓰지도 않는 페이지들을 싹 빼버렸다.¹ 검색도 없앴다. 첫 화면이 난잡했었는데, 그냥 제목만 나오게 바꿨다. 글들은 각각의 페이지에서 읽을 수 있다.

코멘트 부분은 만지려다 귀찮아서 그만뒀다. 그래서 코멘트 부분만 마크업이 마음에 들지 않는다. 다음에 고치련다.

집에 Mac밖에 없어서 아직 Internet Explorer에서는 확인하지 못했다. 회사 가서 확인해야지.

Haml이라는 템플릿 엔진이 있다. 여타의 템플릿 엔진들과 다르게, HTML 문법 비슷하게 생긴 무언가도 보이지 않는다. 이 템플릿 엔진은 결과물이 XML, XHTML이라는 가정 하에 설계된 문법을 사용한다. 아래 예제를 보자.

#forum.section
  %h2 포럼
  %table.list
    %thead
      %tr
        %th 제목
        %th 작성일
    %tbody
      - posts.each do |post|
        %tr
          %th
            %a{:href => post.url}= post.title
          %td.created-at.datetime= post.created_at

위 Haml 코드를 ERB로 옮기면 아래와 같다.

<div id="forum" class="section">
    <h2>포럼</h2>
    <table class="list">
        <thead>
            <tr><th>제목</th> <th>작성일</th></tr>
        </thead>
        <tbody>
            <% posts.each do |post| %>
                <tr>
                    <th><a href="<%= h post.url %>"><%= h post.title %></th>
                    <td class="created-at datetime"><%= h post.created_at %></td>
                </tr>
            <% end %>
        </tbody>
    </table>
</div>

한눈에 느낄 수 있듯, Haml은 매우 간결하고 절제된 문법을 사용한다. Haml 문법 안에서는 의미적으로 타락한(?) 마크업을 만들기 힘들게 되어 있다. Haml의 문법에는 제한이 많지만, 그 제한들 대부분이 바람직하지 않은 것들에 대한 제한이기 때문에 별 문제가 되지 않을 뿐더러, 오히려 도움을 준다. Haml에서 JavaScript 사용하기가 번거롭다는 투정도 보이는데,¹ 내가 보기에는 애초에 원하는 코드 자체—HTML 중에 <script> 태그로 JavaScript 코드를 포함시키는 것—가 나쁜 코드다.

Haskell에서 말하는 함수들은 모두 수학적인 함수들을 이야기한다. 즉, 상태, 부수 효과(side effect)가 없으며, 정의역과 치역이 명확한 관계를 말한다. 덕분에 Haskell에서는 입출력, 난수 발생 따위를 위해 모나드(monad)라는 개념을 사용한다. 아무래도 일반적인 절차적 언어(imperative language)들에 비해 불편할 수밖에 없다. 하지만 대부분의 부수 효과가 버그를 양산하는데 일조한다는 점²을 떠올려보면, “필요악이라면 가능하되 어렵게” 해놓은 Haskell의 절제된 언어 설계가 매우 훌륭하다는 것을 깨닫게 된다—그걸 깨닫기 전까진, ‘뭐 이런 불편한 언어가 다 있어!’라고 생각한다.

이와 같이, 설계에서 어떤 가능성을 제한함으로서 결과적으로 더 낫게 된다면, 그것을 절제된 디자인이라고 할 수 있다. 작은 기능을 포기하는 대신 큰 목적을 성취하는 방법이라고 볼 수도 있겠다.

덧. 오랜만에 WordPress 2.6.1 업그레이드 기념으로 포스팅;