[리뷰] 리치히키의 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 사이트를 한번 이리저리 구경하게 된다.
저런 사람들과 함께 일한다는 것은 어떤 느낌일까.

나도 저 안에 끼고 싶다.