Perl 6.0 개발 소식

geekforum의 이미지

흠....외국은 몰라도 우리나라에서는 펄의 인지도가 형편이 없죠. 특히, 너무 복잡하다고 싫어하는 사람까지 있을 정도이니....

그런데, 지금 펄 6.0이 개발중이라고 하는군요. 파이썬, 자바와 같은 수준의 보다 완벽한 객체지향을 구현하기 위하여 완전 개조가 진행 중이라고 합니다.

class구문이 생기고, C에서의 switch-case에 해당하는 given-when구문도 생긴다고 하는군요. 클래스의 property도 정할 수 있구요.

기존 구문중에 쓸모 없이 복잡하기만 했던 것들은 다 없애버린다는군요. 단, 펄 5.x 호환모드로도 작동이 가능하구요. 그리고 이제는 자바나 C#과 같은 바이트코드/버추얼머신 형식의 언어로 바뀐다군요.

지금, 펄 6.0의 버추얼머신(패럿이라고 합니다만)을 이용해서 C#과 자바를 구현하는 프로젝트도 진행중이라는군요.

다음은 펄 6.0의 데이터를 바탕으로 한번 써본 예제 코드입니다. -_-;;

class MyPerlClass is static //클래스 설정...Property까지...
{
attr $xxx=1; //Class attribute...간단한 initiation은 여기에다 쓰는 듯 합니다...
my $stupid_string;
method stupid_strings { //메쏘드죠...
do something..
};
}

class Derived is MyPerlClass //상속
{ 어쩌고 저쩌구...}

my $MPC = new $MyPerlClass; //클래스 사용

$MPC.stupid_string="I am STUPID!!!"; //이젠 객체에 접근하는데 ->가 아닌 . 이 사용됩니다...
$MPC.stupid_strings;

print $MPC.stupid_string.length; //자바, 파이썬과 같은 일반 변수까지도 객체가 되었습니다...

....

given $switchvalue {
when "xxxx" {....};
when "yyyy" {....};
.....
}; //이게 진짜로 맞는지는 모르겠습니다만...

과연 펄 6.0이 쓰러져(?) 가는 펄 가문을 일으켜 세울 수 있을련지요. 개인적으로 펄을 좋아하는 탓에.... -_-;;

익명 사용자의 이미지

oop와 portable 장점을 강조해서, 새로만들다 싶이한다면, 그거 perl 맞나요? perl이란 명칭을 달고, 다른 패러다임을 표방한다면, 그야 말로.. -_-;;;java도 현재 진행되는 상황을 보면, 별 다를 바 없다는 생각도 들지만, 이런 정도는 아닌데... 어쨌든 확정된 내용인지는 모르겠지만, 좀 어이없다 싶네요..;;

마치 처음 java의 개발생산성이나 초기느릿한 vm에 대해서 논할때, 혹자가 java의 java다움을 버리고, c와 비슷한 notation으로 돌아가고, vm방식을 버리자고 말했던 것과 다를바 없네요..

익명 사용자의 이미지

호빠냐..

익명 사용자의 이미지

Perl6에서 핵심은 CLR로서의 의미입니다.

Perl6를 이야기 할때 마이크로소프트의 .NET을 함께 거론 해야 된다고 생각을 합니다. 그리고 Perl6에서 C、Java와 C#에 관해서는 그 언어의 코드를 생성할 수 있다는 의미입니다. 이것은 패럿 런타임으로 작동하는 코드(실질적인 의미에서는 패럿 어셈블코드)를 펄로 파싱(번역)해서 쉽게 다른 언어의 코드를 생성할 수 있다는 뜻입니다. 컴파일할 때에 파서를 선택함으로서 Python의 syntax를 사용할 수도 있게 될것이라고 생각합니다. 이것은 마이크로소프트의 .NET과 비슷합니다.

.NET 프레임웍의 공통언어 런타임(Common Language Runtime, 이하 CLR)은 [주변 디바이스를 포함하는 컴퓨터자원 모든 것을 추상화한 가상 머신]이며 Windows 이외의 플랫폼으로도 이식될 가능성이 있다고 봅니다. 현재 ActiveState에 가면 이미 .NET프레임 서포트를 표명하고 있고 .NET페이지에는 Perl.NET과 Python.NET의 항목이 있습니다. .NET을 서포트하는 Python은 이미 다운로드할 수가 있고 Perl6 개발과정에서 CLR과 같은 것이 Unix상에서 어떻게 구축이 될것인가가 실질적인 초점이 되지 않을까합니다.

실제로 CLR 그 자체를 펄 커뮤니티가 Unix로 이식할 가능성은 드믈고 Perl6 자체로 존재하는 모든 언어의 플랫폼이 될것이 아닌가하는 생각입니다. 다른 언어를 취급하기 위한 기반을 확장하는 것입니다. 진정한 의미에 있어서의 범용언어로서 새롭게 태어나려고 하는 것입니다.

CLR기반에 관련한 기술중에 하나가 멜보른 대학의 선언형 논리 프로그래밍 언어라는 Mercury프로젝트입니다. Mercury는 WindowsNT(Cygwin반)뿐만이 아니라 Linux나 Solaris등 Unix 패밀리에서 작동합니다. 그 외에도 많은 언어를 Microsoft에서 연구하면서 CLR을 만들어 온것 같습니다. CLR이 Unix로 이식된다면 MS Office가 Unix상에서 작동이 되는 등 여러 방면으로 전개가 될 것입니다. 스크립터에 따라서는 자신의 주특기 언어로서 모든 것을 할수도 있고 다른 언어도 배울 필요가 없는 시대도 올 것이라고 생각을 합니다.

Perl6(코드명, Parrot)은 이런 의미에서 일종의 CLR입니다. Parrot 어셈블러에 의해서 컴파일되면 어떤 언어에서도 작동이 된다는 이야기이고 다른 언어가 Parrot을 서포트 할 것인가 아니면 Parrot이 다른 어떤 언어를 서포트(일부 파서로 다른 언어의 코드로 변역됨)할 것이가 주목되는 점이기도 합니다. 그리고 Parrot는 아주 빠르게 실행이 되기 때문에 그 고속성을 생각하면 스크립언어(인터프리터)로서의 잇점도 아주 크다는 이야기 입니다. 또 Parrot는 실행 스피드가 빠르다는 점이 미력이기도 합니다. 원리적으로 이야기를 하자면 Parrot상에서 움직이는 언어(패럿 어셈블 코드를 생성할 수 있는 언어)를 하나 익히게 되면 만능언어가 된다는 뜻이기도 합니다. 그래서 더욱더 GUI에 관해서도 어떻게 될지가 아주 흥미로운 부분입니다. 펄에서는 이미 TK로 GUI를 서포트하고 있는데 아직 Parrot는 현재로서는 펄 런타임 머신의 성격도 강합니다.

이러한 점에서 현재의 Perl6는 자바진영이나 마이크로소프트 진영등에서도 아주 관심있게 지켜 보고있고 펄 유저들에게도 큰 관심사입니다. 서로 생각과 철학이 다르기 때문에 서로 다른 방법으로 언어와 환경간의 장애를 극복하려고 노력을 하는 것이라고 생각을 합니다. 객체지향보다는 이 점이 Perl6에서 가장 주목받는 핵심이라고 생각합니다.

RisaPapa

익명 사용자의 이미지

Larry Wall이 Perl5가 개인적인 rewriting이었다면 Perl6은 Perl커뮤니티
에서의 재작성이 되었으면 한다고 하더군요.. Perl6은 언어적인 펄에 대한 부분이고
패럿은 펄의 VM에 대한 프로젝트이더군요.
원래 토바즈라는 C++으로 구현하려는 프로젝트가 있었지만 래리에게는 맘에 안들었나 봅니다. (perl.com에 토바즈 기사가 있긴합니다만.)

패럿에 보면 jako와 cola라는 작은 언어가 있는데 그 패럿 어셈블리 코드를 만드는 부분을 보면 perl5으로 언어 문법을 파싱하더군요..

스택기반이 아니라 레지스터 기반이고 특히 흥미로운 점은 패럿 어셈블리어 코드를 머신 코드 뿐만 아니라 .NET이나 JVM
바이트 코드로 만들수도 있다고 합니다..

언어적인 부분도 {}가 있는 Python문법이나 기호가 없는 Perl등을 쓸수 있고
이것에 대한 바이트 코드도 .NET이나 JVM코드으로의 전환이 쉽다고 하더군요..

요즘 가장 흥미있어 하는 프로젝트 입니다.

솔직히 말해 펄 코어그룹은 다른 그롭보다 통 크게 논다는 생각도 합니다만..:-)
(개인적인 생각합니다...)

패럿의 경쟁상대는 68000에물레이터이라는 군요..;

까막_의 이미지

음.. Perl6는 다른언어로 생각해도 무방할듯 합니다.
Parrot엔진이 Perl5도 지원한다고 하니
Perl5시절 코드가 익숙한 사람은 그냥 Perl5시절 문법쓰면 되는거 아닌가요?
--
Let's be engineers!

Let's be engineers!

까막_의 이미지

흘...

Perl6보다 Parrot엔진이 더 기대되는 군요.

Python이나 Ruby등의 언어를 지원한다는걸로 봐서는..
아무래도 스크립트를 많이 생각했나봅니다.

Register기반이라는데.. 뭔진 잘 모르겠지만, CPU비스무리하게 만든다는거 아닌가요?(아아 어셈블리가 가물가물)
흠...

Perl은 원래 그닥 좋아하는 언어가 아니라서리..
Parrot이 되면 JVM이나 .Net으로 스크립트 언어들의 이식이 쉬워지겠네요.

그렇게 되면, 좀 편해지려나...
아니면 Parrot Code로 컴파일 된걸 Native로 바로 바꾼다던지 ㅎㅎ

쩝.. 잡생각 해봤습니다 :)
--
Let's be engineers!

Let's be engineers!

Paladin의 이미지

.Net의 영향이라고 하면 "왠 뚱딴지 같은 소리냐"하고 화낼 분들 많겠군요. 허나 그외에는 아무리 생각해도 Perl가 OOP를 지원하는 이유를 알기 어렵습니다.

실재로 Perl for .Net이 개발되어지고 있으며, .Net 위에서 작동할려면 최소한의 OOP 개념은 있어야 하겠지요.

Visual BASIC 언어도 수많은 VB 매니아들의 반대를 무릅쓰고 VB에 OOP를 삽입했죠. 지금의 VB는 VB++이라고 해도 어울릴듯.

그리고 개인적으로 전망하건데, Perl에 OOP를 가미하고, .Net Platform에서 작동한다면 꽤 인기를 끌 것 같습니다.

그리고 Text 기반이 아닌 창 기반의 인터페이스에서 작동될려면 Event에 반응하는 메쏘드를 표현하는 Delegator(C나 C++에서 보면 함수 포인터) 구문이 필요할 것 같군요.

윈도우 계통의 언어들에는 윈도우 OS가 Event-Driven 방식이라 Delegator가 잘 발달되어 있는 반면, Unix/Linux 계통에서는 OS 운영 자체가 Shell 위주라서 그런지 너무 스크립트 위주로 발달되어 있군요. 나만의 느낌인가....

아무튼간에 Perl을 이용해서 Application 프로그램을 한번 만들어 보고 싶군요.

9th Paladin

익명 사용자의 이미지

> .Net의 영향이라고 하면 "왠 뚱딴지 같은 소리냐"하고 화낼 분들 많겠군요. 허나 그외에는 아무리 생각해도 Perl가 OOP를 지원하는 이유를 알기 어렵습니다.

객체지향 프로그래밍은 무척 오래된 개념이며 또한 무척 인기있는 개념이기도 합니다. 저는 왜 Perl의 OOP 지원이 .Net과 연결이 되는지 이해가 안되는군요. Perl의 특성상(같은 일을 하는 데에는 여러가지의 방법이 있다...던가요?) 여러가지 프로그래밍 기법을 지원하는 것은 아주 당연한 일입니다.

cjh의 이미지

Perl 5부터 이미 OOP를 지원하고 있습니다. CPAN의 절대다수의 모듈은
모두 클래스고요. 구현상의 난점을 제외하면 이미 Perl은 OO언어라고도
할 수 있습니다. 단 기존의 perl style을 유지하기 위해서 언어가 조금
더러워지면서 호환을 유지했다는 생각은 듭니다만.

함수 포인터의 개념도 이미 지원하고 있습니다. anonymous
function도 있고, 특정 이벤트 호출을 위한 callback같은것도
(GUI모듈에 대부분 있는) 많이 쓰이고 있고요. sort나 map 구문이
그렇고, 여러 모듈의 에러 처리 방식이 그렇죠.

--
익스펙토 페트로눔

Paladin의 이미지

그렇군요. 그러고보니 이제 될건 다 되네요.

조금 전에 perl 6.0 관련 사이트에 가니깐 DLL에 있는 함수도 부를 수도 있더군요. 난잡해 보일정도로 특이하긴 하지만. exception 처리하는 것도 있던데, 하는걸 보니 마치 10년전 BASIC 언어에서 on error goto를 보는 기분이 들더군요. ^^;

암튼 여러모로 perl의 본질적인 느낌은 이제 사라지는 것 같군요. 허나 OOP를 지원하는 perl이 나름대로 인기를 끌 것같기는 합니다. perl는 perl만의 표현력이 있으니.

9th Paladin

익명 사용자의 이미지

방준영(junyoung@netbsd.org)입니다.

한가지 궁금한 점이 있습니다. 펄의 문법이 어떤 면에서 다른 언어보다 복잡하고, 왜 소스가 읽기에 더 힘든지 누군가 이유를 알려주시면 감사하겠습니다.

cjh의 이미지

어느 언어든 indent제대로 안하고 변수명 이상하게 붙이고 하면
알아보기 어려운 건 어느 언어나 마찬가지입니다.

다만 perl프로그래머들이 대부분 quick-and-dirty로 짜는 경향이
많아서 지저분해 보일 확률이 높다는 것이죠.
하지만 일반적으로 Perl 코드를 읽기 어렵게 만드는 것은 빈번하게
사용되는 기호들이 주 원인인 것 같습니다. @, $, %, ->, =>
등을 섞어쓰면 읽는 사람이 혼란에 빠지기 쉽거든요.
게다가 제가 다른 글에서 쓴 것처럼 계층 관계를 변수로 표현한다든가,
hashref의 간략하게 쓸 수 없는 빈번한 사용 등은 전체적으로 가독성을
저하시키는 요인이 됩니다. 처음부터 OOP로 설계된 스크립트 언어들은
그런 문제를 문법 수준에서 일정 부분 해결하고 들어갔죠. 클래스
변수 하나 만드는데 bless 구문같은게 필요 없다는 이야기입니다.
@ISA같은걸 쓸 필요도 없고, named parameter를 쓰기 위해서
=>을 남용하게 되는 습관도 있고요.

p.s. 근데 요즘 python 코드가 더 눈에 안들어오는건 무슨일일까요...
ruby는 말할것도 없고요(생각을 너무 많이 하도록 합니다. ruby는)

--
익스펙토 페트로눔

Paladin의 이미지

공감합니다. 제 생각과 같군요.

@, $, %, ->, => 이런 것들이 참으로 편하기는 한데, 많아지면 오히려 더 헷갈리죠. 귀차니즘이 오히려 귀찮음을 만드는 즉 역효과죠.

그리고 관련없는 다른 이야기 좀 더 붙이자면,

Visual C/C++에 가면 소위 헝가리안 노테이션이라 하여 변수명 앞에다 접두사를 붙이죠. 사람마다 생각이 다르겠지만 전 이 헝가리안 표기법을 아주 싫어합니다. 가독성을 올리기는 커녕 짜증만 나게 하죠. Null-terminate string 변수마다 lpsz라는게 붙어 있는거 보면 정말 환장합니다. 이 헝가리안 노테이션을 .Net과 C#의 핵심 리더인 앤더스 헤질스버그가 깨어버렸는데, 그 분에게 심심한 감사를 늘 표하죠.

변수 이름짓기가 어떤 것이 좋은지는 사람마다 다르지만 저의 경험과 제 성격으로 보면, 변수명은 Type에 의존되는 것보다 의미(또는 역할)와 연관하여 짓는게 좋다라는 겁니다. 그러니까 하나의 작업에 연관된 변수를 묶어서 뭔가 공통 분모를 짓고 그 뒤에 세부 명칭을 붙이는거죠. Type이 뭔지를 변수명에서는 신경안씁니다. 그리고 C++은 Strong-Type Check 언어라 Type이 안맞으면 컴파일러가 잡아주니 과거와는 달리 구문때문에 낭패보는 일은 없지요.

다시 본론으로 가서 @, $, %, ->, =>이 많으면 왜 헷갈리느냐 하면, 딱 보면 알겠지만 @, $, %, ->, =>들은 알파벳과 생긴게 많이 달라서 그런지 한눈에 팍들어옵니다. 생긴게 달라봐야 거기서 거기이겠지만 고정관념때문인지 알파벳과 기타 문자는 굉장히 다르게 인식이되죠. (나만 그런가... -.-;")
변수마다 이것들이 붙어있으니 변수의 의미보다는 변수의 Type에 더 신경이 가게되고, 결과적으로, 의미 분석할때 집중력을 저해시키는 요인이됩니다.

근데 저만 이럴지도 모릅니다. 전 헝가리안 노테이션도 싫어하니.

아무튼간에 작으면 재미있고, 가독성이 더 높습니다만, 아주 커다란 코드에서는 공해같다라는. 머 대개는 커다란 코드를 겪지 않으니 이런 걱정은 안하셔도 되겠습니다.

그리고 뭐든간에 처음에는 재미있는데 갈수록 재미없어지는건 아마 단점때문이 아닐까라는 생각도 듭니다.

9th Paladin

musiphil의 이미지

C++에서 Hungarian Notation은 골칫거리가 됩니다.
변수명이 up-to-date인 타입 정보를 가지고 있도록 관리하는 것이 어렵기 때문입니다.

참고: http://www.cuj.com/experts/1911/hyslop.htm

익명 사용자의 이미지

헝가리안이 타입 대신 변수의 의미를 위해서 생긴 노테이션입니다. psz, lpsz
이것은 그냥 접두사일 뿐입니다. 그리고 코드가 복잡해지는 경우에는 이것이
아주 편리합니다. 저 같은 경우에는 원래 타입없는 랭귀지, ST-80에서 시작해
서 이것이 아주 불편했었는데 업체에 나가서 그쪽의 요구대로 헝가리안을
쓰다보니 C같은 언어에서는 상당한 시간 단축(컴파일 오류나 경고를 없애주는)
효과는 있습니다. 그리고 접두사 뒤에 붙이는 변수의 의미에 좀더 신경을
쓰게 되고요. 헝가리안이 불편할 수도 있지만, foo, bar, a, b, c이런 것
보다는 훨씬 낫습니다.

Paladin의 이미지

천만에요. 변수의 의미를 위해 생겼다니 그건 아닙니다.

lpsz같은 접두사가 변수의 의미에 기여하는바는 없습니다. 단지 그 변수가 어떤 Type이라는걸 나타낼뿐이지요. 즉 perl에서 $를 쓰는 것과 같은 이치입니다.

그리고 원칙적으로 Type이 없는 언어란 없습니다. 특정 언어에서 Type이 없어 보이는건 모든 변수가 기본적으로 Variant Type이라서 그렇겠죠. 만약 Variant조차아니라면 기본적으로 int입니다. CPU에 가서 보면 int외의 Type은 인식에 따른 차이일뿐이죠.

C 언어같은 Weak Type-Check 언어에서는 Type이 안맞으면 구문의 오류로 인식하지 않고 Casting을 해버리지요. 이 문제를 극복하는 하나의 방편으로 생긴게 접두사 붙이는 방법인 것입니다. 즉 변수의 의미보다 변수의 syntax에 관련이 있는거죠.

그리고 물론 a,b,c,이런 것 보다는 낫겠죠. 이런 변수 이름은 의미도 없고, Type도 없죠. 그런데 가끔은 이런 것도 필요할때가 있습니다. 단순히 Loop를 돌때 변수 i를 사용하는건 아주 가독성이 높습니다.

i,j,k,p,q,r은 Local 변수 전용이며, 100% Loop에 사용합니다. t,x,y,z는 Loop보다는 임시 저장을 위한 변수로 주로 사용하죠.

그리고 헝가리언 접두사가 필요없는 이유는 이런거죠.

MemberName이라는 변수가 있다고 합시다. lpszMemberName처럼 lpsz를 안붙혀도 바보가 아닌이상 int같은 Ordinary Type이라고 추측하진 않을겁니다. 이것은 누가봐도 String이거나 아님 char*일거라고 추측할겁니다. 이 둘은 Coding 습관상 하나로 통일했을 것이므로 String인지 char*인지 알 수 있겠죠.
MemberCount라는 변수를 봅시다. 뭐 뻔하겠죠. int이거나 unsigned int, 아니면 기껏 틀려봐야 Ordinary Type 이겠죠.
MemberIndex라는것도 뭐 뻔하고.
Member.Active는 Bool Type일거라고 추측 가능하죠.

가만 보면 뻔하지 않은 Type도 있습니다. 그런 변수에 대해서는 추측이 가능하겠끔 충분히 의미 부여를 해주는 이름이 필요하죠. Array같은건 복수형으로 이름붙이면 좋죠.

저도 한때는 헝가리안 표기법에 대해서 귀가 솔깃했었던 적도있었지만 어느순간부터 이것은 변수 이름만 더럽게 할뿐이다라는걸 느꼈죠. 가독성을 높혀준다라는 의견도 많지만 전 반대로 느낍니다. 이것은 오히려 가독성을 방해하는 요소입니다.

인간의 머리는 코드를 보면서 Syntax까지 검사할 필요가 없습니다. 그리고 이런걸 완전히 벗어나야 의미 분석을 능동적으로 할 수 있죠.

Syntax 타당성 검사는 컴파일러에게 모두 맡겨야 하죠. 대개의 언어가 Strong Type-Check 언어로 변화되는 이유가 이런데 있다고 봅니다.

9th Paladin

익명 사용자의 이미지

제말을 잘못 이해 하신듯 합니다. psz가 의미를 부여한다는 것이 아니라
이런 접두사 때문에 그 뒤에 오는 실제 의미를 강요한다는 것이지요.
a 이런식으로 쓰던 사람도 psza라고는 하질 않습니다. pszID 이런 식으로
하지요. 이것도 헝가리안을 쓰는 또는 강요하는 이유중의 하나입니다.
그리고 CPU의 입장은 잘 모르겠고 ST는 실제로 형이 없습니다. 그리고
정적인 타입 검사를 하는 것이 오류방지에 도움은 주지만 실제 생산성은
떨어집니다. MS Press의 Code Complete에 보면 앞의 헝가리안의 영향과
동적 형 검사와 정적 형 검사의 오류방지에 대한 그리고 생산성이 관한
연구가 뒤에 레퍼런스로 붙어 있습니다.

추신)
그런데 어쩌다가 펄이야기가 이까지 왔지요? :-)

Paladin의 이미지

그건 의미를 강요하는게 아니라 구문을 강요하는거죠.

앞글에서도 언급했듯이 변수명에다 syntax(정확히는 Type)를 줄줄 달고 다니면 코드가 작을땐 몰라도 코드가 커지면 공해입니다.

ID같은 경우도 lpszID라는건 단지 이 ID라는 변수가 Null-Terminate 문자열임을 암시할뿐 이 변수가 무엇을 하는건지를 알기는 어렵죠.

좀 경험이 쌓이면 이런 변수에는 LoginedID, UserID, FriendID 같은 보다 명확한 Full name 변수명이 훨씬 좋다라는걸 깨닫을 수 있을겁니다. 이런 변수 앞에다가 lpszLoginedID, lpszUserID, lpszFriendID처럼 lpsz를 붙인걸 보면 이게 바로 공해지 달리 특별히 다른 어떤 것이 공해가 아닙니다.

그리고 때로는 Syntax보다 의미로서의 Prefix가 사용될때도 있는데 이건 헝가리안 접두사와는 성격이 분명 다르죠. 예를들어 HandleMutex, HandleWindow처럼 앞에 붙혀서 Handle임을 암시하게 할 수 있는데 이건 의미론적인 접근입니다.

그리고 .Net이 등장하면서 헝가리안 표기법도 이제 수명 종료했습니다. 아마 그 헝가리 사람 짤렸을지도 모릅니다.

9th Paladin

익명 사용자의 이미지

맞습니다. 객체가 주가 되는 언어, 특히 동적인 언어에서는 헝가리안은
크게 의미가 없습니다. 그리고 당연히 ID가 의미가 불분명하면 pszLoginID
라고 해야겠지요. 그리고 헝가리 사람이 아니라 찰스 시모니라고 엑셀을
만든 사람이 만든 표기법입니다. 그리고 제가 위에서 말씀드린 것 처럼
취향 때문에 이걸 사용하지는 않습니다. IBM같은데서도 물론 다른 노테이션
일 수 있지만 이 같은 형 표기법은 사용합니다. 그건 바로 앞에서 제가
말씀드린 연구 결과들 때문이지요(그건 IBM이 수행한 것이더군요, MS도
아마 여기에 자극을 받아서 찰스시모니의 표기법을 채택한 것 같습니다.).
그리고 코드가 커질수록 이 표기법은 이득입니다. 앞으로 찾아갈 필요도 없
이 형 검사가 가능하니까요. 그리고 컴파일러가 이런일을 돕기는 하지만
안해도 되도록하는 것이 훨씬 시간도 절약이 됩니다. 사람이 자기가 사용하는
변수의 형을 알기가 어려운 것 보다야 좋은 결과가 나오지 않겠습니까? :-)
그리고 이건 타입이 존재는 하지만 엄격하지 않은 C, VB, C++같은 데서
당연히 의미가 있고 Java, ST, Objective-C등에서는 큰 의미가 없습니다.
후자의 두 언어는 동적 타입 검사와 동적 바인딩이 중요하고 프로토콜의
합치가 중요한 언어라 형이 크게 의미가 없고 Java는 거의 모든 것이 객체라
바인딩시의 프로토콜이 중요하지요, 당연히 정적인 형 검사를 하기 때문에
미리 발견할 수도 있을 것이고...

익명 사용자의 이미지

찰스 시모니는 엑셀을 만든 사람이라는 건 맞지만 헝가리 태생이라 그 사람이 사용하던 프로그래밍 표기법을 헝가리안 코드라고합니다. 책에서 읽었습니다. 최근에 다른 연구를 위해 M$를 나갔다고 하더군요. 그 연구는 우선적으로 M$에서 사ㅛㅇ하게끔 계약을 한듯... 며칠전 신문인지 인터넷인지에서 보았습니다.

익명 사용자의 이미지

파이썬으로도 한줄짜리 눈이피곤한 코드를 작성할수 있는건 마찬가집니다.
특수문자만 몇개없다뿐이지...
파이썬코드를 뒤적이다 보면 그런코드를 너무쉽게 발견할수 있읍니다.

펄은 더 심하죠. 적응의 문제일수도 있지만...
처음펄을 보았을때 최소한의 타이핑으로 최대의 효과를 내기위해
만들어진 언어처럼 보였읍니다.
물론 문법자체는 어렵지는 않았지만 눈이피곤한건 어쩔수 없더군요.

제개인적으로는 Ada소스코드가 제일 깔끔하고 아름답게 느껴지더군요.

까막_의 이미지

물론 어떤 언어로 짜든 눈이 아픈 코드를 작성할수 있습니다.

문제는 프로그래머가 얼마나 눈이 덜아픈 코드를 짜기 쉬운가 인데..

파이썬은 그나마 펄에 비해서는 나은 편인것 같습니다.

파이썬은 문법상 명시적인 코드를 만들게 되더군요(저의 경우에)

특히 Java는 문법상 특징덕분에 규칙을 찾아봐야하는 경우가 생기죠.
(이럴땐 변호사되는 기분입니다.)

제가 전에 펄할때는 옆에 책을 놓고 살았던 기억이 납니다 ㅎㅎ
(대게 정규표현식이었죠 --)

개인적으로 OOP개념에서도 Java나 C++보다 낫다는 생각입니다. ^^
(self변수가 갈수록 편해지는군요 ㅎㅎ)

ps. Ada깔끔한가요? 구경안해봐서리 ㅎㅎ Ada나 볼까나 ㅋㅋ
ps2. 펄은 정말 눈에 안들어오더군요 ㅋㅋ
ps3. 아아 두서없는 글이 되었군요 ㅠㅠ
--
Let's be engineers!

Let's be engineers!

익명 사용자의 이미지

펄은 펄 다워야 합니다.

펄 특성을 버리고 다르게 변한다면

펄이 싫어질지도

펄은 암호같고 복잡해서 좋아했는데..

펄은 해커기질 있는 사람에게 좋아 했는데

그렇게 변한다면 ... 펄이 추종자들은

얼마나 남을지...

많이 남겠지만 , 그특성을 아쉬워 하는 사람이

많을 겁니다.

cjh의 이미지

참신한 문법이 많이 띄네요 :)

사실 perl5의 문법이 그나마 perl4를 많이 개량한 것이기는 하지만
그 복잡도에 있어서는 package나 class를 도입하고 많은 부분을
hashref에 남겨서 사실 생산성은 높아졌지만 코드 보기는 참
어려워졌습니다. ->을 .으로 쓸 수 있다면 두글자 쓸 거 한글자만
쓰면 된다는 이야기군요. 전에는 클래스 파생 관계도 변수에
넣어서(@ISA) 표현했는데 그것도 내장으로 바뀐것 같고요.

그런데 이렇게 되면 perl4 -> perl5 로 넘어가는 것 처럼 별 무리
없이 전환되지는 않을것 같군요. 문법 차이가 너무 크죠.

기존의 CPAN저자들은 어찌할지...

--
익스펙토 페트로눔

익명 사용자의 이미지

펄6보다는,
차라리 펄을 완전히 뜯어고쳐서
철저한 OOP로 재구성한 언어인 Ruby가 훨씬
우수한 언어 같네요.

cjh의 이미지

Matz(ruby저자)가 가장 좋아하던 언어는 SmallTalk같은 언어였을
겁니다. ruby에는 perl의 특성이 많이 있지만...

지금 레퍼런스가 정확히 기억나지 않는데 Larry Wall의 글 중에
perl6에서 ruby를 구현할 수도 있다는 이야기를 본 적이 있습니다.
perl6의 문법 자체를 재정의할 수 있도록 만든다는 이야기겠지요.
jython이랑은 좀 다른 관점이지만...

--
익스펙토 페트로눔

익명 사용자의 이미지

perl 은 perl 스러운게 제일 좋습니다.

복잡한 OOP라던지, 바이트코드 같은게 어떤 필요가 있을지 잘 모르겠습니다.
가장 빠른 시간 안에 귀찮음을 덜고 남는 시간만큼 게으름을 부릴 수 있는 언어라는 초기의 정신(?)을 잊는다면 perl 은 더이상 perl 이 아니겠지요..

프로그래밍 하는 기분도 내면서 가볍게(빠른 시간 안에) 쓸 수 있는 방향으로 발전하면 좋겠군요...

익명 사용자의 이미지

저도 '펄'이 '뻘'이 되지 않았으면 좋겠습니다.
저는 언어를 (1)목적도 (2)툴도 아니고 (3)철학이라고 보는데요
철학이 바뀔정도로 전면적으로 뜯어고칠거면 PERL의 다른 버젼으로
만들었으면 좋겠네요.

좋은 언어였는데, 얼라이(동맹)를 풀어야 겠네요.

익명 사용자의 이미지

기술하신 것은 공식적으로 정해진것이 아니라 현재 활발히 예기가 오고가는 그야말로 'draft' 상태라는 것을 명시해주시는 것도 좋겠져.^^;;
Perl이 찬밥인 이유중에서 가장 민감한 것이, 기업시장에서 standalone execute file을 만들수 없었기 때문이 아닌지요?
머,, 이는 ActiveState 사의 Perl Dev Kit 로써 단독실행파일뿐만 아니라 Windows 2K/NT/XP 서비스로서까지 만들수 있고, GUI RAD 툴(http://www.bahnhof.se/~johanl/perl/Loft/)까지 있습니다. 소스까지 공개되어 있는,...
또한 기피하는 것중의 하나가 속도때문이라고 하는 사람도 꽤 봤거든여.. 그러나 분명한 것은 언어자체는 C 로 대단히 compact 하게 짜여져있기땜에 절대 언어엔진 자체가 느린게 아닙져.
느린 이유는 high-level의 자료구조땜에 느린거라고 하는군여.
(http://www.perl.com/pub/a/2001/06/27/ctoperl.html 를 읽어보세여)
6.0이 언제 릴리즈 될진 알수없지만, 혼자서 뭔가를 만들어보며 즐거움을 느끼는 언어로 손색이 없다 생각됩니다.
또한 Inline 모듈은 perl 소스내에서 ASM/C/Python/Java 코드를 *곧바로* 불러쓸수 있어 속도면과 코드작성 효율면에선 정말 별짓(?)다하는 언어라 생각됩니다^^;;
쩝... 제가 아무리 perl 이 좋다해도 시장은 결국 Visual C++ 이나 Java를 쓰겠지만 Perl6 가 릴리즈되고 executable output이 충분히 양질이며 GUI 패키지 바인딩이 제대로 되면 ... ^^;; 해피할겁니다,, 정말...
GUI 패키지는 perl 고유모듈없이 대부분 binding으로 구현되서 좀 맘에 드는게 없슴다.
Qt가 딱이긴한데 라이센스문제가 있고 wxPerl 로 하기엔 RAD 툴이 없고 Tk로 하자니 어설프고 ㅡ.ㅡ;; 쩝...
GUI쫌 신경쓰면 좋겠는데 래리아저씨나 conway씨나..제길...

익명 사용자의 이미지

"컴퓨터속도는 점점 빨라지고 미래에는(?) 스크립트언어는 컴파일언어의
많은 부분을 대체할것이다
스크립트언어가 주가 될것이며 컴파일언어는 특정부분으로 밀려날것이다"
라는 글을 종종 본적이 있읍니다.
누가 GeekForum에 글을 올려 생산적인 토론을 한번해봤으면 좋겠군요...

익명 사용자의 이미지

스크립터언어가 아니라 인터프리터언어로 고칩니다. ^^

임택균의 이미지

그냥 생각해 볼 것이 하나 있는데,

C가 컴파일러일 필요가 있나요?

과거 Easy C 였나요. 인터프리터로 구현한 적이 있습니다.
물론 C로서의 많은 강점을 버렸기는 했지요. :-)
--
임택균.

임택균.

익명 사용자의 이미지

easy C저도 압니다. 아마도 90년도 쯤에 학원에서
복사해줘서 쓴 적이 있습니다. C를 조금은 쉽게 배우게
해주더군요. 결론적으로 볼때 별차이는 없습니다만

C는 코드량이 많은 편이라 기계어가 아닌
인터프리터형 중간언어를 만들면
인터프리터 해석기에 과부하가 많이 걸립니다.
C를 인터프리터로 만들면
자바보다 성능이 나쁠 것으로 생각합니다.

C도 지금은 임베디드용으로 밀려난 언어라 찬밥이죠.
다행히 저는 찬밥이라도 먹고 삽니다만... ^^;

익명 사용자의 이미지

C는 결코 찬 밥이 아닙니다.
막강한 운영체제나 컴파일러들도 대부분 C로 구현이 됩니다.
Processor 제작업체들이 왜 맨 처음에는 Assembler와 C를 만들까요? 바로 개발 툴의 기반이 되기 때문입니다.
실제 C++, Java, C# 등의 언어가 인기가 있을지라도 이것들은 또한 로우레벨의 개발툴로는 찬밥일 수 밖에 없죠...

익명 사용자의 이미지

프로그래머가 되겠다는 사람에게 펄을 권유할 사람이 있을까.. 의문시 됩미다.. 뭐 성능의 큰 차이만 없다면야 언어는 하나의 메서드에 지나지 않으니 까 상관은 없겠죠 그런데 GUI는 어느정도 까지 지원하는지 궁금하네요.. 펄6.0보다는 Perl++같은 새로운 이름을 붙이는게 더 뽀대 날껏 같습미다..

익명 사용자의 이미지

저도 후배들에게 세컨드 언어로 펄을 꼭 권해주고 싶군요.

자료구조 구현하기도 쉽고
좋은 책도 많고 문서화도 잘 되어 있고
개발하다보면 뭔가 빠진데가 있을때 펄로 급히 대응할 수도 있고요
실무에 쓰지 않는다고 해서 가치가 낮아지는 것은 아니라고 생각합니다.

펄의 몇자 배우면서 래리월씨 장말 고민 많이 했구나...라는 느낌이
바로 들더군요. 펄에 숨어 있는 철학중에 공감가는 부분도 많고요.

익명 사용자의 이미지

헐헐...

저는 자주 권한답니다.

혹자는 Write only language 라고 하지만서도,

펄로 Write 안하면 손으로 노가다 하더군요.

C의 섬세함에 쉘의 편리함이 잘 섞인 언어입니다.

제 개인적인 생각으로는 펄에 OOP 넣고,

뭐 하고 하는 것은 안 했으면 좋겠습니다.

C의 switch 문 같은 것은 꼭 들어가야 한다고 생각했는데,

이번에 추가되려는 얘기가 있다하니 기쁘네요.

'한가지일을 여러가지 방법으로' 가 펄의 철학중의 하나지만서도

switch 문 없이 여러가지 구문들로 쓰는 건

영 쓰기도 힘들고, 보기도 힘들더라고요.

강력한 switch 문이 나왔으면 좋겠는데 ^^