Clojure에 대한 오해
Clojure는 Lisp 방언으로 Lisp이 가진 한계(?)를 그대로 가지고 있다. 여기서 한계란 언어 자체의 한계를 뜻하는 것이 아니라 Lisp을 사용하지 않는 사람들의 선입견, 오해, 편견을 말하는 것이다. 알고나면 오해였다는 것을 깨닫겠지만 이 선입견을 극복하기는 쉬워 보이지 않는다. 사람들이 Lisp에 거부감을 느끼는 가장 큰 이유는 다음 두 가지가 아닐까 생각한다.
내 이 세상 도처에서 쉴 곳을 찾아보았으나, 마침내 찾아낸, 컴퓨터가 있는 구석방보다 나은 곳은 없더라.
Clojure는 Lisp 방언으로 Lisp이 가진 한계(?)를 그대로 가지고 있다. 여기서 한계란 언어 자체의 한계를 뜻하는 것이 아니라 Lisp을 사용하지 않는 사람들의 선입견, 오해, 편견을 말하는 것이다. 알고나면 오해였다는 것을 깨닫겠지만 이 선입견을 극복하기는 쉬워 보이지 않는다. 사람들이 Lisp에 거부감을 느끼는 가장 큰 이유는 다음 두 가지가 아닐까 생각한다.
거의 2년만에 블로그에 글을 쓴다. 그동안 티스토리 블로그를 썼는데, 모두 깃헙(GitHub)으로 옮겼다. 깃헙 페이지를 만들면 깃헙 저장소를 블로그로 쓸 수 있다. 만드는 방법도 단순하다. 깃헙에서 {아이디}.github.io
로 저장소를 만들면 된다. 이 저장소에 있는 HTML 파일은 브라우저에서 그대로 볼 수 있다. 정적 사이트 생성기로 사이트를 생성해 깃헙 저장소에 올리면 된다.
쥐메일 주소에 +
를 더해 표식을 남길 수 있다. 즉, 쥐메일 주소가 xxx@gmail.com
이라면 xxx+shopping@gmail.com
과 같이 할 수 있다.
이건 내가 새로운 프로그래밍 언어를 배울 때마다 만들어 보는 간단한 데모 프로그램이다. 미리 정해진 규칙에 따라 화면에 계속 그림을 그린다.
회사에서 작성하는 모든 소스 코드에 대해 Quality Practice(이하 QP)를 적용하고 있다. Java 코드에 대해서는 Findbugs, PMD, Checkstyle과 같은 도구를 사용해 소스 코드를 분석한다. 물론 각 도구를 적용할 때의 규칙(rule)은 QP 담당자였던 내 주관적 판단(또는 취향)에 따라 조정한다.
CI서버에서 대략 삼분의 일 정도의 테스트가 실패하고 있었다. 로그를 확인해보니 어이없게도 실패하는 테스트에서 NoSuchMethodError
가 발생했고, 모두 Google의 컬렉션 라이브러리를 사용하는 부분이었다. 이클립스에서 테스트를 실행시킬 때는 아무런 문제가 없는데 CI 서버에서는 실패하는 것이었다.
Hudson에서 JsTestDriver를 이용한 커버리지 분석 설정에서 JsTestDriver로 작성한 테스트에 대해 커버리지를 어떻게 볼 수 있는지 설명했다. 그런데 이렇게 테스트 커버리지를 분석할 때 문제가 하나 있다. 외부 라이브러리가 커버리지 분석 리포트에 포함되어 커버리지 결과가 왜곡된다는 점이다.
XML 파일이 프로그램을 죽일 수도 있다는 생각은 하지 못했다. XML은 그저 텍스트일 뿐이고 프로그램은 그저 파일을 읽어서 처리할 뿐인데... 그런데 다음과 같은 파일을 보고서야 그럴 수도 있다는 것을 알게 되었다.
나 같은 보통 정도의 두뇌를 가진 사람에게 확률은 이해하기 어렵기만 하다.
얼마전 회사 동료 한 명이 간단한 확률 문제를 물었다. 하트, 다이아몬드, 스페이드, 클로버가 각각 13장씩 있는 총 52장의 카드에서 1장을 골랐을때 이 카드가 하트일 확률은 얼마인가 하는 문제였다. 여기까지는 쉽게 생각할 수 있다. 13/52 = 1/4다. 동료가 문제를 약간 변형해 질문했다. 52장의 카드 중 1장을 골라 따로 보관한 다음, 3장을 추가로 골라 뒤집어보니 모두 하트가 아니었다. 이때 처음 고른 카드가 하트일 확률은 얼마일까?
책을 읽다가 재미있는 인용구를 발견했다. SQL Antipatterns 14장 Fear of the Unknown의 시작부분에 있는 인용문인데, 상당히 쉬운 영어로 오묘한 뜻을 전달하는 것 같은 느낌이 들었다.