팩터의 공부, 어떻게 접근해야할까?
Jonghyouk, Yun
했던것들을 적어보려고 합니다.
0. 욕심을 버린다 : 팩터를 이용해서 어떤 상용 서비스를 만들었다는 이야기는 듣지 못했습니다. 그리고 루비, 파이썬으로 뭘 하
겠다고 하더라도 냉대를 감안하는 현실을 생각하면 팩터는 어디가서 말도 못꺼낼 주제겠죠. 하지만, 새로운것을 공부하기는 기쁜일입니
다. 그리고 그게 생각하고, 코딩하는 자신의 관점에 많은 도움이 된다면 더욱 감사하겠죠.
감히 제가 뭐라고 하기는 웃기겠지만, 팩터는 제가 생각하기에 생각을 표현하는 방법입니다. (파이썬도 그렇겠고, 리습도 그렇겠지
만)
생각을 잘 추상화해서 구현하고, 그걸 다시 작은 부분으로 쪼개 나가는 그런 작업입니다. (모든 프로그래밍이 그렇지만)
팩터는 그런 추상화, 분리, 그리고 다시 조합하는 작업에 적합하다고 생각합니다. 그런 훈련을 몸에 익히고 싶은 사람이라면 해볼만
한 언어라고 생각합니다.
1. 차이를 인정하자 : 팩터는 자바가 아닙니다. 팩터는 리습이 아닙니다. 팩터는 루비가 아닙니다. 차이를 알고, 그 차이를 인
정하는게 중요하다고 생각합니다. 이 차이들이 자신이 원하는것과 너무 다르거나 버겁다면, 팩터는 자신에게 맞는 환경이 아닐지도 모
릅니다. 하지만, grub을 다시 작성하거나 하는 경우가 아니라면 대부분의 경우에 알맞다고 생각합니다. ;-)
몇가지 차이들을 들어보자면...
* 이미지 기반 개발 : 예, 팩터는 이미지 기반 개발환경입니다. 스퀵이나 커먼리습처럼 현재의 VM의 상태를 이미지로 저장
해, 다음번 시작시에 이를 로드해 환경을 조성합니다. 처음에는 이상하고, 잘 적응하기 힘들지도 모르겠지만, 매번 똑같은 라이브러
리를 로드하려 시간을 낭비하거나, 어떤 상태값을 시작할때마다 건들기 위해 시작 스크립트를 작성할 필요없이, 그 상태를 그대로 저
장해둘수있습니다. (원하는 상태의 snapshot을 찍는건 선택입니다. 무조건 변경상태를 저장할 필요는 없습니다.)
그렇다고, 스퀵처럼 외부의 소스코드를 두기 힘든 그런 환경도 아닙니다. 팩터에서 소스코드는 커먼리습처럼 외부의 *.factor
파일로 저장합니다. 그리고 이를 '로드'하여 이미지에 적재하는 방식입니다. 사실 이미지에 적재할때에 native-compiler
을 거쳐서 최적화한 코드를 적재하므로, 이미지를 보관하는게 성능을 향상하고, 개발의 편의를 도모하기 위한 중요한 방법입니다.
* applicative language가 아니다 : g(f(x))가 아닙니다. x f g입니다. 기존의 하던것과 다르게, 그
저 위에서 아래로, 왼쪽에서 오른쪽으로 스택에 쌓이거나(literal), 스택의 문맥에 따라 평가하거나(word) 둘 중 하나
인 단순한 언어입니다. 기존의 idiom에 익숙한것을 생각하지 않고, 꼭 그런 모양이 되지 않는다고 짜증낼 필요는 없습니다. 조
금만 더 익숙해지면 더 좋은 방법을 제시할 수 있게 되는 환경입니다.
단순함은 미덕입니다. 단순함의 미덕을 잘 살리고 있는 언어입니다. homoiconic한 문법 덕분에 정말 빠르게(5년정도) 이
런 언어/환경을 구성할 수 있었다고 생각합니다. (어떻게 생각하면, 리습보다 간단하지 않을까요.) static한 타입과 문법만
이 타입유추와 멋진 ide을 제공할수있다고 믿고 쌓아올린 자바보다 훨씬 간결하고(비교하자면, 가장 간결할것 같은 문법인데요.)
아름다운 문법으로, 그만큼 멋진 code-navigation, refactoring기능을 갖춘 ide을 만들기 적합한 언어입니
다. (fuel의 기능들을 보세요.)
그렇다고, 무조건적인 단순함만을 강요하지 않습니다. 이런 간단한 기반위에 번뜩이는 아이디어들로 멋진 것들을 할 수 있는
vocab들이 충분하다고 생각합니다. (locals, fry-quotation, 객체시스템, ... 제가 생각하기에 거의 대부분
의 팩터의 기반 라이브러리는 이런 재치들이 번뜩인다고 생각해요.)
* imperative한 코드를 별로 권장하지 않는다 : concatenative language은 그 천성이
functional함에 더 적합합니다. imperative을 아예 하지 말라는것이 아니라, functional할 수 있는 경우
에 functional하기를, 가능하면 concatenative하기를 권장합니다. 그렇게 가능한 경우라면, 더 깔끔하고 이해하
기 쉽고, 그리고 다시 factor-ing해서 정돈하기 편리하더라구요.
2. 문서를 읽자 / 따라하자 : 팩터의 문서는 멀리 있지 않습니다. JavaDoc, HyperSpec처럼 무언가를 다운 받
을 필요도 없습니다. 팩터 환경 그자체에 내장되어 있습니다. 심지어, tutorial, cookbook까지 함께 딸려옵니다. 이
런 문서들을 cookbook, first program순으로 하나씩 읽어가며 따라하면 익숙해지던것 같습니다.
3. 문제를 풀자 / 소스를 읽자 : 저는 project-euler의 문제들을 풀면서 팩터로 처음 프로그램을 작성했었습니다.
익숙하지 않은 언어로 뭔가를 해나갈때 처음엔 어색하고, 불편하기만하고 짜증까지 났지만, 무언가 실제로 굴러가는걸, 제대로 작동하
는걸 완성했을때의 쾌감은 말로 표현하기 힘들었습니다. 그리고 그건 어떤 언어로 작성한 프로그램보다 나를 잘 반영한, 나만의 프로
그램이라는 느낌이 있었습니다. (자바로 짤때 그런걸 느끼기 쉽던가요?) 그리고 소스를 읽는게 가장 좋은 예제를 찾는 방법이라고
생각합니다. 팩터의 도움말 시스템은 잘되어있어서 특정 워드의 참조를 찾거나 소스를 찾기도 쉽고, 그런 도움말에 예제도 함께 있지
만, 그래도 잘 모르겠다면 소스를 찾아보는것도 나쁘지 않은것 같습니다. 저는 보통 일단 단위테스트 스크립트를 찾아보고, 없으면
실제 팩터 코드를 뒤적거립니다.
4. 좌절하지말자 : 자전거를 탈줄 아시나요? slava은 팩터를, concatenative language을 공부하는것이 자
전거를 배우는것과 같다고 말했던것 같습니다. 제 생각도 그렇습니다. 넘어지고, 자전거에 바퀴가 두개뿐인게 짜증날때도 있겠지만,
일단 자전거를 탈줄 알게되면, 누군가에게 설명해주기는 힘들지만, 자기몸은 이미 자전거를 탈줄알게 되는것처럼.
자전거 타기의 기쁨을 누리시기를.