MovableTypeWriter에서 mshtml을 사용해보았는데, XHTML 표준에 너무 맞지 않는 코드를 생성해내서, XStandard란 product를 눈여겨보고 있다.

Lite/Pro 버전으로 나뉘어서, Lite 버전엔 확장성 관련 기능들이 좀 빠져있긴 하지만, Lite도 상용 제품에 사용가능하다는 것이 눈에 띈다. 무엇보다도, XHTML 표준에 맞는 코드를 생성해내는 것이 마음에 든다.

“The editor generates clean XHTML Strict or 1.1, uses CSS for formatting, and ensures the clean separation of content from presentation”

pistos2님이 쓰신 여러 HTML editor들의 비교글도 읽어보자.

http://blog.naver.com/pistos2/80002160967

Update: gaemon님에 의하면 blogger에서는 자체 editor에서 XHTML compliant한 코드를 생성해준다고 한다.

Beta service 상태이던 MSN Search가 2월 1일자로 open 되었습니다. 원래 있었는지는 모르겠지만, MSN portal에도 적용되었나봅니다. 밑에 있는 article에서 언급된 특정 사이트로 링크한 페이지를 찾는 기능도 실험해보았습니다. “link:www.lastmind.net” 식으로 검색하면 되는데, 제가 URL을 넣은 comment들이 주루룩 나오는군요.

MSN Search http://search.msn.com/

MSN Search Has Arrived http://slashdot.org/article.pl?sid=05/02/01/1259235&from=rss

MSN Search Launched http://blogs.msdn.com/jhoward/archive/2005/02/01/364537.aspx

Off-Topic But Exciting…MSN Search Answers the Question: “Who Links to My Site?” http://blogs.msdn.com/ncarora/archive/2005/02/01/364715.aspx

MSN Search now live http://blogs.msdn.com/bretgrinslade/archive/2005/02/01/364725.aspx

bindung군의 RSS가 내 RSS reader에서 제대로 sync가 안되는 문제를 해결하기 위해, http-access2 Ruby module을 2.0.4에서 2.0.5로 update했다. 오랜만에 http-access2 페이지에 들어갔더니, trac을 사용하고 있었다. 개인적으로 프로젝트 관리 툴로 dotproject를 써보고 있었는데, 기능은 충실하지만, 필요 이상으로 복잡한 감이 있다. 나도 trac을 한번 써볼까…생각 중.

http://rrr.jin.gr.jp/projects/http-access2/wiki/WikiStart#20041225Version205

Connection: close 헤더를 넣지 않으면, web server측에서 persistent connection을 유지할 경우, HTTPAccess2::Client::get()이 pending되는 문제는 아직 여전한 것 같다. 디버깅해보아야할 듯.

deepblue군이 루비 사용자 모임에 올라온 버그를 메신저로 슬쩍 알려주길래, 내 amd64 machine에 wxRuby를 설치하고 디버깅해보았다.

http://rubyforge.org/tracker/?func=detail&aid=1383&group_id=35&atid=218

전에 wxRuby를 사용해볼 때도, 여러번 segmentation fault를 경험했었는데, 아무래도 unit testing을 해보지 않고, API mapping만 해놓은 모양이다.

그건 그렇고, 루비 사용자 모임의 RSS feed를 받고 있었는데, 최근 업데이트가 안되고 있다 했더니, RSS 링크가 어디론가 사라져버렸다. 뭘까?

Introduction

gentoo Linux platform에서 wxWindows와 wxRuby를 source로부터 설치하는 방법을 기술한다.

Installing wxWindows

1. http://www.wxwindows.org/로부터 wxWindows source를 다운로드 받는다. 본인은 wxGTK-2.4.2.tar.gz를 기준으로 설명한다.
2. wxWindows를 설치한다.

   cd wxGTK-2.4.2/
   ./configure --with-gtk --enable-gtk2 --enable-unicode
   make
   su
   make install
   

3. wxRuby가 htmlproc.h를 필요로 하기 때문에 다음 command를 실행한다.

   /bin/install -c -m 644 ./include/wx/html/htmldefs.h /usr/local/include/wx/html/htmldefs.h
   

4. wxRuby가 문서에 따라 설치한다.

   cd contrib/src/xrc
   make
   su
   make install
   

Installing wxRuby

1. README에 나와있는대로 설치한다.

       > ruby extconf.rb
   > make     [[[or nmake, depending on your platform]]]
   > ruby install.rb
   

2. 단, install 시 “ruby install.rb” 대신 “make install”을 사용한다.

프로그래밍 언어 전쟁

흔히 프로그래머들 사이에 일어나는 성전의 주제 중의 하나가 바로 프로그래밍 언어다. 물론 논쟁의 형태는 “어느 프로그래밍 언어가 더 좋은가/나쁜가?”는 것이다. 이 “좋은가/나쁜가”라는 말 자체는 매우 모호하다.

물론, 프로그래머들이 아닌 컴퓨터 과학자들도 프로그래밍 언어의 성질에 대해서 연구하고 있고, 이러한 “좋음/나쁨”에 대한 여러가지 합리적인 의견들을 가지고 있을 것이다. 하지만, 자연 언어가 그런 것과 마찬가지로, 프로그래밍 언어는 문법만으로 이루어져있지 않다. 예를 들어, 한국어는 한국어 문법만으로 이루어져있지 않다. 한국어로 밥먹었냐고 물어보는 방법, 한국어로 문학 작품을 쓰는 방법, 그리고 한국어를 사용하는 언중들의 사상, 종교, 문화 등 언어 외적인 것이 그 언어와 밀접한 관련을 가지고 있다. 프로그래밍 언어도 마찬가지다. 프로그래밍 언어를 사용하는 여러가지 idiom들, 컴파일러/인터프리터의 구현, 표준 라이브러리, 사용자 라이브러리의 보편화 정도, 언어를 위한 툴 (IDE), 언어가 사용되는 프로젝트에 따라, 프로그래밍 언어를 평가하는 기준은 달라질 수 밖에 없다.

그런데, 실제로 어느 게시판에 들어가서 이러한 논쟁을 구경해보면, 특별히 이러한 기준들을 설정해놓고 논의를 하는 것은 보기 힘들다. 어떤 사람들은 특정 언어 구현에 의한 프로그램 성능을 따지고 있고, 어떤 사람들은 새로운 기능이 추가되었음을 강조한다.

이러한 사실보다 더욱 괴로운 것은, 두가지 언어를 비교하는 논쟁에서, 실제로 (자신이 공격하는) 다른 언어나 다른 환경을 경험하지 못한 사람들이 대부분이라는 것이다. 만약, 두 언어를 어느 정도 경험해보았다고 하더라도, 언어 외적인 여러가지 기준들에 대해서 그 사람이 올바른 평가를 내릴 수 있는지도 의문이다. 서로 부족한 정보를 가지고 누가 ‘옳은가’를 따지는 것은 매우 소모적이고 쓸데없는 일이 되기 쉽다.

옮고 그름의 문제? 선택의 문제!

보통 프로그래밍 언어 전쟁의 대상이 되는 범용 (General-purpose) 프로그래밍 언어들은, 프로그래머가 무슨 일을 하고자 했든간에, 대부분의 일을 할 수 있다. static typing이든, dynamic typing이든, garbage collection을 채용하든 안하든 프로그램이 무슨 일을 하는가에는 상관이 없다. procedural programming language인 C로도 OOP의 polymorphism을 구현할 수 있다.

다만, 프로그래머가 생각하는 방식과 언어가 얼마나 호환되는가, 프로그래머가 원하는 성능을 낼 수 있는가, 프로그래머가 이미 존재하는 라이브러리를 재사용할 수 있는가, 프로그램을 얼마나 여러가지 시스템에서 동작시킬 수 있는가, 우리 팀에 그 언어를 사용할 수 있는 사람이 얼마나 되는가 등이 다를 뿐이다.

예를 들어, 웹브라우저를 만든다고 해보자. C, C++, Java, Python, Haskell, PHP 어떤 언어를 사용하든 웹브라우저를 만들 수 있다. 하지만 각 언어들은 서로 다른 철학을 가지고 있기 때문에, structured programming에 익숙한 사람이 Haskell을 사용해서 개발하거나, functional programming에 익숙한 사람이 Java를 사용해서 개발하는데에는 많은 시간이 걸릴 것이다. 반면에, PHP의 설계자는 웹 어플리케이션을 만들기 위한 언어를 설계했기 때문에, 웹브라우저에는 매우 부적합할 수 있다. 만약, 웹브라우저의 성능이 중요하다면, 어떤 언어의 선택은 매우 나쁠 수도 있다. 또한, 어떤 언어에는 쓸만한 GUI 라이브러리가 없다면, 웹브라우저의 개발에 난항을 겪을지도 모른다.

프로젝트 초기에 프로그래밍 언어를 채택할 임무를 맡은 사람은 바로 이러한 점들을 고려해서 프로그래밍 언어를 선택해야하는 것이다.

무슨 프로그래밍 언어를 선택할 것인가?

David West의 책, ‘Object Thinking’에서는 무슨 프로그래밍 언어를 선택할 것인가에 대한 기준에 대해서 얘기하고 있다.

잘못된 기준

• Loyalty: 우린 마이크로소프트 가게니까, Visual Basic을 사용한다.

• Bandwagon: 모두가 자바를 사용한다.

• Economics: 자바 프로그래머는 10명에 100원이고, 완전히 대체가능하다. 한명을 잃더라도, 쉽게 대체할 사람을 찾을 수 있다.

• Culture: 실시간/임베디드 어플리케이션에서는 C++ 말고는 쓸 수 없다.

• Resume: 모든 회사 취업 광고에는 C# 경력을 물어본다. 뭔가 눈길을 끄는 게 필요하다.

• Inertia: 난 첫번째 프로그램을 COBOL로 작성했고, COBOL이 가장 친숙하다. 따라서, 이 프로젝트에는 COBOL이 적합하다. COBOL을 사용하는 것은 프로젝트를 관리하는 데 편리하다.

올바른 기준

• 실리적 기준: 성숙된 라이브러리, 외부 시스템과의 호환성, 가용한 노동력, 경제적인 이유.

• 성능

• 철학: 언어 디자이너의 의도, 가치, 생각.

Conclusion

위와 같은 기준에 따르면, 약간의 syntatic sugar 라든가 ‘pure XXX language’는 실질적으로 중요한 선택 기준이 되기는 힘들다. 물론 대부분의 선택 기준이 동등하다면, 프로그래밍 언어 전쟁에 참여해서 언어들의 서열을 매기는 것에 관심있는 사람들에게는 쓸모있는 기준이 될 수는 있다. 하지만, 대개는 그렇지 않다는 것이 문제다.

많은 사람들이 프로그래밍 언어의 ‘좋음/나쁨’에 관심이 있지만, 대부분은 ‘잘못된 기준’에 따라 프로그래밍 언어를 선택한다. 왜 CS101에서는 이런 것을 가르쳐주지 않은 것일까?