절제와 제한
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 사용하기가 번거롭다는 투정도 보이는데,1 내가 보기에는 애초에 원하는 코드 자체—HTML 중에 <script> 태그로 JavaScript 코드를 포함시키는 것—가 나쁜 코드다.
Haskell에서 말하는 함수들은 모두 수학적인 함수들을 이야기한다. 즉, 상태, 부수 효과(side effect)가 없으며, 정의역과 치역이 명확한 관계를 말한다. 덕분에 Haskell에서는 입출력, 난수 발생 따위를 위해 모나드(monad)라는 개념을 사용한다. 아무래도 일반적인 절차적 언어(imperative language)들에 비해 불편할 수밖에 없다. 하지만 대부분의 부수 효과가 버그를 양산하는데 일조한다는 점2을 떠올려보면, “필요악이라면 가능하되 어렵게” 해놓은 Haskell의 절제된 언어 설계가 매우 훌륭하다는 것을 깨닫게 된다—그걸 깨닫기 전까진, ‘뭐 이런 불편한 언어가 다 있어!’라고 생각한다.
이와 같이, 설계에서 어떤 가능성을 제한함으로서 결과적으로 더 낫게 된다면, 그것을 절제된 디자인이라고 할 수 있다. 작은 기능을 포기하는 대신 큰 목적을 성취하는 방법이라고 볼 수도 있겠다.
덧. 오랜만에 WordPress 2.6.1 업그레이드 기념으로 포스팅;
August 18th, 2008 at 1:01 PM
꽃띠앙의 생각…
절제와 제한 너무 강조하면 삶이 빡빡하다능….
August 18th, 2008 at 3:32 PM
scala의 XML Processing도 약간 그런 느낌을 받았어요.. 적어도 태그 안 닫으면 컴파일이 안되는.. 사태가.== 찾지 못한 태그의 위치가 소스 라인 위치가 되어서 디버깅도 나쁘지 않았구요. Haskell에 대한 이야기가 많네요. 언제 한번 공부하고 싶네요. ++
August 18th, 2008 at 5:48 PM
Scala의 XML 리터럴에 대해서는 전 반대의 생각을 가지고 있습니다. 말씀하신 것은, 언어 문법의 일부니 당연히 검사를 해야하는 부분이라고 생각하고요. Scala 코드 내에서 XML을 직접 쓸 일이 얼마나 있을까요? 왜 XML을 별도의 파일에 저장하지 않고 소스 코드 내에 포함시킬까요? 아마 그러한 필요성 자체가 좋은 디자인을 위배하는 의도에서 나왔으리라고 봅니다. 따라서 Scala의 XML 리터럴은 글에서 제가 이야기한 절제의 미학과 반대에 있는 기능이라고 할 수 있죠.
August 19th, 2008 at 12:11 AM
제가 들었던 부분이 적절하지 않는 예인건 분명하군요. :-) 하지만 소스에 XML을 포함시키는 부분에 포커스를 잡기 보다는 , 패턴 패칭으로 XML처리를 하기 위해 Scala에 XML 리터럴이 추가된거 같은데요. 왜 좋은 디자인을 위배하는 의도인지 궁금하군요.(관점의 분리같은 의미는 약간 배제하구요.) +_+
솔직히 haml과 비슷하다고 생각하는 erector(http://erector.rubyforge.org/)과 비슷하게 사용할수 있지 않나 라는 생각이 들긴 했습니다. 제 짧은 생각으로는 XHTML/XML이 객체로 환원되면 그 객체의 인터페이스로 제약이 가해지므로, 홍민희님의 의도와 비슷하지 않았나 생각했는데요. 제 생각이 많이 틀렸나보군요 :-)
Scala의 XML Processing으로 MVC/VIew을 간단히 만들어봤는데. 일반 JSP보다는 당연히 느리더군요.
August 19th, 2008 at 2:23 AM
디자이너는 죽어도 배우려 하지 않을것 같은데요.. ㅡ,.ㅡ;;;
August 19th, 2008 at 8:59 AM
XHTML만 안다면 저 문법에 익숙해지는 것이 어렵지 않습니다. 저도 이 글 쓰기 직전에 튜토리얼 보고 얼렁뚱땅 배웠어요. XHTML도 제대로 모르는 디자이너라면 협업하기에 앞서 회의의 시간을 가지는 것도…; 제가 전에 썼던 웹 디자인의 방향이라는 글도 참고해주세요.
August 19th, 2008 at 9:08 AM
관점의 분리라는 점에서 가장 좋지 않겠죠. 물론 Scala라는 언어를 템플릿 엔진으로 보고, 별도의 소스 파일로 분리한다면 문제가 사라집니다만, 애초에 Scala에서 XML 리터럴을 사용해야할 이유가 있을까 하는 생각이 듭니다. 별도의 템플릿 엔진을 사용한다면 될텐데요. Scala를 템플릿 엔진으로 보기엔 너무 후지죠. (일단
class나def뭐시기로 시작해야 한다는 것부터…) 비슷하게 Erector 역시 작은 웹 프로그램에서 간단하게 로직과 뷰를 뭉뜽그려서 사용할 때는 좋겠습니다만, 본격적으로 뷰를 분리하게 되면 오히려 불편하기 때문에 좋은 템플릿 엔진이라고 생각하지는 않습니다.XML이 객체로 표현될 경우, 그 객체의 인터페이스로 제약이 가해진다는 것이 무슨 뜻인지 잘 모르겠습니다. 제가 알기로 Scala의 XML 리터럴은 DOM 객체를 반환하는 표현식으로 취급되고, 객체 인터페이스라는 것은 DOM 인터페이스를 말씀하시는 것 같은데… 어떤 제약을 말씀하시는 것인가요?
August 19th, 2008 at 10:36 AM
erb에 익숙해져서 그런지 haml은 역시 생소하네. ㅎㅎ
민희가 말했듯이 목적에 따라 좋은 템플릿 엔진이 갈라지겠지. 꼭 뷰를 분리하기 편한 템플릿 엔진이 좋은엔진 이라고 할 수 는 없는것 같아 ㅎㅎ
August 19th, 2008 at 11:57 PM
꽃띠앙님 의견에 한 표^^
September 30th, 2008 at 3:18 AM
Haml, 템플릿 언어 보다는 마크업 언어라고 보는게 더 알맞은 것 같기도 합니다. 왜 그렇게 생각하느냐 하면, 제 개인적으로 HTML layout 마크업을 손으로 스크립팅할 때, 거의 비슷한 표현들을 사용하고 있는데, 템플릿처럼 임의 표현블럭을 저장/대체 하지 않고 1:1 대체를 하기 때문입니다. Haml 도 전반적인 용도는 그렇게 보이네요. ^^; 고민은 style 표현과 엮어내는게 쉽지않아서 진정한 스타일 레이아웃 마크업까지는 진보하지 않고 있다는… ㅡㅡ;
아차, 좋은 정보 감사드립니다. 꾸벅~!