Perl Language

펄은 래리 월(Larry Wall)에 의해 개발되기 시작한 언어로, 인터프리터식, 객체지향적, 플랫폼 독립적이며 동적인 대화형 스크립트 언어이다. (컴퓨터) 언어학적인 계보를 살펴보자면, sed, awk 등의 유닉스 환경의 잡다한 처리를 위한 스크립트 언어들의 기능적인 면들과, 언어적 구조로서 Modula와 Lisp의 특징을 모으고, 이에 C/C++ 나 Pascal 등에서 추릴 수 있는 형태적 장점만(수없이 많은 단점을 빼버리고) 등에서 좋은 특질을 모아서 그야말로 최대한의 가능성을 열어둔 것이 -- 이 부분 역시 필자의 주관적 견해임을 밝힌다 -- 펄이다. 펄의 표어는 "There is more than one way to do it." 으로, 소위 미니멀리즘 언어 (하나의 일을 하는 표현, 하나의 의미의 표현은 하나 뿐이라는)에 대항하는 맥시멀리즘 정신으로 무장하고 있다. 이 태생의 역할은 래리 월의 기지 넘치고 발랄한 세가지 미덕, "게으름", "조급함", "자만"으로 이어져 있다. 게으름-부지런함, 조급함-인내, 자만-겸손. 펄 프로그래머라면 이 각각이 추상화와 일반화의 문제에 있어 얼마나 유용한 관점인지 이해할 수 있으리라. 펄의 이러한 특징은 또한 오직 펄이기 때문에 가능했던 하나의 '문화',아케이브 문화, CPAN(http://www.cpan.org) 을 만들어 내었다. CPAN은 말 그대로 bazaar다.
현대의 유닉스, 리눅스 문화에서 PerlLanguage의 부재는 상상하기도 힘들다. 시험삼아, 펄 모듈을 deselect 해보라. 데비안 포테이토판에서는 60%의 패키지가 날아가버렸다. PerlLanguage 없이는 리눅스도 없다. 물론 다른 언어도 그럴수 있다. 아니, 그럴 가능성은 있다. 그러나 현실로, 오직 PerlLanguage이 유일한 도구 언어이다. 또한 실지로 가장 많이 쓰이고 있는 '풀' 언어이고, 또 커스터마이징 언어이다. 그렇지 않은가? 그렇다고 해서 쓰임이 유닉스용 도구에 한정된 것은 절대 아니며, 각종 웹 검색 사이트 운용(Yahoo, Altavista, ...) 및 생물정보학(bioinformatics), 웹 서버 등 넓은 분야에서 제 몫을 단단히 해내고 있다. 최소한 파이썬 보다는 훨씬 더 널리 쓰이고 있다. 개발자 래리 월은 GNU에서 준 최초의 자유소프트웨어 상을, 이 PerlLanguage로 수상했다. 이 외에 펄 자체에 대한 구체적인 설명은 ... 마소 몇 월호를 보라고 읽고 싶지만, 불행히도 국내에서는 펄에 대한 인식이 의외로 미비하다. 펄 철학에 대한 가장 편리한 입문은, 오라일리에서 나온 책, '오픈소스'의 래리 월의 아티클 근면인내그리고겸손을 읽으라. 펄의 사고는 그러하다.

흠. 좀더 실질적인 것을 원하는 분들을 위한 간단한 예로, 고전적 예제인 단어 개수 세기 프로그램을 펄로 작성한 것이 <리스트 1>이다. 주석이 필요없을 정도로 간단하고 직관적이지 않은가.

<리스트 1> 단어 개수 세기

open INPUT, $ARGV[0];
while($line = <INPUT>)
{
   @words = split /\s/, $line;
   foreach $word (@words)
   {
       $wordfreq{$word} ++;
   }
}
print %wordfreq;

조금 더 익숙한 펄 프로그래머라면, 어째서 저렇게 긴 코드를 쓰는지 의아해 할 것이다. 짧고, 그리고 더 가독성 높은 코드는 리스트 2 이다.

<리스트 2> 단어 개수 세기

open INPUT, $ARGV[0];
push @words, split /\s/ while (<INPUT>);
$wordfreq{$_}++ foreach @words;
print %wordfreq;

while문은 자연어인 '영어의 while' 로 읽으라. 아래처럼:

push on @words (what is remain after) split whitespace, while (there is) <INPUT>.
(입력<input>이 있는동안(while) 화이트스페이스로 잘라서(split /\s/) @words 어레이에 넣기(push))

add(++) wordfreq of it($_), foreach @words.
(각 단어별로(foreach @words), 빈도를 더하라. ($wordfreq{$_}++) )

영어 문장과 상당히 흡사해진다는 것을 주지할것. 이런 면에 대해서는, 이 소개글 마지막을 조금 더 보라. 펄에서는 늘 이렇게 인간의 언어에 다가가도록 하는 것이 좋은 코딩 스타일이다.

도대체 무엇 때문에 이토록 펄이 이름을 날리고 개발자 커뮤니티의 날개로 펄펄 날아다니고 있는 것일까? 여러 가지 요인이 있겠지만 가장 대표적인 것을 든다면 역시 "빠른 개발 속도"가 아닐까 한다.

어찌된 일인지 국내에서는 스크립트 언어는 저열한 것이고, 자바나 C++류가 어디서나 최고의 만병통치약이라고 생각하는 사람이 많은 것 같다. 한 두 가지에 우루루 몰리는 집단 문화의 강세 때문인지도 모르겠다. (최근에는 스크립트 언어에도 눈길이 쏠리고 있는데, 우루루 몰리는 집단 문화의 강세 덕분에, 특정 언어에만 몰리는 경향이 있다. 이해 할 수 없는 그 강세, 어디 안 가는지.)

스크립트 언어와 C++의 개발 속도에 대한 비교로 Tcl을 개발한 아우스터하우트(Ousterhout)의 IEEE 논문이 유명한데, DB 애플리케이션 개발에 C++은 이개월, DB 라이브러리 개발에 역시 C++은 삼개월이 소요되었는데, 스크립트 언어로는 각각 하루와 일주일만 걸렸다. 코드 길이를 봐도 3000라인과 300라인의 대략 10배 비율은 극단적인 예가 아니다.

펄에 대한 직접적인 비교는 루츠 프렉헬트(Lutz Prechelt)의 보고서가 통계적으로 비교적 엄밀히 수행된 것인데, 자바, C++, C로 대변되는 비스크립트 언어와 Perl, Python, Rex, Tcl의 스크립트 언어에 대해, 해당 언어 전문가 수십명으로 실험집단을 만들고 동일한 과제(검색 및 스트링 처리)를 주어 여러 가지 측정 결과를 비교했다. 펄과 비스크립트 언어에 대해서만 이야기 한다면, 펄은 C, C++, Java에 비해 평균적으로 삼분의 일 이하의 개발 시간과, 코드의 라인 수도 C, C++, Java에 비해 대략 삼분의 일이고, Java의 절반 정도의 메모리 소모에, 전체 수행 속도는 C나 C++보다는 느리지만 Java보다 약간 빠른 정도를 보여줬다. (주목할 만한 사실은 스크립트 언어 중에서도 펄이 높은 성능을 보여줬다는 점이다) (-리스트2 소개 이후로 여기까지 비교 문단에서는 그저 s/파이썬/펄/ 하였음. 당연히 모두가 사실임.)

여기서 주지할 점은 바로 펄의 높은 생산성이다. 같은 시간 동안에 더 많은 코드를 만들 수 있으면서 동시에 전체 코드 길이는 짧다는 점은 펄의 대표적인 매력 중 하나이다. 펄 유저 그룹에서, C나 C++로 2주일 걸린 작업을 하루에 했다, 허무하다는 등의 이야기는 너무 흔해서 더 이상 뉴스거리조차 되지 못한다... 라는 이야기는 펄 소사이어티에서는 이미 10년 전의 이야기다. 10년전에 래리 월이 한 말; "물론 C가 언제나 더 빠르게 돌아가지요. 하지만 perl은 언제나 더 빠르게 짤 수 있답니다." 그리고 그시기에 이미 BlackPerl 같은 미학적인 시를 쓰기 시작했다. 무의미 시라는 단점이 있지만.

하지만 펄 역시 하나의 도구일 뿐이고, 만병통치약은 되지 못한다. 펄은 자신이 잘 쓰일 수 있는 곳이 있고, C++나 자바 역시 그것들이 효율적일 수 있는 부분이 있다. 현명한 판단은 어느 상황에 어떤 도구를 선택하여 사용하느냐는 것이다.

펄의 다른 스크립트 언어와 비교해서 얻을 수 있는 가장 큰 장점은...

펄의 가장 큰 특징은, 그 자유로움이다. 그 자유로움이 가져다 준 개발자 문화 CPAN은, 성당과 시장 모델을 예로든다면, 지금까지 알려진 단일 언어에 대한 커뮤니티 중에서는 elisp 아케이브와 함께 가장 거대한 '바자'이다.

펄은 '스타일이 있는', '철학이 담긴', 언어의 특징을 가장 많이 지니고 있다. 파이썬의 학습 속도 이야기들을 종종 듣지만, 펄의 경우에는 디자인 자체 부터 자연언어에 유사하게 접근한다는 것을 크게 염두에 두고 있었다.

   kiss $me until die;  # 영어 그대로, 죽을때까지 키스해 주어요. 
   free $me or death $me; # 자유가 아니면 죽음을!

또, 대상이 나라는 것이 확실하면 (내 애인은 나 아닌 것에 키스하지 않겠지. )

라고만 하면 된다. 그러면 대명사가 처리해준다. 생략된 $me. 우리도 말 할때 그렇게 하지 않는가? 모든 이름을 다 읽지 않고, 그것, 저것이라고 하지 않는가?

위와 같은 표현이 억지스럽게 말 맞춘 것으로 보이는가? 아니다. 불행히도 내 코드 속에서 실지로 돌아가는 동사와 명사들이다. 가장 자연스럽고 또 명명법에서 권장되는 방법이다. 동사(함수)와 명사(자료구조)를 위와 같은 식으로 배치하는 것은 펄 언어를 쓸때 가장 표준 적인 것이다. 그저 읽히게 하라. 그저 읽으라.

펄은 늘 다양한 표현을 존중하다. 이를 테면 switch문 (은 펄에 없다) 역할을 하는 코드를 작성하는데에는 펄 교과서에 실릴 예제만으로도 5가지가 된다.

펄은 당신에게 다음 처럼 말한다. 언제나 선택을 하면, 한가지 이점과 다른 한가지 댓가를 치르기 마련이다. 그 모든 선택을 당신이 하라. 여기 모든 방법들이 있다. 필요한 것을 골라써라. 당신의 자유다. 필요없으면? 치워버려라, 혹은 잊어버려라. 아무 상관없다.

펄의 단점으로, 펄을 접하지 않은 이들이 주로 논하는, 가독성 문제는, 전적으로 오해다.

펄은 가장 가독성이 높은 코드 중 하나다. 이 점에 대해서는 숱한 논쟁들이 있었는데 (.. 에디팅 요, 링크 걸기.) 래리 월 자신의 표현을 빌리자면 펄은 '다른 것을 같게 보이게' 하려고 하지는 않는다. 명사와 동사는 '다르다'. 단수 명사는 $가 붙어 $rose 이고, 이들 장미 다발은 @rose 이다. 첫번째 장미는 $rose1이고, 장미다발을 감싸는 것은 pack @rose 이다. 장미들 하나 하나를 헤아리는 것은 count foreach @rose 이고, 장미의 숫자는 그저 = @rose 이다.

C와 같은 언어에서, 동사와 명사, 그리고 기타의 것들이 (함수와 변수, 선언과 매크로 등) 전혀 구분되지 않는다. 왜 그런 정글로 빠져들어야 하나? 우리들의 언어에도 어미나 조사가 구분되어 명사와 동사를 구분하는데, 왜 그런 정글을 자초해야 하나?

좋다, 자 이 글을 쓰게 된 것은 오로지 순전히 파이썬에 대해서만 휘황찬란하게 적어 놓은 글과, 펄에 대해서만 우민의 눈물로 적어 놓은 것이 너무나 어이없어서이다. (어이 없어서 이런 페이지라도 생겼으니 다행입니다. 비록 다른 페이지의 패러디이지만...)

물론, 결론적으로 펄이 파이썬보다 우월한 언어이다. 그렇지 않은가?

결코, 그렇지 않다. 거기에는 하나 이상의 길이 있기 때문이다. (There is ALWAYS more than one way to do it.) 파이썬이 더 좋을 수도 있고, (어떤 조건, 어떤 환경, -- 구체적인 디테일은 당신이 채워 넣으시오), 펄이 더 좋은 때도 있다. 어느것이 더 빠를 수도 있고, 더 느릴 수도 있다. 어느것이 개발 속력이 더 빠를때도 있고, 가독성이 더/덜 좋을때도 있다. 여하간에, 하나 이상의 경우들이 있다. 그렇지 않은가?

펄의 표어, "하나 이상의 길이 있다." 이에 대한 귀도의 답(so 파이썬)은 다음과 같았다. "그래도 명백한 길이 하나는 있다.(있지 않겠느냐) " 라고.

...과연 그럴까?

--nayas

PerlLanguage의 가장 큰 장점은, 엄청나게 많은 숫자의 개발자와 오래된 역사를 통해서 수많은 프로그램 코드가 존재한다는 점이라고 생각합니다. 그 외의 장점은 잘 와닿지 않더군요. --위시

개인적으로 PythonLanguage을 좋아하는 사람이 PerlLanguage을 폄하하려는 것을 보고 좀 씁쓸합니다. 나름대로 장단점이 있을텐데요. 개인적인 느낌으로 PythonLanguage은 좀 베이직같은 느낌이 들더군요. - 베이직이 어때서요? - 교육용언어같은 느낌(남에게 공개적으로 말은 안하지만, 그냥 제 사견입니다.) 속도의 경우 논쟁은 많지만 저는 펄이 좀 빠르다고 알고 있습니다. 혹시 정확한 속도차를 아시는 분? --자하
"정확한 속도차"라는 말이 웃긴 겁니다. "어떤 일을 하고, 어떤 상황에서, 또 각 언어의 평균적 프로그래머들이 비슷한 시간을 투자해서 만든 프로그램이 어떤 속도차를 보이는가" 식으로 조건이 줄줄이 붙어야 합니다. 이런 보고서는 잘 찾아보면 인터넷에 널려있습니다. 가능하면 개인이 혼자 해본 것 혹은, 사견을 읊은 것 말고, 학술지에 난 걸 보세요. --김창준

자연언어에 유사하게 접근한다는 것을 크게 염두에 두고 있었다.
Perl 에 대한 인식이 "CGI 를 처음 배울때 사용해 보는 스크립트 언어" 에서 크게 벗어나지 않는 분위기가 일반적인데, (왜 그런지 잘 모르겠음. 역사적인 이유나 영어와 비슷한 Perl 에서 한글사용자들이 느끼는 괴리감이 있는 것이 아닌가 짐작해 봅니다만) 저는 Perl 굉장히 좋아합니다. 회사에서 Perl 로만 코딩합니다. Perl 은 무엇보다 적당히 느슨해서 아주 편안하거든요. -- JikhanJung

근데 굳이 자연언어 비슷하게 컴퓨터 언어를 만들어야 할 이유가 있을까요? 자연언어는 매우 모호한 체계인데, 차라리 명확한 인공언어 체계를 새롭게 만드는 것이 나을 거라고 생각합니다.

Perl의 경우, 자연언어와 비슷하게 만들려고 한다기 보다는, 중요 구문과 아닌 것의 순서를 바꿈으로써 코드를 읽을 때 더 쉽고 명확히 읽히도록 배려하는 것입니다.

sub do_something
{
  my $data = shift || 0;
  # 첫번째 argument를 $data에 넣는다. 그 값이 없으면 0을 넣는다.

  $data = "default value" unless $data;
  # $data에 값이 없으면, 기본값을 넣는다.

  open(FILE, "data.txt") or return;
  # data.txt 파일을 열지 못하면, 곧바로 return하라.

  $hash{something} = $data if not exists $hash{something};
  # %hash에 something이라는 이름의 데이터가 존재하지 않으면, $data를 넣어라.
}

위와 같은 코드를 보면, 다른 언어에서 에러처리를 위해 if, else를 복잡하게 써야 하는 것에 비해 아주 간결하게 에러처리를 할 수 있고, 주요 구문의 흐름이 전면에 나타남으로써 코드를 읽기가 더 쉬워집니다. 자연어에서도 이와 유사하게 강조하고자 하는 구문을 연결문장의 앞으로 빼는 일이 많지요.

• 이것은 자연어로 치자면 복문을 남용하는 것에 해당한다고 생각합니다. 복문은 쓰기 편한 방법이나 읽기에는 좋지 않습니다. (교정볼 때 하는 일 중 하나가 과도한 복문을 자르는 일입니다.) --DaNew
  

유닉스 쪽에서 Perl이 많이 쓰인다고 들어서 C다음으로 관심을 가졌던 언어는 Perl이었습니다. 그런데 CGI를 만들려고 해보니 PHP가 나오고 스크립트로 써볼려니 Python이 나오더군요. 그 두가지 언어에 빠진후부터는 Perl에 손이 안가게 되었습니다. 그래도 정규식이라는 개념을 처음으로 접하게 해주었고 어렵지만 도움이 되었다는 사실은 인정합니다. --씨엔

DaNew는 하나 이상의 길이 있다와 가독성이 뛰어나다는 배치되는 면이 있다고 생각한다. 자신이 짠 소스를 타인이 손봤더니 생소하게 변했거나 아주 짜증나게(!) 변해버린 경험이 있는 사람이라면, 펄의 모로 가도 서울에 가면 된다는 철학이 꼭 긍정적이지만은 않다는 점에 동의할 것이다. DaNew는 펄의 가독성이 무조건 나쁘다고는 생각치 않는다. 다만, 펄은 타인이 짠 소스의 가독성이 나쁜 것이다. 회사에서 잘리지 않으려면 펄을 하라는 농담은 그런 데서 비롯된 것이 아닐까.

복문을 남용하는 것과, 복문을 적절하게 사용하는 것은 다릅니다. if(false == Call1()) { Error("Call1"); } if(false == Call2()) { Error("Call2"); } 와 같은 패턴은 일반적으로 많이 사용되며, 오류처리 부분이 주렁주렁 매달려 있어 프로그램의 흐름을 읽어가는 데에 방해가 될 수 있습니다. 위의 Perl 소스 예시는 문장 강조의 다양한 방법을 나타내기 위해 의미 보다는 다양한 문장 구조(as A as B와 not only A but also B (적절한 예시인지 잘 모르겠습니다만)만을 목적으로 나열한은 형국이라 혼란스러워 보이지만 주요 구문의 흐름을 강조할 수 있다는 것 자체가 단점이라고 보지는 않습니다. 오히려 관점을 바꿔서 다양한 방법으로 풀어낼 수 있다면 좀 과장해서 CelebrationOfDifferences에 대한 발견에 감사할 수도 있겠지요.

타인이 손봐서 생소하게 변한 것에 짜증을 느낀다는 것은 비단 Perl에만 해당되는 것은 아닐 것이며, 다른 언어의 코드도 힘들게 공들여서 작성한 중요한 코드를 초심자가 바꾸었을 때 무엇을 얻기 위해 그랬는지도 알 수 없다면(일종의 Break the rules) 마찬가지로 짜증이 날 수 있겠지요. 물론 반대로 어디선가 Guru가 나타나 책을 베개삼아 자고 있을 때 내 코드를 스치고 갔을 때 의도가 더 명확해 진다면(BreakTheRulesWhenItCompensates) 감동을 느낄 수도 있겠지요. 얼마든지 타인이 짠 소스코드도 가독성이 좋을 수 있습니다. 이 문제는 코딩 컨벤션의 문제, 프로그래밍 스타일의 상성 문제라고 생각됩니다.

물론 코딩 스타일을 코드의 제약으로 걸어놓은 여타 언어들의 발상도 훌륭합니다만, 이것은 Perl과 비교해 보았을 때 다른 문제이지 틀린 문제가 아니라고 생각합니다.
-- Aha00a 2009-01-09 13:04:18

컴퓨터분류