perl6 에 대한 이해를 돕기 위한 가이드 perl6 라고 부르는 것은 문법만을 말한다.
Test Case들을 잔뜩 모아놓고, 이 코드들이 컴파일되고 실행되어 지정한 결과가 나오는 컴파일러를 만들면, perl6 라고 인증을 받을 수 있다.

perl6를 설계하면서 parrot 프로젝트가 함께 시작되었다.
parrot 은 Virtual Machine 을 만드는 프로젝트인데, perl6 에서 갈라져 나와서 독립되었다.

perl6 는 작동결과에만 초점을 맞추고 있고, 실제 실행 수단에 대해서는 제한하지 않는다.
parrot은 제대로된 byte code 만 입력받으면 그대로 작동한다. perl6와 개념상 분리되어 있다.

perl6 컴파일러를 여러분이 만들게 된다면, 그 결과물이 exe 파일이건, parrot byte code 이건,
java의 class 파일이건간에, perl6 라고 부르면 된다.

하지만 parrot 프로젝트는 perl6 프로젝트와 함께 태동되었기 때문에,
perl6컴파일러는 parrot byte code를 생성하는 것이 당연하다.
perl6가 parrot의 성능향상에 도움을 주는 형태가 된다.

parrot을 타겟으로 한 perl5, python, ruby, java, c# 컴파일러가 있는 상태이고,
안정되고 나면 parrot은 매우 강력한 실행환경이 된다.

perl6 는 풍부한 문법적 특징만으로도 진보된 요소들이 많이 있고,
여러 언어의 장점과 프로그래밍 테크닉등이 문법에 녹아있어,
신세대 해커들의 새로운 친구가 될것이다.

aero 님의 Parrot 를 참고하세요.

개발자와 기획자, 디자이너의 협업 이전 포스트에서 개발력과 기획력을 구분하라는 요지의 주장을 했었다.
다시한번 이야기하자면, 둘을 겸하는 개발자가 잘못된 것이라는 이야기가 아니고,
개발력을 키우려고 할때, 기획력을 늘리는 노력을 잘못 기울이지 말라는 이야기였다.

사실 둘을 겸하는 것은 매우 뛰어난 것이고, 목적에 맞는 좋은 프로그램을 잘 만들어낼수 있는 능력이다.
어느정도 기획적인 일을 겸하는 것은 건조한 개발작업에 도움을 준다.
실제로 개발자들은 지겨운 일에 여러가지 기획적인 요소를 부여해서 동기부여를 한다.
보통 재사용성을 기획하고, 기술력향상을 기획해서 때로는 그냥 해도 되는 일을 좀 더 크게 만들지 않는가?
이런 재능의 낭비를 생산적인 방향으로 돌렸으면 한다.

기획(UX지식)+디자인+개발로 분업이 된 경우의 실무는 위와 같은 과정을 밟게 된다.

1. 기획자는 타겟사용자가 필요한 것(타겟 사용자는 깨닫지도 못하고 있는)을 알아내고, 그걸 어떻게 제공해줘야 좋을지를 결정한다.
2. 디자이너는 이 아이디어를 보기좋게 구성하여 배치한다.
3. 개발자는 이를 이어받아, 그대로 구현한다.

내가 생각하는 좋은 과정은 다음과 같다.
기획(UX지식)+디자인(UX지식)+개발 로 구성하고,

1. 기획자는 타겟사용자가 필요한 것을 알아내고, 디자이너에게 공유하고, 어떻게 제공해줘야 좋을지 함께 결정한다.
2. 개발자는 제공할 형태가 개발에 적합한 것인지 검토한다.
3. 디자이너는 검토완료된 형태로 보기좋게 구성하여 배치한다.
4. 개발자는 이를 이어받아, 그대로 구현한다.

개발자가 두번이나 끼이게 되어서 번거로울거 같지만, 디자인이 나온 상태에서 이건 안된다라고 하면, 일정부터, 기획까지 크게 어긋나게 된다.
1번과정에서 디자이너는 UX에 관한 경험과 아이디어를 기획자와 함께 발휘를 해서 좋은것이고,
2번과정에서 디자이너는 두번 일하는 수고를 하지 않아도 되게 된다.
4번과정에서 기획자는 기획안을 타협하지 않아도 된다.

더 좋은 안이 있다.
기획(UX지식)+디자인(UX지식)+개발(기획지식)으로 구성하고
1번과정에서 타겟사용자가 필요한 것을 알아낼때, 개발자에게 재해석을 하게 하면 전혀 다른 시각에서 한번 검토해볼수 있게된다.

이렇게 하면
타당성 있는 기획을 기획+개발이 함께,
사용성이 좋고 실현가능한 디자인을 기획+디자인+개발이 함께,
시너지를 내어서 퀄리티있는 결과물이 좌초없이 나올수 있게 된다.

모두에게 창의적인 활동을 할 기회를 조금 나누어주면 기획은 탄탄해지고,
모두 만족할수 있을 것이다.