최근 일련의 경험으로 프로그래밍 언어에 대해 여러가지를 생각하게 됩니다.
회사에서 Perl작업을 하면서 있었던 일입니다만, 시스템본부 운영부의 admin들은 perl에서 class를 사용하는 것은 아무래도 느리기 때문에 하지 말아주길 바라더군요. fast-cgi나 mod_perl이라던지 compile해둔 코드를 관리해 실행하게 하는 방식은, 만일 하나의 스크립트가 잘못되어 halt되면 전체를 망가트릴 수 있고, 만일 CGI방식으로 작동하는 스크립트면, halt되었을 때, 해당 프로세스만 kill하면 되기 때문에 CGI방식으로 작업을 하길 원했습니다. 그렇기 때문에 더더욱 객체로 감싸서 작업하는 것은 곤란하겠지요.
최근 Scala이라고 하는 언어를 알게 되었습니다. Martin Ordersky이 만든 자바 컴파일러입니다.
Perl6 VM과 마찬가지로 Static Typing을 지원하고 groovy와 마찬가지로 java의 객체들을 불러 쓸 수 있고, perl과 비슷한 절차적 언어와 비슷한 문법을 가지고 있습니다. javac을 사용하지 않고 자체 컴파일러를 가지고 있습니다. groovy처럼 자바의 Scripting Engine의 Implementation이 아니라, 독자적인 컴파일러로 자바 IL로 컴파일합니다. 장점과 단점 모두 가질 수 있겠네요.
플러스, 닷넷의 CRL도 지원한다고 합니다만, 이에 대한 언급은 매우 작았습니다.
이미 여러 IDE의 플러그인이 개발되어 나와 있더군요. Twitter의 Message Queue는 Scala로 개발되었다고 합니다.
이번의 프로젝트에는 Python으로 해야하는 개발도 있습니다.
Python도 공부해보면 훌륭한 언어입니다. 특히 시스템관리 스크립트로는 제격인 것 같습니다. 기능과 performance간의 trade off을 잘 조정한 것 같은 느낌입니다. Tab으로 syntax를 조절하는 방식때문에 혐오하는 사람들도 꽤 있더군요. vim을 사용한다면 그럴 것 같다는 생각도 듭니다.
최근에는 여러가지 복잡한(?) 라이브러리를 사용한 j2ee솔루션과 php와의 비교도 있었습니다.
보통은, 어떤 솔루션을 구현하는데는 여러가지 언어로도 가능하며(오히려 가능하지 않은 언어를 찾기 어려운 경우가 많으며), 선택한 언어가운데에서도 많은 Variation으로 구현할 수 있습니다.
그런데 보통 하나의 개발팀은 하나의 언어만 사용하는 경우가 많은 것 같습니다. 그도 그럴 것이, 한가지 언어에 -어느 정도- 능통해지기 까지도 굉장히 많은 시간과 경험을 필요로 합니다.(정말 그럴까요? 나는 몇몇 사람들로 부터 반드시 그렇지 않다는 것을 경험합니다. 우선은 그렇다고 해두죠.) 프로젝트를 진행하면서 얻은 노하우와 스킬은 그 다음 프로젝트에서 오류가 적고 좋은 품질의 솔루션을 만들기 위해 언어를 선택할 때, 매우 큰 Advantage입니다. 반면 새로운 언어를 선택하는 것은 조직에게 있어서 엄청난 Pain일 수 있습니다. 새로운 프로젝트에서도 같은 언어를 선택하는 것은 조직으로서는 타당한 결정일 경우가 많습니다.
하지만 시스템(솔루션)으로서 생각해보면, 각각의 언어는 다른 언어와 구별되는 특징을 가지고 있으며, 이는 어떤 솔루션에 있어서는 큰 advantage 인 경우가 있습니다.
예를 들면, 어떤 CI tool을 선택할까하고 살펴본 CI tool Matrix에는 java나 c#의 implementation이 압도적으로 많습니다. 이는 어떤 종류의 소프트웨어에는 어떤 특성을 가지는 언어가 적합하다고 생각하는 경우가 많다는 것이겠지요.
아직 나로서는 결정을 내리기 어렵습니다. 어쩌면 이 글도 뭔가 일련의 생각들을 정리하기 위해 적는 것일지도 모릅니다. (날을 새서 두서없이 적는 것인지도 모르겠습니다. Issue가 무엇인지 제대로 얘기하는 것 같지 않습니다.)
그러나 인터넷에는 어떤 언어를 정해놓고 많은 솔루션의 토의가 있는 것처럼,
언어를 정해놓지 않고(또는 터놓고) 솔루션에 대한 토의도 많이 있어야 할 것 같습니다.
No comments:
Post a Comment