만약 프로그래밍언어가 종교였다면...

글쓴이: ckebabo / 작성시간: 화, 2008/12/23 - 3:40오후

/. 을 기웃거리다 재미있는 글이 있어 링크를 올림니다.
여러가지 언어들을 종교에 비유해서 말하고 있네요. 자동차랑 비교해 놓은것도 것도 링크가 달려 있네요. 다른 언어들로 확장하면 재밌을 것 같아요.

LINK

Visual Basic이 그렇게나 나쁜가요???

Forums:

자유 게시판

비베는 사이비에

글쓴이: M.W.Park / 작성시간: 화, 2008/12/23 - 3:57오후

비베는 사이비에 가깝죠. ^^;

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

형.. 여기서 보네요..

글쓴이: plustag / 작성시간: 화, 2008/12/23 - 6:12오후

형.. 여기서 보네요..

누구냐 넌?

뭐, 세상에는 별의별 사람이 다 있으니까...

글쓴이: winner / 작성시간: 화, 2008/12/23 - 9:09오후

Microsoft가 더이상 Visual Basic을 지원하지 않는다는 것만 봐도 끝난 이야기죠.
Visual Studio는 물론이거니와 Windows Vista에서는
Visual Basic을 위한 ActiveX control인 *.ocx 파일이 제거되었더군요.

그래도 어쩌겠어요. 더불어 살면서 적절히 다른 세상을 접하도록 인도해 나가야죠.

저는 종교가 없어서 잘 몰랐는데

글쓴이: winner / 작성시간: 화, 2008/12/23 - 9:12오후

확실히 언어는 사람의 사고를 지배하기 때문에 언어전쟁은 종교전쟁과도 유사한 것 같아요.
언어와 종교는 아주 적절한 비유인듯...

도스시절에 베이직이

글쓴이: 망치 / 작성시간: 수, 2008/12/24 - 1:57오전

도스시절에 베이직이 아닌 C를 잡았다면 지금쯤 조금 다르지 않았을까 하는 생각이 종종 듭니다.
GW-BASIC, POWER-BASIC 을 거쳐서 Visual BASIC 을 썼었거든요. 그러다가 지금은 PHP 만 만지고 있습니다..;

---------------------------------------
http://www.waitfor.com/
http://www.textmud.com/

Perl 설명이 기가

글쓴이: JuEUS-U / 작성시간: 수, 2008/12/24 - 8:17오전

Perl 설명이 기가 막히는군요 =ㅅ=)b;;

저 사람 대놓고 Perl 까 더군요.

글쓴이: aero / 작성시간: 수, 2008/12/24 - 10:34오전

웃자고 하는 얘기겠지만...
Perl이 알 수 없는 불가사의한 마법의 연속같은 Voodoo교라고 하는데
익숙하지 않다고 불가사의하다니 마법 같다니 하는 건 좀 아니라고 봅니다.
(그렇게 말하는 사람 대부분이 Perl을 제대로 배워보지도 않고 어디서
주워듣고 앵무새처럼 내뱉는 것으로 보이지만...)
Perl의 코드에 sigil,정규식등 기호류가 많이 사용되기 때문에 그런 것 같은데.

그건 마치 중학교 학생이 시그마와 적분기호등이 포함된 수식이 뭐가뭔지
모르겠다고 말하는 것과 같다고나 할까요.

예를 들어
http://greenokapi.net/talks/ReadablePerl.pdf
자료에 나오는 같은 기능을 하는 C# 코드와 Perl 코드를 비교해보면

C# with Linq
 int[] a = Enumerable.Repeat(-1, 10).ToArray();
 int[] b = Enumerable.Range(0, 10).ToArray()
 
Perl:
 my @a = (-1) x 10;
 my @b = (0..10);

C#코드는 Perl의 기호를 그 영단어 뜻대로 동작하기를
기대하는 이름있는 함수로 verbose하게 풀어쓴 것일 뿐입니다.
영어를 모르는 사람에게는 C#코드도 무슨말인지 모르는 암호같을
뿐이겠죠.

Perl코드가 뭐가뭔지 모르겠다 읽기가 어렵다고 하는 것은
어떤 문장 내 개개 단어의 뜻을 알지도 못하면서 어떤 문장의
뜻을 알려고 기대하는 것과 같다는 거죠.

Perl도 물론 장단점이

글쓴이: eungkyu / 작성시간: 화, 2008/12/30 - 2:36오후

Perl도 물론 장단점이 있겠지만 readability가 다른 언어에 비해서 좀 떨어진다는 것은 사실 같습니다.
아니면 ReadablePerl.pdf까지 만들어가며 강조할 필요가 없었겠죠.

어떤 언어든 어떻게 사용하느냐에 달려있죠

글쓴이: aero / 작성시간: 목, 2009/01/01 - 9:34오후

어떤 언어든 어떻게 설계하고 구현하여 사용하느냐에 달려있죠.
하지만 가독성이 어쩌고 하며 Perl을 가지고 걸고 넘어지는 건 경쟁 언어 에반겔리스트들의
근거없는 폄훼에 의해 과장된 면이 있다는 겁니다.

http://labs.kraih.com/blog/2008/10/dispatchers-for-dummies.html

에 보시면 Perl,Ruby,Python의 대표적인 Web framework들의 dispatcher 모양을
비교해 놓았는데 어떤 언어가 제일 읽기 어렵게 만들어져 있는지 보시길..

어떤 언어든지 obscured

글쓴이: keedi / 작성시간: 금, 2009/01/02 - 10:32오전

어떤 언어든지 obscured code 는 작성할 수 있습니다.
그것이 Perl에게만 해당하는 일은 아니지요.

그럼에도 불구하고 펄에게 굳이 가독성이 떨어진다는 짐을 지운다면
차라리 펄이 자유도가 높기 때문이라고 말할 수 밖에 없겠네요.

자유도가 높은 한국어도 우주어 초딩어를 섞어쓰면 가독성은 현저히 떨어집니다.
하지만 한국어보고 가독성이 떨어진다고 하지는 않지요.

중요한 것은 훌륭한 프로그래머는 가독성이 떨어지는 코드를 만들지 않는다는 것이죠.
그것이 C이든, 펄이든, 파이썬이든 간에요...

가독성의 문제는 언어의 문제라기 보다는
프로그래머의 역량 문제라고 하는 것이 정확할 것입니다. :-)

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

Keedi Kim

----
use perl;

Keedi Kim

맞습니다. 어떤

글쓴이: eungkyu / 작성시간: 화, 2009/01/13 - 10:11오전

맞습니다. 어떤 언어로 짜든지 프로그래머의 역량에 따라 obscured하게 짤 수도 있고 clear하게 짤 수도 있습니다. 하지만 그렇다고 해도 언어의 특성이 완전히 사라지는 것은 아닙니다. 아니면 사람들이 계속 새로운 프로그래밍 언어를 만드는 이유가 없어지겠지요.

사람들이 펄의 가독성을 가지고 뭐라 하는 것은 단순 문법의 문제는 아니라고 생각합니다. 예를 들면 $_의 존재가 있겠죠. 분명 코드를 봤을 때는 아무 연관성이 없었는데 뭔가 입력이 되고 출력이 되더라... 그럼 가독성이 떨어질 수 밖에요.

$_는 Perl만 있는게 아닙니다.

글쓴이: aero / 작성시간: 화, 2009/01/13 - 11:17오전

$_는 Perl만 있는게 아닙니다.
Ruby도 Perl의 특수변수( http://perldoc.perl.org/perlvar.html )를
대부분 빼껴갔습니다.( http://cs.podbean.com/2007/09/14/ruby-special-variables/ )
$_같은 것이 존재한다는 자체가 문제라고 하는 것은 이치에 맞지 않습니다.
다만 그것을 적절하게 사용하느냐의 문제로 따져야겠죠.

Perl은 자연어의 특성을 모방한 암묵적 생략이 가능하지만
(어떤 경우에는 $_조차 생략가능 합니다.) 가독성 높은 코드를
작성하려면 $_을 쓰지 않으면 됩니다.
명령행에 주어진 파일들을 차례로 열어서 한 줄씩 읽어 프린트하는
다음 Perl코드

while (<>) {
    print;
}

를 명시적으로 쓰면

while (defined($_ = <ARGV>)) {
    print $_;
}

이고 이것을 $_을 사용하지 않으려면

while (defined( my $line = <ARGV>)) {
    print $line;
}

이런식으로 사용하면 됩니다.

Perl의 암묵적 생략은 그 동작을 정확히 아는 사람이 사용할 때는
짧고 빨리 끝낼 수 있겠지만 그냥 단순한 작업을 한번에 하고
끌낼 경우가 아니거나 가독성(?)을 생각한다면 당연히 그 사용을
자제할 겁니다.

"아무 연관성이 없었는데 뭔가 입력이 되고 출력이 되더라." 이 말은
"어떤 연관성을 알지 못하는 사람이 이해하기 힘들더라"는 말로
고쳐야 할 듯 하네요.
아무런 연관성이 없는데 입출력이 될리가 없으니까요.

인용:Perl은 자연어의

글쓴이: eungkyu / 작성시간: 화, 2009/01/13 - 12:09오후

Quote:

Perl은 자연어의 특성을 모방한 암묵적 생략이 가능하지만
(어떤 경우에는 $_조차 생략가능 합니다.) 가독성 높은 코드를
작성하려면 $_을 쓰지 않으면 됩니다.

제가 하고 싶은 말이 바로 이것입니다.

xxx한 것이 있기는 하지만 가독성 높은 코드를 작성하려면 yyy하게 하면 됩니다.
라고는 하지만 어쨌든 xxx는 존재합니다. 많은 사람들은 xxx를 보고 판단하는 것이구요.

'goto를 사용하면 스파게티 코드가 되기 쉽지만 꼭 필요한 부분에 한정에서 잘 쓰면 goto도
매우 유용합니다.'라고 하지만 그렇다고 goto가 구조화 프로그램에 좋다고 얘기하지는 않습니다.

세상에 훌륭한 프로그래머, 소스를 보기 전에 언어를 독파하는 사람만 있다면 가독성을 따질 이유도 없습니다.

goto는 코드의 흐름을

글쓴이: ceraduenn / 작성시간: 화, 2009/01/13 - 12:56오후

goto는 코드의 흐름을 바꾸는 만큼 적절하지 않은 예 같네요..

xxx는

for(i=0;i＜MAX;i++)printf("%d",array[i]);

yyy는

for (i = 0; i ＜ MAX; i++) {
  printf ("%d", array[ i ]);
}

이런 예가 더 적절하지 않을까요?

Summa Cum Laude http://ceraduenn.egloos.com

동갑합니다. 더

글쓴이: keedi / 작성시간: 화, 2009/01/13 - 1:24오후

동감합니다.

더 가독성 있게 임의로 바꿔 본다면

for (i = 0; i < ACCOUNT_MAX; ++i) {
    printf ("%d", web_account_list[i]);
}

펄이라면 이런식이겠죠. :-)

foreach my $account ( @web_accounts ) {
    print $account;
}

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

Keedi Kim

----
use perl;

Keedi Kim

가독성 높은 언어를

글쓴이: keedi / 작성시간: 화, 2009/01/13 - 1:15오후

가독성 높은 언어를 만들기 위해서 새로운 언어가 나타난다고 생각하지는 않습니다. 기존의 언어가 무언가 불편하거나 마음에 들지 않거나 등의 이유가 더 크죠. 실생활의 언어가 그러하듯이 프로그래밍 언어도 일종의 문화입니다. 파이썬을 만든 이유도 루비를 만든 이유도 심지어 펄을 만든 이유도 가독성이라는 것을 언어의 저자가 우선적으로 고려했다고 보기 힘듭니다.

자신의 정서와 맞지 않으면 받아들이기 무척 어려운 것이 프로그래밍 언어이며, 또한 프로그래밍언어 중에서는 유별나게 문화라는 것을 강조하는 언어 중 하나가 펄입니다. 그렇기 때문에 펄을 맞딱뜨렸을 때 너무 쉽게 받아들이는 사람이 있는 반면 도저히 받아들일 수 없는 사람 또한 있는 것이 사실입니다. 다른 언어에 비해 비교적 호불호가 분명히 갈리는 편이고, 충성도 또한 높은 것이 단순히 맹목적으로 좋아한다기 보다는 자신의 스타일에 맞기때문에 즐기는 것입니다.

저는 펄을 공부하고 펄 프로그래밍을 하면서 하나씩 익혀나갈 때마다 수학 공식이 생각나더군요. 우리가 초등학교 때 배우던 수학 공식에서 중등, 고등 수학을 지나 대학 수학까지 거쳐가던 단계를 한번 떠올려보세요. verbose하던 수많은 공식들은 한 단계 넘어갈 때마다 compressed한 표현으로 변경되고 또 그러기 위해 새로운 기호를 추가하곤 합니다.

저 역시 차례대로 수학을 배워왔기때문에 초등학생이나, 중학생이 대수학을 보았을때 느끼는 감정을 이해할 수 있습니다. 이것은 암호에 가까운 가독성이라곤 눈꼽만큼도 없는 불친절하기 짝이없는 식일 것입니다. 하지만 대수학을 하는 사람들 입장에서는 아름답다고 표현할 정도로 군더더기 없는, 그래서 너무 자명한 식일 것입니다.

만약 우리가 배운 로그에서 밑이 10인 경우는 상용로그라고 해서 10을 생략하곤 하는데 이것은 암묵적이라 가독성이 떨어지니 반드시 로그 아래쪽에 10을 명시해라고 하지는 않지요. 물론 10을 사용해도 되고 10을 사용하지 않아도 됩니다. xxx가 있고 yyy가 있으며 무얼해도 상관없지만 실제로 수학을 배울때 상용로그로 쓰는 것을 추천하죠. :-)

제가 말씀드리고 싶은 것은 이것입니다.

해당 언어에 대한 최소한의 문법도 모르고 가독성을 논할 수는 없다는 것입니다. 그리고 만에 하나 해당 언어에 대해 최소한의 문법도 모르고 높일 수 있는 가독성이 줄 수있는 이점은 무엇일까요? 그렇게 한눈에 알아본 코드를 과연 그 사람이 고칠 수 있을까요?(문법도 모른채?) 만약에 문법이 익숙해졌는데도 불편하다. 이것은 가독성의 문제가 아니라 취향의 문제인 것입니다.

제가 생각하는 가독성에 가장 큰 영향을 미치는 세가지 요소는 다음과 같습니다:

1. 변수와 함수의 이름
2. 자료구조의 복잡도
3. 알고리즘의 복잡도

이 세가지를 뺐을 때 가독성이라는 측면에서 고수준의 언어의 종류에 따라 좌우되는 비중은 아무리 보수적으로 생각해도 단언컨데 10프로도 안된다고 감히 말씀드리고 싶네요.

P.S.
더불어 가독성이 무척 뛰어나다고 생각하시는 언어는 무엇이신지요?
무척까지는 아니어도 비교적 뛰어나다고 생각하시는 언어가 있다면 어떤 언어인지 궁금하네요 :-)

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

Keedi Kim

----
use perl;

Keedi Kim

바라보는 관점이

글쓴이: eungkyu / 작성시간: 수, 2009/01/14 - 1:10오후

바라보는 관점이 달라서 서로 평행선만 달리는 것 같기는 합니다만...

그럼 이런 문장은 어떨까요?

펄에는 다른 언어보다 오퍼레이터 종류가 많고, 특히 다른 언어에 쓰이지 않는 표현이 많으며,
같은 뜻을 여러가지 방법으로 표현이 가능하다.

따라서 같은 의미라도 취향에 맞게 다양하게 표현할 수 있다.

펄 프로그래밍은 이와 같이 자유로운 표현이 가능한 대신 (비록 언어의 가독성을 따질 자격은 안될 지 모르지만)
펄 언어를 완전히 숙지하지 않은 사람에게는 복잡하게 보일 여지도 있다.

정말 완곡하게

글쓴이: keedi / 작성시간: 수, 2009/01/14 - 1:46오후

정말 완곡하게 표현해주셨군요. :-)

제가 아는 범위내에서는 흠잡을 데 없이 정확하게 표현해주셨습니다.

이것을 가독성이 떨어진다고 표현하는 것은 무리가 있다고 생각합니다만,
이렇기 때문에 가독성이 떨어진다고 주장하시면 뭐 어쩔수 없지만요. :-)

코드 하나 첨부하겠습니다.
어제 회사에서 사내 라이브러리용 테스트를 위해서 작성한 코드인데
크게 크리티컬한 부분이 없어서 붙여봅니다.
비록 펄 코드지만 제 코드가 가독성이 떨어진다고 생각하지 않습니다. :-)

http://codepad.org/reJVwioQ

간단하게 설명드리면,
간단한 문서와 설치 방법 역시 명시했으며,
명령줄에서 실행하기 위한 7개의 옵션을 지원하고,
에러 처리와 사용자 입력 값의 validation 처리,
ssh에 접속해서 원하는 작업을 처리하고
그 결과로 로컬 환경에서 후처리 작업까지 수행합니다.

겨우 240줄의 펄 코드입니다. :-)
심지어 주석도 없는 코드이지만 충분히 descriptive 한 코드라고 생각합니다.
또한 펄 커뮤니티에서 권장하는 견고한 코딩 스타일을 모두 따른 코드입니다.

그리고 이런 코드를 작성하는 것은 best practices의 문제이지 별로 어렵지 않은 일입니다.

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

Keedi Kim

----
use perl;

Keedi Kim

물론 동의는 하지

글쓴이: eungkyu / 작성시간: 목, 2009/01/15 - 4:44오후

물론 동의는 하지 않으시겠지만, 저는 그런 면이 가독성에 영향을 준다고 생각합니다.

왜냐하면 펄이 다른 언어에 비해서 패러다임이 완전 다른 것도 아니고 (예를 들면 functional 또는 declarative 언어),
비슷한 수준의 다른 언어와 비교했을 때 비슷한 능력을 가지고 있기 때문입니다.

분명 그런 부분 때문에 다른 언어보다는 초보자의 언어 진입 장벽이 높다고 생각합니다.

그렇지만 분명 확실한 것은 그것이 다른 관점에서 보면 펄의 장점이이기도 하다는 것입니다.
펄의 여러가지 오퍼레이터로 인해 regex를 비롯한 스트링 처리가 편리하다는 것도 분명 장점이고,
아래 다른 분이 쓰신 것처럼 one-liner의 유용함이 부각되기도 어려웠을 것입니다.

네~ 초보자의 진입

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 11:03오전

네~ 초보자의 진입 장벽이 높은 언어입니다.
입문자 - 초보자 - 중급 - 고급 이라고 봤을때
입문자에게는 무척 쉬운 언어지만(대충짜도 잘 돌아가니까요)
좀 무언가를 알기 시작해서 더 파고 싶어하는 초보자에게는
외우고 익혀야할 것이 많기 때문에 학습곡선이 완만한 것은 사실입니다.

기본기(펄이 제공하는 문법)를 익히고 나면 새로운 세상이 열리는데,
대부분 문법을 못떼고 끝내는 것 같아 아쉽군요.
뭐 그래도 더 깊이 알지 않아도 잘 쓰시기도 하구요.
(아는것만 알아도 쓰는데는 문제가 없으니...)

그리고 그런 분들 대부분이 문법을 다 익히 못한 것을
가독성이 떨어지는 오묘한 저세상의 언어(?)
정도로 표현하는 것도 아쉽구요.

해스켈이나 리습이나 보면(해당 언어를 잘 모르고 보면...)
오묘한 언어들은 많지만, 동경심 때문인지, 많은 책들에서 예찬을 해준 덕분인지...
유독 비난의 화살은 펄의 몫이더군요.

말씀해주신대로 가독성에 영향을 준다는 부분은 동의하지 않습니다만
그러한 이유로 가독성에 영향을 줄 수 있다는 eungkyu님의 주장은 존중합니다.

사람마다 생각은 다를테니까요~ :-)

P.S.
하지만 위에서도 여쭤봤듯이 알고 계시는 가독성이 좋은 언어는
어떤 것이 있는지, 정말 있긴 한것인지 사실 궁금하긴 합니다. ^^

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

Keedi Kim

----
use perl;

Keedi Kim

Perl은 $_을 쓰라고 강요하지 않았습니다.

글쓴이: aero / 작성시간: 화, 2009/01/13 - 2:23오후

입문서에 $_을 쓰는 예제가 있으니 이렇게 쓰면 그런가 보다 하고
그냥 따라쓰는지 모르지만 Perl은 $_을 쓰라고 강요하지 않습니다.
사용자의 선택에 맡기는 것 그것이 Perl의 철학이자 모토입니다.
이런 주어진 자유가 방종같고 스스로 통제가 힘들면 코딩 규약을
특정한 형태로 강제하는 Perl::Critic( http://search.cpan.org/perldoc?Perl::Critic )
같은 모듈을 쓰거나 특정 방법 및 스타일을 강제하는 것을 철학으로 하는
언어를 쓰면 됩니다.

말씀드렸다 시피 $_같은 기본변수가 Perl에만 있는 것도 아니고요.
Python도 Python shell에는 _ 라는 기본변수가 있는 걸로 알고 있습니다.

암묵적 생략문법과 $_같은 특수변수를 쓰고 안쓰고, 나아가 Perl을 쓰고 안쓰고는
개인의 선택 및 취향의 문제입니다.

$_가 단점만 있는 것이 아니라 $_를 잘 이해하고 쓴다면 분명 논리적 혼돈없이도
코드의 번잡성을 줄일 수 있는 이점도 분명 존재합니다.

네 말씀대로 사실

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 11:29오전

네 aero님 말씀대로 사실 간결한 50줄 내외의 코드(50줄이지만 엄청난 일을 하곤 합니다. :)에서
반복문안에서 문자열 처리, 특히 정규 표현식 처리를 할때는
사실 $_ 를 써도 코드는 무척 명쾌하고 깔끔합니다.

다른 분들께 묻고 싶네요. 아래의 코드는 어떠신가요? ^^
사용자가 명령행으로 넘긴 인자는 물론 파이프를 통해 표준입력으로 보내는 내용까지
처리해서 주석을 제외한 곳에서 단어를 찾는 간단한 예제입니다.

my @extracted_words;
while ( <> ) {
    chomp;
 
    next if /^COMMENT:/x;
    next if /^#       /x;
 
    push @extracted_words, $1 if /([a-zA-Z][a-zA-Z0-9_]*)/;
}

$_를 사용하고 <> 를 사용했다고 흑마법으로 보이시나요? :-)

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

Keedi Kim

----
use perl;

Keedi Kim

논란(?)

글쓴이: Scarecrow / 작성시간: 수, 2009/01/14 - 2:08오후

논란(?)의 핵심은...

while (defined( my $line = <ARGV>)) {
    print $line;
}

라고 작성하는 사람이 다른 사람이 작성해 놓은

while (<>) {
    print;
}

를 접할때 생기지 않나 생각됩니다.

그런 사람에게 너에게 뒤의 방법으로 쓰라고 강요하는건 아냐 라고만 할 수는 없을 듯합니다.

정확하게 같은

글쓴이: keedi / 작성시간: 수, 2009/01/14 - 2:26오후

정확하게 같은 코드는 아니군요.

while ( my $line = <> ) {
    print $line;
}

while ( <> ) {
    print;
}

저는 이 문제가 아래 문제와 비슷하게 느껴집니다.

log  10^3
   10

log 10^3

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

Keedi Kim

----
use perl;

Keedi Kim

Perl문법을 숙지하고 있다는 전제하에

글쓴이: aero / 작성시간: 수, 2009/01/14 - 3:26오후

Perl문법을 숙지하고 있다는 전제하에

둘의 차이는 단지 코딩 스타일의 차이입니다.
그리고 후자의 형태는 Perl문법이 이렇게 동작한다는 걸 보여주거나
one-liner나 간단한 처리를 위한 코드가 아니면 저렇게 쓸 일이 드물죠.

공동작업을 하는 단위이면 코딩 가이드라인을 정하기 마련이기 때문에
적절한 규칙을 정하면 되고요

자신이랑 전혀 관계없는 딴 사람이 짠 코드가 불편하게 느껴지는 경우가
Perl뿐만은 아닐 겁니다. 그것 때문에 코딩가이드 라인을 정할 때면 자신이
선호하는 스타일을 관철시키기 위해 마찰이 일어나지 않던가요?

심지어 "어떤 일을 해결하는 데에는 오직 하나의 방법이 있어야 한다."는 철학을 내세우는
Python도 Style Guide for Python Code( http://www.python.org/dev/peps/pep-0008/ )
같은 것들이 있죠. 한 가지 방법 뿐인데?

그리고

while (<>) {
    print;
}

이 코드에서 <>의 동작 방식이 <STDIN> 과 어떻게 다르며
그냥 print문만 적었는데 왜 최종으로 읽은 라인이 프린트
되는지를 정확하게 설명할 수 없으면 이 Perl코드를 가지고
Perl이 어떻다저떻다 평론을 늘어놓기 전에
Perldoc( http://perldoc.perl.org/ ) 을 보고
Perl 기본 문법부터 숙지해야 할 겁니다.

print while <>;

글쓴이: Scarecrow / 작성시간: 수, 2009/01/14 - 5:32오후

print while <>; 까지 등장한다면 어떨가요?

이건 단순히 "공백(들여쓰기 깊이, 괄호의 위치 등등)을 어떻게 할 것인가"등의 문제는 다른 언어에도 있다고 설명하기엔 이질감이 느껴지는거 같습니다.

그리고 만약 이런 코드를 접했을때 "이게 된다고?"라는 의문을 가지게 되어... 타이핑해서 직접 perl로 돌려보거나 혹은 "가만 있어봐... 여기서 이괄호가 생략됐고... 이건 여기로 옮길 수도 있고... 그리고 이 변수가 생략된거고... ...... 아~ 이것도 되겠네..."같은 생각을 했다면... 가독성이 떨어지는게 맞는게 아닌가 하고 개인적으로 생각합니다. 소스를 두고 그 소스가 표현하는 알고리즘을 읽는게 아니라 문법부터 추리해야 하니까 말이죠.

modifier 형식은

글쓴이: aero / 작성시간: 수, 2009/01/14 - 5:50오후

콘트롤 키워드가 뒤쪽으로 가는 postfix modifier 형식은
Perl의 de facto standard coding guide line인
Perl Best Practice-PBP( http://oreilly.com/catalog/9780596001735/ )
에 따르면

루프문에서 루프를 제어할 때 쓰이는

last if $i>1;

이런 경우 말고는 쓰지 마라고 가이드 라인이 있습니다.
Perl에서 prefix형식의 경우

if (조건) { 문장 }

C 처럼 { }를 생략할 수 없죠( 이것은 Perl의 엄격한 렉시컬영역 체크와 관련있습니다. )
하지만 간단한 루프 제어문 같은 경우

if ($i>1) { last }

보다

last if $i>1;

이 더 간결하고 가독성이 있기 때문에 이 경우는 그렇게 쓰도록
추천하는겁니다.

그리고 modifier 형식은 그 뒤에 하나의 표현식만 올 수 있기 때문에
굳이 괄호가 필요없습니다. 그것은 문법을 추리해야 하는 것이 아니고
http://perldoc.perl.org/perlsyn.html#Statement-Modifiers 문서를 보면

    if EXPR
    unless EXPR
    while EXPR
    until EXPR
    foreach LIST

이렇게 명시되어 있는 문법이죠.

반면 postfix 형식에 대한 문법의 정의도

    if (EXPR) BLOCK
    if (EXPR) BLOCK else BLOCK
    if (EXPR) BLOCK elsif (EXPR) BLOCK ... else BLOCK
   ..

이렇게 명시되어 있습니다.

그리고 PBP의 규칙을 채크하는 Perl::Critic( http://search.cpan.org/dist/Perl-Critic/ )
모듈을 깔고

print while <>;

를 채크돌리면

Postfix control "while" used at line 5, near 'print while <>;'.
  ControlStructures::ProhibitPostfixControls (Severity: 2)
    Conway discourages using postfix control structures (`if', `for',
    `unless', `until', `while') because they hide control flow. The `u
    and `until' controls are particularly evil because they lead to
    double-negatives that are hard to comprehend. The only tolerable u
    of a postfix `if' is when it follows a loop break such as `last',
    `next', `redo', or `continue'.
 
        do_something() if $condition;         #not ok
        if($condition){ do_something() }      #ok
 
        do_something() while $condition;      #not ok
        while($condition){ do_something() }   #ok
 
        do_something() unless $condition;     #not ok
        do_something() unless ! $condition;   #really bad
        if(! $condition){ do_something() }    #ok
 
        do_something() until $condition;      #not ok
        do_something() until ! $condition;    #really bad
        while(! $condition){ do_something() } #ok
 
        do_something($_) for @list;           #not ok
 
        LOOP:
        for my $n (0..100){
            next if $condition;               #ok
            last LOOP if $other_condition;    #also ok
        }

라고 친절히 설명해줍니다.

가이드라인을 머리에 외우고 있지 않아도 자세히 알려준대로
고치면 됩니다.

몇번 경고먹고도 쓰지 말라는 방식으로 코딩하는 사람은 없을듯.

실제 규모가 큰 Perl 오픈소스 프로젝트들에서는 소스 커밋전에
Perl::Critic 규칙체크를 의무화 하는 경우도 있습니다.

Perl::Critic모듈을 잘 사용하면 이건 이렇게 해라 찾아 다니며
말할 필요없습니다. 이거 돌려서 문제가 없을 때만 올려라 하면
끝이니까요.

perl소스에서도 쓰는거 같군요...

글쓴이: Scarecrow / 작성시간: 목, 2009/01/15 - 3:52오후

http://www.google.com/codesearch?q=%22print+while%22+lang%3Aperl

쓸 수도 있죠

글쓴이: aero / 작성시간: 목, 2009/01/15 - 5:09오후

print while ; 같은 postfix modifier문법이 추리를 해서 알아내야
할 문법이 아니라 문서에 명시적으로 설명도 나와있는건데 쓸 수도 있죠
하루종일 가르쳐줘야 이해할만큼 어렵다면 모를까...
가이드라인은 가이드라인일 뿐이니까요.

Linux Kernel이나 Perl같은 큰 프로젝트를 누가 혼자 만든 것도
아니고 역사가 10년도 넘고 lecacy 코드도 많은데 그런 걸
모든 코드가 똑같은 스타일이기를 기대한다는 자체가 무리죠. :)

저도 python의 for in

글쓴이: pung96 / 작성시간: 금, 2009/01/16 - 10:44오전

저도 python의 for in if를 봤을때, 이게 뭐야!! 이런 생각을 했습니다.
저는 print while <$filehandle> 이나 python의 for in if 이나
둘다 문법만 알면 간단히 이해할 수 있는 것이기는 하지만 for in if는 for in + if 처럼 보이기는 하는데
문법이 어떻게 구성이되서 for in if가 작동하는지 도저히 모르겠어서 여기저기 물어봤더니,,
결국 for in + if 가 이니라 for in if 한 문법이더군요,

결론은 전 for in if가 더 어렵습니다.

for in if라고 하시는

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 12:37오후

for in if라고 하시는 것은 아무래도 { x | x ∈ R, x ≤ 0 } 이런 수식을 그냥 파이썬으로 고대로 옮기는걸 얘기하시는거 같습니다. [x for x in R if x <= 0] 그렇다면 적절한 예는 아닌거 같습니다. 펄의 경우는 같은 예약어를 다른 목적으로도 사용하는 경우(예를 들어 C/C++의 static)가 아니라... 동일한 의미의 구문을 다른 방식으로 비틀어놓을 수도 있게 허용해 주는 것이니까 말이죠.

print while <>; 까지

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 11:13오전

Scarecrow:
print while <>; 까지 등장한다면 어떨가요?

솔직히 말씀드려서 전혀 문제되지 않습니다.

상기 코드를 이해 못한다는 것은 펄의 문법을 제대로 모르는 것일 뿐입니다.
그리고 펄을 배운다면 반드시 알아둬야하는 문법이구요.

post modifier 방식은 명백히 펄의 문법에서 지원하고
많은 사람들이 즐겨쓰는 방식입니다.

KLDP에 계시는 많은 프로그래머분들은 영어에 익숙하시고
영어의 중요성을 강조하시는 편인데,
언어학적으로 post modifier 방식은 영어식 표현에 99% 맞아 떨어집니다.

print while <>;

는

print (it = $_) while (ARGV or STDIN has something = <>)

로 그대로 1:1로 읽을 수 있습니다.

문법을 알고 영어를 안다면 print while <$fh> 는
오히려 가독성이 아주 좋은 표현일 뿐입니다.

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

Keedi Kim

----
use perl;

Keedi Kim

좀 너무 발끈하신것

글쓴이: JuEUS-U / 작성시간: 금, 2009/01/16 - 9:21오전

좀 너무 발끈하신것 같습니다...;;

다른 언어로는 길게 나올 코드가
단 몇줄, 아니 몇글자 단위로 짧게 나오면
잘 모르는 사람들 입장에선 불가사의한 마법일 수 밖에 없습니다. = _=)

특히 일부 코드 골프 식으로 짧게 줄인 코드들은
perl을 아는 사람들에게도 완전 고대의 경전입니다 =ω=)r;;;

계속 말이 돌고 도는군요

글쓴이: aero / 작성시간: 금, 2009/01/16 - 10:27오전

>다른 언어로는 길게 나올 코드가
>단 몇줄, 아니 몇글자 단위로 짧게 나오면
>잘 모르는 사람들 입장에선 불가사의한 마법일 수 밖에 없습니다. = _=)

코드골프나 임시로 쓰고 버릴 코드 말고 general하게 유지보수 되며
쓰이는 코드중에 그런 것들이 자주 보이던가요? 정말 이해 못하겠다는 것이면
어떤 것이 그런지 한 번 코드를 보고싶군요.

>특히 일부 코드 골프 식으로 짧게 줄인 코드들은
>perl을 아는 사람들에게도 완전 고대의 경전입니다 =ω=)r;;;

코드골프는 단지 재미로 하는 것 뿐입니다. 그것이 일반적인 프로그래밍
테크닉이라고 생각하시지는 않겠죠? 코드골프는 Perl만 하는게 아닙니다.
일례로 유명한 코드골프 문제인
99 bottles of beer ( http://codegolf.com/99-bottles-of-beer )
에 대한 perl,ruby,python 코드예를 보면

perl

sub b{$n=99-@_-$_||No;"$n bottle"."s"x!!--$n." of beer"};$w=" on the wall";
die map{b."$w,\n".b.",\nTake one down, pass it around,\n".b(0)."$w.\n\n"}0..98

ruby

99.downto(0){|b|puts "#{b==0?'No more b':"#{b} B"}ottle#{'s'if b!=1} of beer on the wall,
#{b==0?'No more':b} bottle#{'s'if b!=1} of beer.#{b==0?".. Go to the store and buy some more...\n99
bottles of beer.":"\nTake one down and pass it around, #{b-1} bottle#{'s'if b!=2} of beer on the
wall.\n\n"}"}

python

a,t="\n%s bottle%s of beer on the wall","\nTake one down, pass it around"
for d in range(99,0,-1):print(a%(d,"s"*(not d-1==0))*2)[:-12]+t+a%(d-1 or 'No',"s"*(not d-2==0))

Perl,Ruby,Python 좀 한다는 사람에게 저 코드를 보여주면 고대경전같이 보이는게 Perl뿐일까요?

인용:정말 이해

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 12:09오후

Quote:

정말 이해 못하겠다는 것이면
어떤 것이 그런지 한 번 코드를 보고싶군요.

근본적으로 기계도 이해하는걸 사람이 왜 이해를 못하겠습니까?
기계적으로 해석가능한 것인데...
"나는 이해가 되는데 너는 왜 이해를 못하느냐" 그런 문제가 아니죠...

사람이 그걸 이해하는데 "얼마나 오랜시간이 걸리느냐"가 문제죠.
문법을 모두 마스터하면 전부 기계적으로 해석이 가능하다의 문제는 아닌거 같습니다.

개인적으로 펄은 "작성하는 시간"을 줄이려고
"읽는 시간"을 늘려버린 언어라고 생각합니다.

하지만 소프트웨어 개발은 개발보다 유지보수가 중요하므로
펄의 그런방식은 개인적으로 좋은 방식이 아니라고 생각합니다.

조금 놀랍습니다. The

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 12:55오후

조금 놀랍습니다.
언어는 기계적으로 사용하는 것이라고 생각하고,
그렇기 때문에 문법을 익혀서 기계적으로 이해가되면 이야기는 끝난거죠.
기계적으로 이해가 되면 읽는 시간이 오래걸리지 않습니다.

문법을 알아서 기계적으로 이해가 되는데 뜻이 이해가 안된다면
그건 코드의 문제죠. 코드 퀄리티 말입니다.
코드를 이해할 수 없다면 두 가지 문제를 제기할 수 있습니다.
이것은 흑백논리의 차원이 아닙니다.

1. 형식(문법)을 이해 못하냐? (읽을 수는 있습니다.)
2. 뜻을 이해 못하냐? (읽지만 뭔 소리지인지 모르는 것입니다.)

1번이 기계적으로 되었는데 2번이 안된다면 더 할말이 없는거죠.
그리고 2번의 경우는 두 가지입니다.

1. 코드를 개발 새발로 썼던가...
2. 코드는 정갈한데 내가 그 알고리즘과 자료구조, 로직을 이해할 수준이 안되던가..

The Internet Movie Database
Slashdot
Booking.com
Vox.com
LiveJournal
HiveMinder
Amazon

수년동안 발빠르게 개발하고 확장성있게 유지보수하고 있는 대형사이트들이
(일부러 아실만한 사이트들만 적었습니다)
읽는 시간을 늘려버린 유지보수에 좋지 않은 언어를
사용하고 있다고 생각하시는 것은 아니시겠죠? :-)

P.S.
그들이 코드를 공개하지는 않았지만
사용하는 코드가 흑마법일 것이라고 생각하지 않습니다.
하지만 문법을 기계적으로 해석하지 못하는 사람에게는
무슨 마법 주문서로 밖에 보이지 않을 것입니다.

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

Keedi Kim

----
use perl;

Keedi Kim

이해를 못한다고 한적은 없습니다.

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 12:57오후

그걸 이해하는데 "얼마나 오랜시간이 걸리느냐"가 문제라고 했습니다.

어셈블리도 이해를 못하는게 아니라
읽는데 오래걸릴뿐이죠.

질문입니다. 펄보다

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 3:01오후

질문입니다.

펄보다 읽는데 오래 걸리지 않는 언어는 어떤 것들이 있나요?
그리고 정말 오래 걸리지 않는 것은 확실한가요?
마지막으로 펄이 정말 읽는데 오래 걸리는 것도 확실한가요?

XXX라는 언어는 AAA라는 feature, BBB라는 feature, 등등을 가지고 있기 때문에 이래서 좋고 저래서 좋고... 이런 것에 대해서는 수긍할 수 밖에 없거나 수긍하지만...

XXX라는 언어가 YYY라는 언어보다 ...하다 이런류의 상대적 비교는 fact가 들어가기도 어렵고 추측으로만 논리가 전개될 수 밖에 없다고 생각합니다. 그러지 않으려면 fact가 들어가야하는데, 읽는데 오래 걸린다는 주장은 다분히 감상적인 의견이라고 생각합니다.

P.S.
정말 어셈블리를 오래만 걸리면 다 이해하시나요?
정말정말 긴 시간을 주면 다 이해할 수 있다는 이론적인 말씀이시죠?

한눈에 읽고 이해하고 말고의 context에서
조그마한 바이너리를 이해하는데 몇시간~몇일이 걸려서
이해하는 수준의 시간이라면 비교는 좀 어울리지 않는군요.

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

Keedi Kim

----
use perl;

Keedi Kim

그렇게

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 3:08오후

그렇게 주관적이라고는 생각지 않습니다.
perl의 철학만 봐도 그것은 어느정도 나타나니까요...

같은 의미를 가진 여러다른 표현...
간단한 기호로 간략화...

작성할때는 표현방식에 대한 자유도가 높고
단어 대신에 기호를 쓰면 타이핑 시간도 줄고
"가끔 당신의 보스가 금요일밤 9시에 급한 용무를 줄때 쓰게 된다."

하지만 읽을땐
나열된 기호의 의미를 파악해야하며
"아~ 이런식으로 써도 되는거구나"하며 자신이 평소 잘 쓰지 않던 표현방식은 유추도 해야 합니다.

모범 답안 이외의

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 3:56오후

모범 답안 이외의 approach로 수학 문제를 풀이하는 것에 대해서는 어떻게 생각하시는지요?

무수히 많은 직사각형으로 쪼개서 각각의 면적의 시그마로 문제를 푼다면?
lim 무한대 + normal expression 으로 문제를 푼다면?
다른 사람이 integeral을 사용해서 문제를 푼다면?
또 어떤 사람은 또 다른 방법으로 적법한 수학적 표현으로 써서 푼다면?

그렇다면 수학식을 일종의 언어라고한다면(실제로 그렇게 말할수 있죠)
수학식도 가독성을 포기했다고 생각하시는지요?

그렇다고 주장하신다면 그 연장선상에서 펄은 가독성이 떨어지는 언어입니다.

아마도 마지막 댓글이 될 것 같습니다. :)

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

Keedi Kim

----
use perl;

Keedi Kim

해결방법(알고리즘)이

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 4:03오후

해결방법(알고리즘)이 여럿 있을 수 있다는 걸 얘기하는게 아닙니다.
perl언어의 특성에서 나타나는 "동일한 의미의 여러다른 표현"을 얘기할 뿐이죠.

이렇게 적으나 저렇게 적으나 수학풀이법이 바뀌는게 아니라
수학풀이법은 완전 동일한데 사람마다 적는 문체가 다를뿐입니다.

경우에 따라선
"나랑 다른 방법인지 알았더니 막상 읽어보니 내말이랑 같은 말이네"라고 느낄 수도 있을 겁니다.

제가 예시로 든

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 4:14오후

제가 예시로 든 적분 알고리즘이 달랐던가요?
알고리즘은 100프로 동일합니다만.

말씀하신대로 perl언어의 특성에서 나타나는
동일한 의미의 여러 다른 표현입니다.
proof of concept 이냐? 완전한 식이냐?
verbose 하냐 compact하냐 의 차이일 뿐입니다.

그리고 펄에서 동일한 표현의 여러 다른 표현을보고
실제로 문체가 다르다고 표현합니다.
(펄은 여느 언어들과는 다르게 Perl Culture 를 가지고있는 언어입니다.)

혹시 제가 적분에 대해서 잘못 이해하고 있는것인지요?

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

Keedi Kim

----
use perl;

Keedi Kim

알고리즘에 대한

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 4:25오후

알고리즘에 대한 이야기는

Quote:

모범 답안 이외의 approach로 수학 문제를 풀이하는 것에 대해서는 어떻게 생각하시는지요?

에 대한 질문에 그 의미를 분명히 했을 뿐입니다.

이 비유가 적절할지는 모르겠지만...
구분구적법은 전혀 이해하지 못하고 적분 공식만 평소 사용하던 사람에게
구분구적법을 보여주면 "아~ 이렇게 해도 되네"하며
파악하는 시간이 걸린다는 부분을 얘기했을뿐이죠.
하지만 그 시간은 새로운 알고리즘을 익힌 시간이 아니라
언어의 다른 표현방식을 익힌 시간입니다. :)

return 0;

:) 1; ---------------------

글쓴이: keedi / 작성시간: 금, 2009/01/16 - 5:03오후

1; # :)

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

Keedi Kim

----
use perl;

Keedi Kim

그러니깐 내 생각은 이렇다 말만하지 마시고

글쓴이: aero / 작성시간: 금, 2009/01/16 - 12:59오후

그러니깐 내 생각은 이렇다 말만하지 마시고
직접적인 예를 들어서 이런 코드는 어떻더라고 말씀해주시면 좋겠네요.

그런류의 논리를 FUD라고 하는거죠.

>하지만 소프트웨어 개발은 개발보다 유지보수가 중요하므로
>펄의 그런방식은 개인적으로 좋은 방식이 아니라고 생각합니다.

이게 사실이라면 여태까지 어느 언어도 이루지 못한 규모의
정교하게 테스팅되고 유지/관리/보수 되는 Perl모듈 저장소인
CPAN(http://search.cpan.org)이 존재할 수 있었겠습니까?

유지 보수말이 나와서 말인데 CPAN에 있는 Perl모듈중 하나인
Moose ( http://search.cpan.org/dist/Moose/ )
의 자동테스팅 리포트결과를 보여주는
http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Moose+0.64
http://www.cpantesters.org/show/Moose.html#Moose-0.64
를 보시길 바랍니다.

이 만큼 다양한 플렛폼에서 정교하게 테스팅되고 리포팅되는 경우가
다른 언어에도 있다면 한 번 보고싶군요.

그것은 본인이 직접 설명해 주시지 않으셨던가요?

글쓴이: Scarecrow / 작성시간: 금, 2009/01/16 - 1:04오후

그것은 본인이 직접 설명해 주시지 않으셨던가요?

Quote:

실제 규모가 큰 Perl 오픈소스 프로젝트들에서는 소스 커밋전에
Perl::Critic 규칙체크를 의무화 하는 경우도 있습니다.

펄의 다양한 표현방식을 금지하였으니 가능하지 않나 생각됩니다.

펄과 C++의 템플릿

글쓴이: 죠커 / 작성시간: 금, 2009/03/13 - 2:48오후

펄과 C++의 템플릿 프로그래밍에 대한 FUD들이 많아 한마디 적어봅니다.

미분과 적분을 모르는 사람에겐 인테그랄 표시가 가독성을 해치는 요소로 보이겠지만 미분과 적분을 이해한 사람에겐 생산성을 높여주는 표기가 됩니다.

모든 펄의 코드와 C++ 템플릿 프로그래밍이 위의 조건에 만족하는 것은 아니지만 상당수는 만족합니다.

- 죠커's blog / HanIRC:#CN

pascal은 잊혀진

글쓴이: 비행소년 / 작성시간: 수, 2008/12/24 - 10:56오전

pascal은 잊혀진 언어였나요 -_-??

높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ

흑흑..

글쓴이: 샘처럼 / 작성시간: 수, 2008/12/24 - 11:03오전

취미 삼아 object pascal (정확히는 delphi)를 만지고 있는 잊혀진 고대종교를 사용하고 있는 셈이군요.
( "만지고"있는 것이지 "사용하고"있는 것은 아닙니다. **)

글쓴 분이 Java를

글쓴이: youlsa / 작성시간: 수, 2008/12/24 - 12:49오후

글쓴 분이 Java를 싫어하시는 분인가 보네요. 기독교 근본주의라니... ㅋㅋㅋ-

C와 C++의 관계가... 유대교와 이슬람교의 관계... 절묘한 표현인거 같습니다. ^^

무엇보다 Python이 Humanism이란거에 저도 한표...

=-=-=-=-=-=-=-=-=
http://youlsa.com

파이썬이

글쓴이: Tony / 작성시간: 화, 2009/01/13 - 11:19오전

파이썬이 휴머니즘이란건.. 반대 -_-;;;

그저께부터 VB로 개발

글쓴이: snowall / 작성시간: 목, 2008/12/25 - 9:28오전

그저께부터 VB로 개발 시작했는데...-_-
전 satanism에 빠져버린 거군요 OTL

--------------------------
snowall의 블로그입니다.
http://snowall.tistory.com

피할 수 있을때 즐겨라! http://melotopia.net/b

댓글 중에 재밌는 말이 있네요

글쓴이: gracesky / 작성시간: 화, 2008/12/30 - 1:57오후

After 4 years of nothing but Perl programming, I've collected my share of Voodoo dolls.

component를 자유롭게 쓰는 경지에 이르면 이렇게 말할 수도 있겠네요.

'밥먹었니?' 를 구지

글쓴이: Tony / 작성시간: 화, 2009/01/13 - 10:29오전

Cafeteria Christianity

글쓴이: ahsan / 작성시간: 화, 2009/01/13 - 11:50오전

Cafeteria Christianity <-- 이게 무슨뜻인가요?

모두가 한번쯤 사용해 봄직한 비주얼베이직이 사탄니즘이라니 너무했다.

비주얼 베이직은

글쓴이: lifthrasiir / 작성시간: 화, 2009/01/13 - 12:10오후

비주얼 베이직은 일단 6 버전은 망했고 .net은 C#에 먹혀 들어가서 ASP.net에나 쓸 법한(반쯤 농담이지만 그만큼 입지가 좁아졌다는 의미에서...) 언어가 되었으니 얻어 맞을 만도 하죠.

Ruby에서 $_ 를

글쓴이: t3RRa / 작성시간: 수, 2009/01/14 - 1:59오후

Ruby에서 $_ 를 베껴갔다고 그것이 좋다는걸 나타내는건 아닙니다.
참고로 Ruby의 창시자 Matz는 이미 여러해 전 오레일리사와의 인터뷰에서
(잘 기억은 안나지만 아마 Ruby를 처음부터 다시 짜게 된다면이란 질문이었나..)
$_ 같은 것들을 뺐었으면.. 이라고 한거 같더군요.
이유는 가독성때문이었을겁니다.;

An Interview with the

글쓴이: keedi / 작성시간: 수, 2009/01/14 - 3:57오후

An Interview with the Creator of Ruby 입니다.

저도 해당 인터뷰를 예전에 꼼꼼히 읽어봤었습니다.
하지만 Matz가 가독성 때문이라고 하지는 않았습니다.

스타일이 마음에 안든다(ugly style variables)고 했죠.
Matz가 $_ 스타일로 변수 짓는게 자기가 보기엔 추해보인다고 한거죠.
스타일 이야기까지 나왔으니 미학적인 관점에서 접근해야하나요? :-)

스타일과 가독성은 엄연히 다릅니다.
단정적으로 말씀하시지는 않았지만
아 다르고 어 다른데 정확한 정보가 좀 아쉽군요...
(다른 분들이 보시면 또 Matz도 그건 가독성이 떨어진데~ 라고 할텐데.. :-( )

Stewart: I gather you had worked with both Perl and Python before creating Ruby. What bits of Perl did you incorporate in Ruby?

Matz: A lot. Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff. I used too much I guess. I shouldn't have inherited $_, $&, and the other, ugly style variables.

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

Keedi Kim

----
use perl;

Keedi Kim

ruby가 $_을 베껴간 것은

글쓴이: aero / 작성시간: 목, 2009/01/15 - 3:06오후

ruby가 $_을 베껴간 것은 one-liner 때문인 것 같군요
one-liner를 위한 ruby의 command line 옵션도 Perl의 대부분을 베껴 갔습니다.

Perl one-liner( http://sial.org/howto/perl/one-liner/ ) 와 비교하여
HANDY ONE-LINERS FOR RUBY ( http://www.fepus.net/ruby1line.txt )
을 보시면 제 말을 이해하실 겁니다.

Matz의 말은 "정신없이 베끼다가 정신 차리고 보니 후회된다."라고 들리는군요.
$_ 좋다 싫다를 떠나서 만약에 Perl에서 베껴간 그런 특징들을 빼면
one-liner라고 하기도 머쓱한 Python one-liner ( http://wiki.python.org/moin/Powerful%20Python%20One-Liners )
처럼 될 겁니다.

그리고 $_, $. 이런 특수변수들은 English모듈 ( http://perldoc.perl.org/perlvar.html )을 쓰면
$ARG, $INPUT_LINE_NUMBER 등의 긴 이름으로 쓸 수 있습니다. 하지만 많이 쓰는 것이 몇 개 안 되고 뻔하기 때문에
타이핑을 많이치는 수고를 들여서 굳이 저렇게 쓰지 않을 뿐이죠.

Perl이 one-liner에서 강력한 이유가 암묵적생략문법과 기본변수들 때문입니다.
이것들은 그 동작을 정확히 이해한다면 쓰는데 문제가 없습니다. 오히려 간결하고요
동작 방식을 잘 모르더라도 snippet처럼 perl one-liner를 예제를 보고 베껴쓰는 사람들도 많죠...

이런 특징들은 규모가 큰 Perl 프로그램에서는 명확한 경우가 아니면 쓸일이 없거나 쓰지 않습니다.
편리성을 위해 마련해놓은 일부 특징을 전체적인 모습인양 얘기하는 사람들이 문제죠.

C는 아마도 유대교일

글쓴이: sectune / 작성시간: 수, 2009/01/14 - 4:49오후

C는 아마도 유대교일 것이다. 그것은 오랜 역사를 지니고 있고 또 엄격하다. 하지만 그 법은
전세계에 널리 알려져 있고 또 존중받고 있다. 딜레마는, 누구도 이 종교로 개종할 수 없다는 것이다.
당신은 종교생활을 이 종교로 시작하던가, 아니면 이 종교가 광신적이라고 생각하던가 둘 중 하나다.
또한, 일이 잘못되면, 많은 사람들이 세계 자체가 잘못되었다고 비난할 것이다.

자바는 기독교 원리주의가 될 것이다. 자바는 이론적으로 C에 기반했지만, 많은 오래된 규칙들을 무효화
했기 때문에 더 이상 원래의 것과는 더이상 같다고 느껴지지 않는다. 대신, 자바는 자신들만의
엄격한 규칙들을 추가했고, 이것은 후세 사람들에게 원본보다 더 기본적인 것이라 느껴지게 한다.
이들이 세계에서 최고의 언어라는 것은 분명하지만, 그들은 이에 동의하지 않는 것들을 다 불태워버릴
기세다.

PHP는 까페테리아식 기독교이다. 자바와 웹시장에서 싸우고 있다. 그들은 C와 자바에서 몇몇 개념을
가져왔지만, 그중 진짜 딱 입맛에 맞는 것만 가져왔다. 아마도 이 언어는 다른 언어들처럼 조리있지는
않겠지만, 적어도 적어도 훨씬 더 자유롭고, 모든 핵심 아이디어들을 적어도 표면상으로는 지켜준다.
또한 '지옥으로 가라'라는 개념도 사라졌다. (C와 자바의 끔찍한 부분을 말하는듯)
(까페테리아식 기독교란, 까페테리아에서 입맛에 맞는 것만 골라 먹듯이, 기독교에서 입맛에 맞는 것만
받아드리는 개인적인 기독교라는 의미라고, 위키디피아는 말하고 있네요)

C++은 이슬람이다. 이것은 C를 받아들였지만 그 법을 따르는데 그치지 않고, 많은 새로운 법을 만들어
그 위에 덧씌웠다. 매우 다재다능해서 어떤 것의 기초로도 쓰일 수 있다; 엄청나게 포악한 것에서부터
아름다운 예술 작품까지. C++의 신봉자들은 이것이 절대적인 우주언어라고 확신하고 있는데,
이에 동의하지 않는다면 그들의 분노를 자아낼 것이다. 또한, 만약 이 언어나 그 설립자를 모욕한다면,
아마도 죽을때까지 과격한 근본주의자들에게 쫓길 것이다.

C#은 모르몬교이다. 처음 보면, 이것은 자바하고 똑같아 보이지만, 가까이에서 보면 하나의 단체에
의해서 지배되고 있고, (자바의 측면에서 본다면 이것은 사악한 짓이다) 또 많은 신학적인 개념이 꽤나
다르다. 만약 자바의 모든 추종자들이 당신이 이것을 따른다는 것을 눈치채고 엄청난 반대를 하지만
않는다면, 당신은 이 종교가 꽤 괜찮다는 생각이 들 것이다.

Lisp은 선불교이다. 거기에는 문법도 없고, 핵심이 되는 도그마도 없으며, 복종해야할 신격도 없다.
모든 우주는 당신이 닿는 곳이다 - 그것을 움켜잡을 수 있을 만큼 충분히 교화됐다면 말이다.
어떤 사람들은 이것은 언어도 아니라고 말한다; 다른 이들은 말이 되는 유일한 언어라고 말한다.

Haskell은 도교다. 다른 언어들과는 많이 달라서 많은 사람들은 어떻게 이것으로 유용한 것을 만들어
낼 수 있는지 이해도 못한다. 이 신봉자들은 이것이 지혜에 이르는 진정한 길이라고 믿지만,
그 지혜는 대부분의 유한한 존재들에게는 얻을 수 없는 것이다.

Erlang은 힌두교이다. 이것은 유용한 일에 쓸 수 있을 것 같이 보이지 않는 또하나의 이상한 언어이지만,
다른 현대 언어들과는 달리, 동시에 현존하는 다중신격을 가지고 있다.

Perl은 부두교다. 이해할 수 없는 비밀 주문이 연달아 나오고, 염소피를 필요로 하며 영원히 영혼이
더럽혀진다. 가끔 당신의 보스가 금요일밤 9시에 급한 용무를 줄때 쓰게 된다.

Lua는 Wicca다. 범신론의 언어라 쉽게 다른 문화와 장소에 적응한다. 코드는 매우 자유롭고,
다른 전통 언어의 사용자들에게는 마법처럼 보일 테크닉들의 사용이 허용된다. 달과 강하게 연결되어 있다.
(Lua가 Luna와 스펠링이 비슷하다고 해서 이렇게 말하는 모양이지요)

Ruby는 신-이교도이다. 다른 언어들과 아이디어들의 혼합이며 언어로 식별되어야 하는 개념들이 뭉쳐져
있다. 그 신봉자들은 빠르게 늘어가고 있고, 많은 사람들은 그들을 의심스럽게 바라보고 있지만,
그들은 남을 해칠 의도가 없는 좋은 사람들이다.

파이썬은 휴머니즘이다. 이것은 간단하고, 그다지 엄격하지 않으며, 당신에게 요구되는 것은 그저 상식을
따르는 것 뿐이다. 많은 신자들은 다른 언어들이 부과하는 짐들에서 풀려났다고 이야기하고,
프로그래밍의 즐거움을 재발견한다. 이것은 슈도코드 (유사 코드)의 한 형태라고 이야기하는 사람도 있다.

코볼은 고대 이교도이다. 황량한 지역을 지배했으며 당시에는 매우 중요했지만, 요즘은 다행히도 거의
죽은 거나 마찬가지다. 비록 이 신들이 요구하는 의식을 치르기 위해 많은 피해가 있었지만,
오늘날에도 이것이 살아있어야 한다고 주장하는 이들이 있다.

LOLCODE는 파스타교다 (플라잉 스파게티 몬스터를 믿는 종교 - 당연히 뻥입니다) 비전의 종교이고,
인터넷에서 태어난 믿음이며, 개발과 유포를 위한 여러 노력에도 불구하고 아무도 진지하게 생각하지 않는다.

비주얼 베이직은 사타니즘이다. 이것을 제외하고는 사탄숭배자들에게 영혼을 팔 방법이 없다.