IT/모바일
제공 : 한빛 네트워크
저자 : Larry Wall
역자 : 노재현
원문 : Programming is Hard, Let"s Go Scripting...
대부분의 사람들은 스크립팅을 좀 가볍게 생각할 지도 모른다. 정확하게 뭐라고 표현해야 할지 모르겠지만, 보통 다음과 같은 말들로 표현되곤 한다.
쉬운 진입로
기본적으로 스크립팅은 기술적인 용어가 아니다. 보통 스크립팅 언어라고 부를때는 기술적인 판단보다는 언어나 문화적인 판단을 이용하게 된다.
필자는 스크립팅을 언어의 뿌리에서 갈라져 나온 한 종류라고 본다.
과거
Ada Lovelace가 있는 과거로 돌아갔다고 상상을 해보자. 그녀에게 스크립트와 프로그램의 차이점이 무엇이냐고 물어보면 어떻게 대답해 줄까? 분명히 여러분을 우스꽝스럽게 쳐다보며 스크립트는 배우들에게 주는 것이고, 프로그램은 관객들에게 제공해 주는 것이라고 답할 것이다. Ada는 아주 영리한 숙녀였다.
그 이후로 지금까지 우리는 스크립팅을 말할때 그게 무엇인지 혼돈에 빠져 있는 것 같다. 심지어 전문가인 나조차도 더욱 혼란스럽다.
그래서 지금 여기서 필자가 해줄 수 있는 것은 필자의 좁은 소견에서 바라본 스크립팅의 과거, 현재 그리고 미래이다. 그리고 미리 말하는 건데, 글을 쓰는 중에 필자의 편견이 녹아들어 갈 수도 있다는 것이다.
기본
필자는 베이직 프로그래머로 프로그래밍을 시작했었는데, 베이직이 첫번째 주 스크립팅 언어라고 생각한다. 특히나 DEC이 미니컴퓨터에 인자를 가진 재귀 함수를 넣은 BASIC/PLUS가 바로 첫 번째 스크립팅 언어라고 생각한다.
이런 생각에 대해서 어떤 사람들은 의심할 여지가 없이 맞는 얘기라고 하는 사람도 있지만, 아니라고 하는 사람들도 있다. 하지만 이 점에 대해서는 굳이 사과할 생각은 없다.
RSTS BASIC/PLUS
필자가 PDP-11 에서 RSTS 프로그래머로 일하던 시절에는 베이직을 확실히 스크립팅 언어로 생각하고 있었다. 빠른 프로토타이핑과 프로세스 제어 관점에서 볼 때 말이다. 펄의 문장구조는 BASIC/PLUS에서 바로 나왔다. 심지어는 문자열과 정수를 실수와 구분짓기 위한 표시를 변수의 끝에 가지고 있다.
하지만 익스트림 프로그래밍을 할 수 있다. 사실 대학 시절 친구와 함께 페어 프로그래밍을 했던 적이 있다. 우리는 컴파일러 작성 수업을 함께 들으면서 드래곤 책에 있는 많은 내용을 공부했었다. 물론 그때 교수님은 이제 여러분이 자신만의 PL/0 이라고 불리는 자신만의 언어를 만들어야 한다고 말씀하셨다.
어떻게 해야할까에 대해서 생각을 해본 후에 베이직으로 프로젝트를 진행하기로 결정했었다. 교수님에게 말씀드렸더니 마치 제정신이 아닌 것 아니냐는 듯이 쳐다보셨던게 기억난다. 같은 수업을 듣는 어느 누구도 베이직을 사용하지 않았었기 때문이다. 그런데 결과는 어떻게 되었을까? 같은 수업을 듣는 학생 중 그 누구도 컴파일러를 완성한 사람이 없었다. 하지만 우리는 컴파일러를 다 만들었을 뿐만 아니라, I/O 기능까지 추가하고, PL 0.5라고 불렀었다. 바로 이게 빠른 프로토타이핑이라는 것이다.
Unix?
한 때 컴퓨터 센터에 벨 연구소로 부터 연락이 왔었던 적이 있다. 우리한테 Unix V6 테잎을 싼 가격(100 달러)에 팔겠다고 하는 것이었다. 이유인즉, 곧 V7이 나올 것이여서 라는 것이다. 이때 우리는 서로를 쳐다보며 "왜 우리가 Unix라고 불리는 것을 사야하는 거지? 우리는 RSTS가 있잖아."라고 말했다.
JAM (no not that one)
필자의 첫번째 스크립팅 언어는 베이직으로 만든 것이었다. 컴퓨터 센터에서 일하던 중에 임시적으로 그리고 다기능용으로 사용할 메타 언어인 JAM이라고 불리는 언어를 만들었었다.
JAM은 HTML이 아직 없었다라는 것을 제외하면 PHP와 같은 완전한 텍스트 프로세싱 언어였다. 우리는 이 언어를 베이직을 위한 매크로 프로세서로 사용하곤 했었다. PHP와 다른 점은 3000개나 되는 함수를 가지고 있지는 않다는 것이다.
LISP
좋던 안 좋던간에 대학원에 진학했을때, 언어학을 공부했었다. 그리고 그 때 사용했던 유일한 언어는 LISP이였다.
LISP도 스크립팅 언어로 봐야할까? 물론 LISP으로 빠른 개발을 할 수도 있겠지만, 아무리 봐도 스크립팅 언어로 보기는 어렵다.
Pascal, Ada
업계로 진출했을 때, 분산 이벤트 시뮬레이터를 만들기 위해서 파스칼로 컴파일러를 만들었었다. 언어학자로서, Ada를 널리 통용되는 언어라고 생각하지 않는다. 영어나 일본어와 같은 언어가 바로 널리 통용되는 언어이다. Ada는 그저 중간 크기의 언어라고 보면 된다.
Unix, shell
몇 년후에 Unix와 그 외 여러가지 스크립팅 언어에 익숙해 지게 되었다. 좀 더 자세하게 말하면, BSD와 csh 정도.
BSD, csh
C 언어도 조금 배웠습니다.
C
C언어 밖에 없어서였기 때문이다. 여전히 라이브러리에 대해서 공부하고 있다.
shell + awk + sed + find + expr...
유닉스 쉘 프로그래밍의 어려움이 바로 펄이라는 언어가 탄생하게 되는 계기가 되었다. 쉘 스크립팅에 사용되는 여러 언어들 간의 기본적인 동사나 명사들이 일치하지 않아서 언어 자체에 제한이 많이 가해지고 있었다.
C xor shell
더욱더 안 좋았던 것은 1차원의 세계였다는 것이었다. C아니면 쉘에서 프로그래밍을 해야 했었는데, 두 언어가 서로 완전 다른 언어였다는 것이다. 필자가 스크립팅이라는 것을 항상 프로그래밍과는 반대의 무엇으로 봐야하는 것이 아니라는 것을 깨달았을 때쯤에 펄이 탄생했다. 펄이라는 하나의 언어가 두 가지 용도로 사용하기에 모두 좋았다.
Tcl
펄이 나온후에 Tcl이 등장했다. 펄은 모든 것이 문자열인 것처럼 작동하게 끔 되어 있었는데, Tcl은 실제로 문자열을 이용하게끔 만들어져 있었다. 하지만 이 문자열을 이용한 방법은 아주 안 좋은 성능을 나타내는 방법이었다. 하지만 이게 Tcl의 입지를 약화시키는 요인은 아니였다. 두 가지 이유가 있었는데, 하나는, Tcl은 툴을 다루는 것과 만드는 것은 완전 다른 일이라는 Unix의 정신세계를 이어 받았다는 것이다. 언제나 빨리 작동해야 하는 부분은 C로 작성해야만 했다.
두번째 이유는 확장이 어려웠다는 것이다. 그래서 expect, incr-tcl과 같은 툴들이 생겨나게 되었다.
하지만 확실히 말하지만 필자는 Tcl의 위임 모델을 존경해왔다. 하지만 Tcl은 LISP과 같이 모두에게 항상 하나의 문법만을 이용하기를 강요하는 함정에 빠져 있었다.
Python
Tcl 이후에 파이썬이 탄생했다. 파이썬 커뮤니티의 정신은 펄에게 소극적으로 받아들여지게 되었다. 필자는 파이썬에 대해서 많이 알지도 못하고 파이썬이 이렇다 저렇게 평가할 만한 입장이 되지 못한다. 단지 Perl 5의 오브젝트 시스템에 파이썬의 시스템을 이용했다.
Ruby
사실 루비에 대해서는 할 말이 많다. 왜냐하면 많은 루비의 문법이 펄로 부터 왔기 때문이다. 필자는 항상 루비를 펄의 가장 강력한 경쟁 언어로 생각하고 있는데, 그 이유는 단지 루비가 펄의 아이디어를 빌려왔기 때문이 아니고, 루비와 펄 모두 펑셔널 프로그래밍 기능을 파이썬보다 더 심도있게 지원하고 있기 때문이다. 필자의 생각엔 루비는 선언 문법에 있어서 약간 일치되지 않는 점이 있는 것 같다.
*sh
와중에 Bourne이 Korn 쉘과 bash 쉘로 확장이 되게 되었다. 계속적인 쉘의 진화가 보여준건 계속된 문법 기능의 추가가 언어에 정교함을 추가해 준다는 것이였다.
PHP
우리는 최악의 선택이 더 나은 선택으로 작용한 PHP가 승승장구 하는 모습을 보고 있다. 어쨌든 PHP는 펄이 초기에 했던 실수를 반복하고 있는 것 같다. 단지 천천히 진행되고 있을 뿐이다. 한 가지 PHP가 나은 점은 패키징에 있다. 패키징은 네임스페이스를 의미하는 것은 아니다.
JavaScript
그리고 깔끔한 디자인의 자바스크립트이다. 몇가지 이슈가 있지만 결국엔 펄 6를 실행할 수 있는 플랫폼이 될 수 있을 것이다. 필자의 생각엔 새로운 자바스크립트 엔진이 나오게 되면, 이 자바스크립트 엔진을 백엔드로 사용하는 것에 대한 세상의 관심이 집중될 것이라고 생각한다.
Monad/PowerShell
마이크로소프트의 Monad를 조금 보았는데, 펄 6과 같은 오브젝트 파이프 기능이 있어서 기뻤다. 마이크로소프트가 저작권을 침해하지 않았기를 바란다.
Lua, AppleScript
많이 사용되는 스크립팅 언어들이 정말 많이 있을것인데, 먼저 필자는 Lua나 AppleScript에 대해서는 잘 살펴본 적이 없다. 아마도 필자가 게임 디자이너가 아니기 때문일 것이다.
The Present
현재 상황을 볼 때, 여러 스크립팅 커뮤니티가 마치 정글에 있는 여러 부족들과 같아 보인다. 가끔은 서로 거래를 하기도 하고, 전투를 벌이기도 하는 부족 말이다.
필자는 인류학점인 관점에서 한 번 살펴보기로 했다. 여러분의 대다수는 펄 프로그래머 이거나, 아니면 다른 언어 프로그래머 종족이라고 하자. 여러분 각자는 자신이 속한 종족에 따라서 문자열을 다르게 볼것인데, C언어 프로그래머라면 바이트 배열에 대한 포인터라고 볼 것이고, 펑셔널 프로그래머라면 리스트라고 볼 것이며, 자바 프로그래머라면 오브젝트라고 보게 될 것이다.
필자는 문자열을 대문자 T로 시작하는 텍스트라고 본다.
Text
필자는 이 단어를 포스트모더니즘의 관점에서 생각했다. 물론 포스트모더니즘이라는 말은 문맥에 따라서 달라질 수 있다. 어떤 사람들은 포스트모더니즘이 그저 일반적인 것에 힘을 부여해 주는 정도밖에 되지 않는다고 생각한다. 어떤 사람들은 펄에 대해서도 같은 방식으로 생각하기도 한다.
하지만 필자는 포스트모더니즘을 말이든 글이든 간에 텍스트가 양방간에 의사소통을 위해 필요한 지식정도로 생각을 하고 있다. 필자는 멍청한 프로그래밍 언어와는 얘기하고 싶지 않고, 내가 타이핑하는 문자열을 이해할 수 있는 언어를 원한다.
펄은 포스트모더니즘의 언어이다. 많은 보수적인 사람들은 포스트모더니즘을 다소 자유로운 관념이라고 받아들이기도 한다. 그래서 필자의 포스트모더니즘에 대한 견해는 선교(혹은 전도) 활동을 통해서 배운 언어학, 번역학에서 많은 영향을 받았기때문에 어떻게 보면 약간의 아이러니한 면이 있다.
한가지 중요한 점은 어디에도 기본적인 사람의 언어라는 것은 없다는 것이다. 즉, 모든 사람의 언어는 Turing Complete가 되는 것이다.
여러분이 원시 부족이 있는 곳으로 가서 그들의 언어를 분석해 보게 된다면, 그들의 언어가 다른 사람의 언어만큼이나 복잡하다는 것을 알 수 있다. 여러분은 사람의 언어로 여러가지 것들을 말할 수 가 있고, 계속해서 그 말을 하게 된다면, 그 사람의 언어는 곧 Turing Complete이 되게 된다.
그렇기 때문에 사람의 언어는 당신이 그렇다고 생각하고 있던 것과는 많이 다르다. 영어로 얘기할때는 단수와 복수를 확실히 구분해야만 한다. 일본어에서는, 단수와 복수를 구분할 필요는 없지만, 정중함의 정도를 조절할 줄 알아야 한다. 즉, 상대방에 대한 존경을 표현할 수 있는 정도를 선택해야 하고, 상대방의 입장에서 내가 존중 받아야 하는 정도를 생각해서 말해야 한다.
그래서 언어는 당신이 말하도록 되어 있는 것과는 다르다. 분명한건 여러분의 언어로 뭔가를 말해야 한다면, 분명히 그 언어에 따라서 말하려면 간단하게 말하기는 힘들 것이다. 그래서 바로 스크립팅이 나오게 된 것이다.
서로 다른 스크립팅 언어를 이용해서 간결하게 말할 수 있는 방법이 몇가지나 있을까?
러시아식 수프를 만들 수 있는 방법은 몇가지나 있을까?
언어 디자이너는 아주 많은 자유도를 가지고 있게 된다. 필자는 그중에서 일부에 대해서 말해보고자 한다.
early binding / late binding
여기서의 바인딩은 특정 이름을 가진 루틴을 언제 호출할 것인지를 결정하는 것을 말한다. 초기에는 효율성의 이유로 바인딩의 시점을 결정하는 일이 어렵지 않았다. 컴파일 타임에 하거나 아니면 링크 타임에 하면 되었다. 여러분은 여전히 이런 방법의 바인딩을 사용하는 언어들을 보았을 것이다.
하지만, Smalltalk과 같은 언어를 보면 다른 경향을 가지고 있다는 것을 알 수 있다. 그리고 요즘에는 많은 스크립팅 언어들이 지연 바인딩쪽을 선호하고 있다. 왜냐하면 스크립팅 언어들이 "내가 원하는 것을 수행하라(Do What I Mean)"는 원칙을 따르려고 하고 있기 때문이다.
그리고 그 결정은 보통은 지연 바인딩을 선택하게끔 하게 되는데, 이렇게 됨으로써 보다 의미적이고 실질적인 문맥을 가지고 작업할 수 있게 되기 때문이다. 그렇지 않으면 미래를 예견해야만 하기 때문이다.
그래서 스크립팅 언어는 실제 메쏘드의 디스패칭 시점 이전에는 바인딩을 하지 않는 객체 지향적인 관점으로 점차 변화하고 있다. 여러분은 자바와 C++ 언어사이의 충돌을 경험한 적이 있을 것이다. C++의 메쏘드는 기본적으로 non-virtual 타입이다. 그렇기 때문에 지연 바인딩을 하기 위해서는 명시적으로 virtual이라고 명시해 줘야 한다.
자바에는 final이라는 개념이 있는데, 이것은 컴파일 타임에 클래스에 대한 바인딩을 가능하게 해주는 역할을 한다. 필자는 이 두가지 방법이 전부 실수라고 생각한다. 펄6에서는 다른 실수를 할 생각이다. 펄 6에서는 모든 메쏘드는 기본적으로 virtual이고, 오직 전체적으로 애플리케이션 만이 옵티마이저에게 클래스를 finalize 하라고 알려줄 수 있다.
single dispatch / multiple dispatch
다중 디스패칭은 바인딩을 더욱 늦출 수 있는 하나의 방법이다. 실제 오브젝트의 타입을 알때까지 바인딩을 늦춰야 할 뿐만이 아니라 메쏘드를 호출하기 전까지 메쏘드로 전달되는 모든 인자들의 타입까지 알아야만 한다. 파이썬과 루비는 항상 단일 디스패칭만을 하게 된다. 반면에 Dylan은 다중 디스패칭을 사용한다.
여기 바로 펄 6가 내세우는 한 가지가 있는데, 바로 호출자가 명확하게 정의되어야 한다는 것이다. 이 점이 프로그래머에게는 아주 중요하다고 생각하는데 바로 단일 디스패칭과 다중 디스패칭은 개념이 아주 다른 것이기 때문이다.
단일 디스패칭 언어에서는 오브젝트에게 메시지를 보내게 되고, 오브젝트는 메시지를 보고 무엇을 할 지를 판단하게 된다. 다중 디스패칭 언어에서는 하나의 특권을 가진 오브젝트라는 것이 없이, 호출에 관계되어 있는 모든 오브젝트가 모두 같은 비중을 가지게 된다. 그래서 다중 디스패칭 언어를 바라보는 한 가지 관점은 오브젝트들이 완전히 수동적이다 라는 것이다.
하지만 만약 오브젝트들이 어떻게 바인딩을 하게 될지 결정하지 못한다면 누가 해야 할까?
민주적인 방법일 수 있는데, 모든 루틴들이 모여서 정치적인 회의를 열게 된다. 각 루틴은 회의의 대표라고 보면 된다. 모든 대표가 자신의 이름을 모자에 적어 넣은 후에, 누가 하는 것이 가장 좋을지에 대한 투표를 한 후에는, 차선을 뽑고, 그 다음에는 그 차선을 뽑게 된다. 이제 각자는 어떤 루틴을 호출하는 것이 가장좋은지에 대해서 결정을 하게 된다.
기본적으로 다중 디스패칭은 민주적이지만, 지연 바인딩을 하기에는 최악의 방법이라고 할 수 있다.
필자는 그것이 사실이라고 생각하고, 앞으로 더욱 더 그럴것이라고 생각한다. 필자는 이 다중 디스패칭에 대해서 더 많은 시간을 들여서 노력하고 있는데, 왜냐하면 프로그래밍 자체가 단일 디스패칭의 명령-제어 구조로 부터 변화해 가고 있다고 생각하기 때문이다.
이제 컴퓨터 분야는 곤충과 같은 한 무리의 집단에 의해서 더 잘 결정될 수 있는 방식으로 변화해 가고 있다고 생각한다. 즉 단 한 쪽의 의지에 의해서만 결정되는 것이 아닌 그보다 우수한 집단의 판단이 작용할 것이다.
eager evaluation / lazy evaluation
펄 5와 같은 대부분의 언어는 평가를 확실하게 한다. 어떤 언어들은 이런 평가들을 너무 확실하게 하지 않으려고 하기도 한다. Haskell이 그의 좋은 예라고 할 수 있다. Haskell은 실행해야 할 때가 오기전까지는 아무것도 계산하지 않는다. 이런 방식의 장점은 여러분이 무한하게 긴 리스트를 가지고 메모리의 고갈 없이 작업을 할 수 있다는 것이다.
물론 누군가가 프로그램에게 리스트의 길이를 계산하라고 하기 전까지는 말이다.
어쨌든 펄 6에서는 철저한 평가와 그렇지 않은 평가의 혼합에 대해서 테스트를 해보고 있다. 재밌게도, 이런 차이점이 펄 5의 스칼라 문맥 대 리스트 문맥과 아주 잘 매칭되고 있다는 것이다. 그래서 펄 6에서는 스칼라 문맥은 철저한 평가를 하게 되고, 리스트 문맥은 확실한 평가를 하지 않게 된다. 물론 기본적으로 그렇다는 것이다.
언제든지 원한다면 그 반대로도 적용해 볼 수 있다. 무한루프에 빠지지 않도록 중간에 빠져나갈 수 있는 코드만 있다면 for 1..Inf 과 같은 것도 해볼 수 있다.
eager typology / lazy typology
정적 vs 동적으로 알려져 있다. 필자는 점차적인 타이핑(typing)을 더 선호한다. 효율성이 한 가지 이유이다. 펄 6에 타입을 넣은 이유는 강한 타이핑을 위해서가 아니고 다중 디스패칭을 위해서이다.
이전에 했던 다중 디스패칭에서의 회의를 기억하는가? 여러 후보들이 자신들의 이름을 모자에 써 넣은 다음에는 어떻게 그들을 구분할 수 있을까? 각 후보는 모두 각자의 정치적인 기반을 가지고 있다. 각 정치적 기반에서 나오는 강령은 그들이 반응하기 원하는 인자의 타입이다.
우리 모두는 정치인들이 자신들이 받기 좋아하는 부분에 대한 인자의 타입에 대해서 반응한다는 것을 알고 있다.
펄 6가 펄 5와 비교해서 또 다른 방법으로 지연을 하고 있는 것이 있다. 여전히 문맥이라는 개념을 가지고 있다. 하지만 정확히 말하자면 언제 문맥이 정해지냐하는 것이 달라졌다. 펄 5에서는 컴파일러는 컴파일 타임에 어떤 인자가 스칼라 문맥에 속하는지 어떤 인자가 리스트 문맥에 속하는지를 알 수 있었다.
하지만 펄 6에서는 메쏘드의 바인딩 시점(개념적으로는 런타임)까지 그 결정을 지연시키게 된다. 이상하게 들릴수도 있지만, 펄 5의 설계에서 차선으로 미루었던 많은 문제들을 해결할 수 있었다. 예를 들면 프로토타입과 명시적인 참조의 필요성 같은 것이다.
limited structures / rich structures
Awk, Lua 그리고 PHP는 모두 복합 구조체를 연관 배열이 되지 못하도록 제한을 가하고 있다. 장단점이 있겠지만, 사실 awk가 그렇게 했다는 것이 펄은 그렇게 하지 않겠다고 결정하게 된 하나의 이유이고, 그것이 정렬된 배열과 정렬되지 않은 해쉬를 구분하도록 만들었다.
필자는 둘을 다른 것으로 생각했고, 많은 다른 사람들도 같은 생각을 가지고 있었다.
symbolic / wordy
틀림없이 APL은 스크립팅 언어의 한 종류이다. 다른 방면에서 보자면 우리는 단어 때문에 구두점을 피하는 많은 언어들을 알고 있다. 예를 들자면, AppleScript와 COBOL, 그리고 알골 계열의 언어들과 같이 블락을 나타내기 위해서 단어를 이용하는 언어들이다.
나는 균형잡힌 방법을 선호한다. 심볼과 식별자 각자가 자신에게 가장 적합한 방법대로 이용되는 것이다. 프로그래머들에 의해서 문제점을 해결하기 위한 선택된 단어들이 사용되는 것을 좋아하고, 단지 문법을 위해서 사용되는 단어는 싫다.
그런 단어를 사용하게 되면 실제로 많은 단점들이 있기 때문이다. 이점은 필자가 파스칼에서 C언어로 오면서 배우게 된 점이다. 블럭을 지정하기 위해 { 를 사용한 것은 정말 좋은 점이다.
사실 코볼보다 더 심한 언어도 봤었다. 파스칼에서 변형된 언어중에 하나였는데 그 언어는 키워드가 대문자로 표현되서 더 눈에 잘띄게 했었다. 이런건 정말 안된다! 틀린 단어만 계속해서 나오게 될 것이다. IF! foo THEN! bar ELSE! baz END! END! END! END!
어쨌든 펄 6에서는 어디에서 구두점을 사용하고 말지를 결정할 기준을 세웠다. 필요없는 곳에서는 과감하게 제거 했다. 예를 들면, 조건 문에서의 괄호말이다.
그리고 강조해야 되는 부분에서는 더더욱 강조시켰다. 각 심볼은 자신의 존재를 허프만 코딩에 따라서 확실히 해야한다.
이상하게도 새롭게 구두점을 추가한 곳이 한 군데 있다. sigil의 다음에 twigil을 추가하거나 두 번째 sigil을 추가할 수 있다. sigil이 오브젝트의 기본 구조를 말해주는것과 마찬가지로, twigil 도 특정 변수의 활동 영역을 말해주게 된다. 원래 이 아이디어는 루비에서 가져온 것이다.
하지만 sigil 후에 twigil을 숨기게 됨으로써, 루비에 비해 더 좋은 결과를 얻을 수 있고 더 확장적인 twigil 시스템을 갖추게 되었다.
확장성에 대해서 많은 생각을 해 보았었는데, 우리는 아직 우리가 어떻게 생각해야 하는지 모르는 언어를 생각하고 있다. 하지만 새로운 언어에 문법을 위한 공간을 남겨놓는다는 것은 국립 공원과 국립 삼립원을 위해 공간을 남겨놓는 것과 비슷하다. 혹은 고고학자가 고고학적인 유적지를 반 이상 파지 않고, 더 좋은 분석 도구를 갖고 있을 후손을 위해 놔두는 것과 비슷하다고 할 수도 있다.
정말이지 미래를 위한 언어를 설계한다는 것은 많은 겸손을 필요로 한다. 과학과 마찬가지로 오랜 기간에 거쳐 어떤 가정을 하게 되고 생각을 하지만, 그 많은 생각들이 맞지 않는 것으로 나타날 때도 있다. 반면에 지금 여러분이 정확한 예측을 할 수 없다면, 여러분은 정말 과학을 하는 것이 아니다. 돌이켜보건데, APL은 정말 많은 이상한 심볼들을 가지고 있었다. 하지만 APL이 그 같은 시도를 하지 않았다면 아마 지금 그게 이상하다고 생각하지 못했을 것이다.
compile time / run time
많은 동적 언어들은 런타임에 코드의 평가를 할 수 있다. 펄은 그 기능을 좀 다른 각도에서 받아들여서 많은 코드를 컴파일 타임에 실행이 가능하다. 이렇게 하는 것이 동작성의 정의에 혼란을 줄 수 있다. 여러분은 그다지 많은 파일 I/O 연산을 BEGIN 블럭에서 하길 원치 않을 수도 있다. 하지만 이런 방법이 우리는 또 다른 차이점을 가진 언어로 인도하게 된다.
declarational / operational
대부분의 스크립팅 랭귀지 들은 역할측면에서 볼때 너무 지나치게 기능이 들어가면이 없지 않아 있다. 필자 역시 루아를 보기 전까지는 펄 5가 아주 간략화된 오브젝트 시스템이라고 생각했었다. 루아에서는 오브젝트는 단지 해쉬일 뿐이고, 코드를 포함하게 될 경우에 필요한 문법적인 요소가 다소 추가되었을 뿐이다.
심지어는 클래스조차 가지고 있지 않다. 상속과 같은 것은 위임을 통해서 처리가 가능하다. 바로 이것이 루아의 설계자가 루아를 가볍고 임베딩이 가능한 언어로 만들기 위해서 지켰던 것이다. 그들에게는 바로 이것이 제대로 된 설계였다.
펄 5는 파이썬이나 루비에 비해서 좀 더 선언적인 면이 있다. 항상 느끼지만 암시적인 선언은 문제를 일으키기에 너무 쉽다고 생각했고, 명확한 변수의 영역 설정이 좀 더 가독성을 높여준다고 생각했다.
바로 그래서 my 가 있는 것이다. 매우 간략하게 쓴 이유는 많이 사용될 것이라고 예견했기 때문이다. 허프만 코딩과 같인 자주 사용되는 것은 짧게, 하지만 너무 짧게는 하지 않았다. 이 경우 0을 썼다면 너무 짧게 사용한 것이라고 할 수 있다.
펄 6에서는 또 다른 영역 설정의 종류가 늘어나서 my말고도 our라는 것이 생겼다. 하지만 단어 자체의 의미에 약간 혼란스러울 수도 있을 것이다.
immutable classes / mutable classes
자바의 클래스가 닫혀있다는 점은 자바가 꽤 빠르게 실행될 수 있는 이유 중 하나이다. 반대로 루비의 클래스는 열려있는데, 이는 곧 언제든지 클래스에 원하는 새로운 것을 추가할 수 있다. 그 점이 바로 루비를 느리게 만드는 이유 중에 하나일 것이다.
하지만 그 점이 바로 루비에 Rails가 있었던 이유라고도 할 수 있다.
펄 6는 변형가능과 변형불가능 클래스의 혼합형의 기능을 가지게 될 것이다. 또 누가 언제 클래스를 닫을 것인지에 대한 정책도 있을 것이다. 예를 들면, 클래스 자신은 자신을 닫거나 finalize 할 수가 없다. 미안하지만 필자는 펄 6에 관한 얘기를 계속해서 할 것이다.
class-based / prototype-based
여러분중 일부는 Self나 자바스크립트와 같이 클래스가 없는 언어에 친숙한 사람도 있을 것이다. 이런 언어는 클래스 대신에 자신의 부모로부터 복제된다거나 다른 오브젝트에 위임을 하는 방법을 사용한다.
많은 모델링 방법 중에서도 이 방법이 가장 실제 세계와 비슷한 것 같다. 실제 생명체는 재생산이 필요할때는 자신의 DNA를 복제하는 방법을 사용한다. 자기자신의 DNA는 없고, @ISA 배열이 어떤 부모가 나머지 DNA를 가지고 있는지를 알려주게 된다.
펄 6에 있는 메타 오브젝트 프로토콜은 기본적으로 class 기반이지만, 프로토타입 기반 오브젝트로도 충분히 설정될 수 있을만큼 유연하다. 여러분 중 일부는 펄 5의 Moose를 사용해 봤을 수도 있을 것 같은데, Moose는 사실 펄 6의 오브젝트 모델의 프로토타입이였다.
의미적인 레벨에서 말이다. 문법은 조금 다르지만, 펄 6에서 좀 더 자연스러워졌다.
passive data, global consistency / active data, local consistency
당신의 지식에 따라서 데이타나 로직이 얼마나 기능적이고 객체 지향적이느냐가 많이 다를 수 있을 것이다. 사람들은 제각각 사물을 다르게 본다. 어떤 사람들은 수학적으로 생각하기를 좋아한다. 기능적인 프로그래머들은 암시적인 계산들을 여기저기 스택과 힙에 뿌려놓더라도 그 코드들이 사이드 이펙트를 받지 않는 한 신경쓰지 않는다.
어떤 사람들은 사회적인 관점에서 바라보는 사람들도 있다. 이런 사람들에게는 계산의 상태와 같은 정보가 각 개별 오브젝트에 저장되어야 한다는 것은 아주 중요한 사실이다.
물론 어떤 사람들은 논리적인 셜록 홈즈가 될지 사회적인 닥터 왓슨이 될지를 결정하지 못하는 사람들도 있다. 운좋게도, 스크립팅은 이런 접근방법과는 전혀 어울리지 않는다. 왜냐하면 두 가지 방법 모두 정상적인 사람들에게 더욱 어울릴 것이기 때문이다.
info hiding / scoping / attachment
마지막으로 여러분이 컴퓨터 언어를 설계하고 있다면, 데이타를 캡슐화하는 방법에는 여러가지가 있다는 것을 알 수 있다. 어떤 것이 더 중요한지를 판단해야 하고 어떤 방법이 프로그래머로부터 관심사항들을 분리(Seperation of Concerns)하는데 도움이 되는지를 파악해야 한다.
object / class / aspect / closure / module / template / trait
위의 여러가지 캡슐화 방법들을 사용할 수 있다.
transaction / reaction / dynamic scope
아니면 시간 기반 도메인에 기초해서 정보를 독립화 할 수도 있다.
process / thread / device / environment
정보를 운영체제의 개념 공간에 저장할 수도 있다.
screen / window / panel / menu / icon
GUI와 같은 곳에 정보를 담을 수도 있다. 그래 맞다. 나는 모든 것은 오브젝트라는 것을 안다. 하지만 몇몇 오브젝트들은 다른 것들보다 더 똑같다.
syntactic scope / semantic scope / pragmatic scope
정보는 프로그램의 다양한 부분에 담겨질 수 있다. 심지어는 어휘 영역에까지 말이다. 그렇지만 심각하게 고민해 본다면, 어휘 영역이 또한 동적 영역의 종류라는 것을 알 수 있다. 그렇지 않다면 재귀가 정상적으로 작동하지 않을 것이다.
state 이라는 변수는 사실 my 변수보다 어휘적으로 더욱 순수하다고 할 수 있다. 왜냐하면, 해당 어휘 영역으로의 모든 호출들에 의해서 공유되기 때문이다.
그래서 대부분의 영역은 특정 문법적인 영역에 덧붙여진 의미적인 영역이 된다.
아마도 필자가 말한 실질적인 영역(pragmatic)이 무엇인지 궁금할 것이다. 그건 바로 프로그램의 유저의 머리속에 저장된 영역이나 두뇌 속에 있는 대리 저장 물질이다. 예를 들면 게임 카트리지 처럼 말이다.
생각해 보면 대부분의 인터넷 웹페이지는 실질적 영역에 속한다고 볼 수 있다. 실은 모든 데이터는 데이터베이스에 있기 때문이다. 실질적인 영역의 특징은 여러분이 컨테이너의 생명주기를 알 수 없다는 것이다.
어딘가에 있다가 가비지 콜렉터에 의해서 수집될 것이기 때문이다. 구글 캐쉬만이 가장 오래남은 데이터일 것이다. 결국엔 URL을 다 잊게 될 것이지만, URL의 본질만은 잊어버려서는 안된다. 이것이 바로 우리의 다음 자유로의 길을 지켜줄 것이기 때문이다.
use Lingua::Perligata;
만약에 언어가 자신의 문법을 어휘 영역 안에서 변형시킬 수 있다면 어떻게 이런 것들을 파악할 수 있을까? 펄 5는 소스 필터라는 안 좋은 방법을 발견했지만, 이것이 결국엔 Perligata와 Klingon이라는 펄의 신조어를 만들어 냈다. 만약에 제대로 했다면 어땠을까?
제대로 하는 것은 아마도 언어의 진화를 실질적인 영역 혹은 여러 실질적인 영역으로 간주하는 것이 필요했을 것이다. 여러분 스스로 URL과 같은 신조어를 만들어 내야한다. 그러기 위해서는 기반이 되는 언어가 필요할 것이고, 그 기반이 되는 언어를 당신이 좋아하는 신조어로 참고 할 수가 있어야 할 것이다.
사실 이게 바로 펄 6의 핵심에 가깝다고 볼 수 있다. 펄 6을 단순히 하나의 언어라고 본다기 보다는 관련된 언어들의 기반 언어로 봐야한다. 한 군의 언어로서 당연히 공유하는 가치들이 있을 것이고, 이 가치들은 형제 언어나 자식 언어를 통해서 전달되어 지게 된다.
아마도 이런 자유도에 놀랐을 수도 있을 것이다. 물론 이보다 더 심도있게 생각해 볼 수도 있다.
물론 여전히 펄 6를 스크립팅 언어로 볼 수도 있다. 왜냐하면 이런 사고들이 단순히 이분법적인 사고는 아니기 때문이다.
당신은 X에 대해서 생각조차 할 수 없어.
X를 할 수 있는 방법은 한 가지 밖에 없어.
X를 할 수 있는 방법은 여러가지가 있어.
X를 할 수 있는 방법은 셀 수 없이 많아.
여기에 있는 슬로건 중에서 눈에 띄는 것이 있을 수도 있을 것이다.
Curling Up
필자는 모든 스크립팅 언어가 지금까지 말했던 모든 것들에 대해서 심도있게 고려해야 한다고 생각하지는 않는다. 물론 펄 6는 그렇다고 하더라도 말이다.
여러 이론에 의하면 우주는 10, 20 차원에 놓여져 있다고 하지만, 우리는 단지 3, 4차원 정도만을 인식할 수 있다. 나머지는 그저 생각하지도 못한다. 아마도 우리는 스크립팅의 세계에 살고 있는지도 모른다.
대부분의 스크립팅 언어중에서 펄 6는 이 모든 차원을 다 포함하게 될 것이다. 하지만 실제 세계에서 이런 차원들을 알아내기 위해 엄청난 기계들을 이용하는 것과는 달리 우리는 단지 선언을 확실하게 하는 것으로 이런 차원들을 풀어나가게 될 것이다.
예를 들어 펄 5만 해도 이미 그런 것들을 하고 있다. use strict; use warnings; 와 같은 것들 말이다. 이미 기본적인 이런 것들은 당연히 사용해야 하는 것으로 받아들여지고 있다. 그래서 이제 이런 것들은 펄 6에서는 기본 포함이 되는 것으로 바뀌게 될 것이다.
미래
스크립팅의 미래는 어떨까?
필자의 편파적이지 않은 생각에는 펄 6가 대세일 거라 생각한다. ^^
심각하게 생각해 보자면 생태학적으로 볼 때 결국엔 아주 일부 주요 언어들만이 남게 될 것이라고 예견할 수 있다. 애플스크립트 같은 몇몇 언어들은 특별한 생태적 위치를 가지고 있으며 거기서 벗어날 것 같지는 않다.
여러가지 중에서 일반적인 지혜는 나쁜 것이 낫다(worse-is-better)라는 방식을 사용하는 쪽이 더욱 많이 받아들여질 것이다. 뭔가 좀 더 얘기해 보자면 필자가 좀 더 안좋은 것에 익숙하기 때문에 여러분의 안좋은 것에 익숙함 보다는 더 나을 것이다. 그런데 나쁜 것이 좋은 것이다는 접근 방법이 정말 결국에 승리하는 접근방법일까? 이런 것들이 맞는지 안 맞는지는 시간만이 말해줄 수 있을 것이다.
저자 : Larry Wall
역자 : 노재현
원문 : Programming is Hard, Let"s Go Scripting...
대부분의 사람들은 스크립팅을 좀 가볍게 생각할 지도 모른다. 정확하게 뭐라고 표현해야 할지 모르겠지만, 보통 다음과 같은 말들로 표현되곤 한다.
- 간단한 언어
- 모든 것은 문자열이다.
- 빠른 프로토타이핑
- 접착 언어
- 프로세스 제어용
- 간결하고 압축적인
- 최악이 더 낫다
- 도메인 종속적인
- 배터리가 포함되었음
쉬운 진입로
기본적으로 스크립팅은 기술적인 용어가 아니다. 보통 스크립팅 언어라고 부를때는 기술적인 판단보다는 언어나 문화적인 판단을 이용하게 된다.
필자는 스크립팅을 언어의 뿌리에서 갈라져 나온 한 종류라고 본다.
과거
Ada Lovelace가 있는 과거로 돌아갔다고 상상을 해보자. 그녀에게 스크립트와 프로그램의 차이점이 무엇이냐고 물어보면 어떻게 대답해 줄까? 분명히 여러분을 우스꽝스럽게 쳐다보며 스크립트는 배우들에게 주는 것이고, 프로그램은 관객들에게 제공해 주는 것이라고 답할 것이다. Ada는 아주 영리한 숙녀였다.
그 이후로 지금까지 우리는 스크립팅을 말할때 그게 무엇인지 혼돈에 빠져 있는 것 같다. 심지어 전문가인 나조차도 더욱 혼란스럽다.
그래서 지금 여기서 필자가 해줄 수 있는 것은 필자의 좁은 소견에서 바라본 스크립팅의 과거, 현재 그리고 미래이다. 그리고 미리 말하는 건데, 글을 쓰는 중에 필자의 편견이 녹아들어 갈 수도 있다는 것이다.
기본
필자는 베이직 프로그래머로 프로그래밍을 시작했었는데, 베이직이 첫번째 주 스크립팅 언어라고 생각한다. 특히나 DEC이 미니컴퓨터에 인자를 가진 재귀 함수를 넣은 BASIC/PLUS가 바로 첫 번째 스크립팅 언어라고 생각한다.
이런 생각에 대해서 어떤 사람들은 의심할 여지가 없이 맞는 얘기라고 하는 사람도 있지만, 아니라고 하는 사람들도 있다. 하지만 이 점에 대해서는 굳이 사과할 생각은 없다.
RSTS BASIC/PLUS
필자가 PDP-11 에서 RSTS 프로그래머로 일하던 시절에는 베이직을 확실히 스크립팅 언어로 생각하고 있었다. 빠른 프로토타이핑과 프로세스 제어 관점에서 볼 때 말이다. 펄의 문장구조는 BASIC/PLUS에서 바로 나왔다. 심지어는 문자열과 정수를 실수와 구분짓기 위한 표시를 변수의 끝에 가지고 있다.
하지만 익스트림 프로그래밍을 할 수 있다. 사실 대학 시절 친구와 함께 페어 프로그래밍을 했던 적이 있다. 우리는 컴파일러 작성 수업을 함께 들으면서 드래곤 책에 있는 많은 내용을 공부했었다. 물론 그때 교수님은 이제 여러분이 자신만의 PL/0 이라고 불리는 자신만의 언어를 만들어야 한다고 말씀하셨다.
어떻게 해야할까에 대해서 생각을 해본 후에 베이직으로 프로젝트를 진행하기로 결정했었다. 교수님에게 말씀드렸더니 마치 제정신이 아닌 것 아니냐는 듯이 쳐다보셨던게 기억난다. 같은 수업을 듣는 어느 누구도 베이직을 사용하지 않았었기 때문이다. 그런데 결과는 어떻게 되었을까? 같은 수업을 듣는 학생 중 그 누구도 컴파일러를 완성한 사람이 없었다. 하지만 우리는 컴파일러를 다 만들었을 뿐만 아니라, I/O 기능까지 추가하고, PL 0.5라고 불렀었다. 바로 이게 빠른 프로토타이핑이라는 것이다.
Unix?
한 때 컴퓨터 센터에 벨 연구소로 부터 연락이 왔었던 적이 있다. 우리한테 Unix V6 테잎을 싼 가격(100 달러)에 팔겠다고 하는 것이었다. 이유인즉, 곧 V7이 나올 것이여서 라는 것이다. 이때 우리는 서로를 쳐다보며 "왜 우리가 Unix라고 불리는 것을 사야하는 거지? 우리는 RSTS가 있잖아."라고 말했다.
JAM (no not that one)
필자의 첫번째 스크립팅 언어는 베이직으로 만든 것이었다. 컴퓨터 센터에서 일하던 중에 임시적으로 그리고 다기능용으로 사용할 메타 언어인 JAM이라고 불리는 언어를 만들었었다.
JAM은 HTML이 아직 없었다라는 것을 제외하면 PHP와 같은 완전한 텍스트 프로세싱 언어였다. 우리는 이 언어를 베이직을 위한 매크로 프로세서로 사용하곤 했었다. PHP와 다른 점은 3000개나 되는 함수를 가지고 있지는 않다는 것이다.
LISP
좋던 안 좋던간에 대학원에 진학했을때, 언어학을 공부했었다. 그리고 그 때 사용했던 유일한 언어는 LISP이였다.
LISP도 스크립팅 언어로 봐야할까? 물론 LISP으로 빠른 개발을 할 수도 있겠지만, 아무리 봐도 스크립팅 언어로 보기는 어렵다.
Pascal, Ada
업계로 진출했을 때, 분산 이벤트 시뮬레이터를 만들기 위해서 파스칼로 컴파일러를 만들었었다. 언어학자로서, Ada를 널리 통용되는 언어라고 생각하지 않는다. 영어나 일본어와 같은 언어가 바로 널리 통용되는 언어이다. Ada는 그저 중간 크기의 언어라고 보면 된다.
Unix, shell
몇 년후에 Unix와 그 외 여러가지 스크립팅 언어에 익숙해 지게 되었다. 좀 더 자세하게 말하면, BSD와 csh 정도.
BSD, csh
C 언어도 조금 배웠습니다.
C
C언어 밖에 없어서였기 때문이다. 여전히 라이브러리에 대해서 공부하고 있다.
shell + awk + sed + find + expr...
유닉스 쉘 프로그래밍의 어려움이 바로 펄이라는 언어가 탄생하게 되는 계기가 되었다. 쉘 스크립팅에 사용되는 여러 언어들 간의 기본적인 동사나 명사들이 일치하지 않아서 언어 자체에 제한이 많이 가해지고 있었다.
C xor shell
더욱더 안 좋았던 것은 1차원의 세계였다는 것이었다. C아니면 쉘에서 프로그래밍을 해야 했었는데, 두 언어가 서로 완전 다른 언어였다는 것이다. 필자가 스크립팅이라는 것을 항상 프로그래밍과는 반대의 무엇으로 봐야하는 것이 아니라는 것을 깨달았을 때쯤에 펄이 탄생했다. 펄이라는 하나의 언어가 두 가지 용도로 사용하기에 모두 좋았다.
Tcl
펄이 나온후에 Tcl이 등장했다. 펄은 모든 것이 문자열인 것처럼 작동하게 끔 되어 있었는데, Tcl은 실제로 문자열을 이용하게끔 만들어져 있었다. 하지만 이 문자열을 이용한 방법은 아주 안 좋은 성능을 나타내는 방법이었다. 하지만 이게 Tcl의 입지를 약화시키는 요인은 아니였다. 두 가지 이유가 있었는데, 하나는, Tcl은 툴을 다루는 것과 만드는 것은 완전 다른 일이라는 Unix의 정신세계를 이어 받았다는 것이다. 언제나 빨리 작동해야 하는 부분은 C로 작성해야만 했다.
두번째 이유는 확장이 어려웠다는 것이다. 그래서 expect, incr-tcl과 같은 툴들이 생겨나게 되었다.
하지만 확실히 말하지만 필자는 Tcl의 위임 모델을 존경해왔다. 하지만 Tcl은 LISP과 같이 모두에게 항상 하나의 문법만을 이용하기를 강요하는 함정에 빠져 있었다.
Python
Tcl 이후에 파이썬이 탄생했다. 파이썬 커뮤니티의 정신은 펄에게 소극적으로 받아들여지게 되었다. 필자는 파이썬에 대해서 많이 알지도 못하고 파이썬이 이렇다 저렇게 평가할 만한 입장이 되지 못한다. 단지 Perl 5의 오브젝트 시스템에 파이썬의 시스템을 이용했다.
Ruby
사실 루비에 대해서는 할 말이 많다. 왜냐하면 많은 루비의 문법이 펄로 부터 왔기 때문이다. 필자는 항상 루비를 펄의 가장 강력한 경쟁 언어로 생각하고 있는데, 그 이유는 단지 루비가 펄의 아이디어를 빌려왔기 때문이 아니고, 루비와 펄 모두 펑셔널 프로그래밍 기능을 파이썬보다 더 심도있게 지원하고 있기 때문이다. 필자의 생각엔 루비는 선언 문법에 있어서 약간 일치되지 않는 점이 있는 것 같다.
*sh
와중에 Bourne이 Korn 쉘과 bash 쉘로 확장이 되게 되었다. 계속적인 쉘의 진화가 보여준건 계속된 문법 기능의 추가가 언어에 정교함을 추가해 준다는 것이였다.
PHP
우리는 최악의 선택이 더 나은 선택으로 작용한 PHP가 승승장구 하는 모습을 보고 있다. 어쨌든 PHP는 펄이 초기에 했던 실수를 반복하고 있는 것 같다. 단지 천천히 진행되고 있을 뿐이다. 한 가지 PHP가 나은 점은 패키징에 있다. 패키징은 네임스페이스를 의미하는 것은 아니다.
JavaScript
그리고 깔끔한 디자인의 자바스크립트이다. 몇가지 이슈가 있지만 결국엔 펄 6를 실행할 수 있는 플랫폼이 될 수 있을 것이다. 필자의 생각엔 새로운 자바스크립트 엔진이 나오게 되면, 이 자바스크립트 엔진을 백엔드로 사용하는 것에 대한 세상의 관심이 집중될 것이라고 생각한다.
Monad/PowerShell
마이크로소프트의 Monad를 조금 보았는데, 펄 6과 같은 오브젝트 파이프 기능이 있어서 기뻤다. 마이크로소프트가 저작권을 침해하지 않았기를 바란다.
Lua, AppleScript
많이 사용되는 스크립팅 언어들이 정말 많이 있을것인데, 먼저 필자는 Lua나 AppleScript에 대해서는 잘 살펴본 적이 없다. 아마도 필자가 게임 디자이너가 아니기 때문일 것이다.
The Present
현재 상황을 볼 때, 여러 스크립팅 커뮤니티가 마치 정글에 있는 여러 부족들과 같아 보인다. 가끔은 서로 거래를 하기도 하고, 전투를 벌이기도 하는 부족 말이다.
필자는 인류학점인 관점에서 한 번 살펴보기로 했다. 여러분의 대다수는 펄 프로그래머 이거나, 아니면 다른 언어 프로그래머 종족이라고 하자. 여러분 각자는 자신이 속한 종족에 따라서 문자열을 다르게 볼것인데, C언어 프로그래머라면 바이트 배열에 대한 포인터라고 볼 것이고, 펑셔널 프로그래머라면 리스트라고 볼 것이며, 자바 프로그래머라면 오브젝트라고 보게 될 것이다.
필자는 문자열을 대문자 T로 시작하는 텍스트라고 본다.
Text
필자는 이 단어를 포스트모더니즘의 관점에서 생각했다. 물론 포스트모더니즘이라는 말은 문맥에 따라서 달라질 수 있다. 어떤 사람들은 포스트모더니즘이 그저 일반적인 것에 힘을 부여해 주는 정도밖에 되지 않는다고 생각한다. 어떤 사람들은 펄에 대해서도 같은 방식으로 생각하기도 한다.
하지만 필자는 포스트모더니즘을 말이든 글이든 간에 텍스트가 양방간에 의사소통을 위해 필요한 지식정도로 생각을 하고 있다. 필자는 멍청한 프로그래밍 언어와는 얘기하고 싶지 않고, 내가 타이핑하는 문자열을 이해할 수 있는 언어를 원한다.
펄은 포스트모더니즘의 언어이다. 많은 보수적인 사람들은 포스트모더니즘을 다소 자유로운 관념이라고 받아들이기도 한다. 그래서 필자의 포스트모더니즘에 대한 견해는 선교(혹은 전도) 활동을 통해서 배운 언어학, 번역학에서 많은 영향을 받았기때문에 어떻게 보면 약간의 아이러니한 면이 있다.
한가지 중요한 점은 어디에도 기본적인 사람의 언어라는 것은 없다는 것이다. 즉, 모든 사람의 언어는 Turing Complete가 되는 것이다.
여러분이 원시 부족이 있는 곳으로 가서 그들의 언어를 분석해 보게 된다면, 그들의 언어가 다른 사람의 언어만큼이나 복잡하다는 것을 알 수 있다. 여러분은 사람의 언어로 여러가지 것들을 말할 수 가 있고, 계속해서 그 말을 하게 된다면, 그 사람의 언어는 곧 Turing Complete이 되게 된다.
그렇기 때문에 사람의 언어는 당신이 그렇다고 생각하고 있던 것과는 많이 다르다. 영어로 얘기할때는 단수와 복수를 확실히 구분해야만 한다. 일본어에서는, 단수와 복수를 구분할 필요는 없지만, 정중함의 정도를 조절할 줄 알아야 한다. 즉, 상대방에 대한 존경을 표현할 수 있는 정도를 선택해야 하고, 상대방의 입장에서 내가 존중 받아야 하는 정도를 생각해서 말해야 한다.
그래서 언어는 당신이 말하도록 되어 있는 것과는 다르다. 분명한건 여러분의 언어로 뭔가를 말해야 한다면, 분명히 그 언어에 따라서 말하려면 간단하게 말하기는 힘들 것이다. 그래서 바로 스크립팅이 나오게 된 것이다.
서로 다른 스크립팅 언어를 이용해서 간결하게 말할 수 있는 방법이 몇가지나 있을까?
러시아식 수프를 만들 수 있는 방법은 몇가지나 있을까?
언어 디자이너는 아주 많은 자유도를 가지고 있게 된다. 필자는 그중에서 일부에 대해서 말해보고자 한다.
early binding / late binding
여기서의 바인딩은 특정 이름을 가진 루틴을 언제 호출할 것인지를 결정하는 것을 말한다. 초기에는 효율성의 이유로 바인딩의 시점을 결정하는 일이 어렵지 않았다. 컴파일 타임에 하거나 아니면 링크 타임에 하면 되었다. 여러분은 여전히 이런 방법의 바인딩을 사용하는 언어들을 보았을 것이다.
하지만, Smalltalk과 같은 언어를 보면 다른 경향을 가지고 있다는 것을 알 수 있다. 그리고 요즘에는 많은 스크립팅 언어들이 지연 바인딩쪽을 선호하고 있다. 왜냐하면 스크립팅 언어들이 "내가 원하는 것을 수행하라(Do What I Mean)"는 원칙을 따르려고 하고 있기 때문이다.
그리고 그 결정은 보통은 지연 바인딩을 선택하게끔 하게 되는데, 이렇게 됨으로써 보다 의미적이고 실질적인 문맥을 가지고 작업할 수 있게 되기 때문이다. 그렇지 않으면 미래를 예견해야만 하기 때문이다.
그래서 스크립팅 언어는 실제 메쏘드의 디스패칭 시점 이전에는 바인딩을 하지 않는 객체 지향적인 관점으로 점차 변화하고 있다. 여러분은 자바와 C++ 언어사이의 충돌을 경험한 적이 있을 것이다. C++의 메쏘드는 기본적으로 non-virtual 타입이다. 그렇기 때문에 지연 바인딩을 하기 위해서는 명시적으로 virtual이라고 명시해 줘야 한다.
자바에는 final이라는 개념이 있는데, 이것은 컴파일 타임에 클래스에 대한 바인딩을 가능하게 해주는 역할을 한다. 필자는 이 두가지 방법이 전부 실수라고 생각한다. 펄6에서는 다른 실수를 할 생각이다. 펄 6에서는 모든 메쏘드는 기본적으로 virtual이고, 오직 전체적으로 애플리케이션 만이 옵티마이저에게 클래스를 finalize 하라고 알려줄 수 있다.
single dispatch / multiple dispatch
다중 디스패칭은 바인딩을 더욱 늦출 수 있는 하나의 방법이다. 실제 오브젝트의 타입을 알때까지 바인딩을 늦춰야 할 뿐만이 아니라 메쏘드를 호출하기 전까지 메쏘드로 전달되는 모든 인자들의 타입까지 알아야만 한다. 파이썬과 루비는 항상 단일 디스패칭만을 하게 된다. 반면에 Dylan은 다중 디스패칭을 사용한다.
여기 바로 펄 6가 내세우는 한 가지가 있는데, 바로 호출자가 명확하게 정의되어야 한다는 것이다. 이 점이 프로그래머에게는 아주 중요하다고 생각하는데 바로 단일 디스패칭과 다중 디스패칭은 개념이 아주 다른 것이기 때문이다.
단일 디스패칭 언어에서는 오브젝트에게 메시지를 보내게 되고, 오브젝트는 메시지를 보고 무엇을 할 지를 판단하게 된다. 다중 디스패칭 언어에서는 하나의 특권을 가진 오브젝트라는 것이 없이, 호출에 관계되어 있는 모든 오브젝트가 모두 같은 비중을 가지게 된다. 그래서 다중 디스패칭 언어를 바라보는 한 가지 관점은 오브젝트들이 완전히 수동적이다 라는 것이다.
하지만 만약 오브젝트들이 어떻게 바인딩을 하게 될지 결정하지 못한다면 누가 해야 할까?
민주적인 방법일 수 있는데, 모든 루틴들이 모여서 정치적인 회의를 열게 된다. 각 루틴은 회의의 대표라고 보면 된다. 모든 대표가 자신의 이름을 모자에 적어 넣은 후에, 누가 하는 것이 가장 좋을지에 대한 투표를 한 후에는, 차선을 뽑고, 그 다음에는 그 차선을 뽑게 된다. 이제 각자는 어떤 루틴을 호출하는 것이 가장좋은지에 대해서 결정을 하게 된다.
기본적으로 다중 디스패칭은 민주적이지만, 지연 바인딩을 하기에는 최악의 방법이라고 할 수 있다.
필자는 그것이 사실이라고 생각하고, 앞으로 더욱 더 그럴것이라고 생각한다. 필자는 이 다중 디스패칭에 대해서 더 많은 시간을 들여서 노력하고 있는데, 왜냐하면 프로그래밍 자체가 단일 디스패칭의 명령-제어 구조로 부터 변화해 가고 있다고 생각하기 때문이다.
이제 컴퓨터 분야는 곤충과 같은 한 무리의 집단에 의해서 더 잘 결정될 수 있는 방식으로 변화해 가고 있다고 생각한다. 즉 단 한 쪽의 의지에 의해서만 결정되는 것이 아닌 그보다 우수한 집단의 판단이 작용할 것이다.
eager evaluation / lazy evaluation
펄 5와 같은 대부분의 언어는 평가를 확실하게 한다. 어떤 언어들은 이런 평가들을 너무 확실하게 하지 않으려고 하기도 한다. Haskell이 그의 좋은 예라고 할 수 있다. Haskell은 실행해야 할 때가 오기전까지는 아무것도 계산하지 않는다. 이런 방식의 장점은 여러분이 무한하게 긴 리스트를 가지고 메모리의 고갈 없이 작업을 할 수 있다는 것이다.
물론 누군가가 프로그램에게 리스트의 길이를 계산하라고 하기 전까지는 말이다.
어쨌든 펄 6에서는 철저한 평가와 그렇지 않은 평가의 혼합에 대해서 테스트를 해보고 있다. 재밌게도, 이런 차이점이 펄 5의 스칼라 문맥 대 리스트 문맥과 아주 잘 매칭되고 있다는 것이다. 그래서 펄 6에서는 스칼라 문맥은 철저한 평가를 하게 되고, 리스트 문맥은 확실한 평가를 하지 않게 된다. 물론 기본적으로 그렇다는 것이다.
언제든지 원한다면 그 반대로도 적용해 볼 수 있다. 무한루프에 빠지지 않도록 중간에 빠져나갈 수 있는 코드만 있다면 for 1..Inf 과 같은 것도 해볼 수 있다.
eager typology / lazy typology
정적 vs 동적으로 알려져 있다. 필자는 점차적인 타이핑(typing)을 더 선호한다. 효율성이 한 가지 이유이다. 펄 6에 타입을 넣은 이유는 강한 타이핑을 위해서가 아니고 다중 디스패칭을 위해서이다.
이전에 했던 다중 디스패칭에서의 회의를 기억하는가? 여러 후보들이 자신들의 이름을 모자에 써 넣은 다음에는 어떻게 그들을 구분할 수 있을까? 각 후보는 모두 각자의 정치적인 기반을 가지고 있다. 각 정치적 기반에서 나오는 강령은 그들이 반응하기 원하는 인자의 타입이다.
우리 모두는 정치인들이 자신들이 받기 좋아하는 부분에 대한 인자의 타입에 대해서 반응한다는 것을 알고 있다.
펄 6가 펄 5와 비교해서 또 다른 방법으로 지연을 하고 있는 것이 있다. 여전히 문맥이라는 개념을 가지고 있다. 하지만 정확히 말하자면 언제 문맥이 정해지냐하는 것이 달라졌다. 펄 5에서는 컴파일러는 컴파일 타임에 어떤 인자가 스칼라 문맥에 속하는지 어떤 인자가 리스트 문맥에 속하는지를 알 수 있었다.
하지만 펄 6에서는 메쏘드의 바인딩 시점(개념적으로는 런타임)까지 그 결정을 지연시키게 된다. 이상하게 들릴수도 있지만, 펄 5의 설계에서 차선으로 미루었던 많은 문제들을 해결할 수 있었다. 예를 들면 프로토타입과 명시적인 참조의 필요성 같은 것이다.
limited structures / rich structures
Awk, Lua 그리고 PHP는 모두 복합 구조체를 연관 배열이 되지 못하도록 제한을 가하고 있다. 장단점이 있겠지만, 사실 awk가 그렇게 했다는 것이 펄은 그렇게 하지 않겠다고 결정하게 된 하나의 이유이고, 그것이 정렬된 배열과 정렬되지 않은 해쉬를 구분하도록 만들었다.
필자는 둘을 다른 것으로 생각했고, 많은 다른 사람들도 같은 생각을 가지고 있었다.
symbolic / wordy
틀림없이 APL은 스크립팅 언어의 한 종류이다. 다른 방면에서 보자면 우리는 단어 때문에 구두점을 피하는 많은 언어들을 알고 있다. 예를 들자면, AppleScript와 COBOL, 그리고 알골 계열의 언어들과 같이 블락을 나타내기 위해서 단어를 이용하는 언어들이다.
나는 균형잡힌 방법을 선호한다. 심볼과 식별자 각자가 자신에게 가장 적합한 방법대로 이용되는 것이다. 프로그래머들에 의해서 문제점을 해결하기 위한 선택된 단어들이 사용되는 것을 좋아하고, 단지 문법을 위해서 사용되는 단어는 싫다.
그런 단어를 사용하게 되면 실제로 많은 단점들이 있기 때문이다. 이점은 필자가 파스칼에서 C언어로 오면서 배우게 된 점이다. 블럭을 지정하기 위해 { 를 사용한 것은 정말 좋은 점이다.
사실 코볼보다 더 심한 언어도 봤었다. 파스칼에서 변형된 언어중에 하나였는데 그 언어는 키워드가 대문자로 표현되서 더 눈에 잘띄게 했었다. 이런건 정말 안된다! 틀린 단어만 계속해서 나오게 될 것이다. IF! foo THEN! bar ELSE! baz END! END! END! END!
어쨌든 펄 6에서는 어디에서 구두점을 사용하고 말지를 결정할 기준을 세웠다. 필요없는 곳에서는 과감하게 제거 했다. 예를 들면, 조건 문에서의 괄호말이다.
그리고 강조해야 되는 부분에서는 더더욱 강조시켰다. 각 심볼은 자신의 존재를 허프만 코딩에 따라서 확실히 해야한다.
이상하게도 새롭게 구두점을 추가한 곳이 한 군데 있다. sigil의 다음에 twigil을 추가하거나 두 번째 sigil을 추가할 수 있다. sigil이 오브젝트의 기본 구조를 말해주는것과 마찬가지로, twigil 도 특정 변수의 활동 영역을 말해주게 된다. 원래 이 아이디어는 루비에서 가져온 것이다.
하지만 sigil 후에 twigil을 숨기게 됨으로써, 루비에 비해 더 좋은 결과를 얻을 수 있고 더 확장적인 twigil 시스템을 갖추게 되었다.
확장성에 대해서 많은 생각을 해 보았었는데, 우리는 아직 우리가 어떻게 생각해야 하는지 모르는 언어를 생각하고 있다. 하지만 새로운 언어에 문법을 위한 공간을 남겨놓는다는 것은 국립 공원과 국립 삼립원을 위해 공간을 남겨놓는 것과 비슷하다. 혹은 고고학자가 고고학적인 유적지를 반 이상 파지 않고, 더 좋은 분석 도구를 갖고 있을 후손을 위해 놔두는 것과 비슷하다고 할 수도 있다.
정말이지 미래를 위한 언어를 설계한다는 것은 많은 겸손을 필요로 한다. 과학과 마찬가지로 오랜 기간에 거쳐 어떤 가정을 하게 되고 생각을 하지만, 그 많은 생각들이 맞지 않는 것으로 나타날 때도 있다. 반면에 지금 여러분이 정확한 예측을 할 수 없다면, 여러분은 정말 과학을 하는 것이 아니다. 돌이켜보건데, APL은 정말 많은 이상한 심볼들을 가지고 있었다. 하지만 APL이 그 같은 시도를 하지 않았다면 아마 지금 그게 이상하다고 생각하지 못했을 것이다.
compile time / run time
많은 동적 언어들은 런타임에 코드의 평가를 할 수 있다. 펄은 그 기능을 좀 다른 각도에서 받아들여서 많은 코드를 컴파일 타임에 실행이 가능하다. 이렇게 하는 것이 동작성의 정의에 혼란을 줄 수 있다. 여러분은 그다지 많은 파일 I/O 연산을 BEGIN 블럭에서 하길 원치 않을 수도 있다. 하지만 이런 방법이 우리는 또 다른 차이점을 가진 언어로 인도하게 된다.
declarational / operational
대부분의 스크립팅 랭귀지 들은 역할측면에서 볼때 너무 지나치게 기능이 들어가면이 없지 않아 있다. 필자 역시 루아를 보기 전까지는 펄 5가 아주 간략화된 오브젝트 시스템이라고 생각했었다. 루아에서는 오브젝트는 단지 해쉬일 뿐이고, 코드를 포함하게 될 경우에 필요한 문법적인 요소가 다소 추가되었을 뿐이다.
심지어는 클래스조차 가지고 있지 않다. 상속과 같은 것은 위임을 통해서 처리가 가능하다. 바로 이것이 루아의 설계자가 루아를 가볍고 임베딩이 가능한 언어로 만들기 위해서 지켰던 것이다. 그들에게는 바로 이것이 제대로 된 설계였다.
펄 5는 파이썬이나 루비에 비해서 좀 더 선언적인 면이 있다. 항상 느끼지만 암시적인 선언은 문제를 일으키기에 너무 쉽다고 생각했고, 명확한 변수의 영역 설정이 좀 더 가독성을 높여준다고 생각했다.
바로 그래서 my 가 있는 것이다. 매우 간략하게 쓴 이유는 많이 사용될 것이라고 예견했기 때문이다. 허프만 코딩과 같인 자주 사용되는 것은 짧게, 하지만 너무 짧게는 하지 않았다. 이 경우 0을 썼다면 너무 짧게 사용한 것이라고 할 수 있다.
펄 6에서는 또 다른 영역 설정의 종류가 늘어나서 my말고도 our라는 것이 생겼다. 하지만 단어 자체의 의미에 약간 혼란스러울 수도 있을 것이다.
immutable classes / mutable classes
자바의 클래스가 닫혀있다는 점은 자바가 꽤 빠르게 실행될 수 있는 이유 중 하나이다. 반대로 루비의 클래스는 열려있는데, 이는 곧 언제든지 클래스에 원하는 새로운 것을 추가할 수 있다. 그 점이 바로 루비를 느리게 만드는 이유 중에 하나일 것이다.
하지만 그 점이 바로 루비에 Rails가 있었던 이유라고도 할 수 있다.
펄 6는 변형가능과 변형불가능 클래스의 혼합형의 기능을 가지게 될 것이다. 또 누가 언제 클래스를 닫을 것인지에 대한 정책도 있을 것이다. 예를 들면, 클래스 자신은 자신을 닫거나 finalize 할 수가 없다. 미안하지만 필자는 펄 6에 관한 얘기를 계속해서 할 것이다.
class-based / prototype-based
여러분중 일부는 Self나 자바스크립트와 같이 클래스가 없는 언어에 친숙한 사람도 있을 것이다. 이런 언어는 클래스 대신에 자신의 부모로부터 복제된다거나 다른 오브젝트에 위임을 하는 방법을 사용한다.
많은 모델링 방법 중에서도 이 방법이 가장 실제 세계와 비슷한 것 같다. 실제 생명체는 재생산이 필요할때는 자신의 DNA를 복제하는 방법을 사용한다. 자기자신의 DNA는 없고, @ISA 배열이 어떤 부모가 나머지 DNA를 가지고 있는지를 알려주게 된다.
펄 6에 있는 메타 오브젝트 프로토콜은 기본적으로 class 기반이지만, 프로토타입 기반 오브젝트로도 충분히 설정될 수 있을만큼 유연하다. 여러분 중 일부는 펄 5의 Moose를 사용해 봤을 수도 있을 것 같은데, Moose는 사실 펄 6의 오브젝트 모델의 프로토타입이였다.
의미적인 레벨에서 말이다. 문법은 조금 다르지만, 펄 6에서 좀 더 자연스러워졌다.
passive data, global consistency / active data, local consistency
당신의 지식에 따라서 데이타나 로직이 얼마나 기능적이고 객체 지향적이느냐가 많이 다를 수 있을 것이다. 사람들은 제각각 사물을 다르게 본다. 어떤 사람들은 수학적으로 생각하기를 좋아한다. 기능적인 프로그래머들은 암시적인 계산들을 여기저기 스택과 힙에 뿌려놓더라도 그 코드들이 사이드 이펙트를 받지 않는 한 신경쓰지 않는다.
어떤 사람들은 사회적인 관점에서 바라보는 사람들도 있다. 이런 사람들에게는 계산의 상태와 같은 정보가 각 개별 오브젝트에 저장되어야 한다는 것은 아주 중요한 사실이다.
물론 어떤 사람들은 논리적인 셜록 홈즈가 될지 사회적인 닥터 왓슨이 될지를 결정하지 못하는 사람들도 있다. 운좋게도, 스크립팅은 이런 접근방법과는 전혀 어울리지 않는다. 왜냐하면 두 가지 방법 모두 정상적인 사람들에게 더욱 어울릴 것이기 때문이다.
info hiding / scoping / attachment
마지막으로 여러분이 컴퓨터 언어를 설계하고 있다면, 데이타를 캡슐화하는 방법에는 여러가지가 있다는 것을 알 수 있다. 어떤 것이 더 중요한지를 판단해야 하고 어떤 방법이 프로그래머로부터 관심사항들을 분리(Seperation of Concerns)하는데 도움이 되는지를 파악해야 한다.
object / class / aspect / closure / module / template / trait
위의 여러가지 캡슐화 방법들을 사용할 수 있다.
transaction / reaction / dynamic scope
아니면 시간 기반 도메인에 기초해서 정보를 독립화 할 수도 있다.
process / thread / device / environment
정보를 운영체제의 개념 공간에 저장할 수도 있다.
screen / window / panel / menu / icon
GUI와 같은 곳에 정보를 담을 수도 있다. 그래 맞다. 나는 모든 것은 오브젝트라는 것을 안다. 하지만 몇몇 오브젝트들은 다른 것들보다 더 똑같다.
syntactic scope / semantic scope / pragmatic scope
정보는 프로그램의 다양한 부분에 담겨질 수 있다. 심지어는 어휘 영역에까지 말이다. 그렇지만 심각하게 고민해 본다면, 어휘 영역이 또한 동적 영역의 종류라는 것을 알 수 있다. 그렇지 않다면 재귀가 정상적으로 작동하지 않을 것이다.
state 이라는 변수는 사실 my 변수보다 어휘적으로 더욱 순수하다고 할 수 있다. 왜냐하면, 해당 어휘 영역으로의 모든 호출들에 의해서 공유되기 때문이다.
그래서 대부분의 영역은 특정 문법적인 영역에 덧붙여진 의미적인 영역이 된다.
아마도 필자가 말한 실질적인 영역(pragmatic)이 무엇인지 궁금할 것이다. 그건 바로 프로그램의 유저의 머리속에 저장된 영역이나 두뇌 속에 있는 대리 저장 물질이다. 예를 들면 게임 카트리지 처럼 말이다.
생각해 보면 대부분의 인터넷 웹페이지는 실질적 영역에 속한다고 볼 수 있다. 실은 모든 데이터는 데이터베이스에 있기 때문이다. 실질적인 영역의 특징은 여러분이 컨테이너의 생명주기를 알 수 없다는 것이다.
어딘가에 있다가 가비지 콜렉터에 의해서 수집될 것이기 때문이다. 구글 캐쉬만이 가장 오래남은 데이터일 것이다. 결국엔 URL을 다 잊게 될 것이지만, URL의 본질만은 잊어버려서는 안된다. 이것이 바로 우리의 다음 자유로의 길을 지켜줄 것이기 때문이다.
use Lingua::Perligata;
만약에 언어가 자신의 문법을 어휘 영역 안에서 변형시킬 수 있다면 어떻게 이런 것들을 파악할 수 있을까? 펄 5는 소스 필터라는 안 좋은 방법을 발견했지만, 이것이 결국엔 Perligata와 Klingon이라는 펄의 신조어를 만들어 냈다. 만약에 제대로 했다면 어땠을까?
제대로 하는 것은 아마도 언어의 진화를 실질적인 영역 혹은 여러 실질적인 영역으로 간주하는 것이 필요했을 것이다. 여러분 스스로 URL과 같은 신조어를 만들어 내야한다. 그러기 위해서는 기반이 되는 언어가 필요할 것이고, 그 기반이 되는 언어를 당신이 좋아하는 신조어로 참고 할 수가 있어야 할 것이다.
사실 이게 바로 펄 6의 핵심에 가깝다고 볼 수 있다. 펄 6을 단순히 하나의 언어라고 본다기 보다는 관련된 언어들의 기반 언어로 봐야한다. 한 군의 언어로서 당연히 공유하는 가치들이 있을 것이고, 이 가치들은 형제 언어나 자식 언어를 통해서 전달되어 지게 된다.
아마도 이런 자유도에 놀랐을 수도 있을 것이다. 물론 이보다 더 심도있게 생각해 볼 수도 있다.
물론 여전히 펄 6를 스크립팅 언어로 볼 수도 있다. 왜냐하면 이런 사고들이 단순히 이분법적인 사고는 아니기 때문이다.
당신은 X에 대해서 생각조차 할 수 없어.
X를 할 수 있는 방법은 한 가지 밖에 없어.
X를 할 수 있는 방법은 여러가지가 있어.
X를 할 수 있는 방법은 셀 수 없이 많아.
여기에 있는 슬로건 중에서 눈에 띄는 것이 있을 수도 있을 것이다.
Curling Up
필자는 모든 스크립팅 언어가 지금까지 말했던 모든 것들에 대해서 심도있게 고려해야 한다고 생각하지는 않는다. 물론 펄 6는 그렇다고 하더라도 말이다.
여러 이론에 의하면 우주는 10, 20 차원에 놓여져 있다고 하지만, 우리는 단지 3, 4차원 정도만을 인식할 수 있다. 나머지는 그저 생각하지도 못한다. 아마도 우리는 스크립팅의 세계에 살고 있는지도 모른다.
대부분의 스크립팅 언어중에서 펄 6는 이 모든 차원을 다 포함하게 될 것이다. 하지만 실제 세계에서 이런 차원들을 알아내기 위해 엄청난 기계들을 이용하는 것과는 달리 우리는 단지 선언을 확실하게 하는 것으로 이런 차원들을 풀어나가게 될 것이다.
예를 들어 펄 5만 해도 이미 그런 것들을 하고 있다. use strict; use warnings; 와 같은 것들 말이다. 이미 기본적인 이런 것들은 당연히 사용해야 하는 것으로 받아들여지고 있다. 그래서 이제 이런 것들은 펄 6에서는 기본 포함이 되는 것으로 바뀌게 될 것이다.
미래
스크립팅의 미래는 어떨까?
필자의 편파적이지 않은 생각에는 펄 6가 대세일 거라 생각한다. ^^
심각하게 생각해 보자면 생태학적으로 볼 때 결국엔 아주 일부 주요 언어들만이 남게 될 것이라고 예견할 수 있다. 애플스크립트 같은 몇몇 언어들은 특별한 생태적 위치를 가지고 있으며 거기서 벗어날 것 같지는 않다.
여러가지 중에서 일반적인 지혜는 나쁜 것이 낫다(worse-is-better)라는 방식을 사용하는 쪽이 더욱 많이 받아들여질 것이다. 뭔가 좀 더 얘기해 보자면 필자가 좀 더 안좋은 것에 익숙하기 때문에 여러분의 안좋은 것에 익숙함 보다는 더 나을 것이다. 그런데 나쁜 것이 좋은 것이다는 접근 방법이 정말 결국에 승리하는 접근방법일까? 이런 것들이 맞는지 안 맞는지는 시간만이 말해줄 수 있을 것이다.
TAG :
이전 글 : 루비로 게임 만들기 1-2
다음 글 : 유즈케이스 다이어그램(1)
최신 콘텐츠