모나드
모나드에 대한 개념은 꽤 오래 전부터 알고 있었지만, 이렇게 하나하나 이해하며 구현한 적이 없었는데 이런 과정이 이해를 더해주는 것 같아 유익한 경험이었던 것 같다.
js에는 이미 함수형 패러다임이 군데군데 녹아 있다. 꼭 monad라고 명칭 하지 않지만 monad의 일종이 존재 한다. 개념은 언제나 똑같기 때문이다.
monadologia가 갖고 있는 maybe eiter state reader writer task 말고도 엄청 다양한 종류의 모나드들이 있지만 시간 관계상..
이 개념을 어서 도입 하자고 주장할 수 있을까?
이 부분은 사실 긍정적이진 않다. 함수형 패러다임이 oop의 종말을 의미 하는것이 아니다.
함수형 프로그래밍이 주류 패러다임이 아니기 때문에(프론트엔드는 더 그렇다) 독단적으로 도입하는 것은 팀웍에 좋지 않을 것 같다.
또한 정작 이 글을 쓰는 나도 100% 이해했다고 볼 수 없을 것 같다.
https://www.youtube.com/watch?v=ADqLBc1vFwI&feature=youtu.be
(이런 밈도 있다. 엄청 재밌다)
협업을 하려면 모두가 잘 이해하고 있어야 하기 때문이다.
다른 사람에게 함수형 패러다임대로 생각하게 강요하는게 옳은지는 잘 모르겠다.
무조건 효율적인거 같지는 않다
훌륭한 패러다임이지만 원칙을 지키기 위해 먼 길을 돌아가는 감도 없지않아 있다.
이래도 작동하고, 저래도 작동하면 어떻게 작성하던 상관 없는 것 아닐까 하는 생각이 문득문득 들 때가 있다.
immutable이 필요하다.
작성한 모나드들 (특히 값을 갖고 시작하는 Maybe, Either, State 등) 에서 객체를 담는다는게 좀 뻑적지근 하긴 하다. Maybe에서 map 함수에 초기에 담긴 객체의 일부 프로퍼티를 변경한다고 했을때
const value = { name: "hello", age : "24"} as ValueInterface
monadologia
.maybe<ValueInterface>(value)
.map((value) => value.age = 25) // ValueInterface
.map((value) => value.name = "hi") // ValueInterface
이렇게 작성하는게
function test(value: ValueInterface){
value.age = 25;
value.name = "hi"
}
test(value)
이것과 엄청난 차이가 있는가?
사실 reference로 넘어가기 때문에 순수함수도 아니고, 함수를 잘개 쪼개나, 함수 한 곳에서 바꾸나 어떤 객체의 값을 변경한다는 사실은 변하지 않는데 괜히 파일이나 함수 선언만 많아지는 게 아닐까? 게다가 전혀 함수형 프로그래밍 스럽지도 않다. 그냥 기존 방식대로 짜는 것과 표현만 다르지 본질적으로 같기 때문이다.
이런 부분을 immutable을 도와주는 라이브러리를 쓸 수 있지만, 너무 투 머치 아닐까 하는 생각도 들 때가 있었다. 다른 사람들은 어떻게 생각 할지 궁금하다. 성능적으로 immutable.js 같은걸 쓰는게 아무래도 naitive보다 우월할 수 없기 때문이다.
그냥 사람이 조심하면 되려나..
왜 함수형 프로그래밍 라이브러리들이 모나드 자체에 집중하지 않고 함수의 합성에 주안점을 두는지 이해가 되었다. 어쩌면 js와 100% 맞는 패러다임은 아닐지도 모른다는 생각이 들었다.
타입스크립트
js라는 언어 자체가 강 타입 언어가 아니다보니, 사실 거추장 스러운 거라고 생각 했었는데 monadologia.js를 제작 하면서 제너릭에 대하여 고민하고, 타입에 대하여 고민을 하니 하나에 결론에 이르렀다.
실수할 일이 적을 것 같더라
인터페이스를 잘 정의하고, 프로그램 작성을 타입 -> 타입으로 이해하고 작성하는 것이 훨씬 실수의 위험성이 줄 것이라는 생각이 들었다. monadologia를 만들면서 typescript에 대한 막연한 거부감이 사라졌다. 적극적으로 도입해야 한다고 생각하는 쪽으로 생각이 바뀌었다.
기존에 어떤 기능을 구현하는 함수를 작성하면 그냥 뭔가 만든다는 생각 뿐이었지만
타입 기반으로 생각하게 되니 훨씬 사고의 폭이 넓어지는 것 같다. 타입에 대하여 정확히 할 일과 하지 말아야 할 일을 구분해서 프로그램을 작성하게 되기 때문이다.
레퍼런스
그 동안 관련 자료를 찾고, 코드 작성을 할수 있게 도움 준 사이트 목록이다. monadologia.js에는 아래 사이트에서 참고한 코드가 많이 있다.
https://gs.saro.me/dev?tn=429
https://suhwan.dev/2018/04/18/JS-async-programming-with-promise-and-generator/
https://www.python2.net/questions-379737.htm
https://medium.com/@yannickdot/taming-the-async-beast-using-tasks-e62675dde9c
https://blog.burt.pe.kr/series/monad-and-functional-architecture-part-4/#4-4-future
https://www.toptal.com/javascript/option-maybe-either-future-monads-js
https://medium.com/swlh/what-the-fork-c250065df17d
https://hackernoon.com/from-callback-to-future-functor-monad-6c86d9c16cb5
http://blog.weirdx.io/post/12472
https://github.com/eunmin/getting-started-monad
https://www.codeproject.com/Tips/801173/State-Monad-i
https://gist.github.com/hallettj/4043719
https://stackoverflow.com/questions/50321419/typescript-returntype-of-generic-function
https://adit.io/posts/2013-06-10-three-useful-monads.html#translations
https://stackoverflow.com/questions/48346504/what-is-the-purpose-of-the-reader-monads-local-function
https://glot.io/snippets/efmhtd5oky
https://ncatlab.org/nlab/show/monad+%28in+computer+science%29
다음엔 뭘 할것인가?
- 솔직히 글 재주가 별로 없다. monadologia.js를 작성하며 남겼든 포스트 글과 이미지를 정리하고 싶다.
- 부끄럽지만 테스트 도구들을 써본적이 없다. 회사에서도 도입을 못했다..(여러 이유로)
공부를 했어야 했는데 어째서인지 우선순위에서 밀려 있었다. 테스트 코드 작성 경험을 쌓아야 될 것 같다.
monadologia.js는 이대로 아무도 안받는 npm 패키지겠지만, 작성하는 과정은 의미 있었다고 회고 하고 싶다.
읽어주셔서 감사합니다.
