자바 7은 클로저를 지원할 듯

Posted by 大山 Sun, 20 Aug 2006 06:14:00 GMT

자바 7에서는 드디어 클로저를 지원하려나 보다. 지금이 자바 5이니, 자바 7이 언제 나오게 될지는 모를 일이지만.

모르는 분들을 위해 살짝 귀뜸하면, 클로저(Closure)는 코드 중에 함수를 직접 정의해서 객체로 변환시킨 걸 이르는 용어이다. 우리말로 하면, 익명 함수 정도가 될까? 흥미로운 건 이걸 다른 메소드에 인자로 넘길 수 있다는 거다. 예를 들면, 다음과 같은 식이다.

>> [1, 2, 3, 4, 5].map(&lambda {|i| i * 3})
=> [3, 6, 9, 12, 15]
 

위에서 lambda { ... } 부분이 클로저인데, 이는 i에 해당하는 수를 넘겨주면 그의 3배수를 리턴하는 익명 함수 객체이다. 위의 코드에서는 이 클로저를 배열의 map 메소드에 인자로 넘겨주고 있다. map 메소드는 배열의 각 원소에 넘겨받은 클로져를 적용해서, 새로운 배열을 만들어 리턴해준다. 이를 보다 루비스럽게 작성하면 다음처럼 되겠다.

>> [1, 2, 3, 4, 5].map {|i| i * 3}
=> [3, 6, 9, 12, 15]
 

루비에서는 클로저란 어려운 이름 대신, 이를 블록이라고 부른다. 다른 예를 하나 들어보자.

>> ["banana", "kiwi", "apple", "water melon"].sort
=> ["apple", "banana", "kiwi", "water melon"]
 

위의 코드에서 sort 메소드는 배열의 원소를 알파벳 순서로 정렬해준다. 그런데 sort에 블록을 붙여주면 정렬 법칙을 바꿀 수 있다. 다음 코드를 한번 보자.

>> ["banana", "kiwi", "water melon", "apple"].sort {|i, j| i.length <=> j.length}
=> ["kiwi", "apple", "banana", "water melon"]
 

위에서는 문자열의 길이를 비교하는 블록을 sort 메소드에 넘기고 있다. 결과적으로 리턴되는 배열도 문자열의 길이대로 정렬되어진다.

자바 5에서는 generic이 추가되더니 7에서는 클로져를 지원하는 등 자바도 갈수록 루비스러워지는 듯. 자바 7을 기다리는 그대 지금 루비로 오라. ;)

Posted in  | Tags , , , ,  | 22 comments | 2 trackbacks

개발자의 전문성 관리

Posted by 大山 Sun, 16 Jul 2006 16:34:00 GMT

언제나 그렇지만 새로운 기술은 끊임없이 쏟아져 나온다. 영업자는 '유닉스'란 단어 하나만 알아도 마치 그 기술을 전부 아는양 말하지만, 개발자는 터미널 앞에서 수천시간을 씨름하고 나서야 비로소 유닉스를 조금 이해하게 된다. 기획자에게 '웹 2.0'의 도입은 새로운 단어를 하나 익히는 것만큼 쉬울지 모른다. 개발자는 웹 표준, Ajax, RSS, 태그, 웹서비스 등 한무리의 새로운 기술을 익혀야 하는데 말이다.

불과 이삼년 전만 하더라도 마이크로소프트는 영원할 것만 같았다. 수많은 개발자들이 비쥬얼 스튜디오를 익히고 마이크로소프트에서 쏟아내는 신기술을 소화해 내느라 정신이 없었다. 그런데 이제는 개발자는 맥을 써야 한다는 말이 공공연하다.

다들 자바가 대세인 줄 알았다. 프로그래밍의 미래라고 모두가 생각했다. 그런데 자바가 세상에 나온지 불과 10여년이 지난 지금 많은 개발자들이 자바의 마지막이 멀지 않음을 체감하고 있다.

어쩔수 없었던 것일까? 그런데 진작부터 자바가 별 볼일 없다는 걸 알고 있던 사람도 있었더라. 마이크로소프트의 이후를 일찍이 준비해온 사람들도 있고 말이다. Paul Graham은 진작에 알았으면 좋았을 것들이라는 글에서 이런 말을 했다.

인생은 엔진이 없는 행글라이더를 타는 것과 같습니다. 가능하면 맞바람을 타서 최대한 하늘 위로 올라가려고 하십시요. 멋있어 보이는 곳이 있으면 뒷바람을 타고 빠르게 그쪽으로 날아가고 싶은 유혹이 생기기도 합니다. 그런데 뒷바람을 타면 순식간에 지면에 너무 가까운 곳으로 내려가 버립니다. 나중에 내가 원하던 곳은 여기가 아니라는 것을 깨달았을 땐 이미 너무 늦어버리죠.

어떤 것이 맞바람을 타는 일일까? Graham은 경제학 대신에 수학을 전공하라고 말한다. 프로그래밍에 비유하면 자바 대신에 Lisp을 공부하는 일이리라. 당장 돈이 되는 것 보다는 미래를 위해 투자해야 한다.

개발자에게 전문성은 황금 알을 낳는 거위와 같다. 알을 빨리 낳게 하려고 무리수를 두면 거위가 일찍 죽어 버린다. 왜 국내의 수많은 개발자가 마흔도 안되어 개발을 포기하겠는가?

10년 뒤를 생각하고 그때도 유용할 지식을 배우는데 시간을 최대한 투자해야 한다. 물론 10년 뒤를 내다보는 것은 쉬운 일이 아니다. 내가 생각하는 10년 뒤 개발자에게 쓸모 없을 지식과 유용할 지식은 다음과 같다.

  • 거의 쓸모 없을 지식: MFC, COM, ActiveX, 자바 관련 모든 것, Perl, SOAP, XML, 윈도우 서버
  • 여전히 유용할 지식: Unix, 정규식, 관계형 데이터베이스, 메타프로그래밍, emacs/vi, HTTP, HTML XHTML/CSS, 루비, C

앞으로 10년 동안에도 수많은 기술이 나오고 또 사라질 것이다. 아무쪼록 개인의 전문성을 잘 관리해서 개발을 오래오래 즐기도록 하자.

Posted in  | Tags , , ,  | 6 comments | 2 trackbacks

다이내믹 프로그래밍 언어와 자바의 위기

Posted by 大山 Sat, 15 Jul 2006 14:48:00 GMT

다이내믹 프로그래밍 언어란 프로그램 실행중(런타임)에 프로그램 코드 자체가 변경될 수 있는 프로그래밍 언어를 말한다. 대표적인 다이내믹 언어에는 Lisp이 있으며 최근에 많이 사용되는 언어에는 루비, 파이썬 정도가 있다.

혹시 Lisp 개발자로부터 Lisp으로는 프로그램을 짜는 프로그램을 작성할 수 있다는 이야기를 들어 보았는지? Lisp의 이런 특징이 바로 언어의 다이내믹함에서 오는 것이다.

관련성은 있지만 이와 구분되는 개념에는 다이내믹 타이핑, 자동 메모리 관리 등이 있다. 꼭 그런 것은 아니지만 다이내믹 프로그래밍 언어는 보통 자동 메모리 관리, 다이내믹 타이핑 등의 기능도 가지고 있는 경우가 많다. 재미있는 점은 이러한 다이내믹함이 프로그래밍 언어에 추가될 때마다 개발자의 개발 생산성은 획기적으로 높아진다는 것이다.

자동 메모리 관리에는 보통 Garbage Collection이나 레퍼런스 카운팅이 쓰이는데, 이 기능이 있고 없고가 바로 자바와 C++의 가장 큰 차이점이라고 볼 수 있다. 메모리를 수동으로 지정하여 사용하고 해제할 경우 프로그램의 속도를 조금 더 빠르게 할 수는 있지만 이로 인해 손해보는 개발 생산성이 너무 크다. 바로 자바가 성공한 이유이다. 앞으로 자동 메모리 관리를 지원하지 않는 새로운 프로그래밍 언어가 성공할 확률은 제로에 가까울 것이다.

다이내믹(Dynamic) 타이핑에는 얽힌 오해가 있다. C 언어의 경우 포인터 타입 에러로 인해 개발자들이 고생을 많이 하곤 했는데, 이 때문에 자바 언어의 설계시에 스태틱(Static) 타이핑이라는 기능이 들어갔다. 당연히 자바 입문서들은 스태틱 타이핑을 예찬하곤 했었다. 문제는 객체지향 프로그래밍이 도입된 이상 스태틱 타이핑은 사실 중요하지 않게 되었다는데 있다. 결국 자바의 스태틱 타이핑은 불필요한 기능에 가까운 것이다. (물론 이러한 사실을 개발자들이 깨닫는 데 10년에 가까운 시간이 걸리긴 했다.) 다이내믹 타이핑을 사용하면 코드 작성이 훨씬 간편해지기 때문에 개발자의 생산성이 상당히 올라간다. 최근들어 루비나 파이썬 등이 인기를 얻고 있는 이유 중의 하나이다.

마지막으로 언어 자체의 다이내믹함인데, 이런 기능을 지원하는 프로그래밍 언어는 보통 eval이라는 함수를 가지고 있다. eval은 문자열로 전달되는 프로그램 코드를 프로그램 내에서 실행시켜주는 함수이다.

처음 접하는 사람에게 쉽게 이해가 가는 개념은 아니니, 심호흡을 한 번 하고 계속 읽으시길. 도대체 왜 프로그램 코드를 문자열로 받아서 실행시키느냐는 의문이 들 것이다. 이런 기능은 어떨까? 프로그램이 자신이 돌아가는 컴퓨터에 연결된 데이터베이스에 접속해서 데이터베이스 내부의 데이타 구조를 들여다본 다음 그런 데이타를 접근할 수 있는 API 함수들을 동적으로(다이내믹하게) 만들어서 개발자가 바로 쓸 수 있게 해준다면?

바로 루비로 만들어진 레일스 프레임워크의 핵심 모듈인 액티브 레코드의 기능이다. 이러한 프로그래밍 기법을 흔히 메타프로그래밍이라고 부르는데 개발자의 생산성을 획기적으로 높여주는 실로 대단한 기능이다.

위에서 설명한 이유로 인해 다이내믹 프로그래밍 언어는 개발자의 생산성을 무지막지하게 높여준다. 자바의 끝이 보이기 시작하는 이유이다.

Posted in  | Tags , , , ,  | no comments | no trackbacks

프로그래밍 언어는 평등하지 않다

Posted by 大山 Fri, 14 Jul 2006 15:29:00 GMT

가끔 모든 프로그래밍 언어는 다 똑같다고 줄기차게 주장하는 사람들이 있다. 이 사람들의 공통점은? 바로 사용할 줄 아는 프로그래밍 언어가 하나 밖에는 없다는 사실이다.

분명히 말하지만 프로그래밍 언어는 절대로 평등하지 않다. 그럼 왜 위와 같은 주장이 나오게 되었을까? '모든 컴퓨터 알고리듬은 어떠한 프로그래밍 언어로도 구현이 가능하다'는 이론을 잘못 이해해서 그렇다. 이 이론은 '모든 아이는 피카소가 될 잠재력이 있다' 정도의 수준에서 이해하는게 옳다. 같은 알고리듬을 구현하는데 1시간이 걸리는 언어와 1달이 걸리는 언어가 있다면 당신은 어떤 언어를 선택하겠는가?

실제로는 수백개의 프로그래밍 언어들이 매우 넓은 스펙트럼에 분포되어 있다. 이 스펙트럼의 한쪽 끝을 차지하고 있는 언어는 바로 어셈블리어다. 어셈블리어는 컴퓨터의 작동 원리를 배우게 된다는 측면에서 공부해볼만한 언어이긴 하다. 하지만 어셈블리어로 웹사이트를 구축하려는 사람은 아마 정신병원에도 없을듯.

스펙트럼의 보다 흥미로운 쪽은 Lisp이 위치하고 있는 반대쪽이다. 여기서 이 스펙트럼의 분포 기준은 무엇일까? Paul Graham은 이를 응축성(succinctness)이라고 설명한다. 복잡한 개념을 얼마나 작은 유닛에 응축시켜 담을 수 있는지가 기준이라는 것이다. 바로 이 응축성 때문에 Lisp으로 한시간이면 작성할 수 있는 프로그램을 어셈블리어로 짜면 1달이 넘게 걸리게 되는 것이다.

프로그래밍 언어는 평등하지 않지만 한 언어가 언제나 다른 언어보다 우월하다는 것은 아니다. 언어의 선택은 필요에 달라지는게 맞다. 보통은 실행속도가 중요할수록 어셈블리어 근처의 언어를 사용하게 되고 개발 생산성이 중요할수록 Lisp 근처의 언어를 사용하게 된다. 하지만 이미 컴퓨터의 성능이 무어의 법칙을 따라 기하급수적으로 발전해 버렸기 때문에 성능 중심의 언어가 점점 메리트를 잃어가고 있는게 사실이다.

주류 언어만 놓고 보면 프로그래밍 언어는 "어셈블리어 => C => C++ => 자바 => ?", 이렇게 발전해 오고 있다. 당연히 ?에는 Lisp과 유사한 언어가 들어갈 것이다. 많은 사람들이 ?가 루비일 것이라고 생각한다. 나도 물론 같은 생각이다.

Posted in  | Tags , , , ,  | 2 comments | 1 trackback

왜 루비를 배워야 하는가

Posted by 大山 Tue, 06 Jun 2006 10:23:00 GMT

개발자가 새로운 언어를 배워야 하는 이유는 크게 두가지이다. 첫째는 새로운 사고의 패러다임을 익히기 위해서이다. 객체지향, 이벤트드라이븐, MVC, 클로져, 메타프로그래밍, 매크로, 컨티뉴에이션, 다이내믹 타이핑 등은 각각 특정 종류의 프로그래밍 언어와 밀접한 관계를 가지고 있는 개념이고, 이 개념들은 하나하나를 익힐 때마다 새로운 깨달음을 선사해 줄 것이다.

두번째는 먹고 사는 문제이다. 아무리 뛰어난 개발자라 하더라도 시장에서 그가 가진 기술에 대한 수요가 없으면 아무 소용이 없다. 이제는 자바, 그 이후를 준비할 때다. 나중에 쫓겨가는 것 보다는 지금 앞서가는게 훨씬 더 마음이 편하다.

루비는 지금까지 만들어진 여러 프로그래밍 언어의 장점들을 매우 이상적인 형태로 결합한 언어이다. Smalltalk의 순수 객체지향성, Perl의 간결한 정규식 신택스, Lisp에서나 볼 수 있던 클로져, 메타프로그래밍, 그리고 다이내믹 타이핑 등. 게다가 루비의 신택스는 정말 군더더기가 없고 직관적이다. 루비에 익숙해지고 나면, 다른 언어의 신택스가 얼마나 생각 없이 만들어 졌는지를 비로소 깨닫게 된다. 루비를 만든 Matz는 프로그래머의 행복에 촛점을 맞춘 언어를 만들려 했다지 않은가.

게다가 레일스의 갑작스런 인기 덕분에 루비는 이미 미국과 유럽에서 메인스트림에 진입하기 시작했다. 자바쪽의 스타 개발자들이 대거 루비진영에 합류한 것만 보아도 이미 판세는 기울기 시작한 것이 아닐까?

Posted in  | Tags , ,  | no comments | no trackbacks