점프와 쉼없는 나아감

나는 java로 jee 프로그래밍을 한다. 대부분 웹 프로그램이고 백엔드 데이터 처리를 위해 데몬을 만들거나 배치 프로그램을 작성하기도 한다. 어쨌든 GUI 프로그래밍은 거의 해본 적이 없다.

갑자기 데스크탑 GUI 프로그램을 만들고 싶어졌다. 그래서 GUI 프로그래밍을 위한 개발 환경을 알아 보고 있다. 무엇이 좋을까? 우선 전제 조건이 있다.

• C++는 쓰지 않는다. 나는 이상하게 C++만은 쓰질 못하겠다. 그 너저분한 언어 구조가 너무 마음에 들지 않는다.
• 윈도우즈가 주 플랫폼이지만 멀티 플랫폼이면 더 좋겠다.
• 위젯은 가볍고 빠르며 네이티브 위젯이었으면 좋겠다. Swing 같은 건 곤란하다.
• 배포에 문제가 없는 즉 네이티브 바이너리로 결과를 만들 수 있으면 좋겠다.
• 무엇보다 쓰기에 편해야겠다 ㅡ.ㅡ;

우선 닷넷은 제외한다. 닷넷으로 개발하느니 차라리 Java + SWT 조합을 하는 게 더 낫다고 생각한다. 그렇다면 후보는 다음과 같다.

• Java + SWT: 가장 익숙한 조합이긴 한데 좀 지루한 감이 있다. 더구나 네이티브 바이너리를 생성하기 고약하다.
• D: C와 비슷하며 바이너리를 만들 수 있다는 장점이 있다. 문법은 C++ 보다 훨씬 간결하고 현대적이다. 안정적인 GUI 라이브러리가 있는지 모르겠고, C와 비슷하게 상당히 저수준의 프로그래밍을 해야 하는 게 아닌지 하는 의구심이 있다.
• Perl + wxPerl: wxPerl이 지원이 좀 부족한 듯 하다. 배포에 문제가 있는데 PAR를 쓰면 해결할 수 있다고 하는데 글쎄?
• Python + wxPython: 꽤 안정적이고 좋다고 하는데 난 Python이 싫다.
• Ruby + wxRuby: 마찬가지로 난 Ruby 언어를 별로 좋아하지 않는다.
• Ocaml + wxOcaml: Ocaml은 아주 매력적인 언어인데 wxOcaml의 상태가 별로 좋지 않은 듯하다. 2004년 10월이 마지막 업데이트면 좀 곤란하다.
• Common LISP + wxCL: Ocaml과 마찬가지로 상당히 끌리는데 이것도 wxCL의 상태가 별로 좋지 않다. 2006년 5월이 마지막 업데이트. 더욱이 윈도우즈 환경에서 적당한 Free Common Lisp 구현체가 없다.
• Smalltalk - Dolphin Smalltalk or wxSqueak: Dolphin Smalltalk의 앞날이 어찌될지 우려스러웠는데 계속 개발이 될 것 같다. GUI 프로그램 만드는 데 상당히 좋은 거 같은데 Dolphin Smalltalk는 윈도우즈만 되고, wxSqueak은 아직 안정적이지 않은 거 같다. 뭐 그래도 wxOcaml이나 wxCL보다는 낫다.
• C: C++은 싫지만 C는 괜찮다. 그런데 쓰기 편한 라이브러리를 모르겠다. winapi 또는 gtk는 곤란하다.

편하게 가자면 Java + SWT가 제일 낫겠고, Perl + wxPerl도 나쁘진 않을 것 같다.

사실 제일 끌리는 것은 Ocaml + wxOcaml 또는 Common LISP + wxCL 이지만 이건 라이브러리의 상태가 별로 좋지 않은 상황에서 그 언어에 대한 내공이 약한 나로선 어려울 듯 하다.

D나 Smalltalk는 상황은 좋은 듯 싶은데 언어 자체로는 Ocaml이나 Common LISP 보다 매력이 덜하다. :)

고로 뭘로 할지 아직도 정하지 못하고 있다. 어쩌면 영영 생각만 하다 끝날지도 모른다. :)

common lisp 공부를 하면서 매우 궁금했던 것 중 하나는 어떻게 소스 코드를 컴파일하여 실행 코드를 만들어 내거나 또는 인터프리터로 실행시키느냐였다.  다른 프로그래밍 언어에 관한 입문서를 읽어 보면 대개 처음에 "Hello world"를 출력하는 코드를 설명하고 이를 컴파일하거나 실행하는 법을 설명하는데 common lisp 책에는 그런 것이 없었기 때문이다.  REPL 환경에서 "Hello world"를 출력하는 것이 시작이었고 그 뒤로도 계속 REPL 환경에서 대화식으로 프로그래밍하는 것만 있었다.  도대체 소스를 어떻게 컴파일한다거나 또는 실행시키는지 설명이 없었던 거다.

문법 공부하는 중에 틈틈히 이에 관한 자료를 찾아 본 결과 common lisp 구현마다 실행 파일(?)을 만들고 실행하는 법이 다르다는 것을 알았다.  또한 common lisp은 실행 파일(?)을 만드는 게 다른 프로그래밍 언어와는 많이 다르다는 것도 알았다. 어찌되었든 다른 언어에서는 처음부터 다뤄지는 중요한 것을 빼놓는 것을 보고 lisp 프로그래밍의 세계는 사뭇 다르다는 느낌을 받기도 했다.

다른 언어에서 빌드, 전개(deploy)라고 부르는 것 - 실행 파일을 만들어 소프트웨어를 사용할 수 있게 만드는 것 - 을 lisp에서는 delivery라고 하는 것 같다.  lisp은 실행 파일을 만드는 게 아니라 core image 라고 하는 것을 생성한 후 이 core image를 불러들여 실행시키는 방식인 거 같다. core image는 lisp 머신의 어떤 상태를 저장해 놓은 것으로 보면 될 듯 하다.  필요한 모듈들을 불러들이고 소스 파일을 컴파일하여 불러들여 실행할 준비를 갖춰 놓고 이 상태를 저장해 놓는 것이다.  이후 lisp 머신으로 이 image를 불러들이고 시작 함수를 호출해서 프로그램을 실행시키는 거다.  아예 lisp 머신을 포함해서 실행 파일 형식으로 core image를 생성할 수도 있다.  sbcl(Steel Bank CL)이 이 방식이고 Allegro CL도 실행해 보진 않았으나 문서를 살펴 보니 대충 이런 방식인 듯 하다.

간단히 "Hello world"를 실행하는 프로그램을 만드는 경우를 해 보면 다음과 같다.  lisp 구현은 sbcl을 사용했다.

먼저 "Hello world"를 출력하는 lisp 코드는 다음과 같다.

hello.lisp
(defun main ()
    (format t "Hello world~%"))

sbcl을 실행시키고 다음 순서로 컴파일, load 한 후 core image 를 생성한다.

c:\work\lisp> sbcl
* (compile-file "hello.lisp")

; compiling file "D:\\work\\lisp\\hello.lisp" (written 22 FEB 2007 07:03:32 PM):

; compiling (DEFUN MAIN ...)

; D:\work\lisp\hello.fasl written
; compilation finished in 0:00:00
#P"D:\\work\\lisp\\hello.fasl"
NIL
NIL
* (load "hello")

T
* (save-lisp-and-die "hello.exe" :executable t)
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into D:\work\lisp\hello.exe:
writing 1960 bytes from the read-only space at 0x02000000
writing 1472 bytes from the static space at 0x05000000
writing 23617536 bytes from the dynamic space at 0x09000000
done]

c:\work\lisp>

이 core image 를 다음과 같이 실행시키면 된다.

c:\work\lisp>hello --noinform --eval "(progn (main) (quit))"

core image 크기는 대략 24MB 이다.  어찌되었든 이 파일만 있으면 실행시킬 수 있다.  java로 비교하자면 class 파일들을 묶고 여기에 가상 머신까지 합쳐서 배포 파일을 만드는 셈이다.


core image에 compiler, debugger, REPL 까지 포함해서 구성하면 실행 중인 프로그램에 접속해서 디버깅, 코드 수정, 컴파일, 패치도 가능한 모양이다.

어찌되었든 lisp은 매우 독특하고 매력있는 언어다.

책 읽기 시작했다는 이야기만 쓰는 거 같지만.
어제부터 CLOS 책을 읽기 시작했다. 책 제목은 "Object-Orientend Programming in Common LISP, A Programmer's Guide to CLOS"

Common Lisp이 점점 재미있어지고 있다.