15 년 12 월 12일 발표자료

1. 함수형 언어 클로저를 만나다
SliPP 양완수
2015.12.12

2. 대안언어들 관심을 두기 시작
• 빠른 아이디어 검증
• 운영 시 적합한 도구를 뚝딱!
• 먼가 있어보고 싶은데?

3. LISP 과의 첫 만남
• SICP ( Structure and Interpreta:on of
Computer Programs)
• hBps://mitpress.mit.edu/sicp/

4. Scheme
• 머 이런 요상한 언어가 다 있지?
• 그런데 이상하게 끌려…해커가 되는 건가?

5. 첫번째 스터디
• Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)
• hBps://groups.google.com/forum/?
fromgroups#!forum/lisp-korea

6. Clojure 와 만나다.
• Clojure 도 Lisp 이래!!
• 그리고 JVM에서도 돌아간데~~

7. 첫번째스터디 도망~
• 머야? 이 사람들 이클립스도 안쓰잖아!?
• 친숙함의 문제
• 적용할 곳을 찾지 못했다?
• 그저 단순한 호기심

8. 두번째 스터디
• Slipp (hBp://www.slipp.net)
• 2013년 겨울 쯤
• 같은 세계사람들
• 라이브 코딩하며 활발한 토론

9. 어라?
• 코딩이 재미있네~
• 명령이아닌 선언적
• 리스트의 해석
• LEGO 조립같은?

10. 아쉬운 마무리 그리고 느낀점
• 선언적 사고를 통해 우연적 복잡성이 낮아진것 같
다.
• REPL 로 인해 테스트 먼저의 흐름을 잊었다.
• 그리고 쉽지는 않다.
• 결국 친숙함이 문제
• 클로저를 어디다 써먹지에 대한 고민이 별로 없어
• 첫번째 스터디와 마찬가지로 그저 호기심으로
끝!

11. 세번째 스터디
• 이전 스터디의 아쉬움
• 사내 스터디 조직
• 일단 미끼는 JAVA 8
• 함수형에 대해서 진지해짐

12. 뒤를 돌아보게 되다.

13. 동시성 작업을 해본적이 있었나?
• 아직까지 한번도 없다.

14. 동시성 작업을 해본적이 있었나?
• Lock 관리는 비지니스 복잡성이 아니다.

15. 최근만든 객체가 재사용된적 있나?
• 객체의 유연함은 무한대
• 유연함이 재사용성을 깨트리고 있다.

16. 변화에 빠른 대응이 가능했나?
• Agile 시대
• 신중한 설계가 발목 잡는다.

17. 변화를 막을 수 없었다.
• 기본적으로 Mutable
• 변화가 여러 곳에 흩어져 있다.
• 접근 통제로 인해 코드를 이해하고 테스트하기 어
렵다.

18. 코드는 읽기 쉬웠나요?
• 명령방법의 표준이란 존재하지 않는다.
로컬변수 선언 로컬변수 할당
분기문
반복 제어 탈출

19. 코드는 읽기 쉬웠나요?
• 객체간의 관계에도 표준이란 존재하지 않는다.
• 여러 곳에 흩어진 상태의 변화는 코드를 이해하기
힘들게 만든다.

20. ORM ?
• 대부분의 프로그래밍은 데이터의 관리의 문제를
다룬다.
• 영속성에 대한 관리는 비지니스의 복잡성이 아니
다.
• O O가 부재한 상황에서 Rela:on Mapping은 무
의미하게 느껴진다.

21. 노력들
• Design PaBern
• SOLD
• Clean Code
• Framework

22. 좀 나아지셨나요?

23. 표준이란 존재하지 않는다.
• 개취 ( 개인의 취향)

24. 결국 우연적 복잡성 증가
• 우연적으로 발생하는 복잡성

25. 왜 빠져들고 있을까?

26. 함수형프로그래밍은 단순함으로의 복귀

27. Clojure ?
• JVM, Javascript(ClojureScript), CLR 에서 컴파일
되어 실행되는 동적언어이며 함수형 언어이다.
• Rich HicKey가 만들었다.

28. 불변성
• 불변성은 멀티쓰레드 환경에서 안전하다.
• 영속적 자료구조
( def a ’ ( 1 2 3 ))
( def b ( cons 4 a ))

29. 부수효과가 없는 함수
• 오로지 인자로만 결과가 만들어지고 반환값으로
만 외부에 영향을 준다.
• 데이터의 불변성은 부수효과를 없게 만든다.
• 부수효과가 없는 함수는 테스트하기 쉽다.

30. 고계함수
• 함수를 인자로 받고 동적으로 함수를 반환하는 함
수를 다루는 함수
• 코드 구성을 쉽게 해준다.
(defn blank? [s] ( even? #( Character/isWhitspace % ) s ))
(filter #(even? %) [1 2 3 4] ))
à ( 2 4 )
(map #(< 3 % ) [1 2 3 4] ))
à ( 1 2 )

31. 익명함수
• 함수가 하는 일에만 충실하면된다.
• 그 많은 Interface 명을 외우지 않아도 된다.

32. 선언적 프로그래밍
• 명령형적인 프로그래밍에서는 문제 자체에 집중
하지 못하기 때문에 Bug발생의 빈도가 높다.
로컬변수 선언 로컬변수 할당
분기문
반복 제어 탈출

33. 선언적 프로그래밍
• 불필요한 명령이 없어 마치 정의 하는 듯 보인다.
• 선언을 통해 세부 구현을 숨기고 오로지 함수인자
와 반환되는 값에 관심을 가질 뿐이다.
• 코드의 이해도가 높아진다.
(defn blank? [s] ( even? #( Character/isWhitspace % ) s ))

34. 데이터는 시퀀스
• 시퀀스 추상화
• 강력한 시퀀스 라이브러리

35. 객체라는 것은 데이터의 집합일뿐
• 객체를 데이터의 집합으로 본다면
• 조합기에 의한 유연성을 보장 받을 수 있다.
• 변화에 유연해진다.
• 단순히 고계함수에 인자로 넘겨 줄 함수구현 만
변경하면된다.

36. 필요하면 만들어 쓸 수 있다.
• 클로저는 Lisp 의 방언
• Lisp 의 강력한 무기 중 하나 매크로
• 우회로 인한 우연적 복잡성을 제거한다.

37. Java 와 상호작용이 쉽다.
import java class
class 생성 및 사용
sta:c method 사용

38. Java 의 모든 것을 가져다 쓸 수 있다.
• hBps://clojars.org/

39. FP 위에 OO 를 양념으로…

40. 클로저에 대한 오해 I
• 괄호,괄호,괄호
– 실제 비교해보면 약간 많을 뿐 그렇게 과하지 않다.
– 다른 LISP 과 다르게 괄호를 많이 제거 했다.
• 전위표기법은 불편해
– 자 어떤가?
( + 1 2 3 4 5)
( 1 + 2 + 3 + 4 + 5)
hBp://ntalbs.github.io/2014/04/08/clojure-fallacy/

41. 클로저에 대한 오해 II
• 현업에서 사용하지 않는다.
– hBp://clojure.org/Companies
– Amazon, Neglix, Facebook 등 175여개 기업에서 사
용중이다.

42. 결론
• OOP ,FP 가 만병통치약은 아니다.
• 서로 부족한 부분을 보안 해 줄 수 있는 관계

43. 감사합니다.