[리뷰] 리치히키의 Maybe Not 강연을 보고

리치히키는 Clojure를 이끄는 리더이다. Clojure를 알지 못하여도 그의 발표는 너무나도 멋지다. 사실 단어의 사용이 너무 고급스러워서 때때로 못알아듣는다.
영어공부를 해야할 때인 것 같다.

이런 사람들이 발표를 하는 것을 보면, 정말 작은 것에 많은 고민을 한다는 생각을 한다.
리치히키는 null이라는 것을 시작으로 끝없는 고심을 하고 새로운 대안책을 제시한다.

null값이 만들어내는 비극을 그는 이 강연에서 설명해준다. 그리고 다른 언어들은 무엇을 하고 있는지 알려준다.
하스켈은 모나드를 사용한다. (Maybe)
스칼라는 여러가지 타입(?)으로 정의한다. (Any 등등등 꽤 많다)
코틀린의 Nullable타입
자바의 Optional

클로저는 리스프를 사용하며 함수형프로그래밍이다.
그러므로 새로운 타입을 생성하지 않는다.
클로저는 map을 이용하여 모든 것을 표현한다.

우리는 값을 넘기고 받을 때, 그 값들의 모음을 aggregate이라고 한다.
아래는 aggregate의 어원이라고 한다.
from ad- "to" + gregare "flock / herd"
바로 염소 같은 것들의 무리들이 움직이는 것이다. 바로 우리가 데이터를 쓰는 방식이다. 여러 무리들을 데리고 이리저리 돌아다닌다.
클로저는 이렇게 큰 자유를 가지고 있어서 저런 Nullable같은 것에 자유롭다. 값이 없다고? 그냥 넣지 않으면 된다.

하지만 spec이라는 라이브러리를 이용하기 시작하면 아주 동일한 문제를 가지게 된다.
spec은 동적프로그래밍을 하는 클로저에 타입과 비슷한 제약을 추가하는 것이다. 말그대로 스펙을 적어주는 것이다.

왜 spec을 쓸꺼면, 그냥 언어자체에서 타입이나 제약을 사용하지 굳이 맵을 쓴다음에 거기에 spec을 얹는 것일까?

그것은 바로 직교성 때문이다. A와 B가 직교하면 A의 변화에 B는 상관이 없게 된다.
그렇게 코드와 스펙을 나눈 것이다.
그러므로 빠르게 맵을 보내면서 개발을 하고, 정확한 스펙은 spec으로 지정해도 되는 것이다.

그러면 spec을 바꿔도 코드는 그대로 일 것이다. 코드를 바꿔도 spec은 상관이 없다.


각설하고 그런데 왜 여기서 null에 대한 이야기를 한 것일까?
spec에는 똑같이 필수 변수나 값이 옵션이 경우가 있다. 여기서 옵션인 경우가 문제가 된다. 그렇다. 우리는 여기에 값이 언제 올지 알 수 없다.
옵셔널은 아주 큰 특수성을 만든다. spec을 지정했지만 그것 하나하나에 특별한 경우가 생기면 비슷한 모양의 spec이 계속 생긴다.

리치히키는 자신의 설계 잘못을 인정한다. (난 언어개발자 중에 자신의 잘못을 인정한 사람을 찾기가 정말 힘들다.
그런데 그는 세미나에서 자신의 과오를 고백하고 쓰면 안되는 방식으로 쓰는 코드를 보면서 많은 고민을 해왔다고 한다.)

그리고 그는 새로운 해결책을 제시한다. 바로 spec을 다시 둘로 쪼개는 것인다.
그리하여 def/schema로 나뉘어 정의하는 것 같다.

어떤 개념을 def로 정의하고 해당 정의에 대한 형태를 schema로 정의하는 것 같다.

Clojure를 만져본지 꽤 되었지만 이런 세미나를 보면 어느새 Clojure 사이트를 한번 이리저리 구경하게 된다.
저런 사람들과 함께 일한다는 것은 어떤 느낌일까.

나도 저 안에 끼고 싶다.

[책리뷰] 객체지향의 사실과 오해 -조영호 저-

사실 2년 전에 서점에서 중간 정도 읽은 기억이 있다.

그 이후로 이 책에 언급한 몇가지 내용들이 계속 기억에 남았었는데,
시간이 지나고 그 내용들의 문장은 기억나지만 문맥이 흐릿해져 느긋하게 정독을 하고자 책을 구매했다.

이 책은 코드는 거의 없고 저자의 철학 혹은 저자가 공부해온 전문가들의 이론을 설명하는데 대부분을 사용한다.
UML도 찾기 어렵고 수도코드도 없다. 하지만 어떻게 개발을 해야 하는지 설명을 해주는 책이다.

이 책은 표지에서도 나오듯이 객체지향이랑 역할,책임,협력이라는 관점을 설명하는 것이 주 목적이다.
역할은 그 객체의 존재이유이며 책임은 그 역할이 어떤 책임들을 가지느냐로 정의된다고 나는 이해했다.
그리고 협력은 그 역할/책임들로 서로 어떻게 연결이 되느냐 하는 것이다.

이 책은 객체지향의 패러다임을 좀 더 이해하게 해주는 주옥같은 책이다.
사실 여러 언어를 사용해봤지만, 결국 문제는 사람이라는 걸 모르는 사람은 없을 것이다.
완벽한 제약을 걸지 않는 이상 우리는 결국 옳다고 생각하는 길보다는 쉬운 길을 택할 것이다.

블로그에 보면 하스켈을 공부하던 시기도 있었다.
하스켈을 공부하면서 느낀 점은 꽤나 많은 제약으로 인해 결국 하스켈이 원하는 개발방법을 따르려고 노력하지 않으면
개발을 할 수 없다는 것이다.

모나드를 이해하려고 노력하지 않으면 안되며, 함수지향적인 생각을 해야 한다.
스몰토크를 공부한 적은 없지만 아마 스몰토크도 그러할 것이다.

내가 개인적으로 좋아하는 리스프쪽 언어 또한 그 언어와 어울리는 개발방식이 있다. 그렇기에 그에 맞게 사람은 생각을 하게 된다.

하지만 우리가 생각하는 소위 많은 사람들이 사용하는 언어들(자바,파이썬,자바스크립트,C++,C#) 등은 사람들은 사로잡기 위해 모든 것들을 넣었다.
자바는 나의 작은 생각으로 객체지향언어라고 하기에는 정말 많은 부가기능들이 많다.
아마 모든 사람들의 니즈를 충족시키기 위해서 였을까?
그 깊은 뜻을 알지는 못한다. 아마 많은 사람들이 욕하면서도 쓰는 이유는 결국 어떻게든 개발을 하면 돌아가기 때문인 것 같다.

하지만 어떤 개발방식 예를 들어 객체지향/함수지향/TDD/RDD/DDD 등의 방식을 사용하려 한다면 자기자신을 제약하고 채찍질하여
통제해야 하지 않을까 싶은 생각이 이 책을 읽으면서 들었다. 물론 더더욱 공부해야 하는 것은 물론이고!

두고두고 읽으면서, 항상 기억을 하도록 해야겠다.

이 책은 위키북스의 조영호라는 분이 만든 책이다. 정말 감사하다는 말을 올려야 겠다. 새로운 책을 최근에 발행하셨다.
조만간 읽어야겠다.