IT/모바일
가장 인기 없고, 가장 쓰기 두려운 프로그래밍 언어는 무엇인가? 왜 두려워하게 된 것인가? 그렇다면 공정하게 평가된 것인가?
StackOverflow의 2020년 개발자 설문 조사에는 "가장 사랑받는 언어, 가장 두려워하는 언어, 가장 필요로 하는 언어"를 보여주는 표가 포함되어 있다. 사랑받고 필요로 하는 언어는 솔직히 이제 지겹다. 우리 모두가 쓰기 두려운 프로그래밍 언어가 훨씬 더 흥미롭다. 톨스토이가 말했듯이, "행복한 가정은 모두 엇비슷하고, 불행한 가정은 불행한 이유가 제각기 다르다".
그럼 이런 불행하고 사랑받지 못하는 언어는 무엇이며, 프로그래머들이 왜 그 언어를 두려워하는 것일까? 이론 같은걸 들먹이거나 심지어는 바보 같은 말을 하기(아니면 잘못된 이유로 비난받는 언어를 변호해주기) 안달났다고 했을 때 말이다.
좀 더 정확히 말하자면 StackOverflow는 <해당 언어 또는 기술로 개발하고 있지만 계속 하고 싶지는 않다>에 해당되는 개발자의 비율”을 “두려워함”의 그래프로 나타냈다. 그 설명글은 딱히 “두려워함”만큼 끔찍해보이진 않는다. <앞으로 해당 언어로 다시 일하는 것에 관심이 없다>정도 되야 그나마 조금씩 “두려워함”에 가까워지는 것 같다. 셸 스크립트(shell script)를 나타나게 troff macro(트로프 매크로)를 작성하는 것을 포함해 이미 한 것 중 다시는 안할 것들이 엄청 많다.
가장 인기 없는 언어 목록은 Redmonk, Tiobe와 O’Reilly Learning 검색에서도 볼 수 있는 가장 널리 사용되는 언어 목록과 비슷하다. 놀랄 일도 아니다. Bjarne Stroustrup은 “이세상 프로그래밍 언어는 딱 두 가지로 정리된다. 모든 이들의 불만을 명불케하는 언어, 그리고 아무도 안쓰는 언어”라고 정리한다. 납득가는 말이다. 설문 조사와 연관지어봐도 말이다. 수백만 유저가 있는 속에서 그 유저들이 불평하기 시작하게 만드는 건 일도 아니다. 따라서 영원히 장수하는 C와 그의 새로온 친척인 Java가 싫은 언어 목록에 있는 것은 놀라운 일도 아니다.
Kevlin Henney와 필자는 가장 싫어하는 언어 목록에 단기 프로그램과 달리 대형 또는 장기간 프로젝트를 진행하는 프로그래머들의 의견들도 반영돼 있다고 생각한다. 언어 혐오는 “연대 책임”일 수도있다. 최소한의 문서로 크고 진부한 코드베이스와 고정된 모든 버그가 하나씩 무너뜨리는 건축 스타일에 대해 싫어하는 걸 봐라. 그러므로 널리 사용되었지만 인기도에서는 찬밥신세인 언어들은 놀라운 일도 아니다. 또한 한 프로젝트에서는 완벽한 파트너였지만 영원히 다시는 쳐다도 안볼, 그 독특한 언어의 매력에 매료되기 쉽상이다. (필자의 경우 Icon이었다. 한 번 해보면 좋아할 것이다. 참고로 아무도 안 쓴다.)
가장 놀라운 것은 언어가 적절하지 않을 때, 바로 당신들의 예상보다 훨씬 더, 혹은 덜 미움 받는 경우다. 바로 여기에 대해 생각해보고 싶다. 그럼 예선전은 건너뛴 채로 몇 가지 관찰해보자.
-
Java(자바): 자바는 이 세상에 나올때부터 사람들이 싫어하는 걸 즐겼다. James Gosling이 자바(1.0 한참 전)에 대해 처음 발표했던 USENIX 세션에서(아직 출시도 안했던 터라 아무도 사용해본 적이 없었다) 끝나고 나가는 길에서부터 사람들은 벌써 자바가 얼마나 끔찍한 지에 대해 웅성였다. 자바는 이 설문 조사에 나름 9위를 기록했으며 자바의 명성을 비추어 볼 때 감사해야한다.
이 목록 중 초대형 프로젝트와 관련된 언어가 하나 있다면 바로 자바다. 싫어할 만한 요소가 상당히 많다. 물론 대부분 언어 자체에서보다는 자바를 하면서 생긴 나쁜 습관과 관계가 있지만 말이다. 디자인 패턴을 남용하는 것 같다면 잠시 물러나서 뭔 짓을 한 건지 봐라. 모든 것을 디자인 패턴으로 만들어내는 것은 그 패턴이 무엇을 위한 것인지 제대로 이해 못한 것이다(쉬어가는 시간이 필요하다면 <Head First Design Patterns> 또는 <Gang of Four book>을 참고하라). 만약 FactoryFactoryFactory 라고 쓰기 시작하고 있다면 당장 멈추고 산책이나 다녀와라. 만약 ‘ClassWithAReallyLongNameBecauseThatsHowWeDoIt’을 써내려간다면 그럴 필요 없다. 자바는 그렇게 만들지 않는다. 서술적인 이름은 괜찮다. 터무니없이 긴 이름들(터무니없이 깊은 패키지 계층과 함께)은 안 괜찮다. 필자는 항상 코드 각 줄마다 하나의 일관된 생각을 넣으려고 노력했다. 이름이 한 줄의 반이면 그렇게 못한다. 그러나 그것은 자바의 잘못이 아니라 자바 프로그래머들의 이상한 문화적 특성이다.
자바는 장황해보여도 문제가 되는 것은 아니다. 자바 팬이 아닌 한 사람은 클래스(class) 시작 시의 모든 선언(declarations)은 실제로 문서화(documentation)되어 있고, 그 문서화는 대형 프로젝트에 특히 중요하다고 했다. 데이터 구조가 무엇인지 알게 되면, 클래스가 무엇을 하는지 대충 감이 올 것이다. 자바는 대부분의 다른 언어들보다 훨씬 더 읽고 이해하는데 쉽다. 어느정도는 명시적으로 명쾌하기 때문이다. 그리고 경력 프로그래머들도 직접 쓸 때보다 다른 이들의 코드를 읽을 때 더 시간이 오래 걸린다는 걸 알 것이다.
-
루비(Ruby): 루비가 이 목록에 7등에 있다는 것은 놀라운 사실이 아닐 수가 없다. 루비가 자바보다 더 싫다니 말이 되는가? 루비를 프로그래밍하면서 재미를 느꼈던 적이 있는데 대부분 “내가 말한대로(what I said) 하지말고 내가 의도한 대로(what I meant) 해라”의 언어였다. 결국 15년 전 이 약속은 많은 프로그래머들을 사랑에 빠지게 만들었다.
하지만 루비를 대형 시스템의 맥락에서 생각해보면 말이 된다. 적어도 무심코 보는 사람에게는 애매한 코드를 쓰기 어렵지 않다. 어떤 비표준적인 행동을 위해 “몽키패치”된(monkeypatched) 함수(function)나 메소드(method)를 어기며 실행하기 매우 쉬우며 그런 변경사항들은 거의 문서화되지 않는다. 메타프로그래밍(Metaprogramming)은 레일즈(Rails)와 같은 프레임워크에서 훌륭하게 사용되어왔지만 항상 루비 라이브러리의 “그리고 이제 마법이 일어났다”는 면이 늘 신경쓰여온다. 이것들은 대형 프로젝트에 도움되는 특징들이 아니다.
수년 전 루비 온 레일즈(Ruby on Rails) 컨퍼런스에서 어떤 한 사람은 이렇게 말했다. “대형 프로젝트는 이제 없습니다. 루비에서는 90% 적은 줄의 코드면 모든 게 됩니다.” 코드의 줄 수로 프로젝트의 크기를 가늠하는 것은 바보같은 짓이라고 항상 생각해왔다. 만약 루비에선 코드 줄 수가 90%나 적다는 걸 믿는다고 해도 나머지 10%만 해도 큰 숫자다. 특히 아무도 모를 때 생기는 일들을 포함해서 그 코드를 소화해내는 것이 프로그래머인 당신의 몫이라면 말이다. 루비는 꽤 재밌다. 그래서 신속한 스크립트(scripts)를 위해 종종 사용하긴 한다(파이썬으로 갈아탔지만 말이다). 하지만 대형 프로젝트에 이 언어를 선택한다면? 아마 모두를 두려움에 떨게 할 것이다.
-
R: R은 “두려운 목록” 중 10등에 속한다. 아무래도 착각이지 싶다. R은 범용 프로그래밍 언어 이기도 하고 아니기도 하다. 몇몇 통계학자들은 “프로그래머들은 절대 모른다. R은 통계 작업용이지 프로그래밍 언어가 아니다. 이상한 버전의 파이썬(Python)이 아니다.” 라고 말했다. R을 몇 번 가지고 놀면서 Vince Buffalo의 <Bioinformatics Data Skills>에서 R 튜토리얼을 읽어보다가 드디어 위 말을 “이해했다”(적어도 부분적으로는). 루프문(Loops statement)과 if문은 R에선 기본적인 개념이 아니기 때문에, 튜토리얼의 후반부까지 가야 배우게 된다. 왜일까? 왜냐하면 R을 올바르게 사용하고 있다면, 필요없기 때문이다. 사용안해도 되게끔 설계되었다. 만약 당신이 전통적인 컴퓨터 언어를 공부한 사람이라면, 언어와 같이 일하기 보다는 싸우는 모습이 더 익숙할지도 모르겠다. 하지만 조건문(conditional logic)과 반복(iteration)에 대한 더 나은 접근 방식이 있다.
또한 이용 가능한 최고의 툴과 라이브러리를 사용하는데 도움을 준다. R스튜디오(R Studio)는 R에 딱 알맞는 통합 개발 환경이며 타이디버스(Tidyverse)는 데이터 작업을 위한 훌륭한 라이브러리 세트다. 아이러니컬하게도 사실 이는 문제의 한 부분이 될 수도 있다. 뛰어난 그래픽 라이브러리와 웹 프레임워크로 R이 갑자기 전문적인 통계 작업용 보다는 그냥 일반 용도의 공구함 정도로밖에 안보인다. 많은 프로그래머에게 R이 재조명되고 있는 것 같다. 코로나 바이러스 데이터 분석을 하기 위해서일까? R은 Tiobe 지수 20위에서 8위로 뛰어올랐다. 어마어마한 변화다. 이유가 무엇이든 R은 싸우기보다 함께 일한다면 훨씬 더 쾌적한 환경이 될 것이다. 프로그래머보다 통계학자의 의견으로 아주 주관적으로 봤을 땐 말이다.
-
파이썬(Python): 파이썬은 23위다. 널리 사용되고 있는 언어치고는 유별나게 낮은 순위다. 파이썬은 좋아할 수 밖에 없는 언어다. 먼저 지긋지긋한 중괄호“{}”가 생략된다는 것만으로도 가산점이 붙는다. 하지만 그런 것들 빼고 뭐가 좋을까? 항상 “언어를 고르기보다는 라이브러리를 골라라” 라고 말해왔다. 파이썬은 특히 숫자 연산작업에 아주 훌륭한 라이브러리다. Pandas, NumPy, 사이파이(SciPy)와 사이킷런(Scikit-learn)은 파이썬에 푹 빠지기 좋은 또 다른 이유 중 하나일 것이다. 리스트 컴프리헨션(List comprehension)과 같은 기능은 전통적인 제어 구조에 따른 많은 수작업들을 생략해준다. 파이썬은 대형 프로젝트하기에도 좋고, 신속하고 더러운 과제에도 좋다. 스프레드시트(spreadsheet)로 무언가를 하고자 할 때, 거의 항상 파이썬을 이용해 분석한다. 또한 Jupyter와 같은 툴들은 당신의 실험적인 활동들을 과정 속에서 기록하는데 도움을 줄 것이다.
“대형 프로젝트”의 한 편에서는 파이썬은 읽기 쉬운 언어다. 중첩된 중괄호 “{}”나 괄호들로부터 오는 고통도 없고, Comprehension이나 map과 같은 다양한 기능 덕분에 네스팅(nesting) 단계가 더 적다. 아주 합리적인(별나긴하지만) 객체 지향적인 기능을 가지고 있다. 예전 루프(loop)가 있던 스크립트를 다시 열어봤더니 이제는 아예 루프없이 쓸 수 있게 되었다. 한 라인을 일관된 생각으로 쓴다면 그게 바로 다른 가능한 말들 보다 제일 베스트다.
“The Zen of Python”(파이썬의 선禪)의 중요한 슬로건 중 하나는 “명시가 암시보다 좋다(Explicit is better than implicit)”이다. 파이썬에서는 다른 누군가가 무엇을 의미했는지 추측하거나, 이미 만들어진 뜻밖의 예측불가한 코드들을 판독해야될 일은 거의 드물다. 파이썬은 이렇게 프로그래머들에게 반감을 최소화해주며 가장 인기 많은 언어 상을 받을 만하다. 파이썬은 작은 프로젝트에 이상적이면서도 큰 프로젝트에도 좋은, 그런 균형 잡힌 기능들을 가지고 있다.
- 자바스크립트(JavaScript): 자바스크립트에 대해 할 말이 없다. 16등이라니? 잘 모르겠다. 무작위적이고 질서 없는 방식으로 성장한 언어인데 프로그래머들은 Doug Crockford의 고전적인 <JavaScript: The Good Parts>때문에 엄청 강력하고 생산적이라고 느꼈다. 자바스크립트만큼 널리 사용되고, 또 가장 두려운 언어 중 16등밖에 안되는 언어가 어떤 엄청난 곳에서 잘 쓰이고 있는게 확실하다. 그렇다고 개인적으로는 또 좋아할 필요는 없다고 본다.
할 말은 훨씬 더 많다. VBA가 제일 싫은 언어 1등이라는 것은 놀라운 일도 아니다. 여태 안 다뤄본 Objective C에 대한 완전한 무지함은 인정한다. 오래전부터 펄(Perl) 혐오자였지만 그래도 펄이 그렇게 널리 미움을 받고 있었다니 놀랍다(3등). 그래도 상처는 가시지 않는다. Perl 7이 출시된지 몇 년 지난 후에는 무슨 일이 벌어질 지 흥미로워진다. 어셈블리(Assembly)는 어느정도 익숙해져야만 맛있는 맛이다(또한 한 언어로써 습득되어지는 것이 아니다). 이 언어를 사랑할 줄 모른다면 거의 혐오해야한다. 그리고 만약 사랑하지 않는다면 사용하면 안될 정도다. 거의 항상 어셈블리를 피할 순 있지만, 사실상 하드웨어와 직접적으로 작업하려면 대체재가 없다. C(5등)와 C++(8등)은 프로그래머들을 한강에 뛰어들고 싶게 해주지만 어셈블리의 고통 없이 거의 모든 프로젝트를 위한 하드웨어에 충분히 가깝게 해준다. 이 둘은 과거 속으로 사라지고 있는 것일까, 아니면 영원히 함께 있을까? 필자는 후자다. C의 성능과 넓게 보편화되어있음에 C를 요구하는 프로젝트가 너무 많다. 현대 컴퓨팅에서 중요한 모든 것의 기초가 되어있다.
언어들이 왜 좋고 싫은 지에 대해 추측해보는 것은 흥미롭다. 유용할 수도, 아닐 수도 있다. 아무도 모른다.
*****
원문 : The Least Liked Programming Languages
번역 : 김정욱
최신 콘텐츠