• http://en.wikipedia.org/wiki/Lambda_calculus — 늘 느끼지만 위키피디어의 내용은 너무 많고 디테일해서 초보가 따라가기는 쉽지 않다. 그럼에도 여기만한 자료가 없기는 하다. 개론, 역사, 내용, 관련자료 등이 풍부하다.
• http://experthuman.com/programming-with-nothing — 년초에 Hacker news 통해서 보고서는 깜놀! 했다가 Lambda calculus를 보고나서 다시보니, Lambda calculus를 그대로 옮겨놓은 것일 뿐이었다. 그럼에도 역시 대단. 함수형 언어의 바이너리 표기를 보는 것 같다.
• http://stackoverflow.com/questions/114581/how-helpful-is-knowing-lambda-calculus — Haskell과 같은 함수형 언어를 배운다고 하면, Lambda calculus를 먼저 보는 것을 ‘권’하는 의견이 많다. 그러나, 굳이 보지 않더라도 크게 상관없다는 의견도 적지는 않다.
• http://www.iep.utm.edu/lambda-calculi/#SH1b — 내용과는 관련없지만, 재미난 일화. “왜 λ가 사용되었나?” 사실 유무는 확인 불가. 처치 본인도 말이 바뀌니까.

두 언어가 양 극단이라고 볼 수도 있지만, 어떤 측면으로는 굉장히 닮아 있는 것 같습니다. Node.js는 그만큼 Low-level을 다루고 있고, Go는 또 Dynamic한 특정이 강하다.. 라는 의미이기도 하겠죠?

제가 두 언어를 모두 잘 알아서는 이렇다라고 딱 부러지게 말할 입장은 아니고요. 두 언어의 튜토리얼에 나와 있는 http서버 예제를 따라가다가 느낀 것입니다.

다음은 Node.js의 전형적인 Hello World 예제 입니다.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337);
console.log('Server running at http://127.0.0.1:1337/');

Go의 Hello World를 볼까요?

package main
import (
  "fmt"
  "net/http"
)
func main() {
  http.ListenAndServe(":1337", http.HandlerFunc(func(w http.ResponseWriter, req *http.Request){
    w.Write([]byte("Hello World\n"))
  }))
  fmt.Println("Server running at http://127.0.0.1:1337/")
}

거의 흡사하지 않나요? (좀더 비슷하게 보이도록 하려고 조금 수정한 것도 있습니다) 타입 선언을 제외하면 사실상 같다고 할수 있죠.

내부적으로는 goroutine을 사용하는 Go와 single thread 만으로 동작하는 Node.js가 서로 다르지만, API를 설계하는 측면에서는 흡사한 부분이 분명히 있고, 그것은 두 언어의 중요한 설계 철학이라고 생각합니다.

객체지향적 설계를 벗어나서, “꼭 필요한 타입/함수만을 import로 가져오고, 기능 확장은 콜백 혹은 콜백의 묶음(인터페이스)를 이용한다”라는 것이죠. Java Servlet과 비교해보면 차이가 두드러집니다. 상속/재정의를 통해 기능확장을 하는 것과 차이나는 것이죠.

두 언어의 다른 라이브러리들은 어떤지, 그리고 두 언어가 앞으로 발전해 나가는 모습은 어떠할지 지켜볼 필요가 있을 것 같습니다. 서로 도움을 주고 받을 부분이 분명 있을 것 같네요.

이 문서에는 LISP 1.5를 기준으로 MACRO를 도입한 새로운 interpreter를 M-expression으로 상세히 기술되어 있다. 다만 LISP 1.5의 시스템 정의를 조금 알아야 문서를 읽을 수 있어서, “LISP 1.5 Programmer’s Manual”도 같이 봐야 했다.

MACRO definitions for LISP

LISP 1.5에는 Symbol마다 Property list라는 것이 있다. Property list에는 indicator와 value의 쌍이 이어진다. indicator중에서 EXPR이라는 것이 사용자 정의 함수이다. DEFINE 함수로 정의할 수 있다.

DEFINE ( (
(FOO) (LAMBDA (X) ...)
))

동일한 문법을 사용하되, MACRO 함수를 이용하면 MACRO라는 indicator로 해당 함수 정의를 저장해 놓는다. DEFINE 함수와 형태가 일치하므로 내부적으로는 deflist[l;ind]를 이용하여 구현된다. (l은 정의 리스트, ind는 indicator) 즉, define[l] => deflist[l;EXPR]. macro[l] => deflist[l;MACRO]이다.

MACRO ( (
(M1) (LAMBDA (FORM) ...)
))

사용자로부터 식을 읽어들일때마다 매크로를 적용하여 form을 확장(expand)하는 것으로 구현할 수 있다.

구현하기

LISP 1.5는 기본적으로 입력 내용을 함수와 인자리스트형태로 받아서 evalquote[f;a]로 넘긴다. 그래서 Scheme과는 다른 위와 같은 모양이 나오는 것이다. Micro Manual For LISP을 보면, (defun …)형태로 사용자 함수를 정의하는 방식이 소개되므로, 이 방식을 매크로 정의에 사용하면 (defmacro …)형태로 매크로를 정의하도록 할 수 있다.

(defmacro select (form)
  ( (lambda (symbol) (list (list 'lambda (list symbol)
    (cons 'cond
      (maplist (cddr form)
        (function (lambda (l) (cond
            ( (null (cdr l))
              (list 'T (car l)))
            (T
              (list (list 'equal symbol (caar l)) (cadar l))))))))) (cadr form)))
   (gensym)))

문서의 끝에 나온 select 구현을 충실히 옮기면 위와 같다. 아직 quasiquote, unquote 등이 도입되기 전이라 읽기가 상당히 어렵다. 그 필요성을 바로 알 수 있다.

LISP 1.5에는 Symbol마다 Property List가 있지만, symbol->value 사전 형태의 구현에서는 EXPR 사전과 MACRO 사전을 따로 관리해야 하는 문제가 있다. 우선은 indicator에 해당하는 내용을 Symbol에 덧붙여서 저장하고 불러오는 방법으로 같은 효과를 얻을 수 있다.

(define (sqrt-iter guess x)
   (if (good-enough? guess x)
       guess
       (sqrt-iter (improve guess x)
                  x)))

LISP에서는 1.0부터 이미 Tail recursion이 기본모양으로 사용되며, 이를 iterative process로 실행하지 못한다면 재귀호출에 따른 비용이 금방 문제가 된다. (메모리와 관련해서는 많은 언어들이 알아서 처리해준다.)

Go로 LISP을 구현해보고 있다.(링크) 이 문제를 만나서 여러가지 고민 끝에 일단 구현은 해놨는데, 마음에 들지 않지만, 개선하기도 쉽지 않다.

내가 취한 방법은 eval()함수를 재귀적으로 호출하는 대신 반복문으로 바꾼 것이다. 이 방법은 http://norvig.com/lispy2.html에 소개되어 있다. 다만, 이 방법을 적용하려다보니 apply/evalCond 처럼 분리된 함수를 eval()에 inline으로 다시 합쳐야만 했다는 것. eval()의 마지막으로 eval()이 다시 호출되는 곳마다 eval(e, a)의 두 인자값만을 갱신하여 루프를 반복한다.

SICP 5장에 소개된 것과 같은 Register machine을 구현하여 직접 콜 스택을 관리하는 것도 대안이 될 수 있을 것 같다.

11월부터 여유가 생겨서 “Micro Manual for LISP”이라는 문서를 근거로 LISP을 구현해보고 있다. 처음에는 Python으로 eval()함수만 작성해보고, 그다음엔 Java로 read()와 eval()을 작성해봤다. 마지막으로 Go언어로 구현해보는 중이다.

Python과 Java로 간을 본 수준이라면, Go언어로는 여러가지 양념을 쳐보면서 연습중이다. Go언어도 배우고, Git도 배우고, Parsing방법도 여러가지 시도해보고, “Original(?) LISP은 어떻게 구현되었을까?” 라고 하는 역사연구도 하고..

비교적 쉽게 1장짜리 구현이 끝난 다음에는 3장짜리 “MACRO Definition for LISP”을 발견해서 구현해보려는 중이다. 63년에 작성된 메모인데, LISP 1.5에 처음 MACRO를 도입하기 위한 아이디어 및 구현을 정리한 문서이다. 이 문서를 제대로 읽으려 하니 “LISP 1.5 Programmer’s Manual”을 읽지 않을 수가 없어서, 이것도 찾아서 읽는 중이다. 그런데 이 Manual은 100쪽이 넘는다. Manual은 62년에 초판이 나오고 지금 읽고 있는 것은 85년에 나온 2판이다.

Scheme에 비해서 LISP 1.5는 아직 덜 성숙된 모습이라서, 대충 마무리짓고 Scheme버전으로 넘어가고 싶기도 하다. 하지만 일단 시작했으니 LISP 1.5를 충실하게 따라가보고, 그리고 MACRO까지는 구현해보고 난 다음 Scheme으로 넘어가보려 한다. (1.5에 이미, LISP Interpreter, Compiler, Garbage Collection까지 들어가 있다. 이것까지 다 해보기는 좀 벅차다)

1. Micro Manual for LISP
2. MACRO Definition for LISP
3. LISP 1.5 Programmer’s Manual

아이디 만들고 자신만의 레파지토리를 만들어 팀 작업이나 오픈소스 작업을 진행할 수 있습니다. 이미 진행중인 오픈소스에 동참할 수도 있습니다. 형상관리는 물론이고, 이슈 트래킹, 위키 서비스까지 기본으로 제공됩니다.

사실 이러한 서비스의 대표격은 sourceforge 였지만, 이제 많이 죽었죠? 요즘 대세는 아무래도 social coding 이라는 이름을 만들어낸 github.com 이 아닐까 싶네요. 그외, gitorious.org 도 있습니다. 구글의 code.google.com 도 있고, launchpad.net 도 있습니다.

굳이 소스코드 없더라도, 위키/블로그 대용으로 이러한 호스팅을 이용하는 경우도 많다고 합니다.

비트버킷은 형상관리 베이스로 git와 mercurial을 지원합니다.

비트버킷을 만든 회는 아틀라씨안! 컨플루언스라는 기업형 위키를 만들었고, 그 유명한 지라를 만든 회사이기도 합니다. 이 회사가 유명해진 이유 중에는 페덱스데이(FedEx Day)도 있을 것 같습니다.

“What brilliant innovation can you deliver in 24 hours? FedEx Day is our attempt to answer that question”

저는 http://bitbucket.org/jooyunghan/golisp 에 go로 lisp 만들기 프로젝트를 열어놓고 짬짬이 진행하고 있습니다.

system dynamics of component teams and number of developers

Bas 뿐만아니라 Gerald M. Weinberg 나 Kent Beck 등이 자주 그린다.

이름이 여러가지다. Causal-Loop Diagram 이라고도 하고 (대개는 영향 관계가 서로 물고 물리는 Loop 형태를 띄기 때문에 이런 이름이 붙은 모양이다), Influence Diagram 이나 Cause-and-effect diagram 이라고도 한다.

영향관계를 보여주는 다른 도구들도 있지만 차별화 되는 것은 앞서 Causal-loop diagram 이라는 이름에서처럼 cause-effect 가 명확하지 않은 일반 사회적 현상을 나타내기에 명확하다는 것이다. 소위 닭이 먼저냐, 달걀이 먼저냐 같은 경우가 많지 않은가. 하나하나 간섭하는 부모 때문에 아이의 독립성이 결여되는 걸까? 아이가 제 일을 제대로 못하니 부모가 일일이 간섭하게 되는걸까? 사실은 둘 다 맞다. 이런 건 Fish-bone diagram 같은 걸로 나타내기 어렵다. 한 단면밖에 보여주지 못한다.

참고.

• http://www.developerdotstar.com/mag/articles/gray_diagram_of_effects.html – 이게 뭐지?
• http://agilecoach.typepad.com/agile-coaching/2009/10/how-to-create-a-diagram-of-effects.html  – 어떻게 그리지?

제목만 봤을 때는 기대를 했지만, 막상 책을 열어보니 깊이가 부족한 것이 아쉽다. 이것 저것 관련 자료들을 잘 정리한 것 이상의 인사이트를 기대하긴 어려울 것 같다.

바로 차를 내달려 1시간만에 도착한 곳이 ‘리버랜드’ 라는 곳. 휴가철이 지난 평일이라 역시 한산했다. 그럼에도 간간이 지나가는 보트들.

서약서 서명하고 몸무게 말하니까 교관이라는 사람이 조금 허접해 보이는 장비를 채워줬다. 담당 교관과 함께 시끄러운 간이 엘리베이터로 50m 높이의 점프대로 올라갔다. 줄을 서지도 않고 너무 빨리 진행되는 바람에 주변 경관을 구경할 틈도 없었다. 안되겠다 싶어 점프대에 서서 잠시 숨을 고르며 주변을 둘러봤다. 캬~ 역시 멋지다. 저 아래에는 혜정이가 나를 기다린다.

3, 2, 1, 번지!

공포와 짜릿함이 교차하면서 시간이 멈춰버린듯한 느낌. 아무런 소리도 내지 못하고 계속 떨어진다.

멋지네요!

• 주소: 1 Infinite Loop ㅋㅋ
• 전화번호: Home/Work/Cell/Fax 모두 같은 ..
  이건 뭐, W&L Balance가 아니라 W&L Unification 인가요?
• Objective: “I’m not afraid to start from the beginning” .. 그렇겠죠? ㅎ
• Work experience: Apple->NeXT->Pixar->Apple
  첫번째 Apple 관련해서.. “Learned many things, including do’s and don’ts for building executive teams” 흐흐흐흐
• Skill: “Vision Thing” 헉!

http://mbablogger.net/ 에서