Static Type Inference for Ruby

Posted 2008. 3. 26. 04:29
저는 정적 타입 시스템 옹호자이기 때문에 루비, 파이썬 등의 스크립트 언어의 성공을 항상 못마땅하게 생각하던 사람입니다. 농담이고요. 동적인 스크립트 언어가 성공하면서 동적 타이핑이 많은 연구와 노력이 들어간 정적 타이핑보다 훨씬 좋은 것처럼 생각하는 사람들이 늘어나면서 안타까웠던 것은 사실입니다.

실제로는 루비나 파이썬 같은 동적 스크립트 언어도 정적 타이핑을 통해 여러 가지 이득을 볼 수 있습니다. UMD에서 나온 OOPSLA08에 제출한 Static Type Inference for Ruby도 그런 시도 중의 하나라고 볼 수 있습니다. 여기서 제시한 DRuby는 다음의 특징이 있습니다.


1. GLR(Generalized LR) 파서로 루비 문법에서 disambiguation을 위한 규칙을 분리해 내고 확장하기 쉽게 만들었다.

2. RIL(Ruby Intermediate Language)를 정의해 소스 코드를 쉽게 분석할 수 있도록 하였다.

3. 타입 어노테이션 언어와 타입 추론 시스템을 도입해 루비 프로그램의 타입을 정확히 알 수 있도록 하였다.


참고로 근래에는 정적 타이핑과 동적 타이핑을 적절히 결합하려는 시도가 많이 있습니다. soft typing, dynamic type, quasi-static typing, gradual typing 등으로 용어도 다양하네요.

Monad tutorials timeline

Posted 2008. 3. 19. 02:34

4월 마소 원고 주제를 하스켈을 이용한 STM(Software Transaction Memory)으로 잡고 마무리를 하고 있습니다.

지금은 모나드(monad)에 대한 설명을 추가하려고 모나드 튜토리얼을 좀 찾아보고 있었습니다. 모나드는 추상적인 개념이다보니 하스켈 입문자들이 가장 어려워 하는 부분이기도 하고 깊이 있게 이해하기가 쉽지 않은 부분입니다. 과거에는 찾아볼 자료도 별로 없었는데 최근에 하스켈 개발자가 늘고 있어서 그런지 2006, 2007년도에 모나드 관련 글이 굉장히 많이 나왔더군요. Monad tutorials timeline에 보시면 모나드 튜토리얼이 시대별로 어떻게 변천해 왔는지도 보실 수 있습니다.

튜토리얼에는(혹은 튜토리얼이기 때문에) 보통 모나드의 이론적인 배경인 카테고리 이론(category theory)과의 연관 관계를 설명하는 부분이 빠져 있어서 살짝 아쉽네요.

A taste of Haskell

Posted 2008. 3. 18. 03:17
Simon Peyton-Jones가 2007년 OSCON에서 발표한 A taste of Haskell 발표를 봤습니다. 함수형 언어 Haskell을 소개하는 자리인데 1편, 2편 각각 90분씩 총 3시간의 분량으로 비함수형 프로그래머들에게 함수형 언어의 장점과 특징을 소개하고 있습니다. 슬라이드도 여기에서 보실 수 있습니다.

xmonad라는 X 윈도용 윈도 매니저 프로그램을 이용해 함수형 언어에서 간과하기 쉬운 IO 사용이나 외부 함수(foreign function) 호출 등도 다루고 있습니다.

사용자 삽입 이미지

참고로 SPJ 이 분은 GHC(Glasgow Haskell Compiler)를 비롯해 함수형 언어 이론 및 구현에 많은 업적을 남기신 분입니다. 함수형 언어의 실무와 이론을 모두 해본 사람으로 함수형 언어에 대해 누구보다도 열정이 강하고 할 말이 많은 사람이기도 합니다.

이쪽 분야에 관심을 가지면서 보니 참 똑똑한 사람들이 많더군요 ㅠ.ㅠ







뱀다리: OSCON 하니깐 생각나는데 까멜레오 프로젝트도 올해 3월 OSCON에서 발표를 신청했었습니다. 영어로 열심히 설명을 적었는데, 아직 오픈소스를 못하고 있어서 참가 여부가 매우 불투명한 상태라서 문제이지만요.

프로그래밍 언어 Vala

Posted 2007. 12. 10. 12:23
까멜레오 프로젝트에서 GStreamer를 비롯한 GLib 기반의 프로젝트들을 많이 가져다 쓰는 관계로 GLib이나 여기에 포함된 GObject 등의 라이브러리를 쳐다볼 일이 많이 있습니다. GObject는 GLib에서 분리된 (여전히 같은 패키지로 존재하긴 하지만) 라이브러리인데, 다음과 같은  두 가지 목표가 있습니다.

1) C 개발자에게 객체지향 프로그래밍을 할 수 있는 환경을 줍니다. 물론 컴파일러 지원이 전혀 없는 순수한 C 라이브러리인 관계로 Objective-C나 C++과 비교해서는 적어줘야 하는 템플릿 코드가 상당히 많은 편이고 그게 초보 개발자에게는 진입 장벽이 되는 편입니다.

2) 다른 언어로 바인딩을 용이하게 해줍니다. 파이썬이나 루비 등 다른 언어에서 C 라이브러리 함수를 호출하려면 인자나 리턴 값의 타입 변환을 해줘야 하는데, GObject 바인딩을 용이하게 해줍니다. GObject 기반으로 작성된 C 라이브러리는 codegen이라는 코드 생성 프로그램을 이용하면 쉽게 파이썬 바인딩을 만들어 낼 수 있지요.

GLib 런타임 타입 시스템은 나름대로 장점이 있지만 역시 제일 불편한 점은 C 언어가 객체 지향이 아닌 관계로 클래스 하나 만들기 위해서 복잡한 템플릿이 필요하다는 점입니다.

GObject, GLib, GTK+ 기반의 GNOME 프로젝트는 이런 문제점을 해결하기 위해 Vala라는 프로그래밍 언어를 만들고 있더군요. Vala는 언어적으로는 C#과 상당히 유사한(대놓고 베낀) 언어이고, 특이한 점은 타겟 런타임이 .NET CLR이나 JVM이 아닌 GObject라는 사실입니다. Vala는 기본적으로 GObject를 런타임으로 사용한 C 코드로 변환을 하고, 다시 C 컴파일러를 이용해 컴파일하는 방식입니다.

프로그래밍 언어를 만드는 데 있어서 무시할 수 없이 많은 비용이 들어가는 부분 중에 하나가 런타임 작성입니다. 그래서 수많은 언어들이 방대한 언어 런타임을 거저 얻을 수 있는 CLR이나 JVM을 선택하고 있는 이유고요. Vala는 GNOME 프로젝트에서 시작한 만큼 기존에 GObject로 작성된 C 라이브러리를 그대로 사용할 수 있게 하기 위해 GObject를 언어 런타임으로 선택했군요.

작년 가을에 시작해서 아직 버전이 0.1.5 밖에 안 되는지라 안정성은 보장할 수 없다는 게 문제입니다. 많은 사람들이 참여해서 발전을 이루면 좋을 것 같은데 어찌될지 모르겠군요. 아직 언어 명세도 100% 작성이 안 된 것 같아서 프로그래밍 언어로서의 특징보다는 GObject를 이용한 C 코드 생성이라는 구현 이슈에 더 치중한다는 느낌이 듭니다.

2007년 12월 12일 업데이트:

Vala Tutorial
이 나왔습니다.




Lambda the Ultimate

Posted 2007. 12. 3. 03:02
블로그 제목을 "프로그래밍 언어 이야기"로 바꾸고 첫 포스팅입니다.

컴퓨터를 전공하는 후배들을 만나면 컴퓨터 쪽 정보를 얻기 위해 주로 가는 사이트나 구독하는 블로그, 잡지에 대해서 많이 물어봅니다. 사실 저는 관심 분야가 다양한 편이라 한 사이트를 정기적으로 방문하거나 하는 일은 잘 없습니다. (금방 열정이 식기 때문에...) 대신 주로 특정 주제를 가지고 검색을 했다가 관련 사이트들을 들어가보는 방식으로 새로운 것들을 보는 편이고요.

그런 저에게도 새로운 글이 올라오면 항상 체크하고 꼼꼼히 읽어두려고 노력하는 사이트가 하나 있는데 Lambda the Ultimate이라는 사이트입니다. 번역하면 [람다 최고]인 이 사이트는 주로 프로그래밍 언어 전공자들이 프로그래밍 언어에 대한 최신 소식을 전하고 자기들끼리 논쟁도 벌이는 곳입니다. 람다는 함수형 언어의 이론적 바탕이 된 람다 칼큘러스(lambda calculus)의 람다를 지칭하는 말이고요.

물론 [람다 최고]라는 이름에서 알 수 있듯이 주로 함수형 언어 관련 연구자들이 많이 포진해 있기 때문에 함수형 언어를 상당히 옹호하는 글이 많이 올라옵니다. 또한 주로 PL 전공자들이 많다보니 최신 논문이나 이론을 소개하는 등 상당히 학구적인 곳이기도 하고요. 물론 PyPy나 LLVM, IronPythonm EcmaScript 4 등 우리가 자주 듣는 프로그래밍 언어 관련 프로젝트에 대해서도 근황을 전하고 자기 의견을 피력하기도 합니다.

또 메뉴에 보면 Getting Started 항목도 있어서 프로그래밍 언어 관련 이론을 공부할 수 있는 기본적인 책이나 사이트들을 소개해 주고 있습니다. 학교에서 PL 전공하지 않는 이상 접하기 힘든 내용들을 많이 볼 수 있어서 초보자들에게는 매우 귀중한 자료입니다.

PL하면 단순히 자바나 파이썬 같이 새로운 언어를 만들어내는 것만으로 생각하시는 분이 많은데, PL 관련 이론은 프로그래밍 언어의 의미(semantic)를 정형적으로 정의하는 것부터 시작해서 타입 이론(type theory), 구현(implementation), VM이나 컴파일러와의 연계 등 많은 이슈들을 다루거든요.

저는 원래 주어진 프로그램을 분석해서 자동으로 오류는 찾아주는 정적 분석(static analysis)에 관심을 가진 후에 프로그래밍 언어 쪽도 아주 조금 공부하려고 마음을 먹게 되었는데 지금은 잘못된 디자인(대표적인 언어 C 언어)를 고치기 위해 많은 노력을 들이는 정적 분석보다는 처음부터 제대로 설계하자는 "언어 설계" 쪽에 더 관심이 많이 갑니다.

아직 아는 것보다 모르는 것이 더 많기에 공부하는 데로 조금씩 정리해서 써보려고 합니다.

함수형 언어 C# 3.0

Posted 2007. 11. 22. 17:27
마이크로소프트 리서치(MS Research)의 Andrew Kennedy가 슬라이드 만들어 놓은 것을 보니 C# 3.0은 함수형 언어라고 주장하고 있군요. 헤스켈 같은 함수형 언어의 전유물이었던 퀵소트 예제의 C# 버전을 보여주고 있습니다.

사용자 삽입 이미지

아래 헤스켈 코드와 비교해도 손색이 없군요. 물론 타입을 조금 더 써줘야하긴 말입니다.

qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

비함수형 언어에서 lambda

Posted 2007. 11. 21. 01:39
뒷북일 수 있지만 실무에서 C#으로 프로그래밍을 하지는 않는 관계로 오늘에서야 C# 3.0에서는 뭐가 바뀌었는지 잠깐 살펴보았습니다. LINQ처럼 DB 연동이 주라고 생각하고 있었는데, 의외로 타입 추론(type inference)나 람다 표현식(lambda expression) 같이 함수형 언어의 영향을 많이 받은 부분들도 보이더군요.

특히 3.0에 추가된 람다(lambda)는 2.0에 추가된 후에 상반된 반응을 얻었던 익명 대리자(anonymous delegate)을 보강한다는 측면에서 추가되었다고 합니다. 쉽게 말해서 네 자 이상의 이름을 걸러내는 필터를 만들기 위해 C# 2.0에서는 다음과 같이 코드를 작성합니다.

Func<string,bool> filter = delegate(string name) {
return name.Length > 4;
};


반면에 lambda를 사용한 C# 3.0의 코드는 다음과 같습니다.

Func<string, bool> filter = x => x.Length > 4;


x => x.Length > 4라는 부분이 바로 람다 표현식인데, x라는 인자를 하나 받아서 x.Length >4 를 리턴한다는 의미입니다. 위 예제만 보고 처음에는 식 밖에 못 오는 줄 알았는데 { } 사이에 집어 넣으면 구문도 사용할 수 있더군요.

C#의 lambda는 단순히 익명 대리자의 문법을 바꾼 것만은 아닌 듯 합니다. x => x.Length 와  같이 x의 타입을 명시해주지 않아도 타입 추론을 통해 찾아주는 부분은 기존 익명 대리자에 비해서는 발전하였네요.


여담이지만 파이썬 사용 시에 제일 불만이었던 것이 lambda입니다. 파이썬의 lambda는 함수형 언어도 아닌 주제에 말 그대로 람다 식(lambda expression)이어서 하나의 식만 사용할 있습니다.

사실 일반적인 함수형 언어야 프로그램 전체가 하나의 식으로 되어 있고 이를 연산(evaluation)하면서 프로그램을 수행하기 때문에 lambda expression은 무척 자연스러운 방식입니다. 반면에 프로그램 수행이 명백히 문장 중심인 파이썬이 정작 lambda에서는 표현식 하나만 쓸 수 있는 것이 항상 불만이었습니다. 조금만 복잡해져도 할 수 있는 일이 없으니 lambda를 익명 함수(anonymous function)로는 사용하지 못하는 경우가 많았거든요.

파이썬 3000에서도 이 부분에 대한 개선은 없다고 하는데, 파이썬은 쓰면 쓸수록 뭔가 아쉬운 느낌이 드는 언어입니다.

파이썬 마을 번개 후기

Posted 2007. 8. 11. 01:37
오늘 오후 8시 야후 10층에서 있었던 파이썬 마을 입추 기념 번개에 다녀왔습니다. 파이썬 모임에는 처음 참석했는데, 퍼키님이 파이썬 3000에 어떤 변화가 있을지 슬라이드와 함께 직접 파이썬 3.0a1을 시연하면서 보여주셨습니다. (퍼키님 수고하셨어요.) 뒷풀이도 참석했으면 좋았을 텐데, 다음주 제품 데모도 있고 일정이 빡빡해서 아쉬움을 뒤로 하고 돌아왔습니다.

파이썬 3000의 의도는 펄6처럼 거대한 변화를 시도하기 보다는 파이썬 초창기 디자인 실수를 하위 호환성을 포기하는 한이 있더라도 수정하겠다는 것입니다. 언어 전반에 걸쳐서 다양한 변화가 일어나지만, 개인적으로 가장 큰 변화라고 생각하는 부분은 str과 unicode 타입의 구분을 없애고 모든 문자열이 unicode가 된 부분입니다. 대신에 bytes 타입을 도입해서 raw data를 처리할 수 있는 방법은 열어 두었습니다. 최근에 유니코드 관련 구현이 완료되었다고 하는군요.

이번 달 말이면 파이썬 3.0 첫 알파 릴리즈가 나온다고 하니 관심 있으신 분은 미리 받아서 조금씩 익숙해지는 것도 좋을 듯 합니다. 파이썬 3000의 변화에 대해 궁금하신 분은 올해 초에 PyCon에서 귀도가 발표한 동영상을 참조하시기 바랍니다.
파이썬에서 모듈을 임포트할 때는 현재 패키지의 위치에 따라 상대적으로 모듈을 임포트합니다.

예를 들어 glux.draw.pixmap 모듈에서 import cairo하면 glux.draw.cairo, glux.cairo, cario 순으로 임포트를 시도합니다. 만약 glux.draw.cairo라는 모듈이 우연히 존재했다면 원래 의도했던 cairo 모듈을 임포트하는 게 쉽지 않은 일이 됩니다. sys.modules를 통해서 직접 모듈을 찾아오거나, glux.draw.cairo를 glux.draw.gluxcairo 같은 이름으로 변경해야 합니다. 그래서 파이썬 개발자들은 보통 패키지 내부 모듈이라도 표준 라이브러리와 겹치는 이름을 사용하길 꺼려합니다.

다행히 파이썬 2.5부터는 PEP328에 정의된 from __future__ import absolute_import를 사용하면 절대 임포트(absolute import)를 기본으로 만들 수 있습니다. 절대 임포트를 사용하면 위와 같은 상황에서 glux.draw.cairo가 아닌 cairo 모듈을 임포트할 수 있습니다. 이후에 나올 파이썬(파이썬 3000 포함)은 절대 임포트가 기본이 되고 import .cairo와 같은 형태로 점을 찍어서 상대 임포트를 한다고 하는군요.

까멜레오 개발하면서 상대 임포트에 따른 의도치 않은 모듈 임포트를 겪은지라 포스트를 남겨봤습니다.

파이썬 마을 입추 기념 번개

Posted 2007. 8. 7. 21:33
파이썬 마음 입추 기념 번개를 신청했습니다. 이런 저런 모임에 나가보려고 노력은 하지만 항상 뒷북(마감 끝나고 나서 신청하기)만 치다가 이번에는 대략 순위권에 들었습니다. 파이썬을 중심으로 벌써 몇 개월째 까멜레오 프로젝트를 진행하고 있는데, 정작 파이썬 커뮤니티에는 한 번도 못 나가봐서 아쉬웠는데, 이번 기회에 회포를 풀겠군요. 파이썬 전문가분들을 뵙고 그 동안 궁금했던 걸 물어봐야겠군요. 참석 후 소식 전하겠습니다.

Using Haskell from Python with ctypes

Posted 2007. 8. 7. 03:01
Recently, I am trying to make it possible to write Chameleo plugins in Haskell. Chameleo is wirtten mostly in Python and there is no direct method to call Haskell functions in Python. However, Python is the most powerful glue language in the world(Okay, maybe next to Perl), it is not hard to use both Haskell and Python at the same time within an application. PythonVsHaskell shows an example which compiles the Haskell code with ghc and generates a dll file. Python ctypes can call these functions in the DLL as if they are normal C functions.

MissingPy seems to be another option for calling Python code from Haskell (but not calling Haskell code from Python). The recent version is 0.8.9, but it seems to be still in beta quality.

파이썬 데코레이터

Posted 2007. 7. 28. 03:56
오래간 만에 포스팅입니다. 요즘 3-4시간 밖에 못자는 야근을 거듭하느라 블로깅 할 여유가 전혀 없었습니다. 근데 또 한동안 글을 안 쓰니깐 손이 근질근질해서 이제는 짧은 내용이라도 하루에 1-2개 정도는 반드시 남겨야 겠다는 다짐을 해봅니다. 민감한 문제는 안 건드리고 주로 가벼운 프로그래밍 얘기만 하는 걸로요.

요즘 파이썬으로 코딩하는 일이 많아지면서, 파이썬 언어를 조금 더 진지하게 보고 있습니다. 관련해서 마소 8월호에 파이썬 데코레이터(decorator)를 이용한 파이썬 언어 확장을 주제로 글을 쓰기도 했습니다. 조금 있으면 나올테니깐 관심 있으신 분들은 서점에서 잠깐 보시고요. 까멜레오 프로젝트에도 파이썬 데코레이터를 자바의 어노테이션(annotation)처럼 활용하고 있습니다.


예를 들어서 어떤 함수를 수정해야 겠다고 표시해 놓을 때 다음과 같은 @fixme 데코레이터를 사용합니다.

   @fixme("""Take 'border-width' property into account.""")
    def __init__(self):
        ...


코드를 작성하다가 머리가 아파서 아직 구현을 안 한 경우 나중에 구현을 다 한 줄 알고 착각하는 걸 방지하기 위해 다음과 같이 @notimplemented 데코레이터를 붙여놓습니다.

    @notimplemented
    def reorder_child(self, child, position):
        ...


코드를 짜기는 짰는데, 이거 구현이 엉망이라 잠시 해당 메서드를 부르더라도 아무 일도 하지 않게 만드려면 @nop만 붙여주면 됩니다.


    @nop
    def do_many_things(self):
        ...


조금 복잡한 어노테이션으로는 C#의 new와 override 변경자(modifier)를 파이썬으로 데코레이터로 구현해 쓰고 있습니다. @new는 상위 클래스의 메소드를 오버라이드하지 않는 새로운 메소드를 정의함을 의미하고, @override는 반대로 반드시 상위 메소드를 오버라이드한다는 의도를 드러냅니다.


데코레이터가 좋은 점은 코드를 봤을 때 가독성을 높여주는 효과도 있지만, 실제로 코드 수행 시에 여러 가지 일을 해줄 수 있다는 점에 있습니다. 예를 들어 @fixme(comment)는 함수가 호출될 때 콘솔에 comment 내용을 WARNING으로 출력해줘서 항상 이 함수를 고쳐야하겠구나라는 경각심을 가질 수 있게 해줍니다. 반대로 @notimplemented를 붙여놓고는 다 구현한 줄 알고 안심한 개발자에게는 해당 메서드가 불리자 말자 구현 안했다고 에러 메시지를 낸 후 배째고 수행을 중지합니다. @nop은 함수 바디를 무시하고 아무 것도 안 하고 리턴하도록 바꿔버리고요.

@new와 @override는 파이썬의 동적인 특징을 최대한 활용해 메서드가 불리는 순간에 self의 클래스를 구한 후에 클래스의 슈퍼클래스들을 타고 올라가서 같은 이름의 메서드가 있는지를 찾아냅니다. 이렇게 찾아낸 정보로 만약 @new인데 상위 클래스에 같은 이름의 메서드가 있거나 @override인데 상위 클래스에 해당 메서드가 없으면 에러를 출력해 주는 것이죠.

별 것 아닌 확장이지만, 컴파일 언어와 달리 조금만 방심하면 버그가 있어도 모른 채 넘어가는 파이썬 코딩과 디버깅에는 많은 도움이 됩니다. 다음은 @new와 @override의 소스 코드입니다. 버그가 있을지도 모르니 유심히 살펴보시고 더 좋은 아이디어 있으면 환영합니다.


class NoOverrideMethodFoundError(Exception):
    """Exception class for override decorator."""

    def __init__(self, message):
        self.message = message

    def __str__(self):
        return repr(self.message)

def override(func):
    """If there is no suitable method found to override,
    throw an exception."""

    def new_func(self, *args):
        try:
            getattr(new_func, "__override_checked__")
            new_func.__override_checked__ = True
        except:
            method = None
            for base in self.__class__.__bases__:
                try:
                    method = getattr(base, func.__name__)
                    break
                except AttributeError:
                    pass

            if method == None:
                raise NoOverrideMethodFoundError, \
                        "%s is not found to in %s' base classes." \
                        % (func.__name__, self.__class__.__name__)

        return func(self, *args)

    return new_func

#------------------------------------------------------------------------------
# @new
#------------------------------------------------------------------------------

class AccidentalOverrideError(Exception):
    """Exception class for new decorator."""

    def __init__(self, message):
        self.message = message

    def __str__(self):
        return repr(self.message)

def new(func):
    """Prevent accidental method overriding.

    When you use @new decorator, your intention is to declare a
    new method which does not accidentally override the base method.
    """

    def new_func(self, *args):
        try:
            getattr(new_func, "__new_checked__")
            new_func.__new_checked__ = True
        except:
            for base in self.__class__.__bases__:
                try:
                    method = getattr(base, func.__name__)
                    raise AccidentalOverrideError, \
                    "%s.%s accidentally overrided the method %s.%s." \
                        % (self.__class__.__name__, func.__name__, \
                        base.__name__, func.__name__)
                except AttributeError:
                    pass

        return func(self, *args)

    return new_func

Haskell 독서중.

Posted 2007. 5. 20. 06:46
주말 동안에 Haskell, The Craft of Functional ProgrammingThe Haskell School of Expression을 열심히 읽고 있습니다. 2001년도에 프로그래밍 언어(PL) 수업 들으면서 한참 함수형 언어에 빠져들어서 샀던 책인데, 최근에 다시 한 번 읽어보는 중입니다.

최근 프로젝트에서 파이썬을 주 언어로 사용하고 있는데, 제대로 된 타입 시스템이 없는 파이썬 코드에 영 적응이 안 되던 차에 강력한 타입 시스템을 제공하는 헤스켈에 대한 향수가 생겼달까요.

그때만 해도 컨셉은 좋지만 실용적으로 쓰기에는 무리라고 판단을 내렸었는데, 다시 보는 헤스켈이 생각보다 성능이 좋군요. 헤스켈을 바이너리로 컴파일해 주는 GHC(Glasgow Haskell Compiler)의 성능도 상당히 향상된 것으로 보이고요.

심볼 연산(symbolic computation)이 주가 되는 실무에 일부 활용해 보려고 고민 중인데, 관련 소식을 업데이트 하겠습니다.

마소 6월 원고: FFI

Posted 2007. 5. 18. 21:51
오늘 마소 6월 원고를 마감했습니다. 지난 달 원고 쓴지 얼마 안 된 것 같은데 원고 마감은 왜 이렇게 빨리 돌아오는지! 이번달 주제는 외부 함수 인터페이스로 정했습니다. 자바에서 C를 부르고, 파이썬에서 C를 부르고 하는 것들을 말합니다.

외부 함수 인터페이스(FFI, Foreign Function Interface)

근래의 소프트웨어들을 살펴보면, 보통 한 가지 이상의 언어로 작성됨을 알 수 있다. 복잡한 프로그램의 요구 사항을 만족시키기 위해 여러 프로그래밍 언어의 장점만을 취하려는 전략이다. 대표적인 예가 주 개발은 자바로 하고, 성능이 필수적인 일부 모듈만 C 언어로 작성하는 것이다. 자바 언어의 안정성과 방대한 라이브러리를 취하면서, 동시에 C의 높은 성능을 얻을 수 있기 때문이다. 자바와 C를 연결하기 위해 사용하는 인터페이스는 JNI(Java Native Interface)라 불리는데, 자바뿐만 아니라 대부분의 언어들이 외부 함수를 호출할 수 있는 인터페이스(FFI, Foreign Function Interface)를 제공하고 있다. 이 글에서는 자바(JNI)와 파이썬(Python/C API)을 통해 FFI의 개념과 사용 방법을 살펴보자.


자세한 내용은 6월호가 나오면 보실 수 있습니다.


Haskell에 대한 오해?

Posted 2007. 5. 18. 04:57
현대 함수형 언어의 대표격인 Haskell은 이제 대부분 개발자가 이름 정도는 들어본 언어가 되었죠?
그리고 Haskell의 강력함을 소개하는 예제로 빠지지 않고 등장하는 것이 바로 C 언어로 정확하게 구현하려면, 머리 잡아 뜯으며 디버깅해야 한다는 퀵소트(QuickSort)를 다음과 같이 매우 직관적이고 손쉽게 할 수 있다는 것이죠.

사용자 삽입 이미지

위 간단한 예제는 Haskell의 List Comprehension이나 Generic Recursion 같은 함수 언어 특유의 여러 특징을 잘 보여줍니다.

그런데 요즘 주변 친구들에게 Haskell 언어 아냐고 물어보면 이런 대답이 돌아옵니다. 그거 퀵소트 잘하는 언어 아냐? 그냥 퀵소트 잘하는 언어. 아무 짝에도 쓸모 없는 퀵소트만 잘하는 언어...

프로그래밍 언어도 보다 적극적인 마케팅이 필요한 시대입니다.

함수형 언어 공헌자들.

Posted 2007. 5. 18. 04:50
함수형 언어는 대부분 학계에서 출발했습니다. 대학 다닐 때 학과 복도를 보면 컴퓨터 공학 발전에 지대한 공헌을 하신 분들의 사진이 죽 걸려 있었습니다. 그 중에 함수형 언어 공헌자들 사진만 뽑아봤습니다.

사용자 삽입 이미지
Lazy 함수 언어들을 만들고 Miranda 시스템 만든 David Turner

사용자 삽입 이미지
타입 추론(type inference)과 다형 타입(polymorphic type)을 도입한 함수형 언어 ML의 창시자 Robin Milner

사용자 삽입 이미지
고차 함수 등의 개념을 강조한 함수 언어인 FP를 만든 John Backus
 
사용자 삽입 이미지
첫 번째 순수 함수형 언어 ISWIM을 만든 Peter Landin


사용자 삽입 이미지

Lisp을 만든 John McCarthy



사용자 삽입 이미지

Lambda Calculus를 만든 Alonzo Church

음. 부러워라.

Tuple이라는 단어의 기원

Posted 2007. 5. 14. 03:50
함수형 언어의 대부분과 파이썬 등은 튜플(tuple)을 내장(builtin) 타입으로 가지고 있습니다.

("Salt", 100)

과 같이 서로 다른 타입을 가지며 순서가 중요한 타입입니다. 보통은 불변형(immutable) 타입이고요. 함수에서 2개 이상의 값을 리턴할 때 유명하게 쓰입니다. 이 튜플(tuple)이라는 단어가 어디서 왔을지는 별로 생각을 안 해보고 쓰고 있었는데 알고보니 엄청 단순한 거였더군요.

(a, b) -> pairs
(a, b, c) -> triples
(a, b, c, d) -> quadruples
(a, b, c, d, e) -> quintuples
(a, b, c, d, e, f) -> sextuples

이렇게 보면 2개 짜리 pair를 제외한 모든 단어가 tuples 비슷하게 끝납니다. 그래서 tuple이라 불린답니다.

파이썬 -i 옵션

Posted 2007. 5. 9. 14:57
항상 쓰는 프로그램인데도 새로운 기능을 발견하는 경우가 종종 있습니다. 최근에 진행 중인 프로젝트에서 파이썬을 메인으로 쓰고 있는데, 모듈의 테스트를 위해 __name__이 '__main__'인지 확인하고 UI 쓰레드를 만드는 코드가 있습니다.

UI 프로그램이라 전체 테스트를 자동화시킬 수는 없고 기초적인 셋업이 끝나면 바로 파이썬 인터프리터가 뜨면 좋겠다고 생각을 했습니다. 그럴 때 쓰는 용도로 -i 옵션이 있더군요. python -i script.py라고 실행시키면, 스크립트 실행이 끝난 후에도 파이썬 인터프리터를 살려주더군요.

자바스크립트 다시보기

Posted 2007. 3. 20. 02:17
어김없이 마소 마감일이 다가와서 급히 원고를 작성했습니다. 항상 "기본으로 돌아가자"를 신조로 삼는지라 이번 주제는 Ajax와 각종 위젯 제작 언어로 또 다시 각광을 받고 있는 자바스크립트를 재조명해봤습니다.

특히

1) 자바스크립트의 함수가 제1클래스이며 클로저를 지원한다는 사실
2) 자바스크립트의 독특한 오브젝트 생성 방식 및 속성 상속

에 대한 이야기를 중심으로 실었습니다. 지난 달에는 루비를 중심으로 클로저 이야기를 했었는데, 1번은 지난 달 내용이랑 약간 오버랩 되는 부분이 있네요.

내용을 공개했으면 좋으련만, 엄연히 저작권을 대가로 돈을 받는지라 흑 ㅠ.ㅠ 아래 내용은 박스 중에 하나입니다.



자바스크립트에 대한 오해의 시작

Ajax가 자바스크립트를 다시 한 번 메인 무대에 올려놓기 이전에는 대부분의 개발자가 자바스크립트는 일반적인 프로그래밍 언어에 미치지 못하는 단순한 스크립트 도구라고 생각했다. 즉, 정규 프로그래밍 언어보다는 HTML의 보조 도구 정도로 인식되는 것이 일반적이었다.

이런 오해가 생긴 이유는 네스케이프와 썬마이크로시스템즈 사가 자바스크립트를 포지셔닝한 전략에 있다. 이들은 클라이언트 프로그래밍에 있어서 자바스크립트가 자바의 경쟁자로 자리매김하길 원치 않았기 때문에, 자바에 비해 자바스크립트를 열등한 언어로 알려야만 했던 것이다. 당시 자바스크립트의 기능을 제대로 알릴 수 있었다면, 자바스크립트는 좀 더 일찍 주목받았을지도 모른다.

Douglas Crockford의 <JavaScript: The World's Most Misunderstood Programming Language>를 번역하였습니다. <JavaScript: 세상에서 가장 오해가 많은 프로그래밍 언어>를 눌러주세요.

요즘은 JavaScript를 가장 많이 쓰고 있는데, 요즘이야 Prototype, dojo, jQuery, Mochikit, YUI 등 3 세대 Ajax 라이브러리가 쏟아져 나오면서 인식이 많이 달라졌지만, 예전에는 초보자들이나 쓰는 프로그래밍 언어 같지 않은 간단한 스크립트라는 인식이 강했던 것이 사실이었죠. 이 글은 Ajax가 유행하기 전에 JavaScript에 대한 그런 오해를 불식시키고자 작성된 글입니다.

« PREV : 1 : 2 : 3 : NEXT »