Ruby가 Java와 php의 현재 위치를 차지할 수 있을까? 혹은 일부분이라도?

시렌의 이미지

현재 IT에서 프로그래밍 언어쪽을 보면 확실히 Ruby의 상승세가 보입니다. 국내에서도 Ruby와 rails 프레임워크를 활용하여 만들어진 사이트와 웹서비스들이 생겨나고 있으니깐요.

제가 python을 공부하면서 그리고 약간의 php 소스를 분석하면서 느낀건데 이런 pyhton이나 ruby같은 언어가 java나 php의 점유율의 얼마만큼이나 가져올 수 있냐였습니다. 다만 저의 실력이 그다지 안좋아서 기술적인 면들을 열거하면서 말하기가 힘들었습니다.

그런데 오늘 한 글을 보면서 어느 정도 생각이 정리가 되더군요. 이 글을 바탕으로 향후 ruby가 얼마나 IT에 영향을 미칠지 좁게 말해서 Java와 php의 파이의 얼마만큼을 가져올지에 대해서 얘기해보면 재밌을 것 같네요. :)

keedi의 이미지

일단 Ruby에 대해 이야기하는 것과 RubyOnRails에 대해서
이야기하는 것은 완전히 다른 일이라 생각합니다.
링크해주신 글을 읽어 보았으며 웹 프레임워크의 경우
MVC 모델을 벗어나거나 제공하는 기능 이외의 것을 사용하려면
오히려 Java나 PHP를 사용하는 것보다 생산성 및 효율성이 떨어진다
정도로 요약할 수 있겠네요.

하지만 이 것이 Ruby하고는 별개의 이야기겠지요.
RubyOnRails는 말그대로 루비를 이용한 웹 프레임워크이고,
이것은 Perl, Python, PHP를 이용해서 만든 웹 프레임워크에도
어느정도 동일하게 나타나는 현상일 것입니다.

무엇보다도 많은 사람들이 오해하는 것 중의 하나는
바로 링크에서 언급한 MVC를 벗어나거나,
기능 이외의 것을 사용하려면 더 불편하고 성능이 떨어진다입니다.
이것은 개발자의 해당 웹 프레임워크와 언어에 대한 숙련도의 문제라고 생각합니다.
10년차 베테랑 개발자의 실력에는 의심의 여지가 없지만
분명히 그 언어의 철학, 그 언어를 사용하는 프레임워크에 대한 깊은 이해 없이는
10년차 경력자라도 진정하게 웹프레임워크를 사용한다고 하기 어렵겠지요.

어쩌면 우리는 위키 5분만에 만들기, 블로그 10분 만에 만들기와 같은
자극적인 포스팅들에 너무 익숙해진 것 같습니다.
결국 깊은 이해없이는 따라하기 수준일 뿐일텐데요...
이것은 키보드만 칠줄 아는 사람이라면 누구나 다 할 수 있는 일입니다.
(예외 상황만 없다면...)

일단 해당 웹프레임워크의 구조를 정확하게 파악하고 플러그인 및 모듈 작성을
할 수 있는 수준이 되면 해당 웹프레임워크가 제공하지 않는 기능이라 할지라도
프레임워크의 도움없이 작성하는 것보다 훨씬 수월할 것입니다.
또한 유지보수 측면에서도 훨씬 낫겠지요.

Perl의 웹 굵직한 웹 프레임워크로는 Catalyst와 Jifty가 있는데
이 둘 모두 확장성, 유용성, 그리고 대단위 규모의 트래픽 처리를 염두에
두고 만들었으며 실제로 상업적으로(당연히 우리나라는 아니겠지요...:-)
널리 사용하고 있습니다. O'REILLY의 Perl.com에 가면
Catalyst Success Story 아티클들이 많이 있습니다.

Ruby나 Python 역시 훌륭한 언어일테고, 그들을 사용한
웹프레임워크 역시 많은 고려를 하고 선보인 녀석들일 겁니다.

정리하면... 해당 웹프레임워크를 구현한 언어에 대한 능숙도와
해당 웹프레임워크에 대한 깊은 이해 없이는 웹프레임워크를 진정하게
사용한다고 할 수 없다는 것을 말하고 싶었습니다. :-)

그리고 우리나라에서는 유독 심하게 이러한 언어들과 프레임워크에 대해
편견을 가지고 있지요. 그래도 Ruby나 Python은 상황이 훨씬 행복합니다만...
Perl은 거의... 막무가내로 배척하는 수준입니다. :-)

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

lacovnk의 이미지

Ruby의 문제가 아니라, 프레임워크의 문제라는 점에 이 댓글에 동감합니다. 링크된 글에서, Java나 PHP로 된 프레임워크는 역시 동일한 문제를 가지는 것 아닌가요? 얼마나 low-level까지 손댈 수 있는 프레임워크이냐에 따라 또 달라지겠지요.

RoR를 간단히 써보고 있는데, 세세한 설정을 건드릴 수 없다는 것에는 동감하지 않습니다. 정확히 말하면, 세세하게 건들려면 그만큼 더 알고 손을 대야한다는 것이겠지요. 나중에 튜닝을 위해서 method를 재정의하고 직접 SQL을 사용할 수도 있는 등, 프레임워크에서도 성능 이슈에 신경을 많이 쓰고 있는 것은, RoR도 마찬가지입니다. 아직 Apache + PHP 만큼의 널리 쓰이는 조합이 없다는 것은 아마도 현재에 있어서 가장 큰 문제라고 생각합니다만.. 속속 등장하는 서비스를 보면 곧 해결될 수 있지 않을까 생각해봅니다. 수요가 있으면 공급이 있고, 또 기여가 있을테니까.

일단 링크된 글에 대한 의견은 마치고..

LAMP 덕분에 누구나 웹서비스를 할 수 있게 되었습니다. 하지만 어떤 Idea를 실제로 구현해서 서비스로 만드는 것은 그리 간단하지 않습니다. 지금까지는 LAMP 위에 blog, community 등을 다른 OSS를 이용해서 많이들 서버를 돌리고 있습니다만.. 이제 Idea나 Need가 있다면, 간단히 그에 맞는 프로그램을 개발해서 직접 돌릴 수 있게 될 것이라고 생각합니다.

간단히 폼 처리하는데 PHP로 간단히 페이지를 만들어 둘 수 있지만, 페이지가 몇개만 늘어나면 관리하기 힘들어집니다. 그렇다고 대규모 개발을 하기에는 그리 크지 않은 프로젝트일 때, RoR 같은 프레임워크가 힘을 발휘할 수 있을 것이라고 생각합니다.

cjh의 이미지

> Perl은 거의... 막무가내로 배척하는 수준입니다. :-)

perl 애호가로서 마지막 말씀이 가슴에 저미는군요.
국내에서는 python (ruby는 잘 모르겠습니다) 애호가들이 많은 점은 이해가 가지만
실제 perl 사용자도 만만한 숫자는 아닐텐데...

요새 Jifty나 배워볼까 하고 있습니다만 손이 잘 가질 않는군요.
하지만 andrew tang의 Jifty 튜토리얼은 꽤 재미있었습니다.
http://tokyo2007.yapcasia.org/sessions/2007/02/jifty_now.html

--
익스펙토 페트로눔

--
익스펙토 페트로눔

aero의 이미지

펄매니아 ( http://www.perlmania.or.kr ) 에
정인석님이 Jifty에 관한글을 번역/작성해서 올리고 있습니다.
http://www.perlmania.or.kr:9000/trac/wiki/Jifty
저도 시간나면 봐야지 하면서도 손이 잘 안가서.. - -;

그리고 Perl이 하락세라고 하지만 Ruby,Python으로 인해 어느 정도 재조명을 받는것 같기도 합니다.
Ruby나 Python을 처음 접한 사람들이 Perl은 어떨까 하고 관심을 가지는 경우도 많은것 같더군요
하지만 Perl의 깊은 맛을 단시간내에 알기 힘들다는게 문제가 되겠죠...

Perl 6, Parrot 이 Vaporware니 하는 말도 듣긴하지만 꾸준히 개발되고 있고
Ruby나 Python이 잘나간다고 하지만 요즘 보면 여러 복잡한 상황과 불확실성에 싸인 정체상태라고나 할까
그런것들이 느껴져 Perl 6, Parrot 욕할 처지가 아닌것 같습니다.

그리고 요즘 서점(코엑스 반디엔루니스) 가봐도 예전엔 보기 힘들던 Perl서적(Programming Perl, Learning Perl)들도
4~5권씩 많이 꽃혀져 있더군요( 최신판이 아니라 오래된판 번역서라 deprecated된 정보를 습득하게 될까 걱정은 되지만...)
그만큼 관심을 가지는 분들이 늘어나고 많이 팔린다는 말이겠죠?

그리고 이건 여담인데 누구나 한 번 들어봤을 세계적인 투자은행인 모건스텐리에서 Perl을 기간언어로 Intensive하게 사용한다고 합니다.
YAPC::Europe 2007 ( http://vienna.yapceurope.org/ye2007/ ) 홈페이지에서 스폰서 리스트에 morgan stanley가 있길래 "여기에 왠 금융투자사 모건스텐리?"하고 생각했는데 찾아보니 다 그런 연유가 있었더군요..

purple의 이미지

주제와 관계가 적은 질문입니다만, perl의 웹 프레임워크인 catalyst와 jifty의 차이점을 좀 설명해 주실 수 있을까요?

RoR과 같은 스크립트 언어 기반의 웹 프레임워크를 하나 익혀야겠다는 생각에 여러 프레임워크들을 살펴 보고 있습니다. 여러 언어 중 아무래도 perl 쪽이 제일 실용적일 꺼같아 catalyst와 jifty를 살펴 봤습니다(tutorial을 따라가며 예제 프로그램을 만들어 본 정도입니다). 그런데 catalyst와 jifty의 특징, 적합한 규모, 앞으로 발전 방향 등등의 좀더 심화된 비교를 해 볼 수 없으니 어떤 것을 선택해야 할지 모르겠습니다. perl쪽은 커뮤니티가 좀 그런 성향이 있는지 몰라도 신참자가 문서나 사이트에 접근하기가 쉽지 않더군요.

aero의 이미지

Perl로 만들어진 Web framework는 Catalyst,Jifty 말고도 CGI::Application등등 많습니다.
이웃 일본에서만 해도 나름대로 만들어진게 서너개는 되는것 같고..
Jifty는 jesse vincent가 Catalyst 프로젝트에 참여하다 자신이 생각하는 방향과 다른 부분이 있어 새로 시작한 프로젝트입니다. 그가 현재 Perl 6 프로젝트의 Project manager를 맡고 있고 유명한 RT를 만든 Best practical이란 회사의 설립자이며 펄계의 신동 Audrey Tang도 Jifty에 활발하게 참여하고 있어 그것만으로 개인적으로 더 유망해 보이긴 합니다.
Jesse가 Catalyst에서 빠져나와 Jifty를 시작하면서 왜 자기가 새로 이런것을 시작했는지 보낸 메일을
어디 메일링 리스트에서 본것 같은데 다시 못찾겠네요

다음글도 읽어 볼만합니다.
Hey, That's Pretty Jifty, er, Nifty
http://www.oreillynet.com/onlamp/blog/2006/08/hey_thats_pretty_jifty_er_nift.html


http://use.perl.org/~jesse/journal/29381?from=rss
에 보면 Jesse Vincent가 다음과 같은 말을 합니다.

When we were building Jifty, we stole liberally from everything that had good ideas. We dragged Rails down a dark alley and rifled through its pockets. We grabbed Catalyst's wallet.

But really, Seaside's killer features like Continuations and Halos...just stopped me in my tracks. Once we got them into our grubby little perlish hands, I realized: This is the way development is supposed to be.

Rails, Catalyst, Seaside 같은 프레임웍에서 좋은건 다 털어와서(?) 만들고 있다는거죠...

Who의 이미지

저같은 경우도 처음에는 perl에 거부감이 들더군요.
뭐랄까 perl로 된 소스들을 보니 굉장히 가독성이 떨어지는 언어라고 느껴졌었지요.

나중에 perl관련 듀터리얼을 재미삼아 보니
$는 Scalar이고, @은 Array라고 하더군요.
그걸 알고보니 아주 간략한 헝가리안 표기법같은 느낌이 들더군요.
$temp (Scalar Temp), @list (Array List)식으로 읽으니 말이죠.

더군다나 Ruby나 Python은 C와 문법같은게 거리감있는데
perl은 C와 유사한 부분이 많고

그래서 어!! 이거 생각보다 재미난 것이었네 하며 perl을 배척하지 않게된 기억이 나는군요.

aero의 이미지

Perl은 1987년, Python은 1990년대 초반, Ruby는 1993년에
처음 릴리즈 되었습니다. 하지만 Perl이나 Python에 비해 Ruby는 비교적 알려지지 않고 대중화가 되지 않은 상태였으나 Ruby on Rails라는것이 Ruby기반으로 만들어지면서 유행을 타게 되었죠. 우리나라에서는 Ruby언어자체에 대한 번역서보다 Ruby on Rails에 관한 번역서가 먼저나오는 기이한 형태를 띄기도 했고요

Ruby가 비교적 덜 알려지고 덜 퍼졌던 이유는 그 창시자가 일본인이고 전 세계의 다양한 개발자를 끌어들이기 위한 영문문서가 부족해서였다고 보입니다. Perl이나 Python하면 누가 창시자인지 아는 사람이 많으나 Ruby창시자의 이름을 아는 사람은 Ruby에 관심이 좀 있지 않는 이상 모르는 사람이 많을거라 생각합니다. 또 Ruby의 창시자는 영어권 사람이 아니기 때문에 가지는 언어적 장벽으로 인해 인터뷰기사나 관련기사를 보기가 힘들기도 합니다. Ruby가 이러한 상황에서 급속히 무대에 등장하기 시작한건 서구권의 개발자가 Ruby on Rails라는 히트상품을 내놓았기 때문이죠 이에 따라 서구/영어권 개발자들이 관심을 가지고 참여하게 되어 Ruby가 더욱 활성화되는 계기가 된것같습니다.
어떻게 보면 Ruby 창시자보다 Ruby on Rails 창시자가 더욱 유명한것 같기도 하더군요...

Ruby on Rails가 유행하게 된건 새로운 구조를 가진점도 있지만 주위의 마케팅적인 측면지원의 힘도 컸다고 봅니다. 요즘은 그러한 프레임웍이 Perl(Catalyst,Jifty),Python(Django,Turbogear)같은 언어에서도 여러가지로 만들어지고 있고해서 앞으로 Ruby on Rails자체가 다른 프레임웍에 대해 대안이 없는 월등한 우위를 가질 수 있을까는 회의적입니다.

그리고 요즘의 소위 Dynamic typed language (Perl, Python, Ruby등)들을 보면 나름대로의 차기 버젼계획과
다양한 구현들이 속속 등장하고 있습니다.
Perl의 경우 Perl 6, Parrot가상머신이 되겠고 Python의 경우 Python 3000이 있지만 Ruby의 경우 차기 버젼에 대한 Roadmap이 구체화 되어 그려져 있는게 없어 보입니다.( 이건 제가 잘 모르고 있는 사실일 수 있습니다. 그런게 있다면 알려주세요..)

그리고 요즘엔 MS에서 .NET CLR위에서 돌아가는IronPython,IronRuby같은걸 개발하면서 원래 Python,Ruby구현과는 다른 특징들이 Iron(Python|Ruby)에 들어가기도하고 각 커뮤티니에서는 fork논란까지 벌어지는것도 보이고 최근 MS에서는 이런 Dynamic typed language를 지원하기 위한 DLR 가상머신을 내놓는등 발빠르게 대응함으로서, 이런 상황을 보고 있으면 예전에 MS가 Java에 취했던 전략을 Python,Ruby에도 그대로 하는게 아닐까 하는 생각도 들더군요.

하여튼 요즘 Perl,Python,Ruby는 질풍노도의 시기를 겪고 있다고 보입니다.
앞으로 이런 상황 속에서 어떤것이 개발자/유저의 많은 선택을 받게될지 지켜보는것도 재미있을것 같네요.

feanor의 이미지

"Perl의 경우 Perl 6, Parrot 가상머신이 되겠고 Python의 경우 Python 3000이 있지만 Ruby의 경우 차기 버젼에 대한 Roadmap이 구체화 되어 그려져 있는게 없어 보입니다. (이건 제가 잘 모르고 있는 사실일 수 있습니다. 그런게 있다면 알려주세요.)"

YARV(Yet Another Ruby VM)로 찾아보세요. Ruby 구현을 AST 평가 방식에서 바이트코드 방식으로 바꾼 것이고, Ruby 1.9에 들어가게 될 예정입니다.

익명사용자의 이미지

위키가 알려준바에 의하면 YARV가 들어간 Ruby는 올해 크리스마스 선물로 나올거라는군요.

inomaker의 이미지

저 또한 블로터닷넷에서 위의 글을 읽어보았습니다.

그래서 나름의 생각을 게시판에 올렸구요.

일단 현재는 Ruby가 한국에서 얼마나 인기가 있을지는 좀 더 지켜봐야 할 상황이 아닌가싶습니다.

워낙 한국의 독특한 문화라고 해야하나..하여튼 Python이나 PHP와 같이 경쟁력이 있으려면 어느정도 안정성과 성능이 따라줘야 하는게 사실이구요.

그런데..아직은 Ruby On Rails에서 테스트를 해보면 썩 그렇게 좋은 성능은 아닌것 같습니다.

중요한것은 위에분이 말씀하셨듯이.. 해당 프레임웍을 얼마나 잘 이해하고 사용하느냐가 관건이 아닐까요?

저의 좁은 의견입니다만..

아직 국내 개발자들의 수준은 그렇게 질이 높은 편은 아니라고 생각합니다.

요즘들어 개발자 인력이 다 어디갔지..하는 얘기를 많이 듣습니다.

실력있는 개발자가 많이 없다는 얘기인것 같습니다. 우후죽순 개발자는 많이 생겼는데.. 진정한 실력있는 개발자는 없으니..이런 얘기가 나오는건 아닐까...하는 생각도 들어서 나름 씁쓸합니다.

좀 희망적인 것은 웹2.0 사이트중 me2day나 springnote에서 ruby on rails를 사용해서 만들었고 현재까지는 별 무리없이 동작하고 있고 다른곳에서도 조금씩 rails 기반 프로젝트를 시도해보려고 노력중이라는 것입니다.

그러나 좀 아쉬운 부분도 있죠..아직은 국내에서 ruby나 rails 관련 guide 서적이나 전문서적이 많지 않다는 것이지요..
이점은 좀 시일이 지나면 나아질거라고 생각합니다.
국내만 봤을때는 ruby가 python이나 php 정도의 인기를 얻으려면 공부할만한 사이트나 서적들이 많이 있어야 국내 개발자들이 더 많은 관심을 가지지 않을까 하는 생각을 합니다.
이상하게도 개발자들이 영어를 싫어하는 것을 많이 봐서...(제 생각)

어째든..시간이 모든 것을 해결해 주지 않을까요?

keedi의 이미지

저도 영어가 싫습니다~
영어 울렁증 및 알레르기가 있다는 말을 들을 정도입니다만...
필요한 자료를 위해서 어쩔수 없이(?) 영문 자료를 읽고 봅니다만...
결코 영어를 좋아하지 않습니다~ :-)

이런 부분에 있어서는 일본이 무척 부럽습니다.
제가 알기로 일본은 출간되는 해외서적을
국가 차원에서 번역을 하는 것으로 알고 있습니다.
그 책을 읽는 사람이 있든 없든 상관없이요...
이점은 일본의 저력 중 하나라고 생각합니다.
무섭지요... :-)

일전에 perky님 블로그에서 일본의 오픈소스 활동이 많은 것은
머릿수가 많은 것도 한 몫하기 때문이라고 언급하신 것이 생각나는데...
인구수에 의한 요인은 제 생각에 생각보다 훨씬 비중이 낮을 것 같습니다.
오히려 그 사회의 문화와 저변과 의식 등이 오히려 더 큰 요인이라고 생각합니다.
우리나라가 살기가 퍽퍽해서인가요? 먹고 사는 것은 분명히 계속 나아지고 있는데...
참 아이러니한 문제같아요. :-)

일본에서 보통 사람들의 영어에 대한 관심은 우리나라에서처럼
가히 폭발적이거나 목매달지 않는 것 같습니다...
오죽하면 토플이나 GRE시험치러 일본까지 가겠습니까...
(일본은 언제나 자리가 남죠...)

영어를 못해도 깊은 수준의 개발 업무를 진행할 수 있고,
한글 문서로도 깊은 수준의 기술을 논할 수 있는 그런 환경이 얼른 왔으면 좋겠네요...

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

익명사용자의 이미지

루비에 관해서는 영어문서를 얘기하면서 일본이 더 좋은거 같다고 얘기하기가 조금 그렇습니다.

왜냐면 루비가 일본개발자가 만든 것이니 영문보다 일본어 문서가 더 많습니다.

오히려 일본에서 개발된 것이라 영문으로된 문서가 부족하여 영어권에 잘 어필이 안되고 있다고 봐야할 정도죠.

keedi의 이미지

루비에 대해서는 그렇겠네요~ :-)
일본에서 시작해서 밀고있는 TRON도 그렇겠지요?

일본이 원조가 아닌 프로젝트나 기술등의 경우
확실히 일본이 자료나 문서가 많은 것 같습니다.
공헌자들도 많고 커뮤니티도 활발하구요...

위에서 말했던 것처럼 일본에서는 기술 자료 이외의
문학이나 비기술 자료들도 열심히 국가차원에서 번역하려고
애쓰는 것 같아요.

가끔씩 Perl관련 자료를 찾다가 영어 해석하기 귀찮을때
일본판 번역 페이지(놀랍게도 번역양이 대단해요)를 일한 번역기를 돌려서 볼때마다
제 2외국어를 배워야 한다면 일본어를 배워야 겠다는 실없는 생각도 들곤합니다.

일본사람이나 우리나라사람이나 영어가 부담스러운 것은 피차 마찬가지일텐데 말이죠...
평범한 일본사람(유학 준비하지 않는...)들은 오히려 우리나라 사람만큼 영어에 매달리지도 않을텐데요.
일본어 위키피디아 페이지는 볼 때마다 놀랍기 그지없습니다. :-)

우리도 힘내야죠~ :-)

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

mithrandir의 이미지

요새 바이오인포매틱스 분야에서 루비사용자가 꽤 늘어나고 있다고 합니다. 루비가 RoR의 유행덕에 덩달아 사용자를 늘리고 있지만, 웹 이외의 분야에서 범용프로그래밍 언어로 퍼질 가능성도 충분히 있을 것 같습니다.

언어자체의 기민함 - 즉 애자일 프로그래밍에 어울리는 언어라는 점에서 애자일 프로그래밍의 연습용 혹은 주 언어로 사용될 수 있다는 점이죠. 유닛테스트를 내장하고 있다는 점, DSL화 시키기 좋다는 점 등.

현재의 문제점인 성능 문제라거나, 스펙이 따로 정해지지 않고 구현에 의존하고 있는점, 문법이 펄스러운덕에 모호한점 등등이 고쳐진다면 어떤 문제를 해결할때 가장 먼저 손이가는 언어로 택할 날이 언제쯤 오지 않을까요?

개인적으로는 필요한 프로그램을 짤때 루비를 가장 먼저 선택합니다. 라이브러리 수준이 파이썬이나 펄에비해 약간 떨어지는 감이 있지만, 그것도 요새는 워낙 멋진 라이브러리들 (예를들면 hpricot이나 펄에서 온 mechanize가 있겠군요)이 등장하면서 그런 말이 무색해지고 있습니다. 루비를 즐겨봅시다 :)

PS. 요새 하스켈이 너무 재미있어 보여서 큰일입니다 (...)
----
언제나 삽질 - http://tisphie.net/typo/

언제나 삽질 - http://tisphie.net/typo/
프로그래밍 언어 개발 - http://langdev.net

keedi의 이미지

문법이 모호(?)한 것은 단점이자 장점이겠지요.
다르게 말하면 문법이 모호한 것이 아니라 표현력이 풍부하다고 말할 수 도 있겠군요.
(온전하게 동작하는 파서가 존재하는 이상 문법이 모호할 수 는 없겠지요. :)

배우는 입장에서는 문법의 간결하고 숙지해야 할 양이 많지 않은 것을 선호하겠으나
루비든 펄이든 해당 언어에 숙련되기 시작하면 표현력은 오히려 장점으로 다가올겁니다. :-)

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

익명사용자의 이미지

루비는 일본이 고향이니 일본에 문서가 많지 않나요?
한국어와 일본어는 어순도 비슷하고 문화권도 비슷하고 하여
번역하기도 영어보다는 훨 수월할 듯한데(저는 일본어를 못합니다. 쓰미마셍)

일본에서 나온 루비관련 문서들을 한국어로 번역한다면
루비 보급에 도움이 될 듯합니다...

시렌의 이미지

다음 웹검색이 python으로 만들어졌네요.

Blog: http://www.siren99.net

keedi의 이미지

다음은 재미있는 시도들을 많이 하는군요~
보기 좋네요~ :-)

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

익명 사용자의 이미지

여담으로

'C는 죽었다.' C++ 유행할 때
'C++은 죽었다.' 자바 유행할 때

인터프리터 쪽에서도

'펄은 죽었다.' PHP 유행할 때
'PHP는 죽었다.' 파이썬 유행할 때
'파이썬은 죽었다.' 루비 유행할 때

국내에서 SW 이슈를 만들어내는 곳이 극히 적어서 열정적인 소수의 애호가(에반젤리스트 -_-;) 들이 여기저기 매체에서 활동을하면 정말로 'XXX'를 못하면 밥이나 굶지 않을까 하는 우려가 들 정도입니다. 적어도 저는 대학다닐때 그랬습니다. -_-; 지금은 C로 밥을 먹지만요. 다들 나름대로의 영역에서 제 자리를 지켜가는 것 같습니다.

익명 사용자의 이미지

XML이 5년전인가 한창 뜰때도 그랬었죠.
XML 모르면 굶어죽어야 할거 같은 분위기, 무슨무슨 방법론 모르면 퇴출될거 같은 분위기
이거 나와서 저거는 사라질거 같은 분위기

다.. 뜬구름 잡는 소리죠

익명 사용자의 이미지

글쎄요 확실히 xml 열풍에 거품이 있었긴 했지만 이곳저곳 정착된 곳도 많으니까요. 사라질거같은 분위기는 아닙니다 ㅎㅎ