프로그래밍에 대한 사고의 전환을 보여주는 생명 게임

[구르마]

3장에 나오는 생명게임은 클로져 프로그래밍의 진수를 보여주는 것 같습니다.

생명 게임이라는 문제를 푸는데 3가지 방식으로 보여 줍니다.

방식 1. 기존의 imperative한 방식, 곧 index를 이용하는 방식

방식 2. 시퀀스를 이용하는 방식.

방식 3. value를 이용하는 방식.

책에서는 방식 1보다는 방식 2가 더 좋다고 하지만, 솔직히 그런가 싶습니다.

왜냐면 neighbours를 구하는데 단지 index를 쓰냐, 아니면 시퀀스를 쓰냐만 차이가 있을 뿐인데

그걸 이해하는데 있어서는 방식 2가 훨씬 더 어렵더군요.

반면 방식 3은 너무나도 간결하고, 무릎을 탁치며 '이렇게 절묘할 수가!'하는 생각이 들게 하는 방식입니다.

이 세가지 방식을 보면서 데이타를 구성하거나 다루는데 있어 다음과 같은 방식의 우선성을 생각해 보게 됩니다.

인덱스 < 시퀀스 <<< 값

책에서도 나왔듯이 프레드릭 브룩스나 에릭 레이몬드 같은 대가들은 프로그램의 로직이나 플로차트, 코드, 구현보다는

자료구조가 더 중요하다고 했습니다. 자료구조가 정해지면 나머지는 부수적인 것이 되는 것이죠.

자료구조를 나타내는데 있어, 인덱스나 시퀀스는 비본질적인 것이고, 값이 본질적인 것이 되는 거죠.

클로져의 장점은 그것이 우리로 하여금 다른 언어에 비해 비본질적인 것이 아니라 본질적인 것에 더 집중하도록 도와준다는 점에 있는 것 같습니다. 본질적인 것을 표현하고 다루기 쉽게 해준다는 점이죠.

위의 방식 1과 방식 2는 데이타의 모델링을 각각 인덱스와 시퀀스 기반으로 하고 있습니다. 

인덱스 방식과 시퀀스 방식으로 문제를 풀어나가는 것 때문에 발생하는 저 복잡성을 보십시요.

특히 방식2를 이해하기 위해서 저는 몇 시간을 들여서 팽창하면서 수축하는 시퀀스 지도를 그리면서 쫒아가야만 했습니다.

반면 방식 3은 오직 값만을 다루고 있습니다. live cell의 좌표. 단지 이것만이 필요한 모든 것입니다.

dead cell의 좌표는 아예 등장하지도 않습니다. 단지 live cell 좌표 집합의 연대기적 계열이 곧 생명 게임인 것이죠.

따라서 이 계열을 만들어내는 함수만 작성하면 되는 것이었기에 코드가 그토록 간결할 수가 있었던 것이죠.

결국 우리가 데이타 모델링시 값에 의하지 않는다면, 본질적인 것에 의하지 않는다면

클로져라고 해도 우리를 예전의 프로그래밍 방식에서 벗어나게는 할 수 없을 것입니다.

우리가 절차형에서 객체지향으로 사고를 전환해야 했듯이(C처럼 짜여진 자바 코드를 우리는 얼마나 많이 봐왔습니까?)

클로져는 우리가 객체지향에서 값중심 사고로 전환하기를 요구하는 것 같습니다.

이러한 사고의 전환을 위한 Rich Hickey의 pdf 자료가 조금 도움이 될 수도 있을 듯 합니다.

Are We There Yet?

 http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit2009.pdf

 

이제 OOP에서도 떠나야 하는 건가요?

[구르마]

생명 게임 다음 예제인 미로 발생기는 값중심 데이타 모델링으로 직행하고 있네요.

정말 이렇게 짧은 코드로 저런 복잡한 미로를 만들어 낼 수 있다는 것이 놀라울 따름인데요.

제가 여기서 특히 주목하고 싶은 부분은 데이타 모델링을 하는 과정입니다.

p.146에서는 미로를 발생하는 윌슨의 알고리즘에서 다음과 같은 entity를 뽑아냅니다.

1. location 
   
2. the visited state
   
3. the maze itself
   
4. random walks
   
5. exit directions. 
   

이것은 OOP에서 디자인 단계에서 사용자의 요구사항을 분석한 뒤 클래스가 될 후보를 뽑는 과정과

비슷합니다. OOP 모델링 기법에 따라 UML을 작성할 것이고,  결국 위 entity들은  클래스가 될 것입니다.

하지만 값중심 데이타 모델링은 전혀 다른 방식으로 location, wall, maze는 다음과 같이 표현됩니다.

location : 좌표의 벡터, [0 0]

wall : locaton의 집합 #{[0 0] [1 0]}

maze : wall의 집합 #{#{[0 0] [1 0]} #{[1 0] [2 0]} ...}

자 이제 이것을 실제 클로져 코드과 자바 코드로 표현할 때 어떻게 되는지 보시죠.

클로져 표현

; location

[0 0]

; wall

#{[0 0] [1 0]}

; maze

#{#{[0 0] [1 0]} #{[1 0] [2 0]} #{[2 0] [3 0]} ...}

자바 표현

Class Location {

  private int x, y;

  public Location (int x, int y) {

    this.x = x;

    this.y = y;

  }

  int getx() {

    return x;

  }




  int gety() {

    return y;

  }

}




Location loc = new Locatin(0, 0);

Class Wall {

  private Location[2] locs;

  public Wall(Location loc1, Location loc2) {

    this.locs[0] = loc1;

    this.locs[1] = loc2;

  }

  ...

  ...

  ...

}

Wall wall = new Wall(new Location(0, 0), new Location(1, 0));

Class Maze {

  private ArrayList walls = new ArrayList();

  public void add(Wall wall) {

    walls.add(wall);

  }

}

Maze maze = new Maze();

maze.add(wall1);

maze.add(wall2);

maze.add(wall3);

...

클로져에 비해 자바가 월등하게 복잡해졌습니다. 

자바가 OOP라 클래스 정의부 때문에 억울해 할 수도 있겠습니다만,

location과 wall을 다루기 위해서 자바는 결국 index나 List등을 사용해야 하기 때문에

클래스 정의말고 데이타를 조작하고 처리하는 코드도 엄청 복잡해졌을 겁니다.

그런데 이런 차이가 발생하게 되는 근본 원인은 무엇일까요?

중요한 것은 이 차이는 클로져와 자바라는 언어 자체의 차이에서 나온 것은 아니라는 것입니다.

왜냐면 클로져로도 location을 defrecord로 얼마든지 타입 정의할 수 있으니까요.

이런식으로 했다면 클로져 코드도 만만치 않게 복잡해졌을 겁니다.

그렇다면 문제는 위의 짧은 저 클로져의 코드는 도대체 뭐냐는 것이죠. 저것은 왜 저렇게 짧아질 수 있을까요?

이 차이는 언어의 차이가 아니고 데이타 모델링 방식의 차이입니다.

즉 OOP 모델링 방식과 값중심 모델링 방식이 저러한 차이를 만들어 낸 것입니다.

p.146 18번째 줄 에는 다음과 같은 문장이 있습니다.

"a location is just a (natural) identifier."

p.137 10번째 줄에는 natural identifier에 대해 다음과 같은 문장이 있습니다.

"Natural identifiers are opposed to synthetic or surrogate identifiers, where the latter

are usually strings or an artificially generated number, akin to sequences or autoincrements

in databases or object references themselves in most object-oriented languages.

Thus, synthetic identifiers are by definition artifacts of incidental complexity"

여기서는 자연 식별자(natural identifier)와 합성 식별자(synthetic identifier)가 대비되어 나오고 있습니다.

자연 식별자는 데이타 그 자체가 자신을 식별하는 식별자를 말합니다.

합성 식별자는 데이타를 식별하기 위한 별도의 식별자를 말합니다.

클로져 코드에서 wall을 #{[0 0] [1 0]}으로 표현할 때 이것은 데이타 자체가 자신을 표현한 것입니다. 즉 값 자체만으로 자신을 식별한 것이죠. 자연 식별자인 것이죠.

반면 자바코드에서는 wall을 표현하기 위해 wall이라는 변수명이 필요했는데, 이것이 합성 식별자인 것이죠.

자바 코드가 복잡해졌던 이유는 합성 식별자들이 들어가 있기 때문인 것입니다.

합성 식별자가 불필요하게 복잡성을 야기하는 것이죠.

프레드 브룩스가 30년 전에 "No Silver Bullet"에서 소프트웨어 개발에 있어서 본질적 복잡성과 우연적 복잡성을 구분했습니다. 본질적 복잡성은 제거할 수 없지만, 우연적 복잡성은 제거할 수 있다면서 고수준 언어(당시엔 포트란)가 그런 역할을 할 수 있다고 했습니다.

자바가 C언어의 포인터라는 우연적 복잡성을 야기시키는 요소의 제거를 통해 많은 복잡한 비즈니스 문제를 해결한 것을 보아왔던 것 처럼, 이제는 합성 식별자라는 우연적 복잡성을 야기시키는 요소를 잘 피해 갈 수 있는 언어인 클로져를 보고 있는 것입니다. 

이번 예제들을 통해 OOP 디자인 방식은 결국 우연적 복잡성이 포함되는 것을 막는데 매우 취약할 수 있다는 사실을 깨달았습니다. 그동안 CRC로 설계하고 TDD로 개발해 오던 저에게는 정말 당혹스럽기까지 한 순간인 것 같습니다.

이 책을 공부하면서 클로져 코드들이 주로 변수명이나 클래스명 등등  어떤 식별자들이 없는 것이 

별로 그렇게 왠지 코드답지 못하다는 느낌이 있었습니다. 그리고 자바 코드를 보면서 '음 그래~ 이제 코드를 보는 것 같군' 했었는데요.이제는 위에서처럼 자바 코드들이 정말 추하게 보이네요. 저 말도 않되는 복잡성들의 코드들~~

리치 히키가 다음과 같은 말을 했다네요.

"Familarity Hides Complexity"

왜 이런 말을 했는지 정말 충분히 공감이 되는 순간입니다!

이상입니다.

감사합니다.

2012년 9월 5일 수요일 오후 7시 17분 32초 UTC+9, 구르마 님의 말:

[kumjiki]

String string = new String("string");

Array<String> arrayString = new Array<String>();

전 이런 거 쓸 때마다 거북스러웠어요;;

..라고 한 줄 코멘트를 달고 싶은데 메일링 리스트라 좀 어색하네요 ^^;

함수형 프로그래밍이란게, 

데이터 사이의 매핑을 정의하는 (이게 함수죠) 것 자체가 바로 프로그래밍이라

말씀하신 일종의 인식의 전이 같은 게 발생하지 않나 하고

개인적으로 생각합니다.

이것을 요렇게 바라본 것이 저것이다라고만 하면 프로그래밍이 되다니..

(음 '프로그래밍'이란 표현이 적절하지 않은 것 같네요. 절차적인 느낌이라)

2012년 9월 6일 오후 3:56, 구르마 <psk...@gmail.com>님의 말:

--
Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹에 가입했으므로 본 메일이 전송되었습니다.

웹에서 이 토론을 보려면 https://groups.google.com/d/msg/lisp-korea/-/bx30E442MCgJ을(를) 방문하세요.

이 그룹에 게시하려면 lisp-...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 lisp-korea+...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/lisp-korea?hl=ko에서 그룹을 방문하세요.

[구르마]

아래 표는 wilson's 알고리즘의 영문 문장과 클로져 구현 코드간에 일대일 매칭 관계를 보여주고 있습니다.

클로져 코드 라인 총 14개중에 영문 문장을 그래도 표현하지 않는 라인은 단지 6개 뿐입니다!

결국 클로져 코드는 인간의 자연어를 거의 같은 수준의 추상화 수준으로 프로그래밍 코드를 만들어 낼 수 있다는...@@;;;

1	(defn maze	X
2	[walls]	X
3	(let [paths (reduce (fn [index [a b]]	X
4	(merge-with into index {a [b] b [a]}))	X
5	{} (map seq walls))	X
6	start-loc (rand-nth (keys paths))]	wilson's 1 : random pick a loc.
7	(loop [walls walls	X
8	unvisited (disj (set (keys paths)) start-loc)]	wilson's 1 : mark it as visited.
9	(if-let [loc (when-let [s (seq unvisited)] (rand-nth s))]	wilson's 2 : mark visited, random pick unvisited loc.
10	(let [walk (iterate (comp rand-nth paths) loc)	wilson's 3 : perform random walk.
11	steps (zipmap (take-while unvisited walk) (next walk))]	wilson's 3 : until visited loc.
12	(recur (reduce disj walls (map set steps))	wilson's 4 : remove walls.
13	(reduce disj unvisited (keys steps))))	wilson's 4 : mark visited.
14	walls))))	wilson's 2 : return maze.

2012년 9월 6일 목요일 오후 3시 56분 1초 UTC+9, 구르마 님의 말:

[박상규]

2012년 9월 6일 오후 8:27, kumjiki <kum...@gmail.com>님의 말:

String string = new String("string");

Array<String> arrayString = new Array<String>();

전 이런 거 쓸 때마다 거북스러웠어요;;

저도 그렇습니다.

 

..라고 한 줄 코멘트를 달고 싶은데 메일링 리스트라 좀 어색하네요 ^^;

함수형 프로그래밍이란게, 

데이터 사이의 매핑을 정의하는 (이게 함수죠) 것 자체가 바로 프로그래밍이라

말씀하신 일종의 인식의 전이 같은 게 발생하지 않나 하고 

개인적으로 생각합니다.

이제 시작인 것 같네요. 아직 매크로가 남아있다는..