[고찰] 확장 가능한 언어 (Extensible Programming Language) feat 모나드/메크로

분쟁이 생길수 있는 부분이기 때문에 미리 말하자면, 언어 자체에 우열을 가리고, 언어철학에 더 좋고 나쁨이 있을수는 없다. 언어는 기술에 따라가는 요소로 보는 사람도 있고, 기술보다 언어적 철학이 우선시되는 사람이 있을수도 있다. 이또한 무엇이 옳다 그르다 명확하게 할수있는 요소가 아니다. 다만, 개인적인 생각을 적어내는 포스팅 특성상, 내가 선호하는 요소를 그냥 좋다, 나쁘다로 표현하도록 하겠다.

 

대부분의 사람들이 선호하는 언어가 바뀌는 무렵은

내가 사용하고있는 언어가 장황하고 이해하기 어렵다고 생각할때, Simple 하면서도, 가려운 부분을 긁어주는 Feature 가 있는 언어를 만났을때 이다.

특히 그러한 언어를 처음 사용할때에는 하루종일 감탄을 하면서 시간을 보내게 된다. 이것이 특정 프로그래밍 언어에 추종자가 생기는 과정이다.

"아니 이게 된다고?"

그러나 가려운 부분은 한번 긁고 나면 다른곳이 가려워지기 마련이고, 이를 지속적으로 패치하다보면 결국 Simple 한 언어는 점점더 복잡해지고 결국 처음에 사용했던 장황하고 이해하기 어려운 언어로 진화하게 된다.

 

이는 현재 장황한 언어의 대표주자인 Java 의 태동기때, C++ 의 아버지 스트로스트눕이 한 말과 일맥 상통한다.

Much of the relative simplicity of Java is—like for most new languages—partly an illusion and partly a function of its incompleteness.
As time passes, Java will grow significantly in size and complexity.
It will double or triple in size and grow implementation-dependent extensions or libraries. [Stroustrup]

복잡한 소프트웨어는 시간이 갈수록 점점더 복잡해진다. 프로그래밍 언어는 결국 소프트웨어 (또는 소프트웨어 명세) 이므로 점점더 복잡해지는것은 피할수없는 흐름이다.

또한 프로그래밍 언어는 "언어" 라는 특성상 모놀로딕하게 발전하기 마련이다. 레거시를 지원하면서, 사람들의 가려운곳을 긁어주는 Feature 를 추가하면서 그럼에도 불구하고 지금까지 지켜왔던 철학이나 스타일을 유지해야한다

 모던 자바나 모던 C++ 의 새로운 Feature 를 적용하는 방법을 보고 "자바 다운 결정이다", "C++ 다운 결정이다" 하는것 처럼 말이다.

 

모던 자바/모던 C++ 의 명세를 살펴보면 내가 알던 그게 맞나??? 싶을정도 이제 수많은 Feature 를 담고 있다. 그러나 그만큼 제대로 하기에는 러닝커브가 길어지며, 끝까지 하지 않으면 레거시 스타일의 코드가 생성되게 된다.

 그렇기 때문에 "레거시 스타일" 에 대한 공포를 벗어나기 위하여 새로운 언어를 찾으면서,

그렇지만 새로운 언어에 대한 공포 때문에 유사한(익숙한) 언어를 선택하게 된다.

다시는 ~~ 으로 돌아갈수없는 몸이 되어버렸어~

심플하지만, 뛰어난 Feature 를 가졌다고 생각되는 언어로 넘어가면 흔히 하는 이야기다.

그러나 그 또한 일종의 허상(illusion)일 가능성이 높다. Simple 이 아니라 Easy였을 가능성이 높고, 점점더 복잡해질 가능성이 높다.

 

이 흐름이 반복되는 이유는 무엇인가? 바로 언어 스스로 확장가능하지 않기 때문이다.

언어적 차원의 지원이 없는 경우, 새로운 패러다임, 방법론, 디자인을 적용하기위하여 어노테이션(Java), 어트리뷰트(C#) 등을 사용하게 되는데 이는 메타데이터에 Feature 를 의존하는것이 된다. 이는 결국에 가짜 Feature이다.

개인적으로는 어노테이션, 어트리뷰트와 같은 메타 데이터에 의존하는 프로그래밍은 언어적 한계라고 생각한다. 말그대로 메타 데이터에 정보를 쓰고, 그걸 프레임워크가 해석해서 구현을 해주는것은 자바를 프로그래밍하는것인가 어노테이션을 프로그래밍하는것인가?

이러한 메타데이터에 의존하는것보다 언어의 공식적인 지원이 좋다.

자바 롬복 보다 씨샵의 프로퍼티나 코틀린의 데이터가 좋다.

똑같은 데코레이터(또는 프록시) 의 자동적인 구현을 해도 python 의 데코레이터가 java 에서 어노테이션을 사용하는것보다 좋다.

그러나 문제는 공식적인 지원으로 Feature 가 추가되는것을 세월아 네월아 기다릴수없다는것이다.

그렇기 때문에 언어 스스로 확장가능한 (Scalable 또는 Extensible) 기능을 언어적 차원에서 지원해주는것이 좋다고 생각한다. 메타데이터가 아니라 메타 프로그래밍이 더 가치가 있다고 생각한다.

 

나는 모나드를 Programmable Semicolon 이라고 부르는것을 좋아한다. 이것이 모나드의 진정한 아이덴티티라고 생각하기 때문이다. 모나드 자체는 Bind 함수 여부일뿐이지만, 모나드전용 문법설탕 을 제공해주기 때문에, 모나드 구현체 이기만 한다면, 언어적 Feature 처럼 사용이 가능하다.

[반대로 모나드용 문법 (Haskell do / Scala For / F# Computation Expressions) 이 있어야지만, 모나드가 가치있다고 생각한다.]

Lisp계열을 Programmable Programming Language 이라고 부르는것을 좋아한다. 이것이 Lisp 의 아이덴티티는 Macro 에서 온다고 생각하기 때문이다. Clojure 에서는 더이상 feature의 가능 여부를 따지는것이 무의미하다.

나는 이러한 메타 프로그래밍의 가치를 믿는다. 이러한 언어를 쓴다고 이것으로 내가 직접 언어를 확장할 필요는 없다. 언어를 확장할수있다는것 자체의 가치가 있다고 믿는다. 똑같은 기능을 가지는 라이브러리를 쓴다고 해도, Java 의 어노테이션기반의 라이브러리보다, Clojure 의 라이브러리가 더 좋다고 본다. 똑같은 future 기반의 라이브러리를 쓴다고 해도, Java 보다, Scala 의 future가 의미 있다고 생각한다. 라이브러리 자체의 가치가 아니라 언어적으로 지원으로써의 의미이다.

 

내 의견의 결론은, Extensible 자체가 언어의 Feature 가 되는것이 "최후의 프로그래밍" 에 맞는 속성이라고 생각한다.

 

"최후의 프로그래밍" 언어라는것은 로버트 C 마틴의 최후의 프로그래밍 언어의 인용.

참고로 "자바가 망하고, 시대의 격변이 있을것이며. Clojure 가 최후의 프로그래밍언어로 홀로 살아남을것이다" <- 이런 생각은 하지 않는다.... 그러나 확실히 Extensible 한 언어를 해보는것은 좋은 경험이 될거라고 확신한다.
일단.. 뭔가 해커스럽잖아?