Programming Language War

프로그래밍 언어 전쟁

흔히 프로그래머들 사이에 일어나는 성전의 주제 중의 하나가 바로 프로그래밍 언어다. 물론 논쟁의 형태는 “어느 프로그래밍 언어가 더 좋은가/나쁜가?”는 것이다. 이 “좋은가/나쁜가”라는 말 자체는 매우 모호하다.

물론, 프로그래머들이 아닌 컴퓨터 과학자들도 프로그래밍 언어의 성질에 대해서 연구하고 있고, 이러한 “좋음/나쁨”에 대한 여러가지 합리적인 의견들을 가지고 있을 것이다. 하지만, 자연 언어가 그런 것과 마찬가지로, 프로그래밍 언어는 문법만으로 이루어져있지 않다. 예를 들어, 한국어는 한국어 문법만으로 이루어져있지 않다. 한국어로 밥먹었냐고 물어보는 방법, 한국어로 문학 작품을 쓰는 방법, 그리고 한국어를 사용하는 언중들의 사상, 종교, 문화 등 언어 외적인 것이 그 언어와 밀접한 관련을 가지고 있다. 프로그래밍 언어도 마찬가지다. 프로그래밍 언어를 사용하는 여러가지 idiom들, 컴파일러/인터프리터의 구현, 표준 라이브러리, 사용자 라이브러리의 보편화 정도, 언어를 위한 툴 (IDE), 언어가 사용되는 프로젝트에 따라, 프로그래밍 언어를 평가하는 기준은 달라질 수 밖에 없다.

그런데, 실제로 어느 게시판에 들어가서 이러한 논쟁을 구경해보면, 특별히 이러한 기준들을 설정해놓고 논의를 하는 것은 보기 힘들다. 어떤 사람들은 특정 언어 구현에 의한 프로그램 성능을 따지고 있고, 어떤 사람들은 새로운 기능이 추가되었음을 강조한다.

이러한 사실보다 더욱 괴로운 것은, 두가지 언어를 비교하는 논쟁에서, 실제로 (자신이 공격하는) 다른 언어나 다른 환경을 경험하지 못한 사람들이 대부분이라는 것이다. 만약, 두 언어를 어느 정도 경험해보았다고 하더라도, 언어 외적인 여러가지 기준들에 대해서 그 사람이 올바른 평가를 내릴 수 있는지도 의문이다. 서로 부족한 정보를 가지고 누가 ‘옳은가’를 따지는 것은 매우 소모적이고 쓸데없는 일이 되기 쉽다.

옮고 그름의 문제? 선택의 문제!

보통 프로그래밍 언어 전쟁의 대상이 되는 범용 (General-purpose) 프로그래밍 언어들은, 프로그래머가 무슨 일을 하고자 했든간에, 대부분의 일을 할 수 있다. static typing이든, dynamic typing이든, garbage collection을 채용하든 안하든 프로그램이 무슨 일을 하는가에는 상관이 없다. procedural programming language인 C로도 OOP의 polymorphism을 구현할 수 있다.

다만, 프로그래머가 생각하는 방식과 언어가 얼마나 호환되는가, 프로그래머가 원하는 성능을 낼 수 있는가, 프로그래머가 이미 존재하는 라이브러리를 재사용할 수 있는가, 프로그램을 얼마나 여러가지 시스템에서 동작시킬 수 있는가, 우리 팀에 그 언어를 사용할 수 있는 사람이 얼마나 되는가 등이 다를 뿐이다.

예를 들어, 웹브라우저를 만든다고 해보자. C, C++, Java, Python, Haskell, PHP 어떤 언어를 사용하든 웹브라우저를 만들 수 있다. 하지만 각 언어들은 서로 다른 철학을 가지고 있기 때문에, structured programming에 익숙한 사람이 Haskell을 사용해서 개발하거나, functional programming에 익숙한 사람이 Java를 사용해서 개발하는데에는 많은 시간이 걸릴 것이다. 반면에, PHP의 설계자는 웹 어플리케이션을 만들기 위한 언어를 설계했기 때문에, 웹브라우저에는 매우 부적합할 수 있다. 만약, 웹브라우저의 성능이 중요하다면, 어떤 언어의 선택은 매우 나쁠 수도 있다. 또한, 어떤 언어에는 쓸만한 GUI 라이브러리가 없다면, 웹브라우저의 개발에 난항을 겪을지도 모른다.

프로젝트 초기에 프로그래밍 언어를 채택할 임무를 맡은 사람은 바로 이러한 점들을 고려해서 프로그래밍 언어를 선택해야하는 것이다.

무슨 프로그래밍 언어를 선택할 것인가?

David West의 책, ‘Object Thinking’에서는 무슨 프로그래밍 언어를 선택할 것인가에 대한 기준에 대해서 얘기하고 있다.

잘못된 기준

• Loyalty: 우린 마이크로소프트 가게니까, Visual Basic을 사용한다.

• Bandwagon: 모두가 자바를 사용한다.

• Economics: 자바 프로그래머는 10명에 100원이고, 완전히 대체가능하다. 한명을 잃더라도, 쉽게 대체할 사람을 찾을 수 있다.

• Culture: 실시간/임베디드 어플리케이션에서는 C++ 말고는 쓸 수 없다.

• Resume: 모든 회사 취업 광고에는 C# 경력을 물어본다. 뭔가 눈길을 끄는 게 필요하다.

• Inertia: 난 첫번째 프로그램을 COBOL로 작성했고, COBOL이 가장 친숙하다. 따라서, 이 프로젝트에는 COBOL이 적합하다. COBOL을 사용하는 것은 프로젝트를 관리하는 데 편리하다.

올바른 기준

• 실리적 기준: 성숙된 라이브러리, 외부 시스템과의 호환성, 가용한 노동력, 경제적인 이유.

• 성능

• 철학: 언어 디자이너의 의도, 가치, 생각.

Conclusion

위와 같은 기준에 따르면, 약간의 syntatic sugar 라든가 ‘pure XXX language’는 실질적으로 중요한 선택 기준이 되기는 힘들다. 물론 대부분의 선택 기준이 동등하다면, 프로그래밍 언어 전쟁에 참여해서 언어들의 서열을 매기는 것에 관심있는 사람들에게는 쓸모있는 기준이 될 수는 있다. 하지만, 대개는 그렇지 않다는 것이 문제다.

많은 사람들이 프로그래밍 언어의 ‘좋음/나쁨’에 관심이 있지만, 대부분은 ‘잘못된 기준’에 따라 프로그래밍 언어를 선택한다. 왜 CS101에서는 이런 것을 가르쳐주지 않은 것일까?