洪民憙 (홍민희) 블로그

이하의 글은 2011년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

잘 알려져있다시피 Python과 Perl은 상이한 철학을 가지고 있다. 하나의 문제를 해결하는데 여러 방법이 있을 수 있다고 하는 Perl의 철학은 오래되었고 또 매우 널리 퍼져 Ruby의 철학에도 깊은 영향을 주었다.

There’s more than one way to do the same thing.

반면 Python의 철학은 하나의 문제를 해결하는데는 가장 명확한 하나의 답이 존재한다는 쪽이다.

There should be one — and preferably only one — obvious way to do it.

내가 비록 Python만큼 Perl에 능숙하지는 않지만, 철학에 있어서는 Perl에 마음이 기운다. 아무튼 갑자기 철학 얘기를 꺼낸 이유는 따로 있다. Perl과 Python의 이러한 철학과 다르게, 막상 구현체의 종류에 있어서는 상대의 철학에 더 가깝다는 생각이 들어서이다.

Python의 경우 JVM 위에서 돌아가는 Jython이 나온 이후 본격적인 다중 구현체가 존재하는 언어1가 되어 현재는 성숙한 구현체만 따져도: 가장 널리 쓰이는 레퍼런스 구현인 CPython, CLR에서 돌아가는 IronPython, 다른 각도의 병렬 프로그래밍 가능성을 보여준 Stackless Python, Nokia의 S60 플랫폼에서 동작하는 Python for S60, CPython 3.x에서 머지될 것 같은 Unladen Swallow, Python으로 Python을 구현하여 부트스트랩에 성공한 PyPy2 등 다양한 것들이 존재하는 상황이다.

반면 Perl 5는 현재까지 명백히 단일구현체이고3, Perl 6의 경우 레퍼런스 구현인 Rakudo부터가 아직 명세의 모든 부분을 충족할만큼 성숙하지는 않은 상태라 Python의 여러 구현체가 평균적으로 매우 성숙해있는 것을 감안하면 아직은 좀더 지켜봐야하는 상황이다.

항상 함께 비교되곤 하는 Ruby만 해도 MRI, JRuby, IronRuby, MacRuby, Rubinius 등의 여러 구현체가 있는데 유독 Perl만 단일구현체에서 벗어나지 못하고 있는 듯하다. 이렇게 된 원인을 짐작하자면 역시 언어 명세가 복잡해서 구현이 힘들기 때문이 아닌가 싶은데,4 내가 Perl 명세를 잘 알지 못하므로 이에 대해 자세히 아는 분이 계시다면 자세히 설명해주시면 좋을 것 같다.

언어의 표현력이 중요하다고는 생각하지만 역시 이런 걸 생각해보면 Lisp이나 Io처럼 극미니멀리즘으로 가는게 편한 것 같기도 하고.


  1. 생각해보면 Lisp 방언들을 제외하면 C, C++, Java, C# 정도 말고는 다중 구현체가 존재하는 언어가 그렇게 많지는 않다.

  2. Python 창시자 GvR도 밀어주고 있어서 새로운 레퍼런스 구현이 될 공산이 크다.

  3. Perl 6가 나온 마당에 언어 구현자가 Perl 5를 구현할 동기가 생기지 않는 것도 Perl 5의 새로운 구현이 나오기 힘들게 만드데 한몫 하는듯 싶다.

  4. 일단 파서부터가 Python이나 Ruby는 명세에 존재하는 BNF를 가지고 파서 제너레이터나 파서 컴비네이터를 쓰면 비교적 쉽게 달성 가능하지만 Perl은 필터 등의 기능 때문에 그렇게 간단하게 구현될 수 있는 문법이 아닌 것으로 알고 있다.