Perl은 과연 죽었는가?
제가 예전에
FOSS계의 서태지+하리수? ( http://kldp.org/node/73898 )
라는 Perl계의 신동 Audrey Tang의 활약상에 대해 올린적이 있습니다.
위의 글처럼 Perl은 미국,일본,유럽등 해외에서는 YAPC( http://www.yapc.org/ )
같은 Perl 컨퍼런스도 활발히 열리고 있고 사용자층도 두텁고 각종 커뮤니티도
활발한 반면 국내에서는 거의 죽었다 혹은 망했다 표현이 어울릴 정도로
암울한 상태라고 볼 수 있습니다.
이렇게 된 이유가 뭘까 나름대로 생각해봤는데 얼마전 Orielly홈페이지에서
읽으면서 수긍이 가는 컬럼하나를 보고 번역을 해봤습니다.
http://advance.sarang.net/~aero/perl/stop_perl3.html
위 컬럼을 보시면 아시겠지만 국내에서는 Perl을 제대로 활용해볼 노력과 수고전에
Perl 대한 잘못된 사용과 몰이해에서 오는..
"펄은 코드가 더럽다(쓰기전용이다)", "scalable하지 못하다" 등등의 검증안된
컬럼,서적들의 오해를 Perl에 대해 비우호적인 타 언어사용자들과 Perl에 대해
깊이 알지 못하는 사람들이 인용하여 더더욱 무조건적으로 확대 재생산해내면서
이런 상황까지 이르렀다고 봅니다.
과연 Perl의 생명이 끝난것일까요?
그렇게 비난받고 없어져야 할 언어일까요?
덧붙여 펄의 창시자 Larry Wall 이 2006년 2월 이스라엘에서 열린
OSDC::Israel에서 발표한 Perl의 현재,미래에 대해 강연한
"Present Continuous, Future Perfect"라는 강연 내용도
핵심 서두 부분을 번역해서 올립니다.
http://advance.sarang.net/~aero/perl/perl_present_future.html
(이 글은 Larry wall의 폭넓은 지식,통찰력,철학을 엿볼 수 있는 좋은 자료라고 생각됩니다.)
제가 올린 문서들의 링크를 따라가며 꼼꼼히 읽어보시면서 Perl에 대해 다시한번
되돌아 볼 수 있는 계기가 되었으면합니다.
좋은 글, 잘
좋은 글, 잘 읽었습니다
----
Forensic Computing On Linux
아직 멀었어
괜히 플레임성이
괜히 플레임성이 될지도 모르겠만.. ^^
http://advance.sarang.net/~aero/perl/perl_present_future.html 중에
글쎄요 전
글쎄요 전 오래전부터 perl 이외의 스크립트 언어에는 흥미를 거의 느낄수가 없군요.
너무 익숙해져서...
국내에는 python과 같은 언어를 적극적으로 보급하려는 사람이 많은 탓도 있고, 해외에서는 아직도 CGI등의
작성에 많이 사용되는 perl이지만 국내에서는 이 대신에 ASP/PHP/JSP가 지나치게 보급된 나머지 숙련된 perl
프로그래머들은 웹 프로그래머가 거의 없고(perl = CGI = 느림 = 큰데 못씀이라는 이상한 인식 때문이지요.
FastCGI 나 mod_perl에 대해서 조금 더 알아보면 좋겠는데...), 남은 것은 대부분 시스템 엔지니어들입니다.
이마저도 python으로 많이 옮겨간 것 같고...
결국 국내에서 perl을 사용할 사용자 층이 거의 없다는 것이지요.
해외와는 거리감이 꽤 있는지라 국내에서는 perl 정보를 얻기가 매우 힘든것도 사실입니다.
있어봐야 10여년 전 정도 perl4 시대의 정보가 대부분이고...
사실상 리소스 부족에 의한 이해 부족이 크다고 봅니다. 주위에 perl 코드 작성하는 사람 봐도
aero님이 번역해주신 글 대로 perl4 코드(제 기준으로 말하면 use strict; 를 서두에 넣지 않은 코드)로
작성하는 사람이 대부분의 perl programmer들이고 CPAN의 넘쳐나는 모듈을 이용할 생각을
잘 안해보는 것 같더군요.
--
익스펙토 페트로눔
--
익스펙토 페트로눔
제 생각도
제 생각도 리소스 부족과 오래된 자료들이 오히려 perl의 사용자들을
과거에 머물게 하고 다양한 용도의 저변의 확대를 막는데 일조 한다고 생각합니다.
국내에 번역된 Oreilly의 대표적 Perl 서적으로는
펄프로그래밍 2nd edition,
펄 제대로 배우기 2nd edition
이 있는데 원서는 Programming Perl(펄프로그래밍)은 3rd edition,
Learning Perl(펄 제대로 배우기)은 4th edition 이 나온상태이지만 번역판은 아직도
오래된 판이 그대로 찍혀 팔리고 있는상태이고.
그리고 위의 두책의 내용을 보면 일반적인 Oreilly책이 표지가 이쁘고
내용이 좋다는 평이 있지만 Programming Perl은 너무 reference적이라
처음접하는 사람이 스스로 길을 찾아 배우려고 하면 질려서 헤매기 쉽고
Learning Perl은 Perl의 각종 기능들을 case by case로 다루는 형식이라
언어자체를 체계적으로 익히기에 적합하지는 않다고 봅니다.
제가 지금까지 본 자료중에 Perl에 입문하려는 사람들에게는 적합한 자료는
Beginning Perl
http://www.perl.org/books/beginning-perl/
이라고 봅니다. 이 자료는 위 싸이트에서 pdf가 무료로 제공되는데
( Apress 에서 책으로 찍어 팔기도 합니다.)
위 문서는 최신 Perl에 관한 내용과 설명이 잘되어있고 코딩 가이드라인을
제시해서 체계적으로 Perl언어에 접근할 수 있게 해주는것 같습니다.
그리고 덧붙여
http://perltraining.com.au/notes.html
에 있는 pdf문서들도 추천합니다.
그 외에도
http://www.perl.org/books/library.html
에 공개된 좋은 서적자료들이 많습니다.
그런데 문제는 영어에 언어적 장벽을 가지는 사람은 접하기 힘들다는 점이 있겠지요 - -
그러고 보니, 정작
그러고 보니, 정작 perl 은 대안언어축제 - 언어들 에서도 언급되지 않고 있군요. ㅜㅜ
CGI == perl 이었다가...
CGI == perl 이었다가 망한(?) 게 아닐까요?
CGI가 유행이었을 때에는 perl이 강세였던 적도 있었죠. 그때는 python 쪽에서 python이 찬밥 신세라는 소리도 나왔던 걸로 기억합니다.
CGI가 구시대의 유물 정도로 취급을 받으면서 perl도 도매금으로 취급받는 게 아닐까 생각합니다. CGI의 구닥다리 이미지가 perl에 씌워진 거죠. 제대로 안쓰면 위에서 말한 perl3와 다를 바 없는 php이지만 CGI보다 신형(?)이라는 이미지로 각광을 받았던 거구요. 사실 많은 php 코드가 "코드가 더럽다", "scalable하지 못하다"이지만 php는 그런 말을 별로 듣지 않고 있죠.
----------
그렇지만 그래도 저는 perl 보다 python이 더 좋습니다. :)
아마도
저도 웹에 대해서는 잘 알지 못하지만 perl도 cgi 단계를 넘어
mod_perl, Mason, HTML::Templete,FastCGI등이 쓰이며 발전을 하다
현재는 Perl의 Ruby on Rails라고 할 수 있는 Catalyst,Jifty등이
등장하여 개발되고 있습니다.
하지만 위 같은것을 쓰려면 Apache모듈을 컴파일해서 추가해야하거나
Apache설정등을 조정해야하는등 손이 좀 가야하는데 php같은것들이야
한번 깔아놓으면 비교적 그러한 수고가 없이 알아서들 쓰지만
호스팅업체에서는 이런 Perl기반 웹개발자들의 요구사항을 받아줄 시스템관리자의
지식결여와 그에 드는 비용때문에 그런 요구를 거의 무시하다시피해서.
개발자들이 본의 아니게 속편하게 쓸 수 있는 php같은 다른 언어로 넘어가게 되지
않았나 생각도 됩니다.
그리고 프레임웍기반의 개발을 하려면 기초부터 쌓아가야하는데 그러한 perl에
대한 체계적인 지식을 갖춘 개발자가 부족한 현실도 한 몫 하겠지요.
반갑네요. 저도
반갑네요. 저도 제작년부터 perl의 매력에 빠져서 이번에 catalyst를 이용해서 웹페이지를 만들어 보려고 노력 중에 있습니다.
오랜만에 다시 하는거라 쉽지는 않은데... php 보다는 좀 더 재미난 것 같네요.
다들 자료는
다들 자료는 어디에서 구하시나요? perl.com ?
국내자료는 영 찾기가 힘듭니다.
...
자료는 구글님께서 잘 알려 주실겁니다.
물론 한국말로 제작된 양질의 도큐먼트들은 별로 못봤습니다.
국내자료는
국내에서 대표적 perl관련 싸이트로는
http://www.perlmania.or.kr
http://www.perl.or.kr
이 있고
위 싸이트에 가면 유명한 Perl관련 싸이트에 대한 링크도 있습니다.
하지만 최신 경향을 따라갈려면 아직까지 해외싸이트를 볼 수 밖에 없는것 같네요.
일단 Perl을 공부하시려면 위에서 제가 소개해드린 Beginning Perl은 먼저보시고
기타 궁금한것은 perl패키지 안에 포함되어 있는 perldoc
( http://perldoc.perl.org/ )에 있는 문서중에 관심있는걸 찾아서 보시는게
좋습니다. 영어가 장벽이 된다면. 보고 싶은 pod문서를 찾아서 perldoc의 일본어 번역
프로젝트 싸이트인 http://perldoc.jp/docs/perl/ 에 가서 일본어로 번역된
해당 pod가 있으면 그것을 http://enjoyjapan.naver.com/ 같은 온라인 일한번역기를
통해 보시면 일본어와 한국어가 어순과 사용단어가 비슷하므로 대강 알아먹을 정도로
번역이 되어서 보입니다.
그리고 짜장국 싸이트인 http://www.douzhe.com/down/perl/ 에
가면 Ebook이 좀 모여있습니다. :)
마케팅을 하는
마케팅을 하는 사람이 없어서 그렇겠지요. 관련된 커뮤니티도 국내에 많지 않고요. 굳이 그렇게 하지 않아도 이미 알아서 잘 사용하고 있는 것일수도... ==3=3
그런것 같기도
그런것 같기도 합니다.
예를 들면 Python을 만든 Guido는 Ruby on Rails가 인기를 끌면서
Python사용자들이 Ruby로 빠져나가고 Oreilly출판사에서 팔리는 책도
Ruby가 Python을 넘어가게( http://radar.oreilly.com/archives/2005/12/ruby_book_sales_surpass_python.html ) 되기까지하자 스스로 나서서 우리도 Ruby on Rails에
필적할 만한 Web framework이 필요하다며 Python 커뮤니티를 독려해서( http://www.artima.com/weblogs/viewpost.jsp?thread=146149 )
오늘날 Django,turbogears같은 발전된 모습의 python web framework이 나왔고
후에 Guido는 Django를 마치 세자책봉을 내리듯 Python의 대표 web framework으로 인정하고
Django와 TurboGears가 합쳐지기를 원한다고 발표( http://pyre.third-bit.com/blog/archives/613.html )
하는등 보따리를 싸다니면서 여기저기 적극적으로 개입하며, Python커뮤니티에는
Python의 정책 결정에 Guido는 만표를 행사한다는 농담이 있을정도로
Guido가 이러한 대중을 선동하고 다스리는 정치적인 성향이 좀 있고
게다가 우리나라에 Python이 보급될 초기 전파에 적극적으로 나섰던 분들이
보여줬듯이 Python유저들은 어느정도 에반젤리스트(복음주의자)적 성향을 지닌 반면
Perl의 Larry wall은 정말 유유자적하는 철학자 스타일인것 같습니다.
강연 내용에도 보면 무슨 과학/철학강의 하듯이 Perl커뮤니티는
이미 아무도 모든것을 따라가지 못하는 스스로 진화,발전해나가는
하나의 유기체처럼 인식하고 있지요.
그리고 Perl유저들은 우리만 조용히 잘 쓰면되지 이런성향으로
Python및 타 언어 유저들에 비해서 에반젤리스트적 성향이 대체로 없는것 같습니다.
흠...
Perl이 우리나라에선 참으로 안타까운 케이스죠...
Perl을 인기 없게 만든건 일부 잘 알지도 못하는 사람들의 말이 퍼지고 퍼져 그것이 정설로 되어 버린듯 합니다.
저도 Perl이라는 언어를 이제 2년정도 다루어 보고 있고, 정말 많은 툴들을 Perl로 작성해서 썼습니다. 그 활용도는 정말 최상이었다고 해도 과언이 아니었습니다.
풍부한 모듈, 검색만 하면 나오는 각종 도큐먼트들... 뭘 만드는데에 있으선 부족함이 없었기 때문에 생산성은 최고 였습니다.
음. perl 이 죽었다고
음. perl 이 죽었다고 하는 것은 잘못된 전제인듯..
웹에서 perl 이 죽은 것이지, 시스템에서 죽었다고 생각되지는 않습니다. 그리고 대부분 익수한 언어를 사용하려는 습관이 있을 것이고요.
웹에서의 perl 은 mod_perl 이 있다고 하지만, meory leak 이 너무 커서 쓰기에는 망설여 집니다. http://validator.kldp.org 를 mod_perl 로 돌렸다가 4시간만에 apache 가 죽어버리는 바람에 현재는 perl cgi 로 작동하고 있지요.
perl 이 좋은 부분이 있고, python 이 좋은 부분이 있을 것이고, php 가 좋은 부분이 있습니다. 즉, 상황에 맞게 가장 적절한 곳에 적절한 언어를 선택해서 사용을 하는 것이 가장 바람직한 모습이 아닌가 싶습니다.
제 경우에는, 문자열 파싱할 일이 많을 경우에는 perl 을, 적은 시간에 빠르게 작성해야 하는 경우에는 php 를 많이 이용합니다. (물론 shell 에서 입니다.)
python 과 ruby 는 객체적인 개념이 싫어서 별로 관심을 가지지 않고 있습니다.
루비는 잘 모르겠지만 파이썬은 객체 개념 없이 써도 됩니다.
루비는 잘 모르겠지만 파이썬은 객체 개념 없이 써도 됩니다. 솔직히 $, @ 없는 펄로 써도 무방하다고 봅니다. 확실히 문자열 처리에 있어서 python 은 루비나 펄과 같이 문법적 배려가 없어서 더 나쁠지는 모르겠지만, 파이썬은 객체 개념 없이 그냥 문자열 파싱 목적으로 써도 크게 무리가 없습니다. ^^
사실 펄이 나쁜지
원래 쓰레드를 시작한 원문만 보고 펄 커뮤니티가 거의 없다고 하시길래, 그렇게 된 이유가 펄에 대한 오해가 확장되서가 아니라, 펄의 태생적인 단점 때문에 그렇게 되었다는 요지의 글을 작성했는데, perlmania.or.kr 가보니 그 정도면 매우 활발한 수준의 사이트라고 생각되서 다 지웠습니다. 그 사이트 가보니 아직도 펄 쓰는 사람 많은데 왜 이런 걱정을 하시는 지 모르겠습니다만 ^^ 솔직히 펄이 주목의 전면에 나서기는 좀 힘들다고 봅니다. 펄의 장점이라는 것이 특정 분야에 한정된 곳에서 나온다는 점도 있고, 펄이 버전을 거듭하면서 혁신되었다고는 해도 그 태생적인 문법적 복잡성은 분명히 존재한다고 생각합니다. 이건 양쪽 다 사용하시는 분들께서도 많이 동의를 하실 것이고, eric s. raymond 도 지적했었던 문제이기도 하기에 비단 우리나라 사람들의 편견만이라고 보기에는 힘들다고 생각합니다
저 역시 무언가
저 역시 무언가 획기적인 이벤트가 있지 않는한 펄이 우리나라에서 주목의 전면에 서기는 불가능하지 않을까 생각합니다. 그렇지만 펄의 장점이라는 것이 특정 분야에 한정된 곳에서 나온다는 것은 아닌것 같습니다. 우리나라외에서는 굉장히 다양한 분야에서 사용하고 있는 것으로 알고있습니다. 특히 생명공학 쪽 뿐만아니라 외국쪽의 3D 애니메이션이나 영상처리하는 쪽은 무조건 Perl 사용은 필수로 요구하는 곳이 많은 곳으로 알고 있습니다. 가까운 일본만해도 펄 사용자가 굉장히 많고요. 단순히 문자열만 처리하려고 펄을 사용하는것 같지는 않습니다~ :-)
그리고 태생적인 문법적 복잡성이란 것은 아무래도 최초로 배운 언어와 비교했을때 이질성의 정도가 얼마나 크게 느껴지냐에 의해 판단하는 것이 아닌가 합니다. 처음부터 펄을 배우는 사람은 의외로 쉽게 받아들이더군요. 물론 어쩌면 제 개인적인 생각이지만 이것은 펄 쪽의 양질의 도서 때문인지도 모르겠습니다. 전 이제 겨우 가볍게 펄을 사용한지 2~3년이지만 펄의 구문들을 보면 편안함을 느낍니다~ ^__^;;
개인적으로 펄을 사용하면서 아쉬웠던 것은 초급 <-> 중급의 단계의 갭이 크다는 것, 양질 원서들의 번역서가 없는점, 커뮤니티의 규모와 활성도가 크지 않은점, C와의 연동을 위해서는 상대적으로 노력이 더 필요하다는 점, 대부분의 사람들이 막연히 펄은 어렵고, 시대에 뒤떨어졌으며, 문자열 처리할때만 쓰고, 별로다!라는 편견을 가지고 있다는 점(교수님들조차!)... 정도 랍니다. :-)
Smashing Watermelons~!!
Whatever Nevermind~!!
----
use perl;
Keedi Kim
저도 안타까운 점은
저도 안타까운 점은 일부 타 언어 사용자들이 Perl의 부정적인 면만을 부각시키며 대립각을 세우는 형태의 (이건 정권교체시기가 다다르면 정치계에서도 뉴페이스로 부각되기 위해서 쓰는방법 이죠) 네거티브한 방법으로 언어의 전파에 나서서 국내에서 새로운 유저들의 Perl사용자층으로 유입되는데 안좋은 영향을 끼쳤다는겁니다.
그리고 일반적으로 Perl이 원하는것을 쉽고 빠르게 하는데 좋다고 하지만 Larry wall이 2001년 일본 쿄토에서 열린 Perl/Ruby conference에서 LWN( lwn.net )과의 인터뷰( http://lwn.net/2001/features/LarryWall/ )에서 다음과 같이 말한바 있고
"Ruby and Python are languages that are designed more with the computer science mind-set, trying to be minimalistic. Some people prefer that kind of language. Perl was designed to work more like a natural language. It's a little more complicated but there are more shortcuts, and once you learned the language, it's more expressive"
위에서 keedi님이 초급 중급의 갭이크다고 말하셨듯이 Perl을 어느정도 이상 단계로 올라가서 더나은 표현성으로 사용하려고 하면 어느정도 복잡함을 넘어서는 노력이 필요한건 맞는것 같습니다. 그래서 저도 그걸 넘어서려고 계속 익히고 배우고 있고 거기에서 재미를 찾고 있구요.
하지만 국내의 Perl의 활용현실은 이 단계를 넘어가보기 전에 Perl에 대한 편견과 오해를 가지고 떠나버리고 Perl을 계속사용하는 유저층도 이런 단계를 못 넘어가고 있어보인다는데 안타까움이 있는거죠...
저는 c/c++, java를 주요 언어로 사용합니다만..
파이썬과 펄은 재미로 공부해서 초보적인 수준입니다
(각각 책두권을 사서 6개월은 파이썬, 6개월은 펄이런식으로 지하철에서만 공부했네요)
쉘스크립트 문법이 도대체 적응이 안되서요
(적응되었다가도... 시간지나면 또 까먹는...이렇게 5년이 넘었습니다.)
어떤 스크립트를 하나 작성하는데... 그러니깐 문법적인 공부와 약간의 예제작성해본 수준에서
두 언어로 각각 작성해보았습니다. (쉘스크립트의 대안을 위한 나의 주요 언어로 선택하기 위해서요)
펄로 먼저 해보고, 파이썬으로 해보았습니다.
초보자가 프로그램 작성하기에 어떤게 더 쉽냐는 측면으로는 파이썬이 월등하게 나았습니다.
둘다 코드는 100~200줄입니다.
작성하기 어려웠기때문에 더 애착이 가서 그랬는지 펄로 된 스크립트를 한달간 사용했습니다.
한달후 수정할 일이 있어서 펄코드를 보는순간...
내가 이런걸 작성한 적이 있었던가 할 정도로 햇갈렸습니다.
뭐랄까...암묵적인 문법들이 너무 많다는 느낌.. 문법을 기억하고 있지 않으면 소스코드를 도저히 볼수 가 없었습니다
잘하시는 분들은 당연한 코드겠지만요
반면에 파이썬 코드는 읽어나가기 좋았습니다. 주관적인 생각으로 가독성이 펄에 비해 월등히 뛰어납니다.
결론은 초보자가 작성하고 유지보수하기 쉬운 스크립트 대안 언어로는 펄보다는 파이썬을 추천하고 싶습니다.
저는 파이썬 전문가나 매니아는 전혀 아닙니다. 그냥 스크립트 필요할때 쉽게 작성해보는...수준입니다.
@.@
Perl의 철학이
Perl의 철학이 다양한 표현성을 중시하고 "한가지 일을 하는데 여러가지의 방법이 있다"를 지향하며 자연어적 생략을 모방한 암묵적 생략 문법 같은 언어상의 넓은 자유도가 코딩시에는 다양한 방식으로 짧고 빠르게 만들 수 있게 할지 모르나 후일에 보기 힘든 코드를 만드는 원인을 제공한다고 하는건 부인할 수 없을것 같습니다.
그래서 "자신이 짠 Perl코드를 6개월 후에 보면 왜 Perl을 안쓰고 XXXXX을 써야 하는지 알것이다."라는 농담도 있더군요.
이것은 높은 자유도속에 작성자의 나름대로 자유의지와 스타일을 존중해주고자 하는 Perl의 철학때문에 본의 아니게 이런 문제를 야기한점도 있지만 그렇게 후일에 보기 힘들게 만드는 사람에게도 책임이 있다고 봅니다.
그래서 Perl Medic ( http://www.amazon.com/Perl-Medic-Transforming-Legacy-Code/dp/0201795264 ), Perl Best Practices ( http://www.oreilly.com/catalog/perlbp/ ) 같은 코딩스타일 안내서 같은 책들이 그러한 문제에 빠지는걸 막아주기 위해 나왔고 Perl Best Practice에 있는 코딩규칙들을 기반으로 골라가며 강제하게 할 수 있는 Perl::Critic 모듈( http://search.cpan.org/dist/Perl-Critic/ )까지 나와서 자신이 난 너무 자율적이라서 문제다 싶으면 강제적으로 타율적 스타일로 이끌 수 있습니다. 실제로 Perl::Critic 모듈들은 Perl web framework중 하나인 Catalyst( http://www.catalystframework.org/ )와 유명한 DIY RSS/Atom aggregator인 Plagger ( http://plagger.org ) 등 몇몇 Perl project에 실제로 도입되고 있는 상태인걸로 알고 있습니다.
Perl은 이렇게 개개인의 자유의지존중과 넓은 자유도에서 나온 문제점을 그것을 다시 이용해서 역으로 억제할 수 도 있게 하는거지요. 그게 Perl만의 매력이자 재미일수도 있고...
또 Perl에서 재미있는것들을 더 보자면 Perl 모듈저장소인 CPAN 에서 실험적이고 심각(?)하지 않는 모듈들을 위한 Acme:: ( http://search.cpan.org/search?query=Acme&mode=module ) 라는 module namespace를 만들었는데 Perl의 프로그램이 실행될때 Perl parser에 가기전에 자기 자신을 한 번 읽어서 전처리같은 것을 할 수 있는 Source filter기능을 갖춘 Fiter:: 계 모듈을 사용하여 자신만의 코멘팅스타일을 만든다든지 Acme::Comment ( http://www.perl.com/pub/a/2002/08/13/comment.html ), 공백문자들로만 이루어진 프로그램을 만든다든지 Acme::Bleach ( http://search.cpan.org/dist/Acme-Bleach/lib/Acme/Bleach.pm ), Python 들여쓰기 스타일로 만든다든지 Acme::Pythonic ( http://search.cpan.org/~fxn/Acme-Pythonic-0.45/lib/Acme/Pythonic.pm ) 하는 일종의 자기 문법재정의 같은일을 할 수 있고 기타 Acme::EyeDrops ( http://search.cpan.org/~asavige/Acme-EyeDrops-1.51/lib/Acme/EyeDrops.pm )나 Acme::MorningMusume ( http://search.cpan.org/~kentaro/Acme-MorningMusume-0.07/lib/Acme/MorningMusume.pm ) 같은 재미있고 농담같은 모듈들도 많습니다.
제가 말하고싶은바는 이런정보들을 접하고 시도해보느냐 정보를 접하기가 어려워 그냥 모르고 돌아서 가버리냐가 해외와 우리나라의 차이점이라는겁니다. 여기에는 얇은 사용자층으로 인한 다양한 정보 부재의 원인이 크겠지요.
그리고 뭐가 좋다 나쁘다를 떠나서 해외에 비해 상대적으로 침체된 국내의 Perl의 사용자층이 넓어져서 생태계에서도 호랑이가 가장 강하다고 호랑이만 살 수 없고 생물학적 종의 다양성이 중요하듯이 다양성이 확대됐으면 하는 바람에 이런 글을 올린것이구요.
가독성은
사실 가독성은 펄 자체의 문제가 아니라 본인의 코딩스타일에 많이 달렸다고 생각됩니다.
perl에는 predefined 상수와 여러가지 syntax sugar라 볼수 있는 방법들이 존재하지만
자신이 진짜 몇달뒤에도 다시 볼꺼라 생각하면 그런걸 많이 피해가게 됩니다.
css hack처럼 완전 알아볼수도 없게 짤수도 있지만
가독성을 고려하면서 짜놓으면, 몇년 전것도 쉽게 고쳐서 쓴적 많았습니다.
가독성을 고려하면서 짜면 어느 언어나 읽기 쉽게 짜여지기 마련입니다.
뭐 그래도 $@#같은 문자들이 많아서 조금 파이썬에 비해서 첫눈에 지저분하게 보이기는해도
몇달만에 가끔씩 perl 코드 만지는 저도 가독성 문제로 고민한적은 없네요.
perl의 단점중에 많이
perl의 단점중에 많이 지적되는 부분이 바로 그런 건데, 코딩 스타일에 기인하기도 하지만
사용자가 신경을 더 쓰면 많이 좋아집니다. 아무래도 perl이 web이나 간단한 관리용으로
많이 쓰이다 보니 모듈 사용이 거의 없거나, 함수를 잘 나누지 않거나, 라이브러리 등으로
모듈을 분리하지 않거나 require 등을 애용한다거나 하면 아무래도 소스 코드 읽기가 매우
힘들어집니다.
큰 프로그램이라면 필요한 함수는 sub 로 다 나누고, 가능하면 모듈로 짜서 별도 파일로 분리하고,
use strict 정도는 꼭 넣고, 경고 안 나오도록 짜 두면 나중에 보기도 편해집니다.
자유도가 무지하게 높고 편하게 해 둔 만큼 스스로 규칙을 지켜서 짜야 되는게 perl programming이 아닌가 싶네요.
p.s. 저는 이상하게 python 소스만 보면 머리가 아파집니다. -_- 예전에는 tcl이 그러더니...
--
익스펙토 페트로눔
--
익스펙토 페트로눔
지나가다..
매일 눈팅만 하다 한글자 적고 갑니다.
얼마전 잠시 미국에 출장을 갔다가 google에 아는 개발자 분이 계셔서 구경하고 왔습니다.
google에서는(물론 국한된 팀일수도 있겠지만) 많은 부분을 python과 c/c++로 개발을 한다고 하더군요.
전 주로 perl을 쓰기에 perl을 쓰지 않는 이유를 물어봤더니, perl을 readability가 떨어지고, 개발자마다 독특한 코딩패턴이 있어서 공동작업이 어렵다더군요... (물론 반론이 있을수 있겠습니다만..)
전 전공이 프로그래밍이 아니라, 직업상 필요할때마다 간단한 스크립트짜서 자동화를 시켜놔야 일이 수월하기에 가끔씩 perl로 스크립트를 작성하게 되는데, 매번 애를 먹는게, 예전에 짜놓은 것들을 보면 제가 짜놓고 남이 짠 코드를 보는 듯한 느낌이 있습니다. 아직 python은 써보지 못해서 모르겠지만, 만나뵜던 google 개발자분의 얘기를 듣고 잠시 python에 솔직했던 기억이 납니다.
google이
google이 Python 창시자 Guido를 채용하고 Python에 우호적이긴 하지만 Perl을 사용하지 않는다는건 아닌것 같습니다. 실례로 Google이 내놓는 OpenAPI들에는 Perl이 빠지지 않고 Google에서 별도로 Perl 전문가를 채용한 사례도 있습니다. ( http://www.nntp.perl.org/group/perl.jobs/2141?show_headers=1 )
야후는 반면 Perl에 우호적이죠 Yahoo의 Open source정책을 대변하는 Jeremy Zawodny( http://en.wikipedia.org/wiki/Jeremy_Zawodny )는 Perl,MySQL hacker로 한때 자신의 블로그에 Ruby나 Python을 배워보려고 한다는 글을 올려 ( http://jeremy.zawodny.com/blog/archives/007085.html ) Ruby,Python 복음전파자들의 엄청난 코멘트들이 달리는 낚시질을 단행하기도 했었죠.
그런 Yahoo도 Yahoo의 Google code라고 할 수 있는 Yahoo developer networker에
Ruby( http://developer.yahoo.com/ruby/ ), Python( http://developer.yahoo.com/python/ ) 열어서 다양한 개발자를 지원하고 있습니다.
Perl 의 경우 워낙들
Perl 의 경우 워낙들 one liner 형태나 실업무의 편의를 위해 사용하시는 분들이 많아서 외부에 공식적인 형태로 드러나지 않는 게 아닐까요? 저희 회사만 해도 몇몇 분이 Perl enthusiast 라서 Perl 로 상당히 많은 작업을 자동화하고 있습니다. 이렇게 만든 툴은 회사 경쟁력 측면도 있고, OSS 에 대한 회사 차원의 이해도 빈약한지라, 아무래도 공개할 수 없게 되더군요. 그러나 조용히 잘 돌아가고 있습니다.
여담이지만 그래도 Perl 커뮤니티는 Lisp 커뮤니티 보다는 Major 하다는 점을 위안으로 삼는 것은 어떨지...
----
LUX ET VERITA | Just for Fun!
----
LUX ET VERITAS | Just for Fun!
저희 회사에서는 PERL로 많은것을 합니다.
저희 회사에서는 PERL로 많은것을 합니다.
1. 웹서버에서도 mod_perl를 사용합니다.
2. SOAP도 약간의 문제가 있지만, SOAP::Lite를 사용합니다.
3. 웬만한 어드민관련된것은 PERL을 기반으로 합니다.
솔찍히 PERL로 많은것을 하는것에 대해서 저희 회사 많은 개발자들의
반대가 많았습니다. 그 이유는 시작은 쉽게 할수 있으나, 지속적인
소프트웨어 사이클인 확장을 유지할수가 있겠는가 였는데, 결국 저희는
"해보자"를 선택했고, 가능하다는 판단을 내렸습니다. 이런 이유는
저희처럼 초기에 시작하는 회사는, "사람"을 구하기가 힘들었구요,
그래서, "개발자"="관리자"="운영자" 라는 관점에서 시작했습니다.
즉 단일언어로, 신입사원이 들어오면 무조건 "PERL"로 코딩을
시작하는쪽에 무게를 두었습니다. (물론 shell을 미친듯이 써서
가능할지는 모르겠지만여..)
그래서, 초창기에 C/C++로 코딩하던 친구들을 PERL로 끌어 내렸구요,
PERL을 C 코딩하는 것처럼 쓰고 있습니다.
현재 하나 문제가 되고 있는것은, "GUI"관련 app을 PERL로 하기는 좀
너무 어거지다 인데요, 뭐 그거는 native platform에서 하기로
결론을 지었구여.
어째튼, 저도 앞에 분들이 말씀하신것처럼, PERL관련해서는 해외에는
넘처나는 엔지니어와 리소스가 있지만, 우리나라에서는 찾기가 힘든
것 같습니다. 제가 알기에는 mod_php보다더, mod_perl을 해외
대기업들은 선호합니다. (아무래도 하던사람들의 모멘텀 때문이
아닐까 생각합니다만..)
그렇다고 무조건 PERL만 고려하는것은 아닙니다. 저희는 PHP도
쓰고 Java도 쓰기 시작했습니다. 아직 Python, Ruby는 아니지만,
처음 PERL을 선택했던것처럼, 이제 4년이 지난 지금 저희는
다른 언어를 고려하기 시작할것 같습니다. 물론 PERL로 역시
결론이 날수도 있구요..
The State of the Onion 10
Perl은 만든 Larry Wall 아저씨가 매년 Perl의 현상황에 대해 농담을 섞어가며 두서없이 얘기하는 The State of the Onion 10번째 얘기가 최근에 올라왔습니다.
http://www.perl.com/pub/a/2006/09/21/onion.html?page=1
글 내용중에 "I think the basic Perl paradigm is "Whatever-oriented programming."
라고 말하는것과
Perl 6의 개발과정은 시간이 많이 걸리고 있는 만큼 의견충돌도 많고 의욕에 찬 젊은이들이 참여했다가 거기에 상처받고 떠나기도 했는데 그것을 가족과 자라나는 아이에 비유하며 진짜 어른이 되려면 아이인 상태의 전문가가 되는데 10년,아이를 벗어난 상태의 전문가가되는데 또 다른 10년이 걸리는데 어떤 사람들은 두번째 단계를 잘해내지 못한다며 진정한 전문가가 되려면 지식과 기술적 능력뿐만 아니라 서로를 배려할 수 있는 태도와 성숙된 판단력이 필요하다고 말하는게 와닿네요. 이건 사람뿐만 아니라 Perl 6의 개발과정에도 적용되는것이고....
다음은 글 내용중에 있는 인상적인 이미지입니다.
이미지를 보니 "XX야 팬티사놨다 집으로 돌아와라"라는 얘기가 떠오르는 군요 :)
제가 열심히 쓰고 있습니다.
음..광고성이 될랑가는 모르겠지만 올블로그라는 사이트를 운영하고 있습니다.
블로그 메타사이트인데요. 수집기와 백단은 대부분 perl 로 되어있고
웹 서비스중 일부분 역시 perl 로 되어 있습니다.
앞으로도 perl 로 만들어질 부분은 계속 늘어날 것입니다.
개인적으로 perl 만큼 좋은 언어는 아직까지 보지 못한 것 같습니다. :-)
Perl..
많이 공부해야 하는데...
위 링크 사이트 감사합니다;
저는 펄을 좋아합니다
저는 펄을 매우 좋아합니다
국내에서는 펄을 좋아하는 사람들이 많지 않은 것이 아쉽습니다
최근에는 파이썬이 참 매력적인 언어라고 느껴지지만 펄도 나름대로 매력있는 언어라고 생각됩니다
(글을 쓰다가 보니 상당히 오래된 스레드가 올라온 것이네요^^;; )
멋진 쓰레드군요.. 다시 봐서 좋았습니다.
멋진 쓰레드군요.. 다시 봐서 좋았습니다.
_________________________
http://joone.net
https://kldp.org/blog/2725
http://opensoftware.tistory.com
http://joone4u.blogspot.com
https://gnome.or.kr
우왕 4년이나 지난 글이 댓글이 달려서 다시
우왕 4년이나 지난 글이 댓글이 달려서 다시 올라왔군요.
Perl유저 입장에서 4년전의 상황과 현 상황을 비교하여 다시 정리해보자면
Perl6 2010년 7월 Rakudo Star라는 이름으로 정식릴리즈 되었습니다.
대부분의 구현이 이루어진 상태이지만 여전히 개발중이기 때문에
아직은 프로덕션 환경에서 사용하기에는 부족한 점이 있습니다.
참고:
http://www.perlfoundation.org/perl6/index.cgi?rakudo_star_press
http://dev.perl.org/perl6/
http://kldp.org/node/116561
Perl5는 4년전 5.8.8에서 정체가 있는듯 했으나
jesse vincent라는 사람이 PM을 맡으면서 예측가능한 개발/릴리즈 주기를
가져가기로 해서 꾸준히 릴리즈를 거듭하여 현재까지 다음과 같이 버젼을
꾸준히 업그레이드 해왔습니다.
5.8.8 2006-Jan-31 5.8.9-RC1 2008-Nov-10 5.8.9-RC2 2008-Dec-06 5.8.9 2008-Dec-14 Hugo 5.9.0 2003-Oct-27 The 5.9 development track Rafael 5.9.1 2004-Mar-16 5.9.2 2005-Apr-01 5.9.3 2006-Jan-28 5.9.4 2006-Aug-15 5.9.5 2007-Jul-07 5.10.0-RC1 2007-Nov-17 5.10.0-RC2 2007-Nov-25 Rafael 5.10.0 2007-Dec-18 David 5.10.1-RC1 2009-Aug-06 The 5.10 maintenance track 5.10.1-RC2 2009-Aug-18 5.10.1 2009-Aug-22 Jesse 5.11.0 2009-Oct-02 The 5.11 development track 5.11.1 2009-Oct-20 Leon 5.11.2 2009-Nov-20 Jesse 5.11.3 2009-Dec-20 Ricardo 5.11.4 2010-Jan-20 Steve 5.11.5 2010-Feb-20 Jesse 5.12.0-RC1 2010-Mar-29 Jesse 5.12.0 2010-Apr-12 Jesse 5.12.1 2010-May-16 Jesse 5.12.2 2010-Sep-06 Ricardo 5.12.3-RC1 2011-Jan-09 Ricardo 5.12.3-RC2 2011-Jan-14 Ricardo 5.12.3-RC3 2011-Jan-17 Ricardo 5.12.3 2011-Jan-21 (현재 안정버젼)그리고 Perl쪽도 대표적인 웹프레임웍인 Catalyst( http://www.catalystframework.org/ )
이외에 Dancer( http://perldancer.org/ ), mojolicious( http://mojolicious.org/ ) 같은
현대적이고 경량화된 웹프레임웍도 등장하여 중흥기를 맞고 있습니다.
참고:
http://www.slideshare.net/xSawyer/perl-dancer-for-python-programmers
https://www.socialtext.net/perl5/index.cgi?web_frameworks
그리고 요즘에 과거의 legacy한 면을 버리고 Moose( http://www.iinteractive.com/moose/ ) 같은
진보된 OOP프래임웍과 그동안 발전해온 모듈 및 언어적 특징등을 이용하여 현대적이고 세련된
코드를 작성하자는 소위 Modern Perl이라는 움직임이 있습니다.
그래서 chromatic이란 분이 최근에 "Modern Perl" 이란 책을 무료로 내놨습니다.
http://www.onyxneon.com/books/modern_perl/
작년 크리스마스에는 한국 펄 커뮤니티인 서울 펄 몽거스에서
펄 크리스마스 캘린더 사이트( http://advent.perl.kr/ )를 열어 기사를 모았습니다.
또 최근에 Learning Perl 5판을 번역한 거침없이 배우는 펄( http://www.google.com/search?q=%B0%C5%C4%A7%BE%F8%C0%CC+%B9%E8%BF%EC%B4%C2+%C6%DE )
이 출간되었습니다.
perl과 c#의 성능 비교 결과에 대한 의문점...
perl과 c#의 성능을 비교해 보려고 제 노트북에서 테스트 했더니 재미있는 현상이 발견 되었습니다.
http://bit.ly/e5gNoW
언어별 벤치마킹으로 유명한 사이트죠.
재미있는 현상이라는 것은 다름이 아니고 3000번 반복까지는 perl성능이 우수했으나 200,000번 반복하니 10배 이상 perl이 느려지더군요. - 테스트 알고리즘별로 직접 확인해 보세요.
3000번까지 펄이 빠르다가 왜 수만번 이상부터 느려지는 것인지... 뭔가 반복 작업에 대한 최적화를 c#의 JIT(Just in time compilation)에서 하는게 아닐까 생각하는데 아시는분 계십니까?
저 사이트가 좀 그런게
저 싸이트가 그런게 어떤 알고리즘 구현에 있어 거의 로직이 1:1로 대응되는 코드로 비교한다기 보다.
언어간에 차이가 좀 많이 난다 싶어 실제 구현소스를 보면 빠르게 돌아가는 소스는 쓰레드,다중프로세스등의
병렬화를 통해서 처리하는 경우가 종종 있습니다. 그래서 액면 그대로 믿으면 안되는거죠.
C#과 비교하셨다면 Windows에서 하셨을텐데 Perl은 어떤버젼을 쓰셨는지요?
Windows Perl에서는 문자열 append시 메모리 할당속도가 좀 느린 문제점이 있다더군요
(ActiveState Perl 5.12.2 이후 버젼에는 패치가 된걸로 알고 있고, 현재 5.13.4 개발버젼에 적용된상태라고 합니다.)
참고:
https://groups.google.com/group/perl.perl5.porters/browse_thread/thread/e383d31f079f6149/eee0433d3f848054?hl=de
http://search.cpan.org/~avar/perl-5.13.10/pod/perl5134delta.pod#Performance_Enhancements
환경은 우분투 매버릭에서..
해당 사이트에 테스트 환경이 나오는데, 모두 우분투 같은 리눅스 환경에서 테스트된 결과인 것으로 알고 있습니다.
제 노트북 환경은 듀얼코어가 나오기 전의 인텔칩입니다. 저역시 우분투 매버릭 배포판이었고, c#은 novel에서 하는 open source프로젝트인 mono에서 테스트 했습니다. 윈도 환경이었으면 더 빠른 결과를 냈을듯 합니다.
매버릭의 mono의 버전은 C# compiler version 2.4.4.0 : 최신은 2.6으로 시작할 겁니다.
perl은 5.10.1 built for i486-linux-gnu-thread-multi 네요. 이역시 최신은 5.12로 시작하죠?
해당 사이트는 누구든 더 빠르다고 생각하는 소스코드를 제공 할 수 있는 형태인듯 하고 c#소스를 보았으나 따로 멀티 쓰레드를 활용한 부분은 보이지 않았습니다. 그리고 글에서 썼지만 특이한게 반복 횟수가 적으면 perl이 배로 빠르고 반복 횟수가 수만번 이상되면 c#이 10배 이상 빨라진다는 것 같습니다. 상식적으로 perl이 약간 느리다가 반복횟수가 많아질수록 더 느리다면 이해가 가는데, 더 빠른 결과를 보이다가 나중에 느리다는게 이해가 가질 않네요. 3000회 반복시에는 perl이 배로 빠른 결과를 냅니다.
그리고 텍스트를 뿌리는 IO루틴 때문인지 200,000번 반복시 real타임은 10% 정도 perl이 느린 수준이지만, 순수하게 cpu time만 재는 user time에서 10~20배 이상의 차이를 보이더군요.