흔히 파이썬하면 파이썬 언어 명세보다는 Guido van Rossum이 작성한 CPython을 의미하는 경우가 많습니다. 하지만 CPython 외에도 파이썬을 구현한 프로젝트가 많이 있었습니다. 한 때 많은 사람들의 관심을 받았던 Stackless Python을 필두로 시작된 파이썬 구현은 현재 JVM과 .NET에 올라간 Jython, IronPython으로 이어지고 있습니다. 파이썬으로 파이썬을 구현하자는 PyPy 프로젝트도 있습니다.

더 이상 개발되지는 않지만 실험적인 파이썬 구현으로는 PyVM과 Vyper가 있었습니다. 그 중 Vyper는 John Max Skaller OCaml로 작성한 파이썬 구현입니다. 당시 파이썬 스코핑(scoping) 룰에 불만을 품고 시작해 좀 더 빠르고 함수적인 파이썬을 만들려는 시도였습니다. IBM dW에 보면 Stackless Python의 Christian Tismer와 Vyper의 John Max Skaller와 인터뷰가 있더군요. 하지만 지금은 Vyper의 홈페이지 링크조차 깨진 채 존재하지 않는군요. 아아. Vyper가 커뮤니티의 도움을 얻어 CPython과 더불어 성장해줬다면 조금 더 함수형인 파이썬이 나왔을지도 모르겠습니다.

IBM dW의 연재 중에 Crossing borders는 프로그래밍 언어와 기술 간의 경계를 뛰어넘어 새로운 세계를 맛 보자는 뜻으로, 다양한 함수 언어를 소개하고 있습니다.

헤스켈 소개

Crossing borders: Explore functional programming with Haskell


얼랑 소개

Crossing borders: Concurrent programming with Erlang


비함수형 개발자에게 함수 언어의 개념을 소개하는 것은 비교적 쉽습니다만, 그 다음 단계인 함수 언어로 실제 어플리케이션을 작성하는 일과는 상당한 괴리가 있는 것으로 보입니다. 저 역시 함수 언어에 관심 갖고 공부해온 지가 꽤 오래되었지만 비교적 최근에서야 업무를 비롯해서 시험적으로 조금씩 써보는 정도거든요.

특히, 함수 언어를 실제 어플리케이션 작성에 쓰기 위해 반드시 풀어야할 문제는 IO, 외부 함수 호출, 동시성(concurrency) 등인 것 같습니다. Real World Haskell은 Haskell로 연습 문제만 풀지 말고 실제 어플리케이션을 작성할 수 있도록 가이드하자는 취지해서 작성되고 있는 책인데, 얼마나 성공적일지 지켜봐야겠습니다.

순수(pure) 함수, 다른 말로 참조 투명한(referential transparent) 함수는 수학적인 함수와 마찬가지로 같은 인자를 넣으면 언제나 같은 값을 돌려줌을 보장하는 함수입니다. 간단한 예로, OCaml로 작성된 다음 피보나치 수열 함수(fib)는 참조 투명한 함수입니다.



위 fib 함수는 비효율적으로 작성되어 있기 때문에 무척 느립니다. 이런 순수 함수를 최적화하는 방법으로 알고리즘 자체를 꼬리 호출(tail recursion)하도록 변경하거나 더 나은 알고리즘을 찾는 방법 등도 있겠지만, 함수를 그대로 두고 메모리 공간을 희생해서 속도를 향상하는 최적화 방법으로 기억(memoization)이 있습니다.

다음 memo 함수는 Developing Applications With Objective Caml에서 발췌한 예입니다.


이 함수의 타입은



로 원래 함수와 동일한 타입의 함수를 리턴합니다. 코드를 살펴보면 table을 두고 계산 결과를 저장해서 한 번 f(e) 값이 불리면 두 번째 불리는 f(e)는 새로 계산하지 않고 저장된 값을 쓰게 됩니다. 일종의 동적 프로그래밍(dynamic programming) 기법입니다.

기억(memorization)이 가능한 이유는 함수가 참조 투명하기 때문입니다. 매번 호출할 때마다 값이 바뀌는 함수라면 이전 함수의 결과를 저장해뒀다가 재활용하는 것이 불가능하기 때문입니다.

어느 정도 속도 향상이 있었는지 측정하기 위해서 시간을 재는 함수를 다음과 같이 만들어 봅니다.



OCaml은 함수 언어고 a + b라고 해서 a를 b보다 먼저 연산(evaluation)한다는 보장이 없습니다. IO의 경우는 순서가 중요하기 때문에, IO의 순서를 정하기 위해서 위와 같이 let 구문을 연달아 늘어 놓는 방법을 많이 씁니다. 앞서 let이 새로운 스코프(lexical scope)을 만들기 때문에 순서가 보장되게 됩니다.



fib를 memo로 감싸서 memo_fib 함수를 정의한 다음에 2번 불러보면 두 번째는 이미 계산된 저장 값을 가져 오기 때문에 매우 빠르게 계산됨을 확인할 수 있습니다.

전통적으로 프로그래밍 언어의 외부 인터페이스(외부 함수 호출)는 주로 C로 되어 있었습니다. 자바의 JNI(Java Native Interface)가 대표적이고, 파이썬도 Python/C API를 제공합니다. 함수 언어 OCaml로 C 인터페이스를 제공하고, Haskell도 마찬가집니다.

C는 프로그래밍 언어계의 에스페란토인 셈인데 C가 이렇게 널리 쓰이는 이유는 다음과 같습니다.

1. C는 표준화된 언어이다 (ISO C)
2. C는 운영 체제 구현 언어로 가장 많이 사용된다. 대표적으로, Unix, Windows, MacOS 등이 모두 C로 구현되어 있다.
3. 많은 라이브러리가 C로 구현되어 있다.
4. 대부분의 프로그래밍 언어가 C 인터페이스를 제공하기 때문에, 프로그래밍 언어가 C 인터페이스만 제공하면 다른 언어와 바인딩도 가능하다. 일례로, Pycaml은 OCaml C 인터페이스로 Python/C API를 호출해 파이썬을 바인딩한다.


자바 가상 머신에서 동작하는 언어에서는 자바가 C를 대체하는 새로운 에스페란토가 되고 있습니다. 자바는 앞서 C가 프로그래밍 언어 인터페이스로 많이 사용되는 이유가 모두 맞아 떨어집니다.


1. 자바는 표준화된 언어다 (Java Language Specification)
2. 자바는 자바 플랫폼 구현 언어로 사용된다. 자바 라이브러리는 모두 자바로 작성되어 있다.
3. 많은 라이브러리가 자바로 구현되어 있다.
4. 대부분의 JVML이 자바 인터페이스를 제공하기 때문에, 프로그래밍 언어가 자바 인터페이스만 제공하면 다른 언어와 바인딩도 가능하다.

프로그래밍 언어를 공부를 단계별로 나눈다면

(1) 프로그래밍 언어의 문법를 파악
(2) 프로그래밍 언어의 의미(semantics)를 이해
(3) 프로그래밍 언어 커뮤니티가 사용하는 관례와 용법 파악
(4) 프로그래밍 언어 내부 구현(컴파일러, 인터프리터) 지식을 활용한 최적화 코드 작성

정도의 순서로 진행될 것입니다. OCaml은 일반적으로 상당히 빠른 머신 코드로 컴파일될 수 있다고 알려져 있지만 OCaml 컴파일러가 어떤 최적화 기법을 사용하는지 알면 더욱 더 효율적인 코드를 짤 수 있을 것입니다. 

예를 들어, 다중 인자를 받는 OCaml 함수를 정의할 때 두 가지 방법을 사용할 수 있습니다. OCaml QnA의 Making code run fast라는 글에서 인용했습니다.





첫 번째는 커리(curried) 형태이고, 두 번째는 언커리(uncurried) 함수로 여러 인자를 하나의 튜플로 만든 형태입니다. 

개발자가 느끼기에 두 코드가 하는 일은 거의 동일하지만 OCaml 컴파일러 입장에서 봤을 때는 달라지는 부분이 생깁니다. OCaml 바이트코드 컴파일러(ocamlc)의 경우, 커리 함수는 힙(heap) 할당 없이 스택에 변수를 넘겨서 함수 호출을 수행함을 보장합니다. 반대로 언커리 함수는 힙에 튜플을 만들어서 넘깁니다. 호출된 함수 안에서는 다시 튜플에서 각각의 원소를 꺼내 와야 하기 때문에 커리 함수에 비해 속도가 느려집니다.

그런데 반드시 이렇게 되어야만 하는 것도 아닙니다. 네이티브 컴파일러(ocamlopt)는 두 경우 모두 힙에 할당하지 않고 레지스터를 이용해 파라미터를 전달하기 때문에 두 함수는 성능 차가 없어집니다.

또 하나의 예로, 대부분의 Lisp이나 ML 컴파일러는 부동소수점 계산이 느립니다. 가비지 콜렉션, 다형성/타입 추상화 등 때문에 부동소수를 힙에 할당하고 포인터를 저장하는 방식으로 구현된 경우가 많기 때문입니다. float 두 개 더하려면 포인터를 2개 읽어서 float를 가져와 더한 다음에 그 결과를 다시 포인터가 가리키는 주소에 저장해야 하기 때문에 속도가 느려질 수밖에 없습니다.

컴파일러가 부동소수점을 언박싱(unboxing)하는 최적화를 하면 이 문제를 완화시킬 수 있습니다. 다만 컴파일러가 모든 케이스를 자동으로 언박싱할 수 없기 때문에 몇 가지 트릭을 사용하게 되고, 이런 트릭을 모르는 개발자는 속도가 느린 프로그램을 작성할 수밖에 없게 되는 것이죠.

예전에 조엘(Joel) 아저씨가 "The Law of Leaky Abstraction"을 이야기했는데 그 말이 딱 맞아떨어지는 부분입니다. 프로그래밍 언어를 추상화시켜서 내부 구현을 모르도록 만들어놨지만 결국 제대로 사용하려면 내부 구현을 상당 부분 알아야 한다는 것이죠.

OCaml의 라이브러리(표준 라이브러리 제외)는 GODI 프로젝트를 통해 관리되고 있습니다. GODI 툴 체인(godi_console)을 사용하면 OCaml 라이브러리를 쉽게 설치/제거할 수 있습니다. GODI 라이브러리 목록은 camlcity.org 홈페이지에 링크되어 있는데,  생각보다 별로 많지 않은 것 같네요. Perl의 CPAN와 비교하면 약간 부끄러울 정도랄까요? godi_console로 확인해보니 164개의 라이브러리가 있군요.

GODI로 설치된 OCaml 라이브러리는 다음과 같이 로딩합니다. 예를 들어, Bitmatch라는 라이브러리 로딩하려면 다음과 같이 합니다.

OCaml 프로그램은 이론적으로 절대 크래시가 날 수 없습니다. 외부 모듈(C로 작성된 코드)를 호출한 경우가 아니면 죽을 수가 없게 타입 시스템 자체가 디자인되었기 때문입니다.

하지만 강한 타이핑(strong typing)하는 언어라도 직렬화(OCaml에서는 Linearization 용어 사용, 자바의 Serialization과 같은 개념)를 지원하면 타입 시스템을 얼마든지 깨먹을 수 있게 됩니다. OCaml은 Marshal 모듈을 사용해 직렬화를 하는데, Marshal 모듈을 이용하면 다음과 같이 'a 타입을 'b 타입으로 강제로 바꾸는 함수(C의 캐스팅)를 작성할 수 있습니다.




이렇게 작성한 후에 다음과 같이 int 타입을 float로 강제로 변환한 후에 덧셈을 하면 크래시가 발생하고 프로그램이 죽게 됩니다.

프로그래밍 언어의 특성 중 실용적인 관점에서 가장 중요한 요소 중 하나는 성능입니다. 요즘 동적 언어가 인기를 얻는 것을 보면 생산성이 성능보다 더 높은 점수를 얻고 있는 것 같긴 하지만, Python이나 Ruby를 .NET이나 JVM으로 포팅해서 HotSpot이나 JIT을 이용하려는 시도는 성능은 여전히 중요한 요소임을 반증합니다. (물론 .NET이나 JVM의 방대한 라이브러리를 재활용하고 다른 언어로 작성된 프레임워크를 사용하려는 목적도 큽니다.)

프로그래밍 언어 자체의 성능은 비교할 수가 없습니다. C 언어라도 컴파일러가 거지같으면 굉장히 느릴 수 있고, 옛날에 느리다고 욕먹던 Java도 근래 많은 최적화를 한 서버 JVM을 사용하면 C/C++과 유사한 정도로 성능이 올라가기도 하니깐요. 따라서 프로그래밍 언어 보다는 프로그래밍 언어의 구현을 놓고 성능을 비교해야 합니다.

그런데 벤치마크라는 게 컴파일러나 인터프리터 몇 개 갖다 놓으면 바로 비교가 되는 것이 아니고 또 별도의 벤치마크 프로그램을 통해 간접적으로 테스트해야만 합니다. 어떻게 벤치마크 할 것이냐를 놓고 이견이 많고 시끄러울 수밖에 없습니다. 어떤 언어는 과학 연산만 죽어라고 하는 벤치마크에는 매우 취약한 반면에 문자열 연산이 많은 벤치마크에는 좋은 성능을 보여줄 수도 있으니깐요.

어느 정도 신빙성이 있는지는 모르겠지만, Debian에서 프로그래밍 언어를 비교하는 벤치마크를 하나 제공하고 있습니다. The Computer LanguageBenchmarks Game인데, Gentoo나 Debian이 깔린 리눅스 머신에서 몇 가지 벤치마크의 성능을 순서대로 보여줍니다. 모든 벤치마크를 모든 언어에 대해 돌려보니, Java 6 -server의 성능이 인상적이고, 함수 언어인 Clean, Haskell GHC, OCaml 등도 상당히 좋네요.

IBM dW의 Crossing borders: Typing strategies beyond the Java model는 프로그래밍 언어의 타이핑 전략(typing strategies)에 대해서 이야기하고 있습니다. 상당수 개발자들이 프로그래밍 언어의 타이핑 생산성, 유지보수성 등에 상당한 영향을 미친다고 생각하고 있고, 자바 개발자들이 상당수 루비로 갈아탄 것도 이와 무관하지 않아 보입니다.

이 기사의 저자는 자바 타이핑에 대한 대안으로 서로 양극단에 있는 Ruby와 OCaml의 타이핑을 비교하고 있습니다. Ruby는 동적 타이핑을 하는 대표적 언어이고, OCaml은 정적 타이핑의 대표 주자인 ML 계열의 언어입니다.

프로그래밍 언어의 타이핑을 구분하는 방법은 몇 가지가 있는데, 정적/동적 타이핑, 강한(strong)/약한(weak) 타이핑이 일반적인 구분 방법입니다. 여기에 하나 덧붙이자면 명시적/암묵적 타이핑이 있습니다. 명시적 타이핑 언어는 자바나 C#처럼 모든 타입을 개발자가 적어줘야 하는 방식이고, 암묵적 타이핑은 OCaml이나 Haskell처럼 개발자가 일부 타입을 기입하지 않더라도 타입 추론을 통해 컴파일러가 나머지 타입을 찾아내는 방식입니다.

자바가 루비에 비해 생산성이 떨어지는 문제를 동적/정적 타이핑의 문제로만 볼 수 없는 이유는 자바와 OCaml을 비교했을 때 자바 이상으로 강력한 정적 타이핑을 제공하는 OCaml 코드가 자바보다는 루비에 가까운 간결함을 보이기 때문입니다.

근데 하나 분명한 것은 자바는 아니라는 것입니다. 루비도 좋고 OCaml도 좋고 장단점이 있지만 명시적 정적 타이핑하는 자바는 이제 수명이 다하고 있다는 것이 핵심이 아닐까 싶습니다. Spring, AspectJ, Hibernate 등 다양한 자바 기반의 거대 프레임워크가 존재하는 이유는 반대로 생각하면 자바만으로는 일반적인 어플리케이션 개발에 요구되는 메타프로그래밍을 쉽게 할 수 없기 때문입니다.

물론 워낙 개발자가 많은 자바 진영이다 보니 그리 쉽게 망하겠냐는 생각을 하실 수도 있겠지만, 자바를 다른 언어로 대체하려는 움직임은 자바 진영 내부에서 가장 먼저 논의되고 있습니다. 요즘은 JVM에서 동작하는 언어(JVML)에 대한 이야기로 뜨겁습니다. 함수 언어와 객체지향 언어를 결합한 Scala가 신예라면, JVM 용 스크립트 언어인 Groovy, Jruby, Jython 등은 이미 많은 유저를 확보했습니다. 그 외에도, Lisp의 현대판인 Clojure, CLR과 JVM에서 동시에 동작하는 Fan, Scheme JVM 버전인 SISC 등이 그야말로 자바를 따라잡기 위해 노력하고 있는 상황입니다.

자바는 이런 언어의 라이브러리를 구현하기 위한 시스템 언어 정도로 물러서고 어플리케이션 프로그래밍은 자바가 아닌 좀 더 생산성이 높은 언어로 하는 시대가 올지도 모르겠습니다.

얼마 전에 오픈소스화한 까멜레오 프로젝트의 첫 바이너리 릴리즈를 이번주 수요일로 잡고 열심히 정리 중에 있습니다. 원래는 지난 주에 릴리즈를 하려고 했으나 또 막판에 욕심이 생겨서 조금 더 안정화를 하려고 일주일 정도 일정을 미뤘습니다.

일단은 윈도 인스톨러(.msi 혹은 .exe 형태) 형태로 홈페이지에서 직접 다운로드 받아서 설치하실 수 있도록 만들고 있습니다. 그리고 별도의 위젯 사이트를 준비 중인데, 여기서 원하시는 위젯을 다운 받아서 설치하시면 됩니다. 위젯 사이트에 자기가 만든 위젯을 등록할 수도 있습니다.

까멜레오 관련 홈페이지

까멜레오 메인 홈페이지
까멜레오 프로젝트 블로그(영문)
까멜레오 오픈소스 홈페이지
까멜레오 메일링 리스트
까멜레오 커뮤니티 홈페이지(곧 개장)

까멜레오 개발자 서광열님
까멜레오 개발자 이인서님
까멜레오 개발자 전종환님
까멜레오 개발자 조치원님


블로그가 없는 분들은 생략했습니다.

참고: 오픈소스로 공개한 이후 최근에 북마크 위젯이 생겼습니다.

까멜레오는 주로 Python과 C로 작성되었습니다. UI와 위젯 작성은 파이썬으로 하고, 속도가 생명인 미디어 재생/분석 코드는 C로 작성되어 있습니다.  그런데, 프로젝트를 하다보니 코드를 C로 작성하면 아무래도 작성 시간도 오래 걸리고, 품질도 그리 높지가 않더군요. 특히, 메모리 깨먹는 버그나 멀티쓰레드 관련 버그는 정말 괴롭습니다.

최근에 이런 문제를 돌파해보고자 함수 언어인 OCaml을 까멜레오 구현 언어로 추가하기 위한 작업을 끝마쳤습니다. 특히, 비디오 처리(video processing) 코드를 OCaml로 작성해서 오류를 줄이고 작성 속도도 높여보자는 것이 가장 중요한 취지입니다.

기존 까멜레오 코드가 상당 부분 파이썬으로 코딩되어 있기 때문에 OCaml와 Python을 연결하기 위해 Pycaml 프로젝트를 가져다가 조금 고쳤습니다. OCaml과 Python이 직접 붙는 것은 아니고, Ocaml의 C 인터페이스를 이용해 Python/C API에 붙이는 방식으로 구현되어 있습니다.

아직 기본적인 데이타 타입 변환만 있고, Python의 list, tuple. dict와 OCaml의 list, tuple, assoc list 등을 변환해주는 코드 등이 부족한 상태라 사용이 그리 쉽지는 않은 상태입니다. 이쪽은 OCaml로 코드를 작성하면서 조금씩 추가해 나가려고 생각하고 있습니다.

일본 자바 유저 그룹(JJUG)에서 개최하는 Cross Comunity Conference 2008 에서 Scala를 주제로 한 세션이 2개 열리는군요. 내용은 당연히 일본어로만 진행된답니다-_-

http://www.java-users.jp/contents/events/ccc2008spring/



참고: 엔터프라이즈 어플리케이션 개발로 소개하는 Lift는 Scala 기반의 웹프레임워크라고 생각하시면 됩니다.

마소 원고 쓰면서 Scala를 가지고 놀다가 재밌는 사례를 발견했습니다.

val은 보통 변하지 않는 값(immutable)을 선언할 때 쓰는 키워드인데, 다음과 같이 선언을 했더니 오류가 발생하지 않고 x 가 1이 되더군요.



우변의 x + 1은 x가 아직 초기화 되지 않았기 때문에 오류가 발생해야 맞을 것 같은데, 신기하게 그냥 0으로 초기화되고 1을 더해서 x의 값은 1이 되었습니다. scala-user 메일링 리스트에 물어봤더니, Scala 인터프리터에서 위와 같이 선언하면 다음과 같은 클래스를 생성한다고 합니다.



x가 필드가 되기 때문에 x은 자동으로 0이 할당되고, x + 1은 1이 됩니다. 이건 구현상의 이슈고, Scala에서는 적절히 오류가 발생해야 맞을 것 같은데, 언어 명세에 어떻게 정의해놨는지 모르겠군요.

scala.user 메일링 리스트에 partial application에 대한 질문이 올라왔군요.



와 같이 함수 m을 정의한 후에 a와 c의 값을 정해주고 b만 인자로 받는 새로운 함수를 만들어내는 문제입니다.

Scala에서 이 문제에 대한 해답은



Scala에서 _ 는 partial evaluation을 하도록 만들어 줍니다.

참고: partial application과 비슷한 용어로 커링(curring)은 (A, B) => C를 A => (B => C)로 만들어 주는 방법을 말합니다. parital application과 커링은 구분해서 사용해야 합니다. LtU의 Currying != Generalized Partial Application?! 을 참조하세요.

5월 마소에 Scala 프로그래밍 언어를 소개합니다. Scala는 객제+함수언어를 지향하며 자방 가상 머신(JVM) 위에서 돌아가는 언어입니다. 얼마 전에 블로그에서 한 번 소개를 한 적이 있었습니다.

사실 기본적인 문법 및 HelloWorld 스타일의 예제만 소개만 해서는 어떤 언어나 비슷하기 때문에 Scala의 여러 특징 중에 어떤 점을 부각해서 글을 작성할지 고민을 했습니다. 일단 머리 속에 떠오른 몇 가지 아이디어는 다음과 같았습니다.



자세한 내용은 5월 호에^^;

까멜레어를 오픈소스화한 이후에 까멜레오 개발팀은 까멜레오 관련 모든 논의와 토론을 메일링 리스트와 트랙을 통해 하고 있습니다. 아직 시작은 미약하지만 영어 사용권 개발자들을 무시할 수 없기 때문에 모든 준비는 영어로 하는 것을 원칙으로 정했습니다. 따라서 오픈소스하기 몇 달 전부터 트랙의 티켓은 모두 영어 작성해 왔습니다.

사실 한국 사람들만으로 구성된 개발팀에서 지속적으로 영어를 사용해 커뮤니케이션하는 일이 처음에는 쉽지 않았습니다. 프로젝트 초기 셋업 때 영어로 작성을 하다가 중간에 한 번 효율성을 문제로 한글로 복귀한 적도 있었습니다. 오픈소스 논의가 본격화되면서 다시 영어로 돌아가기는 했지만요.

처음 영어로 전화했을 때 가장 큰 문제점은 한글로는 더 자세히 적었을 버그 정황 설명을 영어로는 1-2줄에 다 축약해 버린다는 점이었습니다. 뭔가 부족하다고 느끼면서도 어떻게 표현할지 몰라서 막연히 전달되리라 생각해 버리는 것이죠.

지금은 영어로 개발 관련 의사소통을 하는 일이 어느 정도는 자연스러운 문화로 정착이 되었습니다. 물론 이런 습관은 수십 개의 오픈 소스 프로젝트 메일링 리스트에서 원하는 질문을 하고 답변을 받고, 의견을 제시해야 하는 오픈소스 개발자에게 반드시 필요한 자질이라고 생각됩니다.

대기업에서는 영어 사용에 대한 기사가 많이 나오던데, 개발팀의 주소통 언어로 영어를 사용하는 또 다른 예가 있으면 알려주세요.

얼마 전에 인사이트 출판사의 부탁으로 김석준 님이 번역하신 Programming Erlang 리뷰를 맡았는데 지금 최종 마무리를 하고 있습니다. 원래 월요일에 리뷰를 마치고 택배로 보냈어야 하는데 까멜레오 릴리즈 준비에 치여서 깜빡하고 있었습니다. 퀵으로 보내드려야 할 듯.

저는 병행/분산 프로그래밍, 외부 함수 호출, 파일/소켓 등 IO, 멀티 코어 CPU 프로그래밍 쪽 챕터를 집중으로 리뷰를 했습니다.

Programming Erlang 번역본은 원서를 그대로 살리기 위해 직역투의 번역이 많았는데, 특히 "그", "이것" 등 과도한 대명사 사용이 조금 번역투의 느낌을 풍겼습니다. 하지만 전체적인 내용은 별다른 오역 없이 무난히 번역되어서 얼랭(erlang)에 관심가진 개발자라면 별다른 두려움 없이 번역서를 읽으셔도 괜찮으리라 생각됩니다.

김석준 님이 여러 감수자들의 의견을 종합해서 반영한 후에 조만간 책이 출간될 것으로 예상됩니다. 많이들 읽어주시고, 얼랭 뿐만 아니라 함수 언어에 대해 관심을 가져보시면 어떨까 합니다.

전종환 님이 까멜레오 위젯 만들기를 주제로 글을 올려주시고 계십니다.

Chameleo Widget 만들기 1
Chameleo Widget 만들기 2
Chameleo Widget 만들기 3

아직 문서화가 많이 부족하긴 합니다만, 까멜레오 위젯이 어떤 방식으로 만들어지는지 간단히 맛을 보실 수 있는 글이 되겠습니다.

저도 시간나는 대로 튜토리얼과 매뉴얼 작업에 들어갈 예정입니다.

오픈소스 까멜레오 프로젝트 페이지가 오픈했습니다. 아직 문서화를 많이 하지는 못한 상태이긴 하지만 서브버전을 통해 소스를 내려 받은 후에 빌드해서 프로그램을 실행시켜 볼 수 있습니다. 까멜레오 전체 구조, 위젯 만들기 등 문서는 앞으로 차츰 추가해 나갈 예정입니다.

개발 메일링 리스트도 만들었습니다. 구글 그룹스를 이용하면 되는데 다음과 같이 세 개의 메일링 리스트가 있습니다.

[1] http://groups.google.com/group/chameleo : 까멜레오 전반에 관련된 논의를 하는 곳입니다. 일반적인 질의/응답도 이 메일링 리스트로 하시면 됩니다.

[2] http://groups.google.com/group/chameleo-commit : 까멜레오 소스 코드 커밋 메일이 오는 곳입니다.

[3] http://groups.google.com/group/chameleo-bugs : 버그 관련된 리포트를 받을 수 있는 곳입니다.


까멜레오 개발팀은 IRC에도 상주하고 있습니다. irc.freenode.net으로 접속하셔서 #chameleo 방으로 들어오셔서 질문하시면 시간나는대로 즉각 응답해 드리고 있습니다.

개발자들이면 당연히 어떤 어플리케이션이나 프레임워크를 들여다 볼 때 어떤 기반 기술로 이루어졌는지 궁금해 하실 것입니다. 까멜레오는 100% 오픈소스 라이브러리들만 사용해서 만들었습니다. 까멜레오에서 중요하게 사용되는 컴포넌트는 다음과 같습니다. UI를 비롯해 거의 대부분의 요소를 파이썬 바인딩을 통해 사용하고 있습니다.



까멜레오는 비디오 위에 자연스럽게 UI를 보여주기 위해 OpenGL 기반의 3D GUI 툴킷인 GLUX를 만들었습니다. GLUX는 GTK+와 QT처럼 (물론 훨씬 간단합니다) 일반적인 2D UI를 표현할 수 있고, 3D 애니메이션과 반투명(translucent)한 UI를 구현할 수 있게 해주는 파이썬으로 작성된 라이브러리입니다.

또한 비디오 메타데이터를 처리하는 부분이 까멜레오가 GStreamer 등 로우레벨 미디어프레임워크와 차별화하는 부분입니다. 일례로, 간단한 자막 등을 표시하기 위해 자막을 GStreamer 파이프라인(DirectShow의 필터그래프로 유사한 개념)을 통해 흘려보는 방식은 비디오 메타데이터를 처리하는 최선의 방법으로 보기 어렵습니다. 까멜레오는 자막을 비롯한 비디오 태그, 각종 메타데이터를 쉽게 붙이고 처리할 수 있는 프레임워크를 제공합니다.

자막을 단순히 보여주기만 하는 것이 아니라 자막 데이터를 받아서 빈칸을 만들어 받아쓰기 위젯을 만들 수도 있고, 자막을 검색할 수도 있고, 어려운 단어는 자동으로 인터넷 사전을 뒤져서 뜻을 보여주는 등 간단한 메타데이터 하나로도 무궁무진한 어플리케이션을 만들어낼 수 있습니다.