예전 내가 썼던 블로그가 갑자기 떠올랐다. http://ageldama.blogspot.de/2012/03/nodejs-haskell-io-monad.html

내용은,

1. 콜백헬 싫다.
2. 그런데, 하스켈의 IO Monad처럼 imperative code을 작성할 수 있으면, 3. 이것들끼리의 제어권을 주고 받는걸 event loop측에서 제어하면서도, 4. 각각의 statements끼리 그냥 주욱 흐름대로 작성한것과 다르지 않게 짜기 쉽다.

굳이 이 얘기 왜 하냐하면, 사실 요즘에 RxJava2 보고, Python3에서 asyncio 같은거 보면서 이런거, 그러니까 결국엔 모나드스러운 체이닝을 구현하고, 그걸로 콜백들을 풀어서 잘 해결하고 있는거 같은 인상이 들어서.

결론? 내 아이디어 부심. 그리고 조금 더 잘 생각하고 실제로 어떻게 구현할지 고민해봤다면 좋았을거라는, 나 자신의 능력 한탄하기.

SBCL은 멀티쓰레딩을 잘 지원하는 커먼리습 컴파일러이지만, 공식사이트에서 제공하는 리눅스 바이너리가 아니라 OSX 바이너리는 멀티쓰레딩이 꺼져서 컴파일되어있다.

http://www.sbcl.org/manual/#Threading

요건 자기 리습에서 *features* 을 평가해서, 리스트에 :threading, :sb-thread 같은 키워드를 포함하는지 확인해보면 알 수 있다.

어쨌든 지원하지 않을 경우에, 컴파일을 다시 해야하는데, 우선 준비물은 GNU CLISP 같은 여기저기서 잘굴러가고 적당히 설치해서 부트스크래핑에 이용 가능한 커먼리습 컴파일러를 준비한다.

다음 포스트를 참고해서 작업해봤다.:

http://haminhvuong-blog.tumblr.com/post/22109095116/compile-sbcl-with-multi-thread-enabled-on-os-x

create customize-target-features.lisp with content

1
2
3
4
5
6
7
8

(lambda (features)
      (flet ((enable (x)
               (pushnew x features))
             (disable (x)
               (setf features (remove x features))))
        ;; Threading support, available only on x86/x86-64 Linux, x86Solaris
        ;; and x86 Mac OS X (experimental).
        (enable :sb-thread)))

그리고 다음의 커맨드들로 빌드하고 설치 끝.

요즘엔 그냥 독일 생활, 도르트문트에 조금씩 더 적응해서 사는게 편안해졌다.

식기세척기, 세탁기, 커피머신, 팀사람들, 출퇴근길, 놀러가는 동네, 구경가는 전자제품상가.

그냥 어느정도 이제는 독일어를 하나도 못하지만, 적어도 팀 사람들과는 정도 붙이고 재밌게 잘지내가고 있는거 같다.

커피를 캡슐커피 기계가 있어서 적당히 입맛을 붙이고 마셔보고있다. 괜찮다. 토스트랑 꿀이랑 사다가 가볍게 먹고 해결하고 살고있다.

비자도 4년짜리 블루카드도 됐고, 마음이 편안해졌다.

책은 열한계단 을 읽고 많은 생각을 해봤다. 체체파리의 비법, 시녀이야기, 그리고 테드 챙의 당신 인생의 이야기 을 읽어볼까 생각하고 있다.

그냥 최근의 자바나 node.js, 특히 자바의 RxJava 같은걸 보다보면, ¹ 뭔가 언어적으로 지원하지 않는걸 뜯어내서 동작하게 만들고 너무 골치가 아프게 만들어지는건 아닌가 생각도 든다. (사실상 콜백. ㅎㅎ)

그리고 지금 한창 JDBC이라던지 이런 입출력과 관련된 부분에서 비동기 방식을 지원하려고 많은 변화가 있을만한 시점인거 같다.

예상은 아마 몇년간은 이런 혼란이 자바쪽에는 계속 있을거 같다는 생각이다. (async/await 같은 키워드가 추가되고 하려면 자바에 몇년이 더 걸릴지는 아무도 모를거 같다. lambda이 추가되는데 얼마나 오래걸렸었는지 추억해보자..)

그런데, “아몰랑 닥치고 얼랭씁십다” 이런 얘기를 하고 싶은건 아닌데, 그래도 사실 자바로 이런걸 하고 있다보면, 얼랭에서 이미 잘 해결한 문제를 왜 이렇게 고민하고 있어야하고, 왜 이렇게 저수준의 작업을 매번 프로젝트를 만들때마다 해야할까 싶다.

https://immutables.github.io/ 요즘 이걸 살짝 봤는데, 재미있었다.

그런데 일단 깊이보거나 써보기 전에 드는 걱정은,

1. 이거 기존의 몇몇 프레임웍이나 라이브러리들이랑은 친하게 지내기 어렵지 않을까.
   • 왜냐하면, 대부분의 POJO에 연관된 생성단계에서, default constructor 와 setter-methods을 갖고, 값을 세팅하는 경우가 대부분인데,
   • 예를들면, 대부분의 ORM 프레임웍들이나 POJO으로 JSON등을 Deserialization해서 직접 객체를 생성할 책임을 프레임웍이나 라이브러리가 가져가는 경우에 대부분.

…그러면 결국 말짱황인거 같다.. 아무리 accessor 메서드들 boilerplate으로 생성하는거 막아주는게 좋다고 해도, 솔직히 그냥 한번 IDE에서 생성하고 평범하고 조금 멍청하게 만들어놓고 쓰는게 더 낫겠다는 생각이든다.