모나드 펑터같은게 수학의 한분야인 범주론(카타고리 이론)에서 나왔는데, 범주론은 수학에 대한 수학 혹은 메타 수학으로 수학적 방법론을 수학 자체에 재귀적으로 탐구하는 학문인걸로 보여요. ㅎㅎ
범주론이 궁금하시면 링크의 책을 한번 읽어보면 맛은 약간 볼수 있습니다. 번역서도 있고요, 이책을 좀 더 일찍 만났더라면, 수학이 이렇게 기계적이고 지겨운게 아니라 엄청 흥미 진진한거란 생각을 가지게 되었었을 텐데.. 아쉬워요 ㅎ
https://harfangk.github.io/2017/09/08/how-to-bake-pi-review-ko.html
아무튼, 실질적으로 프로그래밍에 빠질수 없는 상태, 비동기, 효과를 복잡하게 다루는데 있어 확실한 기반이 있다면? 안심이 될텐데 그게 수학적 공리라는거죠.
함수 합성을 할때 이 결과가 맞으리라는 보장을 어떻게 하지?
- 불변값을 기본으로 참조 투명성 확보
- 수학적 공리에 의한 보장
대표적인 수학적 공리(수학적 진리)인 결합법칙과 교환법칙을 보면
- (x * y) * z = x * ( y * z)
- x + y = y + x 이게 언제나 참이라는걸 잘 알죠.
그럼 한번 대수구조를 살펴보죠.
https://github.com/fantasyland/fantasy-land/raw/master/figures/dependencies.png
Functor -> Apply -> Applicative -> Monad 요렇게 화살표가 그려져 있는데 펑터, 애플리, 애플리커티브, 모나드의 구조는 각각 그 구조를 입증할수 있는 공리를 가지고 있고 화살표 순대로 공리를 포함하고 있죠. 꼭 클래스 상속구조처럼요. 그래서 하스켈에서는 타입 클래스라는 이름으로 새로운 자료구조를 제안하고 있죠.
각 수학적 구조, 즉 대수 자료형의 공리를 한번 살펴보면
- u.map(a => a) is equivalent to u (identity)
- u.map(x => f(g(x))) is equivalent to u.map(g).map(f) (composition)
- v.ap(u.ap(a.map(f => g => x => f(g(x))))) is equivalent to v.ap(u).ap(a) (composition)
- v.ap(A.of(x => x)) is equivalent to v (identity)
- A.of(x).ap(A.of(f)) is equivalent to A.of(f(x)) (homomorphism)
- A.of(y).ap(u) is equivalent to u.ap(A.of(f => f(y))) (interchange)
- M.of(a).chain(f) is equivalent to f(a) (left identity)
- m.chain(M.of) is equivalent to m (right identity)
이 공리는 단순한 함수에 메소드가 아닌, 어떤 함수가 이런한 구조를 따르고 입력값이 변하지 않는다면 언제나 옳다라고 수학과 논리가 확증해주는 효과가 있는거죠. 그리고 효과, 비동기를 이 함수에 Boxing하여 숨긴다음 안전하게 조합 가능하게 됩니다. 함수에 박싱하는건 다음에 한번 더 이야기 해보면 좋을거 같아요 ㅎㅎ
아이덴티티(항등원), 합성, 호모몰피즘, 카타몰피즘 등등 ADT의 용어는 수학적 엄밀함을 나타내고 있는거죠. 그래서 이런 자료구조를 만들고 이렇게 합성하면 일단 틀릴일이 없다는 확신을 우리가 가질수 있는 겁니다. 그리고 프로미스등은 이 구조를 응용한 하나의 사례에 지나지 않게 되는거죠.
아카데믹에서는 이런 안전한 합성을 극단적?으로 탐구 해서 하스켈등이 있다면, 반대로 산업쪽에서는 파이손같이 동적 타입으로 차라리 테스트를 열심히 하자 이런 분위기 였는데, ㅎㅎ 세상참 알다가도 모를일 이네요.
아무튼 ADT는 수학적으로 증명된 참인 법칙 = 공리를 응용하여 상태, 효과, 비동기를 안전하고 쉽게 다를 수 있도록 하는 프로그래밍 전략의 일종이라고 생각합니다. 하스켈은 이걸 컴파일 타임에 잡아준다고 주장하고요. 물론.. 그렇다고 모든 런타임 에러를 잡는건 또아니지만요 ㅠㅜ
https://harfangk.github.io/2017/08/17/understanding-computation-review-ko.html
넘나 잘 읽었어요. 승기님이 알고 있는 모두를 흡수할 수는 없지만 그래도 정말 너무나 잘 읽었습니다. 감사해요!
이것 덕분에 저는 프로그램 작성을 단순하게 하며 복잡한 문제를 분할해서 정복할 수 있게 해주고, 잘 동작할 것이라는 확신을 더 빨리 갖게 해주며, 결국 그 모든것이 생산성을 높여준다고 생각하고, 프로그래밍에서 이 개념이 필요하다는 것에 있어서 완전히 공감합니다.
그리고 하스켈에 세워진 타입 시스템은 저 효과를 더욱 신뢰할 수 있게 해주며,
더 안전하게 합성할 수 있도록 도와주는 것이겠네요.
여기서 하스켈의 대수 구조 혹은 타입 시스템이 있어야 하는 이유가 무엇인가를 생각해보면,
언어를 사용하는 개발자가 새로운 타입을 만들고 싶어서 만들고자 할 때,
미리 준비된 저 대수 구조를 따르면,
저 결합 법칙과 교환 법칙을 가져올 수 있기 때문에 라고 생각해요.
또 한 준비된 함수 조합들에 해당 타입 들을 안전하게 합성/적용/통과 시킬 수 있기 때문이겠죠.
결과적으로 개발자가 결합 법칙과 교환 법칙을 지키지 못할 어떤 새로운 타입을 만들게 될 수 있고,
또 개발자가 무에서부터 시작해서 자기가 만들고자 하는 소프트웨어안에,
결합 법칙과 교환 법칙을 지키는 시스템을 만들어내기엔 너무나 어려운 일이니,
거의 완벽한 가이드가 되어주며,
발전시킬 방향을 보여주는 것이라고 생각해요.
그것이 너무나 하스켈을 경외심이 들게 하는 점이라고 생각하고. 아름답고요.
그런데 하스켈이 아닌 다른 언어에서,
개발자가 새로운 타입을 만들지 않아도 된다면,
예를 들면 자바스크립트안에 이미 언어에 준비된 타입들만 사용한다면,
그리고 그 타입을 필요할 때 불변적으로 다룬다면,
그 타입들의 메서드와 그 타입들에 연산자나 함수를 적용을 하는식이라면,
항상 동일한 동작을 할 것이라는 보장이 가능해진다고 생각을 하는거죠.
그리고 안심할 수 있게 되고요.
그래서 자바스크립트에 맞고, 쉽고, 함수형 프로그래밍의 장점을 최대한 활용할 수 있는 해법을 찾아보고 있는 것이구요.