Lens에 대해서 글을 써 볼까... 아니면 SMT에 대해서 글을 써 볼까... 이런 고민은 끊이질 않는다 😵

@bglbgl gwyng 메시지 패싱이 함수 호출보다 더 근본적인 요소라고 저는 생각합니다. RPC 프레임워크만 봐도 함수 호출을 메시지 패싱으로 구현할 수 있는 것은 자명하죠. 그래서 함수 호출은 메시지 패싱의 특수한 형태로 보아야 한다 생각합니다.

@bglbgl gwyng 가장 원하시는 답은 함수 호출과 메시지 패싱이 근본적으로 어떻게 다르냐?는 것이 될 텐데요. 이따 퇴근하면서 덧붙여보도록 하겠습니다.

이론적으론 자바는 반쪽짜리 OOP인가 봅니다. 모든 건 객체고, 객체들끼리 함수 호출이 아닌 메시지 패싱을 해야되고, 이 메시지들 처리 방식을 객체가 능동적으로 결정해야 Pure OOP라 부르나 봅니다. 어디까지나 이론적인 얘기입니다. 스몰토크나, 아니면 얼랭등을 만져봤으면 더 쉽게 이해할 것 같은데요. 낮에 객체 지향 얘기가 보여 교양 공부 해봤습니다.

@bglbgl gwyng 월드 와이드 웹에 누구든 웹 서비스를 연결하고 수정하고 분리할 수 있는 것은, 그 과정에서 웹이 절대 망가지지 않는 것은, 상당 부분 월드 와이드 웹이 기초한 프로토콜이 메시지 패싱에 기반하고 있기 때문입니다.

@domatdo도막도 넵 그렇습니다. 제가 처음에 올린 단문도 객체지향이 설계에 실질적으로 도움이 되는 사례를 나열해보면 상속을 벗어나지 않는다는 주장이었습니다. 메시지 패싱으로 어떤 설계 문제를 해결했다,는 사례를 저는 아직 모르고, 최소한 잘 알려지지 않은거 같습니다.

@domatdo도막도 그렇다면 저는 메시지 패싱을 잘 활용한 코드의 예시를 보면 설득이 될거 같네요. 저는 그것이 메소드 호출 이상의 의미를 갖는지에 대해 아직 회의적입니다.

@domatdo도막도 메시지 패싱은 잘은 모르지만 그런게 있다는건 알고는 있습니다. 그렇다면 Java가 메시지 패싱을 어떻게 지원한다고 할수 있을까요? 또 그걸로 어떻게 설계의 이점을 얻을까요?

@bglbgl gwyng 객체지향 프로그래밍의 핵심이 메시지 패싱이라는 개념이라는 것은 여러 객체지향 언어를 비교해보면 명확하게 확인할 수 있습니다. 상속, 상태, 접근자, 접근 제한자, 클래스, 프로토타입, 멤버 변수, this 바인딩, 메서드 디스패치 등등 다양한 개념이 여러 언어에서 서로 다르게 나타나는 한편 메시지 패싱이라는 아이디어는 변치 않습니다.

@bglbgl gwyng (답문이 너무 짧아서 노파심에 덧붙이지는 말입니다만 오해의 여지를 안 만들기 위해 최대한 드라이하게 이야기하려고 노력중이라 여겨주시면 좋겠습니다..ㅎㅎ)

@bglbgl gwyng 메서드에 기반한 메시지 패싱 매커니즘과 인터페이스라는 개념을 제공합니다.

@domatdo도막도 좋은 책 추천 감사합니다! 그런데 제가 의심하는게 사실 '객체와 그것들의 협력에 대한 이야기' 요 부분입니다. 가령 Java와 같은 객체지향 패러다임의 언어 프로그래밍 언어가 실제로 객체들의 협력을 위해 언어적으로 어떤 기능을 지원하나요? 저는 그런 기능이 딱히 없다고보고, 그래서 1. Java는 객체지향 언어가 아니다 2. 객체지향 패러다임은 (실질적으로) 그 문제와 별로 관련이 없다. 두 결론 중 하나를 택해야 한다고 생각합니다.

@bglbgl gwyng 저는 반대로 상속을 빼놓고도 객체지향을 이야기할 수 있고, 더 나아가서는 응당 그래야 한다고 생각합니다. 상속은 객체지향 프로그래밍을 추구하는 프로그래밍 언어들이 자주 채택한 구현 기법 그 이상 그 이하도 아니지요. 중요한 것은 복잡계를 객체로 모델링하고, 또 그 복잡계를 적절히 조합해 복잡도를 제어하는 일입니다. 객체지향은 객체와 그것들의 협력에 대한 이야기가 되어야 하지 그 외에 어떤 구현 디테일에 대한 이야기가 되어서는 안 된다고 생각해요.

방금 하스켈 학교에서 객체지향 vs 함수형 떡밥이 n번째로 돌았는데, 나는 그냥 객체지향 = 상속(서브타이핑) 이라고 생각한다. 객체지향에서 상속을 빼면 뭐 남는게 없다. 그래서 객체지향이란 단어를 의미있게 사용하려면 상속이랑 동치시켜 사용할수 밖에 없다고 본다.

근데 상속은 코드를 합성하는 수많은 방법중 하나일 뿐이다. Java같은 언어는 그 수많은 방법중 딱 하나 상속만을 언어 자체에서 지원하는거고, 거기서 벗어나는 다른 유용한 추상화들은 죄다 디자인 패턴이라고 퉁쳐서 부른다. 그래서 객체지향 vs 함수형(= 상속 vs 함수형)은, 나에겐 Monoid vs 타입클래스 같은 비교처럼 들린다. 좌변과 우변이 체급이 안 맞아서 대결이 불성립한다.

논리와 low-level data representation을 다뤄볼지, 아니면 함수형 추상 기계들(Turing Machine같은 것이지만 함수형을 위한 것들)을 다뤄볼지$\ldots$ 딱 결론이 나질 않는다 ☠️

사람이라는 게 참 묘하다. 서비스 개발을 시키면 플랫폼 엔지니어링을 하고 싶고, 플랫폼 엔지니어링을 시키면 서비스 개발을 하고 싶어한다. 둘 다 해야 할 때는 이론 공부를 하고 싶다고 하고, 이론 공부를 시키면 서비스 개발을 하고 싶다고 한다.

For my library and CLI projects, I've been writing documentation before writing any code. It helps me imagine the final interface early on, which usually leads to better design. Sure, sometimes I miss implementation details and have to revise later, but hey—it's just docs. Docs are easy to change.

This tiny habit has surprisingly big payoffs. When I focus on how things will be used rather than how they'll be built, I end up with interfaces that actually make sense.

Anyone else do this? Curious about your experience with documentation-first approaches.

RE: https://hollo.social/@hongminhee/01964c76-ef1e-7994-b3f0-57f967742566

@domatdo도막도 그 둘은 같습니다만 thunk에 congruence rule이 없습니다. 즉 M = L이어도 thunk(M) = thunk(L)인 것은 아닙니다. (M을 계산한 결과가 L인 경우, thunk(M)은 지연된 계산이기 때문에 더이상 평가가 진행되지 않아 thunk(L)이 될 수 없습니다.)

@ailrunAilrun (UTC-5/-4) (force . thunk) m = m이라 볼 수 있지 않았나요?

@domatdo도막도 thunk . force가 좀 난해한 녀석이죠. thunk를 LISP의 quasi quotation으로, force를 back quotation으로 이해하면 thunk . force는 항등입니다만, thunk를 그냥 지연된 계산으로 이해하면 thunk (M)은 지연된 M 계산이고 thunk (force (thunk (M)))은 지연된 force (thunk (M)) 계산이라 같다고 하기 미묘합니다. 이 맥락에서 같다는 두 프로그램이 실행되어서 문법적으로 동일한 결과 값을 준다는 이야기일 때요.

@domatdo도막도 다른 말로는 Up (Down a)는 모나드(Monad)고 Down (Up a)는 코모나드(Comonad)가 되는데요, 이를 이용해 CBPV는 Effect 또한 자연스럽게 다룰 수 있습니다. 글에서 다루기에는 소개할 내용이 많아서 생략했지만요.

@domatdo도막도 그리고 force . thunk는 항등사상이 맞습니다. M은 M이라는 계산을 하는 녀석이고, force (thunk (M))도 정확히 M이라는 계산을 하는 녀석이죠.

PostHog 뉴스레터는 중소규모 팀 맞춤형(즉, 사이드프로젝트 물주는 사람들한테도 좋은..)으로 좋은 내용이 많아서 새 글이 올라올때마다 여기에도 자주 공유하고 싶음

@ailrunAilrun (UTC-5/-4) 생각해보면 return도 두 언어를 오가는 대응에 해당하네요. 모든 값을 계산으로 바꾼다는 점에서 force보다도 더 thunk의 짝이 되기 좋아보이나 싶지만 조금만 더 생각해보면 둘을 합성해서 항등 사상을 얻을 수가 없으니 아주 잘 어울리는 한 쌍은 못 되는군요. 뭔가 to의 역할을 잘 생각해보면 보이는 게 있을 거 같은데… 고민해봐야겠어요.

@ailrunAilrun (UTC-5/-4) 아하. CBPV의 thunk와 force를 일반화하면 두 언어 사이에서 항을 변환하는 사상을 떠올릴 수 있겠네요. 메타프로그래밍 관점에서 생각하면 항을 메타 언어의 데이터로 바꾸는 생성자(lisp의 quote 같은)와 메타 언어의 데이터를 대상 언어의 항으로 되돌리는 eval 생성자를 생각할 수도 있겠어요. 더 흥미로워지는데요?

@domatdo도막도 수반 논리(Adjoint Logic)에 기반한 언어간 상호운용성(interoperability)입니다. CBPV를 이 관점에서 이해하면 계산 언어와 값 언어간의 상호운용성을 특정한 방식으로 구현했다고 볼 수 있습니다. CBPV가 수반 논리보다는 제한적인 대신 그 제한이 기계 수준에서 이해하는데는 유용한 점이 있다고 비교해 볼 수 있겠네요.

@domatdo도막도 저 개인적으로는 CBPV랑 경쟁하는(?) 체계를 연구하고 있다보니 CBPV의 약진이 맘에는 안 듭니다만 $\ldots$ 그래도 재미있는 체계죠.

Yacc와 같은 파서 제네레이터에 BNF를 넣으면 파서 코드가 자동으로 생성된다. 그런데 HTTP나 ActivityPub 등의 프로토콜 스펙을 입력으로 넣으면 자동으로 코드를 구현해주는 도구 어디 없나?

Facebook에서 특히 자주 발생하는 문제지만 그렇다고 다른데에서 안 터지는 것도 아니라 참 답답$\ldots$