귀도가 구글로!

by

파이썬 프로젝트의 창시자이자 BDFL인 귀도 반 로섬이 오늘
구글에 입사했다는 발표를 했습니다.
앞으로 구글에서 일과시간의 50%를 파이썬 개발에 투자할 수 있고
그 대부분은 Python 3000을 위해서 쓸 것이라고 하네요.
무척 회사가 마음에 드는 모양입니다. 🙂

파이썬에 ElementTree 통합~

by

세상에 이보다 쉬운 XML 파서/제너레이터가 있을까 하는 생각이
들 정도로 단순한 API를 제공해 주는 프레드릭 런드의 ElementTree가 드디어 파이썬에 통합되었습니다. 그동안 프레드릭의 고집 때문에 다른 사람들이 토론하기를 꺼리고 있었는데 마침 이번 토론에서는 프레드릭이 적극적으로 참여하게 돼서 이제 드디어 파이썬 안에도 쓰기 쉬운 XML 파서가 생겼습니다. 이히히. 귀도가 간단하게 “pythonic”이라고 해 줄 정도로 파이썬의 기본 이념에 충실한 것이 아닌가 싶군요~

요렇게 하면 간단하게 xml 조작해서 쓰기까지! — 파이썬 2.5부터 제공됩니다. 🙂

*가 와일드카드로 쓰인 이유

by

*(U+002A)는 꽤 오래 전부터 와일드카드로 쓰이고 있었는데, 근래에 와서는 검색엔진이나 컴퓨터와 별 관계없는 수업에서도 *가 와일드 카드로 쓰는 것이 종종 목격이 되기 시작했습니다. (와!)

과연 그 유래는 무엇일까! 곰곰히 생각해 보고 이리 저리 생각해본 결과 *의 아스키 코드값에서 그 답을 찾을 수 있었습니다.

*의 정체는 삶과 우주와 모든 것에 대한 답, 42였던 것!

(Don’t panic! 너무 진지하게 생각하지 마세요 =3=33)

정적 링크한 darcs 패키지

by

그동안 버전 관리를 안 하고, 저자의 하드디스크를 rsync하는
방식으로 희한하게 배포를 해 왔던 Io가 엊그제부터 분산 버전 관리 시스템인 darcs를 쓰기 시작했습니다. (그동안 소스코드 버전관리를 안 한 이유는 여기에 적힌 까다로운 조건을 만족하는 것을 찾느라 그랬답니다.) darcs는 haskell로 작성되어 있고, 엄청나게 속도가 느린 것을 제외하면 기능상으로는 흠잡을 것 없이 아주 뛰어난 버전 관리 시스템인 것 같은데, 개인적으로 너무 불편한 것이 아직 ghc가 FreeBSD/amd64로 포팅이 안 되는 바람에, 제 컴퓨터에서는 쓸 수 없다는.. 그런 문제가 있었습니다. 흑흑 Y_Y 다들 커밋한거 받아보고서는 좋다~ 느리다~ 걱정된다~ 하고 있는데 amd64쓰는 죄로 소스도 못 받아보고 완전 왕따가 돼서..

그래서 amd64의 32비트 에뮬레이션 기능을 이용해 보려고 이렇게 저렇게 한참 노력해 봤지만, 동적 링킹에서는 도저히 어떻게 하는지 감이 잘 안 와서.. 결국은 포기하고 i386 머신에서 정적 링크를 해서 만든 패키지를 그냥 amd64에 까는 방법으로 했습니다.
그래서 결과로 나온 darcs-1.0.5.tbz 으흐흐.. 혹시 저처럼 또 왕따당하는 분이 있으실까봐 올려 봅니다. 그런데, ghc가 -static을 넣으면 정적 링크를 해 주는 것처럼 매뉴얼에는 써 있는데, 한참을 해 봐도 정적 링크를 안 해주더군요. 그래서 결국에는 ghc를 verbose mode로 돌려서 나오는 링크 커맨드를 그대로 쳐서 -static만 추가해서 하는 방법으로.. =.=

한글로 Io 프로그래밍

by

요즘 Io로 시간날 때 이것 저것 장난치며 놀고 있는데, 모든 것이 다 교체가 가능하다는 말에, 한글로 프로그래밍도 제법 가능할까 하는 생각이 들어서, 한번 쑥 바꿔봤습니다. 흐흐. 우선, 기본적으로 Io는 한글이 식별자로 쓰이지 못하기 때문에 패치를 해야하는데, IoLexer.c에서 글자 읽는 부분을 패치를 했습니다. (아직은 임시로 테스트해보기 위한 흉악한 패치입니다. =3)

그래서 이제 코드가 어떻게 보일지 무척 궁금해서 얼마 전에 코드 레이스 관객 문제를 Io로 풀었던 것을 고쳐 봤습니다. 우선, 원래의 Io코드는 이렇게 됐습니다. (창준형이 수정해 줌)

이제 한글로 프로그래밍하려면, 기본 객체들이나 메쏘드들 이름을 일일이 바꾸는 초기화 루틴이 필요한데, 그 부분을 이렇게 넣어 봤습니다.

번역은 대충 일단 간단하게만.. 흐흐;; 그러면 위의 개미수열 소스가 이렇게 됩니다.

이히히. 아무래도 대/소문자 구분이 없다보니 약간 코드가독성이 떨어지는 것 같기도 하고.. 한데, 나름대로 교육용 언어로는 괜찮을 것 같기도 하고… 띄어써야 할 부분이 문법과 다른 게 좀 거시기하고… (애매하군요 -.-;;)

오픈소스 커리큘럼이 있다면

by

오늘 SoftExpo 2005 부대행사로 열린 오픈소스 데스크탑 컨퍼런스의 부대행사로 (-.- 여러겹;;) OSS 커미터 원정대 모임이 있었습니다. 흐흐흐. 오랜만에 강남 가려니 어찌나 먼지;; 가급적이면 앞으로 강남 모임은 삼가해야하겠다는 생각이 흐흐;;

여러 얘기가 오가는 도중에, 오픈소스 프로젝트에 참가하는 방법을 대학 커리큘럼에서 가르치는 곳은 없냐는 얘기를 어느 분이 꺼내셔서 머디 먼 집에 돌아오는 길에 멍하니 생각해서 실라버스로 한번 만들어봤습니다. 🙂 (시험 전날이라 별게 다 재미있다-.-)

과목명: 오픈소스개발실습

  • 기본정보: 3학점, 주2시간 오프라인 강의
  • 수강대상: 컴퓨터과학전공 2학년(2학기)
  • 수업목표 및 개요: 오픈소스 개발은 비교적 쉽게 참여할 수 있으면서도 여러가지 형태의 진보된 개발 방법을 습득하고 연습할 수 있는 좋은 기회이자, 흥미를 느끼고 지속적으로 기여하는 경우 많은 경험을 할 수 있다. 일반적인 오픈소스 프로젝트들에 여러 형태로 기여하고 참여할 수 있는 방법과 그에 필요한 여러가지 기술들을 소개한다. 그리고, 실제로 관심 있는 오픈소스 프로젝트에 참여하여 실습해본다.
  • 선수과목: 필수/없음, 권장/C프로그래밍,자료구조,시스템프로그래밍
  • 성적평가방법: 중간(실기) 25%, 과제 50%, 퀴즈1회 15%, 수업외 참여 10% (수업기간 내에 있었던 버그보고 등의 관련 메일/URL을 제출)
  • 교재 및 참고문헌: 주교재 없음
  • 수업 일정:
    • 1주 – 오픈소스의 정의와 소개, 개요
      – 수강신청 확인 및 변경
    • 2주 – 개발 과정 개요
      – 일반휴학 접수 마감
    • 3주 – 버전 컨트롤 시스템: CVS와 Subversion 실습
    • 4주 – 버그 트래킹 시스템: Bugzilla, Trac, GNATS, 메일로 보고하기 실습
    • 5주 – 오픈 소스 라이선스
    • 6주 – 오픈 소스의 특징적 버그 추적 기술, 패치 제출, 스타일의 관례
      – 학기 1/3선, 퀴즈
    • 7주 – More 관례: 빌드, 배포, 버전, 문서화, 기여자 참여 과정, 번역 등
    • 8주 – 중간고사: (실습 시험) 버그 추적, 패치 제출, follow-up
      – 학기 1/2선
    • 9주 – 사례연구: 주요 오픈소스 프로젝트 2가지, 소규모 오픈소스 프로젝트 2가지
      – 수강철회기간, 졸업신청 및 연기신청
    • 10주 – 프로젝트 시작 안내 및 진행 방법 설명
    • 11주 – 진행 상황 발표: 대상 프로젝트 선정과 간단한 프로젝트 소개, 작업할 내용 소개
      – 학기 2/3선
    • 12주 – 진행 상황 발표 및 아이디어 교환: 작업할 내용의 1차 패치를 버그트래커에 제출한 후 그 내용을 소개 (11주 과제)
    • 13주 – 진행 상황 발표: 다른 사람의 패치들에 follow-up한 다음에 개선된 패치를 제출한 후 그 내용을 소개 (12주 과제)
    • 14주 – 진행 상황 발표: 11주에 제출한 자기의 패치에 대한 가급적이면 최종판의 개선된 버전을 제출한 뒤 소개 (13주 과제)
    • 15주 – 프로젝트 최종평가: 자신이 제출한 패치를 적용한 프로그램 스냅샷과 가상의 릴리스 어나운스를 만들어서 제출.
    • 16주 – (없음)
      – 기말고사 기간

으흐흐… 뭐 프로그래밍 실습 같은 비슷한 과목을 대체하는 형태도 좋고.. 그런대로 해볼만 할 것 같기도 해요 =3=33

마지막 채플

by

저희 학교에서는 졸업하기 위해서 채플을 4학기 이수하도록 되어있습니다. 출석만 하면 이수가 되는 것이지만, 출석을 잘하기가 쉽지가 않아서.. 벌써 학교를 몇년 다니는데도 못 끝내고 있었지요 =.=;;

이번 학기가 마지막으로 4번째 학기였는데, 이번 학기에는 전출을 했기 때문에 오늘 종강 채플이 마지막 애플이었습니다. 학부 재입학을 안 하는 한은 인생의 마지막 채플이라고 생각하니 나름대로 감격스럽고 그렇습니다. -ㅇ-;; 1학년 때는 들어오기 그렇게 싫었던 채플도 나름대로 뭔가 정도 가고 아하하;;

채플이 복학하고 나니 바뀐 것도 제법 있었습니다. 1, 2학년 때에는 좌석도 딱딱하고 노래한다고 일어서라고 그러고 앞에서 연설하는 것도 무척 재미없어서 맨날 들어가서 숙제나 하고 그랬습니다. 그런데, 복학하고나니 대강당이 새단장을 쫙 해서 좌석도 상당히 편해졌고, 프로그램도 신경을 많이 써서 누구에게나 감동을 줄 수 있을 만한 연설들이 많았습니다.

지금 생각나는 것으로는 청소년 위원회의 최영희 위원장의 강의가 가장 인상 깊었는데, 30년 넘게 노동운동과 양성평등운동을 하시던 분이라 그런지, 경험에서 우러나오는 여러가지 이해하기 쉬운 사례들을 들려줘서 지금까지는 그냥 막연하게 알고 있었던 양성평등에 대해 보다 넓게 이해할 수 있었습니다. 옛날에 매일 전경들이랑 싸우던 학생운동 동료분이 지금은 아들이 전경이 되어서, 곧 있을 농민 상경 시위 때문에 잠을 못 이루고 걱정을 하더라는 얘기도 정말 와닿았구요.. 상대방을 이해하기가 그렇게 쉽기도 하구나 생각을 했습니다. 🙂

그 외에도 주로 방송/언론 관련 동아리 소속 학생들이 나와서 명사들과 대화하는 대화 채플이라는 것도 흥미로웠는데, 제가 들어갔던 시간에는 《하루가 소중했던 사람들》이라는 책을 지은 김혜원 권사님이 오셨었습니다. 사형수 교화는 정말 대부분의 사람이 이해하기가 쉽지 않은 굉장히 어려운 것인데, 대화에서 우러나오는 30년동안의 경험들을 들으면서 나름대로 여러가지 인간적인 감동들을 얻을 수 있었습니다. 집안에서 아드님과 가사에 대한 얘기를 하는 것도 재미있었구요.. 🙂 묵묵히 가사를 맡으시는 어머님들도 속으로 가사를 싫어하면서 가족들을 원망하는 마음도 있다는 것을 알게 되어서 지금이라도 알게돼서 다행이라는 생각이 들었습니다. 또 하나 대화 채플에서 흥미로웠던 것은, YBS에서 나온 학생이 2학년인데도 굉장히 말을 빠르게 하면서도 조리있고 귀에 잘 들어오게 한 것이었습니다. 흐흐 나도 말을 좀 잘 했으면 좋겠네 하는 생각이 깊게 들었습니다.;;

채플은 나름대로 강제로 종교행사에 참가시킨다는 비난을 받기도 하지만, 저야 뭐 병특 하는 동안에 다른 사람과 잘 어울리는 것에 대한 훈련을 많이 받아서 이제 별 불만에 없게 되었습니다. –;;;; 채플이 끝나서, 후련하기도 하고 섭섭하기도 하지만.. 결코 다시 듣는 일은 없기를;;; -O-

코드레이스 다녀왔어용

by

051126-0004

대안언어축제에서 인기있었던 코너를 분리해서 새로운 행사로 만든 코드레이스를 했습니다. 이번에는 준비기간도 짧고, 학기중이라 자봉분들과 자주 만나지도 못하고 후다다닥해서 막 정신이 없었네요.. 리허설때도 여러가지 했어야 했는데, 학교 시험하고 겹쳐서 당일날 가서야 삽질을.. ㅠ.ㅠ

이번 대회에서는 참가자들의 프로그램에 대한 acceptance test를 계속해서 자동으로 채점을 해야했기 때문에, 자동채점 프로그램과 그를 공시하는 점수판 프로그램이 중요했습니다. 그런데, 그 전까지 특별히 제대로 돌아가는지 테스트도 못해보고 당일 아침에 별의 별 희한한 에러를 다 만나가며 수정하느라 좀 전반부 거의 대부분의 시간을 제대로 진행하지 못한 문제가 있었습니다. 대회가 진행되는 trac과 svn, 해설용 vnc 접속, 점수판, 채점들도 모두 같은 노트북에 세팅했었는데, trac과 점수판이 받아들이는 요청이 엄청나서 로그가 막 우루루루루 올라가는 판에 vncviewer 12개가 떠 있으니까.. 노트북이 로드가 80까지 올라가서 계속 멈추는 바람에 또 난감해하고.. 하여간 여러모로 해설을 할 수 있을 만한 맥락이 조성이 안 돼서 그 부분에 대해서는 정말 아쉬움이 남습니다. 그래서 이 부분에 대해서 다음부터는 해설자는 해설만 계속 하고, 옵저버와 trac/svn/스코어보드 유지를 담당하는 기술적인 자봉을 따로 둬서 해결하는 것으로 뒷풀이 때 의견이 모아졌습니다.

이번 행사에는 C++팀이 4군데, C#팀이 1군데, Python팀이 2군데, Ruby팀이 2군데, Java팀이 2군데 해서 모두 12팀이 참가를 했습니다. 생각보다 C++의 비율이 엄청 높았는데, 처음 기획 때는 동적 언어들이 너무 유리하지 않을까 해서 무척 고심을 해서 동적 언어들이 너무 유리하지 않은 방향으로 가도록 초기 문제를 조정했었습니다. 그 영향인지 동적 언어를 쓰는 팀들이 속도가 C++에 비해서 크게 나지 않았던 것이 약간 아쉽지만, 적당히 평형을 유지했던 것 같습니다. 🙂 초반기에는 중앙대 동아리에서 단체로 출전한 “밥묵자”라는 팀이 C++로 굉장한 리드를 했었는데, 이 팀에서는 다른 여러 프로그래밍 대회의 경험이 많아서 그런지, 경진대회에 적합한 코드를 빨리 만드는 것을 잘했습니다. 그런데, 후기에 타입이 여러가지로 늘어나거나 evaluation 규칙이 바뀌는 등의 기존의 디자인을 벗어나는 요구사항들이 나오기 시작하자, 역시 경진대회를 많이 연습한 팀인 연대의 “액션가면사주세요”가 엄청나게 유연한 C++ 코드를 무기로 계속 만점가도를 달려서 결국 우승하게 되었습니다.

김형용님께서 찍으신 사진입니다.

기획하던 단계에서의 생각은, 아무래도 요구사항이 많이 바뀌는데다가, 알고리즘이 크게 어려운 것이 필요한 문제가 없고 거의 디자인 문제였기 때문에 경진대회 준비팀들이라고 특별히 유리할 것은 없다고 생각했었습니다. 그런데 아무래도 문제를 빨리빨리 풀고, 발생하는 난관들을 잽싸게 해결하는 부분에서 경진대회팀들이 많이 익숙해 있어서 유리하지 않았나 싶네요. 2위를 한 “Effect”팀은 독특하게도 C#으로 출전하셨는데, MonoDevelop을 굉장히 익숙하게 다루시는 모습이 아주 인상적이었습니다. 1위가 C++이고 2위가 C#이라니 정말 충격이지요.. -O-;

다른 팀들도 다들 잘 해주셨는데, 문제 출제에서 약간 문제가 있어서 초기에 너무 요구사항들이 한꺼번에 나가서 상당히 혼란스러웠음에도 불구하고 금방 적응하고 빨리빨리 해결하고 그러셔서 적지않이 놀랐습니다. 역시 코딩 고수이 이렇게 많구나!

이제, 코드레이스 준비는 다 끝났으니(-O-;;;;), 본격적으로 다음엔 재미있는 코드레이스가 될 수 있을 것 같습니다. 좀 더 좋은 코드레이스를 위해 창준형이 말한 두가지가 집에 오는 길에 계속 생각이 났습니다. 아직 마땅한 좋은 생각은 없지만~ 계속 생각해 봐서 2회는 더욱 좋은 대회로.. 🙂

  • 1,2위 팀 뿐만 아니라 모두가 집에 가면서 나도 이겼다 하는 생각을 갖고 돌아갈 수 있게 하는 방법은 없을까
  • 축구나 야구처럼 선수들이 재미있기 보다는 관객들이 즐길 수 있고 배울 수 있는 흥미로운 대회를 만들 수는 없을까

몇가지 대회 자료입니다. (여기 있는 것 외의 trac 안의 데이터 등은 곧 소프트웨어진흥원 홈페이지에 공개될 예정입니다.)

물론 채점 프로그램과 점수판 프로그램은 zlib/libpng 라이선스을 적용하여 다른 곳에 사용하실 수 있습니다.

오픈룩 방문객 분석~

by

요새 구글 통계가 인기이길래~ 저도 한번 해 봤습니다. +_+ 호홍; Firefox가 Firebird이던 시절에 해본 통계에 비해서 엄청나게 많은 변화가 있었습니다. 깜짝 놀랐어요! ^_^

웹 브라우저 점유율


2003년에는 MSIE가 85%에 육박하고, Firebird가 7.2% Mozilla가 6.0%에 불과했습니다. 이제는 위의 그래프에서 같이 이제 OpenLook에서는 Firefox가 무려 31%로 올라왔습니다! 우와! 한편, Mozilla는 이제 0.6%로 내려가서 모질라 계열 브라우저에서는 Firefox로 완전히 넘어간 것을 알 수 있었습니다. (소수 의견–요새 유행하는! ^_^;;–으로 Safari가 0.86%, Opera가 1.56% 등이 있었습니다.)

플랫폼 점유율


한편, 플랫폼 점유율은 2년전과 거의 같았습니다. 윈도우 계열 사이에서의 비율이 2000이상의 버전이 거의 압도적으로 늘어났지만 윈도우 자체의 비율은 변화가 아주 미미했습니다. 기타 운영체제해서는 리눅스는 거의 같았지만, FreeBSD가 약간 감소하고, MacOS X가 약간 증가하였습니다.

국가별 비율

한국에서 방문하는 분들의 비율이 얼마나 될지도 상당히 궁금했는데요~ 87%정도가 한국에서 오신 접속자이셨습니다. 그 외에는 미국이 4.45%, 일본이 1.15%, 중국이 0.91% 등등이었고, 팔레스타인, 세네갈에서도 1분씩 오셨군요 -ㅇ-;

도메인별 비율

아마도 리버스가 등록된 IP에 대해서 검사한 것 같은데, 모든 IP에 대해서 리버스를 등록하는 미국의 ISP인 팩벨이 가장 비율이 높군요.. 그 외에도 비교적 많은 IP에 대해서 리버스를 등록하는 서울대와 카이스트가 그 다음으로 각각 1.2%, 0.8%를 차지했습니다. 으흐흐. 아무래도 우리나라에서는 리버스를 전혀 등록 안 하는 것이 통상적이라서 도메인 통계는 크게 의미는 없는 것 같네요..

단골 손님 비율

링크를 따라서 오시거나, 검색엔진을 통해서 처음 오신 분들과 자주 오시는 분들의 비율도 흥미로왔습니다. pxr.openlook.org도 등록해 놓았는데, 거기는 아직 홍보가 안 되어서 그런지, 단골 손님 비율이 거의 1% 이하였는데, openlook은 다행히도 44% 정도가 자주 오시는 분들이군요. 에헤헤 요새 글도 별로 없는데 감사합니다. 뒹굴 _-_

오픈소스 범용 VM

by

틀린 부분을 찾으시면 알려주세요. 🙂

최근 몇년새에 CPU가 하도 빨라져서 그런지, 범용VM이 트렌드로
떠오르고 있는 듯 합니다. 90년대 말의 Java의 유행의 뒤를 이어서
.NET(ECMA CLI)가 여러 언어들이 동시에 통합된 인터페이스로 라이브러리를 공유하는 것을 VM의 주요 특징으로 뽑아내기 시작한 것이 대중적으로는 그 시초라고 볼 수 있겠습니다. 한동안 GNU lightning이나 Psyco같은 VM을 포함하지 않은 JIT 시스템이 뭔가 비전을 제시해줄 것만 같았지만, 결국엔 JIT에서 높은 효율을 내기 위해서 빠질 수 없는 타입 인퍼런스, 메모리 참조 단축, 가비지 컬렉션 같은 것 때문에, 돌아가는 상황을 완전히 제어할 수 있는 VM 수준의 것이 있어야 안정하게 좋은 성능을 낼 수 있었기에 결국은 이렇게 범용 VM의 유행이 왔을 것이라고 봅니다.

Parrot

오픈소스 범용VM으로 처음 알려지기 시작한 것은 아무래도 parrot이라고 할 수 있겠습니다. parrot은 스크립트 언어를 위한 범용VM을 표방하고, 인스트럭션들을 굉장히 스크립트 언어의 주요 작업들에 직관적으로 대응될 수 있을 정도로 간단한 환경을 만들어 주었습니다. 그렇지만, 너무 원대한 꿈을 꾸면서 만든터라, 새로운 아키텍처로의 이식이 다른 VM들에 비해서 쉽지 않고, 내부적인 구조가 너무 어려워서 처음 보는 사람들이 길을 잃어버리기 좋은 환경이라 새로운 개발자의 참여가 적어서 결국은 지금의 상태처럼 다른 사람들은 베이퍼웨어라고 부르지만, 자기들은 곧 릴리스한다고 우기는 상태가 된 것 같습니다.

Mono

그 다음으로 뜬 범용VM은 Mono라고 할 수 있겠는데, 물론 Mono는 ECMA CLI의 스펙을 구현한 것이기 떄문에 VM의 디자인은 독창적인 것은 아니지만 Microsoft제품과의 호환성을 충분히 확보함으로써, 일단은 사용자 뿐만 아니라 개발자들의 관심을 많이 얻었습니다. Mono는 Parrot이 헤메는 과정을 어느정도 보고 나서 개발이 되었기 때문에, 초기부터 너무 큰 꿈을 그리는 것보다 돌아가는 작은 것들을 엮어놓고 나중에 좋은 것으로 부분 부분을 교체하는 방식으로 발전이 되어 와서 결과적으로 쓸만한 것이 나오는 시간이 훨씬 적게 들었고, 그에 따라 지금과 같은 성공을 거둘 수 있었습니다. Mono는 가비지 콜렉터로 boehm-gc를 쓰고 있는데, 이게 겉으로나 소스에서나 보이는 것에 비해서 훨씬 포터블하지가 못합니다. 포팅하기도 쉽지가 않고요.. 그래서, 결국은 Mono는 마이너 플랫폼에 포팅할 때 boehm-gc가 상당한 걸림돌인데, 곧 Mono에서 자체적으로 만든 gc를 도입한다고 하니까 기대를 걸만 하겠습니다. 🙂

LLVM

LLVM은 2002년 정도부터 다른 VM들과는 달리 최적화를 위한 플랫폼이 주요 목적으로 개발되었습니다. 이 VM을 만든 사람은 석사,박사학위 논문의 주제로 LLVM을 썼는데, 박사학위 논문은 “광범위 데이터 구조 분석과 최적화”라는 제목인데, 그에 걸맞게 LLVM은 머신 코드를 실행하면서 데이터 구조적으로 발생하는 여러가지 최적화 가능 지점들을 자동으로 발견해서 최적화를 수행합니다. 대표적인 예로 strcat의 두번째 인자로 변하지 않는 스트링 상수가 들어가는 경우에 memcpy로 교체해버리는 것이 있는데, 이런 것이 컴파일타임에 수행되는 경우 상당한 부작용을 유발할 수도 있다는 점을 생각해 보면, valgrind같이 틈새시장을 굉장히 잘 노린 기발한 착상이라고 할 수 있겠습니다.

LLVM은 valgrind처럼 머신코드를 직접 받아주는 것은 아니고, LLVM의 바이트코드로 생성된 코드를 만들어주는 C/C++ 등의 컴파일러를 사용해서 컴파일하면 그 코드를 실행하면서 분석하고 최적화를 해 주게 되어있는데, 최적화 자료를 토대로 컴파일할 때 아예 머신코드로 컴파일해버리는 기능도 있어서, mono의 머신코드 컴파일러보다도 한단계 더 발전한 것이라고 볼 수 있습니다. LLVM은 현재 PyPy같은 여러 다른 언어 프로젝트에서도 LLVM 코드를 생성하는 기능이 들어가고 있다는 점에서 많은 사용자들을 확보해가고 있어서 앞으로 아주 장래가 기대가 됩니다.

NekoVM

NekoVM은 올해 나온 것이라 다른 것들에 비해서 상대적으로 역사가 짧습니다. NekoVM도 Parrot 만큼이나 굉장히 고수준의 인스트럭션을 갖고 있어서 스크립트 언어를 만들기가 굉장히 간단하게 되어 있습니다. 그리고, NekoVM은 VM 코드가 라이브러리 코드로 단지 50KB 내외밖에 안 된다는 점에서 고속의 실행 코드가 필요한 고수준 도메인 언어에서 뭔가 아주 쓸모가 있어 보입니다. 그런데, NekoVM은 Parrot보다도 더 고수준으로 올라가 있어서 속도를 위해서는 저수준 VM보다는 약간의 희생이 있고, 런타임 최적화를 수행하지 않기 때문에, 장기간 돌더라도 크게 빨라지지는 않습니다. 게다가, 라이선스가 다른 VM과는 달리 GPL이 적용되어 있기 때문에, 기업 사용자들이나 X11/BSD 계열 라이선스를 쓰는 오픈소스 프로젝트들에게 어필하기가 어렵다는 점이 걸림돌로 작용합니다. 만약 GPL을 감수할 수 있는 환경이라면 특히 웹 애플리케이션의 템플릿용 언어로는 굉장한 효율을 발휘할 수 있을 것 같네요.

이제 VM이 이렇게 점점 늘어감에 따라서, 새로운 언어를 만들거나 독특한 동적 실행환경을 만들기에는 점점 좋아지고 있습니다. DSL(Domain Specific Language)로 프로그램 내부에 스크립팅 기능을 추가하면서도 빠른 속도를 유지할 수 있고, 여러가지 다른 언어들을 하나의 VM 위에서 서로 호출하고 참조할 수 있다는 점에서 옛날 패러다임과는 다른 색다른 시도를 할 여지가 많아지고 있는 것 같아서 기대가 됩니다! 🙂

알림: 이 외에도 GNU Portable .NET이나 여러 오픈소스 JVM들이 있겠지만, 거기는 관심이 없어서 자세히 안 본터라 안 적었습니다. =3=3