2015.10.24 쿠팡에서 진행된 제 4회 Lisp 세미나에서, 2번재 세션으로 발표한 PT입니다. ^^;

1. Clojurescript로 하는
함수형 UI 프로그래밍

2. 순서
● UI 프로그래밍은 어려워 - 그 복잡성
● 어떻게 복잡성은 제거되는가
○ CSP / FRP / ReactJS / Flux
● 클로저스크립트의 ReactJS 랩퍼들
● HTML5 어플리케이션
○ Node-webkit / Atom Shell / CEF3

3. UI 프로그래밍은 어려워
● UI 프로그래밍의 복잡성
○ UI 컴포넌트 : 버튼, 이미지, 리스트, 트리, 콤보박스, 레이아웃, 윈도우 등등.
○ 비동기 입력 : 마우스/키보드 이벤트등의 장치 입력, 넷트웍 입력, 백그라운드 서비스 등등.
○ 비즈니스 로직상의 상태들을 관리해야 함.
○ 각 종 입력에 따라 상태들이 동적으로 변함 : 비즈니스 로직상의 상태, UI 컴포넌트의 상태.
● 상태 관리의 복잡성을 처리하기 위한 기존의 도구가 너무 열악
○ UI 컴포넌트의 상태 관리를 위한 도구
■ OOP : 컴포넌트 구성.
■ MVC 패턴들 : 비즈니스 영역과 뷰 영역의 상태 분리를 위한 어플리케이션 아키텍쳐.
○ 비동기 입력들의 상태 관리를 위한 도구
■ 콜백 : 이벤트나 각종 입력을 처리하기 위한 비동기 처리 함수.

5. UI 프로그래밍은 어려워
Test is enough?

6. UI 프로그래밍은 어려워
바보는 복잡성을 간과한다. 실용주의자는 복잡성을 견디어 낸
다. 어떤 이는 회피한다. 천재는 복잡성을 제거한다.
- 알랜 펄리스(Alen Perlis)의 프로그래밍 경구

8. 복잡성 제거
● 복잡성의 제거 -> 단순성 추구
○ 우연적 복잡성의 제거 : 도구의 개선
○ 본질적 복잡성의 완화 : 세계에 대힌 인식의 전환
● UI의 2가지 주요 복잡성
○ 비동기 입력 처리의 상태들
○ UI 컴포넌트들의 상태들
● 이 복잡성은 어떻게 제거 될 수 있는가?

9. 비동기 입력 처리에서의 복잡성
UI 컴포넌트들상에서의 복잡성

10. 비동기 입력 처리에서의 복잡성
● GOTO Statement Considered Harmful - Edsger W. Dijkstra
○ Goto의 제거 추상화 : if, for, switch-case, subroutine(procedure)
○ 구조적 프로그래밍(structured programming)
● Callback is modern goto
○ 콜백은 Goto다 : 특히 시간과 관련된 Goto (When something happens, do this)
○ 특성 : 비동기적, 언제 실행될 지 모르는. 순차적이지 않다.
○ 콜백 제거 추상화 : CSP / FRP
○ 비동기 프로그래밍

11. 비동기 입력 처리에서의 복잡성 제거 - CSP
● “Communicating Sequential Processes” by Tony Hoare, 1978
○ 세마포어(1963)를 만든 Edsger W. Dijkstra 가 서문 작성.
○ 컴퓨터 산업이 어느 정도 발전하면서 Concurrency를 본격적인 문제로 인식됨.
○ 람다 연산이나 튜링 머신은 동시성에 대한 고려가 없는 sequential computation 수학
○ process 대수라는 수학의 한 분과로서 Concurrency를 수학으로 정식화.
○ parellel process를 마치 sequential 하게 보이게 하는 것.
■ 채널을 통한 메시지 전달 : 푸쉬-풀 기반 큐
■ 채널 과 프로세스가 모두 1급.
■ 채널을 매개로 하여 프로세스간의 제어를 시퀀스하게 조절.
● Occam, JCSP, NewSqueak, Go Lang, Clojure
● Clojure : core.async 라이브러리

12. 비동기 입력 처리에서의 복잡성 제거 - FRP
● Functional Reactive Programming
● 사용 사례 : robotics, music synthesis, animation, game, gui 등
● Fran, “Function Reactive Animation” by Conal Elliott and Paul Hudak, 1997
○ Behaviors 와 Events 라는 개념을 도입
● Elm, “Elm: Concurrent FRP for Functional GUIs” by Evan Czaplicki, 2012
○ Signals can also be transformed and combined.
● Signal(Behavior)
○ time-varying values : mutable values, state.
● FRP inspired
○ Observable Stream: ReactiveX(Rx.Net: MS, RxJava: Netflix, RxJS: MS, RxSwift)
○ EventStream : Bacon.js

13. FRP 와 CSP
● CSP(core.async)
○ light-weight multi-thread 기반
○ low-level library.
● FRP
○ 시그널은 CSP의 채널로 쉽게 구현됨.
○ 보다 추상화 수준이 높다.
● Rich Hickey와 David Nolen은 FRP를 비선호
○ light-weight multi-thread 기반이기 때문에 동시성에 보다 충실하다고 볼 수 있음.
● 하지만 FRP에는 놓칠 수 없는 중요한 개념이 있다.
○ Rich Hickey나 David Nolen에게는 아마도 암묵적 지식
○ 하지만 이것은 명시적으로 인식할 필요가 있다.

14. FRP - 시그널
● 함수형 프로그래밍(FP)
○ 상태(mutable value, side-effect)를 격리.
○ immutable value를 입력과 출력으로 하는 함수들의 조합으로 문제를 해결 : F(x)
○ world -> v1 -> F1 -> v2 -> F2 -> v3 -> F3 -> v4 -> world
● “Are We There Yet?” - Rich Hickey
○ Value : an immutable magnitude, quantity, number.
○ Identity : A putative entity we associatie with a series of causally related values over time.
○ State : Value of an identity at a moment in time
○ Time : Relative before / after ordering of casual values

16. FRP - 시그널
● Signal(Behavior)은 중요한 개념이다.
○ time-varing value
○ 즉 상태를 하나의 값으로 추상화.
○ 그러면 상태는 다시 함수로 처리할 수 있는 value로 취급.
○ FP에서 멀리했던 상태를 value로 볼 수 있는 관점을 제공해서 FP가 다룰 수 있는 영역을 확장.
○ 시간상 미래에 계속 값이 발생하는 Identity
■ core.async(CSP)의 채널은 Queue Identity
■ [v1, v2, v3, v4, ?, ?, ?, ...)
○ Elm : Time Signal / Keyboard Signal / Mouse Signal / Input Signal
● FRP의 헤스켈 커뮤니티에서의 정의
○ “FRP is about handling time-varying values like they were regular values” - Haskell Wiki

17. Signal
as Value

19. 비동기 입력 처리에서의 복잡성
UI 컴포넌트들상에서의 복잡성

20. UI 컴포넌트들상에서의 복잡성
● OOP
○ Object with state : not composable.
● “Local State is Poison” - Awelon Blue
○ Global State is good in functional programming.
참조: The Functional Final Frontier - David Nolen

21. UI 컴포넌트상에서의 복잡성
참조: Hacker Way: Rethinking Web App Development at Facebook

22. UI 컴포넌트상에서의 복잡성
참조: Hacker Way: Rethinking Web App Development at Facebook

23. UI 컴포넌트상에서의 복잡성 제거 - ReactJS
● Just UI
○ (V in MVC)
● Virtual DOM
○ Re-render the whole app on every update.
○ Observation이 필요없이 전체를 빠찜없이 다 그린다.
○ No model dirty checking! No Data Binding!
○ Virtual Dom을 Diff 하고 변경이 된 부분만 Browser Dom에 반영.
○ Virtual Dom은 단지 메모리상의 조작이기 때문에 Diff가 엄청 빠름.
○ Browser Dom은 느리기 때문에 최종적인 변경만을 반영하기 때문에 랜더링이 엄청 빠름.
● One-Way Data Flow
○ 부모 컴포넌트에서 자식 컴포넌트로 데이타가 아래로 흐른다.
○ 위나 옆으로 흐르지 못한다.
● Component
○ just a function :
○ F(x1) = x2 : Component(data) = VDom
○ reusable, declarative

24. UI 컴포넌트상에서의 복잡성 제거 - Flux
● 페이스북에서 만든 어플리케이션 아키텍쳐
● 단방향 데이터 흐름을 활용해 뷰 컴포넌트를 구성하는 React를 보완하는 역할

25. 클로저스크립트의 ReactJS 랩퍼들
● 왜 ReactJS를 바로 쓰지 않고 클로저스크립트를 써야 하는가?
○ 자바스트립트 프로그래밍은 짜증난다.
○ 클로저스크립트는 최상의 함수형 프로그래밍을 할 수 있다.
○ 클로저스크립트에 immutable date structure 덕분에 ReactJS 보다 훨씬 빠르다.
■ JS Object는 Object의 모든 속성을 비교.
■ CLJS 자료구조들은 비교시 단순 pointer 비교.
○ core.async
○ 서버측의 Cloure와 코드 공유가 가능
○ 서버와 클라이언트간에 데이타 전송 : edn, transit
■ json보다 더 효율적.

26. 클로저스크립트의 ReactJS 랩퍼들
● Om
○ David Nolen이 처음 만듦. 가장 많이 사용.
○ ReactJS의 생명주기에 맞추어서 컴포넌트를 만들어야 하는 등 다소 어려움
● Reagent
○ ReactJS의 생명주기를 몰라도 컴포넌트를 만들 수 있어 가장 쉬움.
○ hiccup 스타일.
● Quiescent
○ 사용하기는 Om과 Reagent의 중간 정도 수준.
● Rum
○ Tonsky가 만듦. 최근 조명을 많이 받고 있음.
○ 믹스인 기능을 이용해 om과 reagent 컴포넌트를 가져다 쓸 수 있다.

27. HTML5 크로스플랫폼 어플 - 데스크탑
● NW.js(node-webkit)
○ 인텔이 개발
○ Chromium + node.js
○ Light Table, WhatsApp, ...
● Electron(atom shell)
○ 깃헙이 개발
○ Chromium + node.js
○ Atom Editor, Slack, ...
● CEF3
○ Chromium Embedded Framework 3
○ C, C++, Java, Go, DonNet 인터페이스
○ Adobe Dreamweaver CC, Evernote, Tencent QQ, StoneHearth Game UI, ...

28. HTML5 크로스플랫폼 앱 - 모바일
● Cordova
○ 아파치에서 관리
○ HTML5+JS+CSS 로 하이브리드 모바일앱을 개발하는 프레임웍
● Crosswalk
○ 인텔에서 개발.
○ Google Chromium WebView 기반의 하이브리드
● React Native
○ 페이스북이 개발.
○ ReactJS를 기반으로 해서 아이폰/안드로이드 Native 앱을 개발

29. Clojure is your screet weapon.