Perl이 16살이 되었답니다....(perl 1.0_16 Release)

RisaPapa의 이미지

perl.perl5.porters뉴스그룹에서...

This Week on perl5-porters (15-21 December 2003)
A year ends in the little world of the Perl 5 porters, and perl itself
turns older. Hopefully this doesn't mean that the development is
stalled. Read below what happened this week among the porters.

Happy Birthday, Perl
Perl turned 16 years old, and for this occasion, Richard Clamp released
perl 1.0_16.

http://groups.google.com/groups?threadm=20031218081226.C22E2F5CB0%40phoenix.squirrel.nl

More MakeMaker issues
Rafael Garcia-Suarez remarks that the core module SDBM_File can't be
built on AIX with the xlC C compiler. Due to a post-5.8.2 change in
MakeMaker, the Makefile.PL for SDBM_File was tweaked, and this caused
this failure; but apparently that tweak is no longer necessary.

http://groups.google.com/groups?threadm=20031215181953.631460ab.rgarcia%40hexaflux.com

Alan Burlison also requested that MakeMaker's version cross-checking
could be disabled, in order to help his module Solaris-PerlGcc, which
allows to compile XS perl modules on Solaris with gcc against the
system's perl.

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-12/msg00621.html

Finally, Ilya Zakharevich proposed patches to improve a few things on
MakeMaker.

http://groups.google.com/groups?threadm=20031218203848.GA7783%40math.berkeley.edu

Clone fixes
Stas Bekman filed a ticket for a bug he reported before, bug #24660 :
weak references can't be properly cloned between interpreters. This
makes them currently unuseful for solving thread programming problems.
Elizabeth Mattijsen reports a similar problem (bug #24663) : assigning
an object to a weakened copy after cloning produces a panic error
message.

Those bugs were fixed by Enache Adrian. There are still problems and
Enache thinks that new ones are waiting to be discovered.

http://groups.google.com/groups?threadm=20031218203725.GA1181%40ratsnest.hole

POSIX::setuid() not perlish enough
Stas Bekman reported as bug #24641 that POSIX::setuid() doesn't update
the $< and $> variables, while it affects correctly the program
environment. The same problem exists with POSIX::setgid() as well.

http://groups.google.com/groups?threadm=rt-3.0.7_01-24641-68239.15.8235086069146%40perl.org

Signal handlers in eval{} blocks
Bug #24699 demonstrates that signals handlers, once set local()ly in an
eval{} block, might be restored *after* the block is exited. This
causes problems if the eval was present to trap an exception thrown by a
temporary signal handler. Rafael suggests a workaround.

http://groups.google.com/groups?threadm=rt-3.0.7_01-24699-68573.13.2276312695285%40perl.org

Substitution Bug
Ton Hospel found bug #24704, which demonstrates a case where a character
mysteriously disappears in an innocent-looking substitution. Sadahiro
Tomoyuki finds out that this is due to a problem with the offset to
which the actual "char*" is stored internally. Marty Pauley proposes a
patch.

http://groups.google.com/groups?threadm=rt-3.0.7_01-24704-68587.10.0650134616711%40perl.org

In Brief
Continuing a thread from last week, Scott Walters has a clever use for
tieable stashes : method overloading on method signature.

Craig Berry ported perl to the recent OpenVMS 8.1 on Itanium I64.

Enache Adrian continues to hunt down and fix memory leaks.

Yitzchak Scott-Thoennes found a contrived case where the "Too late to
run CHECK block" warning is not produced (bug #24684) :

INIT { eval "CHECK {print qq:in check in init\n:}" }

Tels proposed new method names for Math::BigInt, to make the interface
more consistent :

http://groups.google.com/groups?threadm=200312191051.13468%40bloodgate.com

About this summary
This summary was written by Rafael Garcia-Suarez. Weekly summaries are
published on http://use.perl.org/ and posted on a mailing list, which
subscription address is perl5-summary-subscribe@perl.org. Corrections
and comments are welcome.

nachnine의 이미지

Congratulations![/code]

김충길의 이미지

음.. 나이 꽤 먹었군요.

혹 질풍노도의 시기를 격는건 아니겠죠 :-)

screen + vim + ctags 좋아요~

코퍼스의 이미지

아쉽군요.
이 위대한 언어에 대한 감상들이 우리 나라에서는 이렇게 저조하다니...

왜 펄이 한국에서는 대중적인 언어로 성공하지 못하였을까요?

다른 나라들에서는 예외없이 C 다음으로 가장 많은 프로젝트로 수행되는 언어인데요?
음.. 고급의 펄 기법과 테크닉들을 다룬 한글 서적들이 너무 늦게 소개된 이유도 있을까요?

A few Good Man

nachnine의 이미지

Perl 의 강력함은 많은 사용자들이 알고 있을겁니다

단지 Re 를 달지 않는 것 뿐이겠죠 :)

굉장히 축하할만한 일이긴 하지만, 그렇다고

Reply가 많이 달릴 성격은 아니죠

( 정치를 소재로 하거나, 과격한 표현, 특정인물에 대한 공격
이 들어가면 리플은 최소 40개 이상 )

feanor의 이미지

답글을 늘리기 위해서:

Life's just too short! You need Python!
펄에 대한 감상이 저조한 이유는 다들 파이썬으로 옮겨서 그래요. =3=3=3

--feanor

serialx의 이미지

펄이 그렇게나 늙었나요? :shock:

예전부터 써오면서, 언어의 강력함에 놀라기도 했는데..

엄청나군요.. 나랑 나이가 같다니.. :oops:

암튼.. 쇼크네요..

dhunter의 이미지

Perl은 강력해보이긴 하는데 Perl REGEX 도 모르겠고 PHP 보다 문서가 접근하기 힘들어보여서요... (... 사실 PHP 보다 개발자 문서 정리 잘된 언어도 드물겠지만요)

아무튼, 생일축하-

from bzImage
It's blue paper

cjh의 이미지

코퍼스 wrote:
아쉽군요.
이 위대한 언어에 대한 감상들이 우리 나라에서는 이렇게 저조하다니...

왜 펄이 한국에서는 대중적인 언어로 성공하지 못하였을까요?

다른 나라들에서는 예외없이 C 다음으로 가장 많은 프로젝트로 수행되는 언어인데요?
음.. 고급의 펄 기법과 테크닉들을 다룬 한글 서적들이 너무 늦게 소개된 이유도 있을까요?

저는 회사에서 대부분의 일을 perl로 합니다만... 간단하게 뭐 짤때는 이거만한게 없죠. 모듈 적당히 쓰고...

perl을 처음 접한게 97년에 perl 4.x 였으니까 꽤 오래되었네요. 그때는 모듈 구성이 없어서 oraperl이나 perltk처럼 특정 기능을 추가한 perl을 따로 만들고는 헀습니다(그럼 oraperltk를 빌드하려면... :<). 지금은 DBI모듈이나 Tk모듈을 사용하면 그만이지만... 한동안 4.x에 익숙해져 있다가 5.x로 가는데 약간 힘들었는데 아직도 그 버릇이 남아있어서 OO 기능은 제대로 사용 못하고 있습니다.

perl이 문서가 부족한 것도 아니고(주요 서적은 다 번역되어 나와 있습니다) 이용자가 없는 것도 아니라(문서화 잘되기로는 perl만한게 없습니다. perl 모듈은 대부분 self-documented라서 별도의 매뉴얼 페이지 없이 바로 perldoc으로 읽어볼 수 있습니다) 국내에서의 기본적인 인식이 저급 CGI프로그래밍 언어로 굳어져 있어서 그런게 아닌가 싶군요.

실은 그것보다는 훨씬 더 많은 일을 할 수가 있습니다. 가령 만화같은거 부정 접근을 막으려고 gif파일 접근 자체에 PHP 세션을 걸려면 PHP로는 못하죠(물론 파일을 읽어서 출력하거나 redirection으로 처리할 수는 있겠지만 gif파일의 authentication handler를 가로채지는 못합니다). mod_perl을 사용하면 PHP::Session모듈을 조금만 쓰면 쉽게 가능했던 기억입니다.

일전에 마소에 mod_perl 글 실린 거 보고 우리나라에도 이렇게 쓰는 분 있구나... 하고 감동했던 적이 있습니다. perl이 국내에서도 나이에 맞는 관록을 더 많이 보여주었으면 하네요.

--
익스펙토 페트로눔

smalljam의 이미지

생일축하해요.펄

펄 한국싸이트중에 활성화된 곳을 알고 계시면 알려주시면 감사하겠습니다.
http://www.perl.co.kr
위 싸이트는 지금 운영되고 있는 곳인가요?링크가 살아있기는 한데,
대문의 이미지도 깨져있고^^;4,5년전 페이지같은 느낌이군요. :twisted:

In the UNIX,
화일 시스템은 지평적인 공간 감각을 제공하며 ,
프로세스는 생명을 갖는 생명체와 같아보인다.
--BACH

Ooryl Qrygg의 이미지

제 개인적인 의견으론 perl자체도 위대하지만,
perl에 관련된 책이나 문서치고 킬킬대거나,
'오! 이럴수'가 하며 읽지않은 책은 없었던 것 같습니다.
learning perl서문은 거의 압권이었고,
programming perl에서의 object는 단지 blessed thingie라는
간단한 oop의 진리, 등등...
perl cookbook, advanced perl programming, &
mastering algorithms with perl의 그 현란함 등등...

한마디로 perl그 자체가 happy hacking을 위해서 만들어진
언어 아닌가 생각됩니다.

perl 만세!

Gands considered it the height of presumption to use personal pronouns to refer to themselves, because it arrogantly assumes the listeners know who the speaker is.

eek의 이미지

perl이 정말 좋은 도구 이구요..
ㅋㅋ 넘 좋네요.
:D :D :D :D :D :D :D :D :D :D :D :D :D :D
perl 만세~~~ 빨리 6.x버젼이 나오면 좋겠네요..

Perl 만세~~~

M.W.Park의 이미지

feanor wrote:
답글을 늘리기 위해서:

Life's just too short! You need Python!
펄에 대한 감상이 저조한 이유는 다들 파이썬으로 옮겨서 그래요. =3=3=3

--feanor

저도 이 경우에 속하지 않나 싶습니다.
지금은 python도 거의 손 놓았지만... perl의 매력에 빠지려는 순간 선배가 python을 소개 해줬었죠... ㅋㅋㅋ

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

whitekid의 이미지

M.W.Park wrote:
feanor wrote:
답글을 늘리기 위해서:

Life's just too short! You need Python!
펄에 대한 감상이 저조한 이유는 다들 파이썬으로 옮겨서 그래요. =3=3=3

--feanor

저도 이 경우에 속하지 않나 싶습니다.
지금은 python도 거의 손 놓았지만... perl의 매력에 빠지려는 순간 선배가 python을 소개 해줬었죠... ㅋㅋㅋ

비슷하네요. ... 다른 비슷한 프로젝트의 대부분이 대부분 perl로 되어있길레... Perl을 배워야겠군 하고 생각하고 Perl이란 언어를 들여다봤을때 음.. .그 웬지모를 복잡함이란... 문법이 한눈에 들어오지 않고 복잡하게 보였다는(^^그땐 그랬죠.. 지금 보니 조금은 틀리지만..) 그래서 좀더 쉽게 접근할 수 있는(저희 팀에 perl을 다루는 사람은 아무도 없었죠.) 언어를 찾았는데..(C또, PHP도 안맞았죠.. 쉽고 간결한 언어를 찾아서..) 그때 눈의 뜨인게 Python이였죠..

처음 코드르 봤을때 그냥 이해가 가는 느낌의 언어.. 복잡한 $(PHP에서는 쓰지만 이건 개인적으로 싫어서 C만 해보다 보니.. 싫어.서..)도 안보이고... 다양한 확장성과, C언어와의 유합가능성등등...매력적으로 보여 Python으로 전향해 버렸습니다.. 그래서 아직까지 perl은 못하고 있죠.. ㅋㅋ

What do you want to eat?

fibonacci의 이미지

저도 perl을 배울까, python을 배울까 생각하다가
python을 배운 경우입니다.
그나저나.. 참 오래되었네요.. 16년이라...

No Pain, No Gain.

babowolf의 이미지

perl..이라..

전 프로그래밍을 learning perl이란 책과 함께 처음 시작했답니다. 지금 생각하면 얼마나 큰 행운이었는지 모르지요.. :)

지금은 Perl에 대한 열정을 접어두고 C를 사용하고 있지만, 언제나 프로그래밍에 대한 마음이 흔들릴때면 perl로 '놀면서' 쉰답니다.

놀수 있는 언어가 잘 없는 거 같은데, Perl은 그런 언어 같아요.

생일 축하 합니다. 첫사랑 생일 축하 하는 것 같군요. :wink:

P.s : 근데 잘 못해요 Perl은... 좋아하는거랑 잘하는건 좀 다른가 봅니다.

지킴과 버림, 달굼과 불림으로,
죽음에 맞서 살림을, 갈라섬에 맞서 하나됨을-

McKabi의 이미지

perl 쓰는 사람은 어딜가나 보입니다.

python 쓰는 사람은... 아직 보기 힘듭니다.

서울에서 회사 다닐 때는 주변에 널렸는데,
제주로 내려온 지금은 찾기 힘드네요.

ㄲ ㅏ ㅂ ㅣ / M c K a b i / 7 7 r b i / T o D y

nohmad의 이미지

우리나라에서 펄이 성공하지 못한 가장 큰 이유는
순전히 웹 때문이라고 생각합니다.
pl==cgi라고 생각했다가 갑자기 웹으로 사람들이 몰리면서,
asp, php 등에 비해 떨어지는 처리능력 때문에
기존 CGI 방식의 단점이 Perl의 단점으로 전이된 게 아닌가 싶습니다.

그렇게 보면 파이썬은 운이 좋은 것 같습니다.
보통 벤치마크를 해보면 펄이 파이썬보다 더 빠른데도
펄이 느리다고 불평했던 사람들이
파이썬 느린 것은 참을만 하다고 생각하는 것 같습니다.
웹의 부작용이지요.

연배가 있으신 분들 중에는 펄을 보조언어로 사용하고 계신 분들이
그래도 꽤 있는 것 같습니다.

저의 2세가 고등학생이 되었을 때에는,
제2외국어처럼 펄, 파이썬, 루비 등이 선택과목이 될 지도 모르지요.
펄과 파이썬의 진검 승부는 그때 다시....

RisaPapa의 이미지

펄에 대해서 스피드가 느리다고 생각하는 것은 개발자 자신의 자질 문제라고 생각합니다. 모드펄이나 FastCGI를 많이 사용하고 있는데 펄과 ASP,PHP,JSP등의 스피드를 비교해 보면 아직 펄이 가장 빠릅니다.

펄 버전별로 조금식 차이는 있는데 Perl-5.005_03을 Perl_Malloc옵션으로 컴파일해서 FastCGI를 운영할때는 거의 C를 FastCGI화해서 사용하는 것과 같은 스피드가 나옵니다.

며칠전에 기존에 CGI로 운영되는 페이지를 FastCGI화해서 리눅스(RH-7.2)에서 테스트를 했는데 저 자신의 눈을 의심할 정도의 스피드가 나왔습니다. 무려 20배이상의 스피드가 나왔기 때문입니다. 아마 PHP,JSP,ASP등으로 같은 서비스를 하는 페이지를 작성해도 그정도의 스피드는 불가능하리라고 생각합니다.

작년에는 주로 PHP와 자바의 FastCGI에 대해서 일년동안 연구해 왔는데 PHP의 경우 스피드는 모듈과 별다름이 없었습니다만 독립적인 프로세스로 작동하기 때문에 외부에서 작동하는 PHP를 마치 한대에서 작동하는 것처럼 하는 분산처리가 가능하다는 것 이외에는 별 메리트가 없었고 자바의 경우에는 꼭 필요한 클래스만 로드시켜서 작동 시킬수가 있었기 때문에 그 나름대로 많은 스피드의 향상이 있었던 기억이 있습니다.

저 개인 적인 생각입니다만 컴퓨터 언어에 대해서 깊게 하면 할수록 펄의 능력에 대해서는 감탄을 합니다. 그리고 요즘에는 LISP를 개인적으로 연구하고 있는데 FastCGI화한 LISP의 웹패이지도 역시 환상적인 스피드가 나옵니다. 미국의 화이트 하우스 웹서버도 LISP로 작성이 되었고 웹페이지 기술 언어도 LISP라고 합니다.

내년에는 LISP에 푹 빠져서 살아 보려고 합니다.

nohmad wrote:
우리나라에서 펄이 성공하지 못한 가장 큰 이유는
순전히 웹 때문이라고 생각합니다.
pl==cgi라고 생각했다가 갑자기 웹으로 사람들이 몰리면서,
asp, php 등에 비해 떨어지는 처리능력 때문에
기존 CGI 방식의 단점이 Perl의 단점으로 전이된 게 아닌가 싶습니다.

그렇게 보면 파이썬은 운이 좋은 것 같습니다.
보통 벤치마크를 해보면 펄이 파이썬보다 더 빠른데도
펄이 느리다고 불평했던 사람들이
파이썬 느린 것은 참을만 하다고 생각하는 것 같습니다.
웹의 부작용이지요.

연배가 있으신 분들 중에는 펄을 보조언어로 사용하고 계신 분들이
그래도 꽤 있는 것 같습니다.

저의 2세가 고등학생이 되었을 때에는,
제2외국어처럼 펄, 파이썬, 루비 등이 선택과목이 될 지도 모르지요.
펄과 파이썬의 진검 승부는 그때 다시....

죠커의 이미지

제가 봤던 몇권의 php책에는 원색적인 perl cgi에 대한 비난이 있었습니다.

우리나라에 perl은 cgi로 초창기에 알려진 부분도 있어서 근거없는 저급의 php책들이 유행할때 나쁜 (..) 소문도 덩달아 유행하지 않았나 싶어요.

예나 지금이나 악서들의 피해는 큰것 같음.

cjh의 이미지

perl은 원래 게으른 시스템 관리자를 위한 언어입니다. 웹은 한참 뒤(펄이 6-7세 무렵에... ^^)에 나왔죠.

그러고 보니 perl은 php/python/java등쌀에 고생이 많네요. :)

--
익스펙토 페트로눔

nachnine의 이미지

저는 perl 을 cgi로 활용하지는 않고

문자열 관련 batch 작업을 할때 쓰는데요..

그것만으로도 충분히 raison d'etre 가 되죠.

php가 perl을 비난할 이유는 없죠.

어차피 c보다 느린건 매한가지인데요 뭘^^:

Saintlinu의 이미지

의견은 아니지만..

전 프로그래머가 아니라서 코딩을 따로 할 일은 없지만.

어떤 시스템에 python이 있으면 그걸로 필요한 일하고,

어떤 시스템에 perl만 딸랑 있으면 그걸로 하고,

아무것도 없으면 가장 확실히 도움을 주는 shell script로 하곤 합니다.

근데 Perl의 문자처리능력이나 단순반복의 처리능력은 아름답지 않나요?

문자 조립하는거나 이런건 보는걸로도 아름다움이 느껴지는 언어라고

생각해요 ^^

다만 저 같이 코딩에 약한 사람이 코드를 보기에 정규표현식의 가독성은

힘들긴 하지만요.

ps. Perl이 나이가 많군요. 래리아저씨도 그럼 나이가 많겠군요.

행복하세요 ^_^

dreampia의 이미지

PERL 상당히 재미있는 언어죠..

요즘은 C로 짜기 귀찮은거 PERL로 짜고 있는데^^

우리나라도 PERL이 좀더 활성화 되면 좋을텐데..

>/dev/null 2>&1