언어를 만들고 싶다고 한참이나 생각했었지만, 코딩을 반복할 수록 그게 얼마나 어려운 일이진 실감하게된다.

참조우선순위
—-
방금전에 파이선이 좋다고 하는 글을 올렸는데, 사실 언어자체로 보면 이상한 점이 꽤 많다.

x = 2 
def F():
x = 1
def G():
print x
G()
F()

처음 이 코드를 봤을 때 직감적으로 와 닿질 않았다. 브레이스 “{} ” 너무 익숙해져 있기 때문인가보다. 파이선 코드를 자꾸만 보고있으면 브레이스가 없어진 것이 소스를 더 이쁘게 해주는 것 같다는 느낌이 들기도 한다.

그건 그렇고 위의 소스를 실행하면 화면에는 “2”가 찍혔었다. 최신버전에서는 그러지 않는다.

변수 참조 순서가 로컬(함수 G의 안쪽), 글로벌 (맨 바깥의 x=2), 그리고, 내장된 변수의 순서이기 때문에 F 안쪽에 있는 변수는 참조되지도 않는다.

맨 처음에 언어를 설계할 때 빼먹은 몇 가지가 지금에 와서 발목을 잡고있다.

한글
—-
자기들이 적어놓은 글에는 잘된다고 자랑을 해놓았지만, 쓰다보면 걸리는 일이 꽤 많다. XML 쪽 기능을 보강해주는 xmlplus라는 놈을 설치해봤는데, 역시 한글 인코딩에서 문제가 발생했다.

자바가 몇년에 걸쳐서 해온 일을 똑같이 반복하는 것처럼 보인다. 자바도 맨처음에는 데이터베이스에서 뭔가를 꺼내고 넣고, 할 때마다, new String(xx.getBytes(..), “..”) 를 반복해주었었다. 그리고… 지금도 그래야만 하는 엔진들이 몇개인가 있다.

일본인이 만들었다는 Ruby는 일본어에 대해서만큼은 그런 문제가 없겠지.

약한참조
—-
올해 초에 자바가상기계를 들여다봤었다. 사람이 볼 것이 아니다.

엔지니어의 “자기만족”을 위해서 도전해볼만한 작업도 아니었다. 그것은.. 왕.. 노가다다. 혹시 가상기계를 들여다볼 분은 vi와 ctags 를 이용하시길 (아니면 emacs). 그거 없었으면 거의 불가능했을 것이다.

어쨌든, 잘 돌아가는 가비지컬렉터 하나 만들기도 힘든 일인데, 하나 만들고 나면, “약한참조가 필요해요~” 라고 요구사항이 추가되어버린다. 아무리 논문이 많고 예제가 많아도 어차피 모든 구현은 새롭게 해야하는 것인데.

언어 만들기
—-
파이선 덕분에 거의 포기하기 직전까지 갔었지만, 그래도 나의 “영원한 꿈” 은 다시 피어올랐다. (언제가 될지는 나도 모른다.)

1. 우선 브레이스 “{}” 가 없는 것이 씨언어 계통에 익숙한 자들에게는 큰 장벽일 수 있다.
2. 가슴에 와닿지 않는 모듈과 클래스와의 관계도 문제다. “유연한” 것이 능사는 아닌 법.
3. 변수가 타입이 없는 것은 좋기도하고 나쁘기도 하다. 이것은 더 써봐야 장점인지 단점인지 알 수 있을 것 같다.
4. 변수를 선언하지 않는 것도 마찬가지.
5. __init__ 대신에 다른 것이 적당하지 않을까. 가장 거슬리는 키워드다.

가장 이상해 보이는 것은 “define” 대신에 “def” 를 쓰는 것이다. “심플” 이라는 철학을 지키기 위한 것이겠지.

언어가 “풀어주는 것” 과 “막아주는 것” 사이에서 줄타기를 하는 것이라고 한다면, 파이선은 “풀어주는 것” 쪽으로 과도하게 가버린 것은 아닐까. 이런.. “언어 만들기”가 꿈이다.. 라기보다는 “언어 비교하기” 가 되어버린 듯하다.

 

Leave a Reply

 

Theme by HermesThemes

Copyright © 2017 돌핀호텔의 기억. All Rights Reserved