https://github.com/attltb/Lecture-Monad/blob/main/KOR/I-3.md
반박받은 것들 중에서 설득력이 있다고 생각하는 내용들 반영해서 좀 고쳐봤음.
갤에 올린 글은 본문은 수정 안하고 수정본 링크만 추가해놈.
가장 중요한 게 T<A>타입 자체를 계산으로 보는 설명들에 대한 얘긴데, 내 최종적인 입장은 새로 추가된 1-3에 다 나와 있음.
계산 자체를 Moggi의 모델을 통해 정의되는 개념으로 보는 입장은 충분히 그럴듯함.
문제는 그 입장 자체가 아니라 그 입장에 기반한 설명이 Moggi의 모델에서 T<A>가 계산인 이유를 올바로 이해했느냐임.
Moggi 논문 보면 Optional(=Maybe)이랑 List와 동치인 집합이 Notion of computation 중에서 가장 먼저 사례로 소개되는데
저자는 그냥 A타입을 반환하는 실패할 수 있거나 비결정적인 프로그램을 Optional<A>나 List<A>타입의 람다식으로 나타낼 수 있으니까
그런 의미에서 이것들을 계산의 타입이라고 했을 가능성이 높은 정도도 아니고 확실함.
즉 Maybe나 List타입의 값 자체가 계산을 나타낸다고 볼 수 있다면서 논리적 곡예를 하는 설명들은
그냥 Moggi 본인은 하지도 않은 이상한 짓을 하고 있는거.
프로그래밍의 모나드를 꼭 발견자와 같은 방식으로 이해할 필요는 없겠지. 다른 이해가 더 유용하면 받아들일 수도 있는 거고.
그러나 Maybe나 List모나드 타입 보고 계산이니 뭐니 하는 설명들은 유용하기는커녕
지금껏 모나드 공부하는 사람들의 혼란을 늘리는 데만 기여했으므로 그냥 백해무익한 게 맞다는 게 내 결론이다.
하여간 새로 추가된 1-3에 내 입장은 다 정리되어 있음.
그 외에도 2장에서 약간 사족처럼 보이는 내용 좀 뺐는데 그거 말고 특별히 고칠 건 없었는듯?
이번 글은 주제부터가 모나드를 설명하는게 아니라 모나드 설명 자체를 다루는 메타주제라 당연히 어려울 수밖에 없는데
그럼에도 불구하고 내 글이 모나드에 대한 다른 어떤 소개보다도 이해가 잘 된다고 하는 사람들이 있다.
그만큼 내 접근과 방향성 자체는 옳다고 확신하고 있다.
여하간 수정작업은 일단 끝났고 이제 3장 4장 쓸것임. 개인적으로 하는 다른 일도 있어서 이제부터 한달 정도 걸릴것같다.
또 왔냐? bind가 더 핵심적인 개념인데, 수학에 심취해서 본질을 못 보는 듯.
팩트1. 모나드에 대해 어느 정도 말할줄 아는 사람중 bind가 모나드 활용의 핵심이라는 걸 모르는 저능아는 없다.
팩트2. bind가 모나드 활용의 핵심이라는 건 bind를 통해 모나드를 정의하고 가르치는 것이 최선이라는 것을 의미하지 않는다. 대부분의 사람들은 join부터 배울 때 bind를 포함한 모나드의 모든 것을 더 직관적으로 쉽게 잘 이해한다.
팩트3. 많은 사람들이 개별 모나드를 배울 때 겪는 지적 병목의 상당 부분은 개별 모나드의 bind 구현이 종종 매우 복잡하고 어렵다는 데 기인한다. 알려진 대부분의 모나드는 join과 lift가 bind보다 압도적으로 쉽기 때문에 bind는 join과 lift로부터 어떻게 일반적으로 구현될 수 있는지만 가르쳐주고 join과 lift를 가르쳐주는 것이 개별 모나드의 bind를 가르치는 가장 쉽고 효율적인 방법이다. 이 방법은 설명해야 할 개별 모나드가 많으면 많을수록 우월해진다.
팩트4. do표기법은 물론 bind를 통해서 이해될 수 있지만 꼭 bind를 통해서만 이해되어야 하는 것이 아니다. 어차피 그걸 문법 설탕으로 본다면 join이나 flatlift (이건 그냥 내가 부르는 명칭인데 Kleisli triple의 오리지날 정의에 bind 대신 포함되어 있는 (A→T〈B〉) → (T〈A〉→T〈B〉) 타입의 함수 말하는것임) 가지고도 똑같은 일 하는 문법 설탕을 충분히 만들 수 있다.
팩트5. 문법 설탕 어쩌고만 앵무새처럼 되풀이하면서 왜 그런 설탕이 만들어졌는지 이유는 하나도 안 가르쳐주는 병신튜토리얼들을 빼면 bind가지고 do 표기법을 설명하는 가장 정통적인 방법은 bind를 말 그대로의 변수 바인딩이랑 연결짓는 것이다. 오늘날 대부분의 모나드 튜토리얼들은 이 설명을 안 하는데 그 이유는 해봤을때 잘 안 되서다. 모나드를 처음 배우는 사람들일수록 변수 바인딩의 의미를 확대 적용하는 이런 설명들을 어려워하고 직관적으로 받아들이지 못한다.
팩트6. 니가 수학에 심취해서 본질을 못 본다고 주장하는 내 모나드 강의에 대해 가장 높게 평가하는 건 모나드를 완전히 처음 접하는 사람들이다. 니같은 놈들이 만든 강의가 "어려워요 ㅠㅠ", "모나드 빡세네" 이딴 댓글밖에 못 모으는 동안 나는 "뭐야 왤케 설명잘해", "드디어 하스켈 정상인 등판. 갤에 하스퍼거들 이해한척 개소리 웅얼대는거 좆같았었다.", "나 하스켈 배워본 적 없는데 글에서 이해안되고 생각한 비율이 20% 일 정도로 설명이 놀랍게 깔끔하다.", "내가 하스켈 입문할 때 이런 글이 있었어야 했는데", "설명 오지네요", "내가 읽은 모나드 글중 가장 이해가 되는 기분임" 등의 코멘트만 일관되게 받았다.
넌 진짜로 개좆도 모르는것 같은데 왜케 깝침?
너보단 많이 알고 모나드도 훨씬 많이 써봤으니 걱정 ㄴㄴ해. wadler가 왜 fmap과 join으로 설명하다가 bind로 갈아탔는지 고민은 안 해봤음? do 표기법을 쓰고 싶기 때문에 이펙트 안에서 값을 꺼내는 함수가 필요한데, 이게 bind가 대쳇잔 이유임. bind m k = join (fmap k m)은 그 다음의 일이라니까...
강의도 안 썼는데 맞는 건 억울하지만, 솔직히 다른 사람들 강의가 다 실패했다고 주장하는 건 조금 그렇지 않음?
방금 팔로잉했으니까 내 깃헙이나 보셈
그러니까 니가 그 effect랑 (이거 정의되기는 하냐?) bind가지고 내꺼의 절반만큼이라도 제대로 작동하는 모나드 강의 만들어 보고 말을 하라는 얘기임. 이펙트 안에서 값을 꺼내는 함수는 무슨 모나드 처음 배우는 사람들이 그걸 잘도 알아듣겠다. 누가 bind완전 버리래? 그건 모나드 안에서도 어려운 주제니까 join가지고 모나드 설명한 후에 그거의 활용 소개하면서 나중에 소개하라는 거잖아.
모나드는 애초에 다른 개념으로써 존재했기 때문에 지금의 형태가 된거다. 애초에 "계산을 나타내는 타입클래스 한번 만들어보자." 이런 생각 가지고 만들었으면 지금같은 형태로 못 만들어졌지.
난 너보다 모나드 가르치는 문제에 대해 백배는 더 고민해봤고 그래서 이런 글도 자신있게 쓸 수 있는거다. 내가 do 표기법 안에서 bind가 변수 바인딩에 대응된다는 너도 아는 걸 모를거라고 생각함? 그걸 잘 아는 내가 그 설명을 안 하는건 (물론 요약본에서만 안하고 나중에 본버전에서는 다 한다) 다 이유가 있음. 내가 계속 고민한 문제는 어떻게 하면 이 개념을 처음 접하는 사람한테 잘 전달할까다. 그 고민에서 출발한 나한테 지금 니가 지적이랍시고 나도 뻔히 아는 얘기들 늘어놓는게 얼마나 피상적으로 보일지 생각이나 해 봐라.
딱 하나는 인정함. 얼마전까지 물리학이나 하다 온 뭔 이름도 없는 좆뉴비새끼가 지난 30년간 아무도 못푼 문제를 풀겠다고 덤비는게 꼴같잖아 보인다는 거. 근데 이 바닥에서 아무도 못한거 자기가 하겠다고 덤비는 놈 보는게 그렇게 드문일임? 그런 놈들이 다 실패하는 것도 아니잖아 왜 색안경부터 끼고봄?
팔로우는 감사함... 솔직히 프로그래머로써의 경험이나 모나드 써본 경험은 나보다 님이 훨씬 많긴 할듯.
색안경 끼고 본 건 ㅇㅈ한다... 글을 잘 쓴 것도
적어도 깃갤에서 지들도 이해못하고 앵무새처럼 어디서 복붙한 내용만 떠들던 새끼들보단 글쓴이 설명이 이해가 더 쉬움
free monad 관련해서도 글 하나 써주삼 ㅋㅋ
뭐 아주 간단히 설명하자면 F가 어떤 functor일 때 a이랑 F〈a〉랑 F〈F〈a〉〉 랑 F〈F〈F〈a〉〉〉... 를 논리적으로 전부 포함하는 T〈a〉라는 타입이 있다고 치자. T〈a〉 := (a | F〈a〉 | F〈F〈a〉〉 | F〈F〈F〈a〉〉〉 | .... ) 이런 식으로. 이 경우 T〈a〉는 무조건 unit과 join이 정의되기 때문에 (a도 T〈a〉에 포함되고 T〈T〈a〉〉도 T〈a〉에 포함되니까) 모나드가 될 수밖에 없음. 이거를 free monad라고 하는건데 일단 지금 쓰는 거에 집중하고 싶다.