the 0.8 true language

Matz의 원문 "[言語] the 0.8 true language" 을 되는 대로 번역한 글입니다. 가급적 원문을 참조해 주시기 바라며, 자동번역기에서 매끄럽게 문맥을 다듬은 정도로만 봐주시길.

===

어떤 문제에도 모두 사용할 수 있는 완벽한 언어(the one true language)가 존재하지 않는다는 것은 명백하다.

예를 들어, Ruby가 아무리 훌륭한 언어라고 하더라도, Ruby 언어는 Ruby 언어로 기술되지(쓰여지지) 않았다. 또한, OS와 같이 Ruby로 작성하기에 적합하지 않은 분야는 얼마든지 있다.

Ruby가 원래 적절하지 않은 언어라는 프로그래머도 있는 것 같지만, 그 문제는 이번에 다루지 않는다.

원래 100% 완벽한 언어는 존재하지 않는다. 그러나 만일 80:20 의 법칙에 따라 "80% 영역을 커버하는 언어"를 생각한다면 그런 언어는 어떤 특성이 있어야 하는걸까?

100% (=ONE), 80% (=0.8), 그래서 "the 0.8 true language" 에 대한 특성을 생각하는데 언어 자체의 본질에 촛점을 맞추기 위해 아래와 같이 가정해보자.

"컴퓨터는 충분한 성능을 가진다"는 것을 가정한다. 세상에 완전한 성능의 컴퓨터가 없고(성능이 향상되더라도 처리할 일이 증가하므로) 현실적인 가정이 아니라고 하더라도 어디까지나 사고 실험(연습)이라고 생각해보자.

컴퓨터의 성능은 고려하지 않지만 인간의 본질은 그닥 변하지 않기 때문에, 현대의 인간이 가진 능력은 고려해야 한다. 예를 들어 100년 후 인간이 누구라도 "사물을 선언적으로 파악하고 프로그래밍하는" 것이 아무것도 아닌게 되어 있다면 모르지만, 현대에서 그럴 수 있는 사람은 극히 소수이다.

먼저 80% 영역을 커버하기 위해서 해당 언어는 범용 언어의 특성을 가져야 한다. 특수목적언어(DSL)와 특수 모델을 가진 언어(논리형 언어라든지, 일부 함수형 언어라든지)에서는 80%의 문제 영역을 커버할 수 없기 때무이다. 

물론, Prolog를 사용해서 OS까지 쓴 사람들이 있다는 것을 알고는 있지만, 역시 보통의 프로그래머로 보기는 어렵다..어이..이봐...(ㅡㅡ0 생략같은 느낌)

한편, 넓은 영역에서 충분한 생산성을 제공하기 위해서는 고도의 추상화 능력이 있을 필요가 있다. 현대의 프로그래머는 BASIC과 FORTRAN 같은 언어로는 추상화 능력을 발휘할 수 없는거 같다.(이 문장은 자동번역기의 한계로 의역임). 현재까지 알려진 추상화 기능에 효과적인 것은 객체 지향 프로그래밍과 함수형 프로그래밍이다.

따라서 the 0.8 true language 에서는 이 두가지를 어떤 방식으로든 포용할 필요가 있을 것이다. 특히 "객체와 메시지(또는 동적 바인딩)" 과 "High-Order 함수(와 클로저)" 가 필요할 것이다. 

또한 언어의 간결함도 중요하게 된다. 자세한 사항은 "--- Succinctness is Power ---" 를 참조하라. 그리고 동적인 특성도 중요하다. 이것은 Java 업계에서 DI가 주목받고 있는 것을 보아도 알 수 있다. DI와 XML을 사용한 핵심 설정 파일이라고 하는 것은, 결국 단단한(굳은) Java 응용 프로그램을 어떻게든 유연하게 동적으로 사용하려는 시도로 밖에 보이지 않는다. 처음부터 동적인 언어를 사용하는 경우, 둘 다 거의 필요없는 것들이다.

나는 임시 DI에 대해 관심을 가지고 여러 가지로 알아보고, 스스로 DI 컨테이너 구현을 시도해 보기도 했다. 하지만 Ruby로 작성할 경우 DI 컨테이너가 불과 20 줄로 구현될 수 있으며, 잘 생각해보면 20줄이 안되도 거의 같은 것을 할 수 있다는 것을 깨달았을 때, DI라고 하는 것은 굳은(단단한, 딱딱한) 언어를 위한 기술이라고 깨달았다.

여기까지는 일반적인 이야기이고, 이제 미래에 대해 이야기를 해보자.

개인적으로 장래성있는 기술 트랜드의 하나로 "내부 DSL의 대두"이다. 특수 목적 언어인 DSL을 기존 언어의 확장으로 제공함으로써,

- 구현이 용이
- 기능(및 언어의 기본 어휘)이 풍부
- 쉬운 문법 이해
- 프로그래밍 비 전문가로부터 지식의 인도

등을 동시에 제공할 수 있는 멋진 기술이다. 여기에서 내부 DSL을 실현하기 위해 언어가 갖추어야 할 성질은 "유연하고 확장성이 있어야 한다"는 점과 "남용하기 쉬운 문법" 이라고 생각한다.

여기서 의견이 나뉜다고 생각하지만, 나는 Lisp을 "내부 DSL에 적합하지 않다"고 생각한다. 더 정확하게 표현해보면 "List의 S식과 매크로는 DSL을 구현하는데 적합하지만, 확장성이 너무 빠르게 외부 DSL의 영역에 도달할 것" 이라고 생각한다.

뭐, "그런거, 별 일 아니다" 라고 생각하는 사람도 많을지 모르는데,

the 0.8 true language 는 어떤 형태로든 내부 DSL을 지원해야 한다고 생각한다. 해결 방법은 하나만 있는것은 아니고 잠시만 생각해봐도

- Lisp 과 같은 매크로를 사용하는 언어에서 확장성의 지원
- Ruby와 같은 블럭, 괄호등을 사용하지 않아도 되는 문법의 지원
- Java 와 같은 XML을 사용하여 DSL 구현을 지원하는 라이브러리(등) 제공

등을 생각할 수 있다. 마지막으로 조금 다른 측면의 생각이 드는데 확장성이다.
"확장성" 이라고 하면 여러가지를 의미하지만, 여기서 생각하는 중요한 것은 다음과 같은 것이다.

(하드웨어 성능향상 관점에서)멀티 코어화가 진행되고 있기 때문에, 그 코어를 활용할 수 있는 병렬 처리 기술. 1대의 컴퓨터에서 처리할 수 없을 정도로 방대한 데이타를 위해 여러 컴퓨터를 사용하는 분산 처리 기술.

이 모두가 현재에서 가까운 미래에 컴퓨터 업계로 반영될 것이기 때문에, 첫번째 "시스템은 고려하지 않는다"는 가정에 반하는 말이 되지만, 중요한 부분이며 이 부분이 Ruby가 좀(아니, 많이) 약한 측면이 있기 때문에 향후 중점을 두고 발전하지 않으면 안되는 것이다.

그런 이유로 the 0.8 true language 가 갖추어야 할 특성에 대해 생각하여 보았다. 나의 견해이지만 Lisp 이나 Ruby는 꽤 좋은 방향으로 가고 있다고 생각한다. Python은 좋은 언어이긴 하지만, 일종의 문법이 유연한 프롬프트가 나오지 않기 때문에 DSL에는 적합하지는 않는 듯하다.

이런 고려사항을 기반으로 생각하면 앞으로 Java 쪽에서는 점점 XML의 활용과 JVM에서 Java가 아닌 언어의 대두가 예상된다. 또 확실히 JRuby, Groovy, Scala나 Clojure 같은 것들이 나와 있다.

그닥 효과적인 결론도 없이 이만 끝낸다.

===

자바쪽에서 XML뿐만 아니고 어노테이션의 광범위한 확산을 같이 얘기해 주는게 좋았을 듯 하고 코드 예시도 좀 들어줬으면 하는 아쉬움은 있습니다만, 파레토의 법칙으로 익숙한 2:8 비율을 언어에 대입한 생각이 재미있습니다.

짤막한 글로 접하긴 했지만, 왠지 위트가 있는 사람일거 같습니다. Matz~
Trackback 0 Comment 0
prev 1 2 3 4 5 next