bgl gwyng

이제 VitePress로 문서를 뽑아볼까...

그동안 Conal이란걸 만들고 있었습니다. Classic FRP 라이브러리입니다.

또, 소개글 쓰려니까 머리 아파서, 클로드랑 즉석 팟캐스트를 열었습니다. 술술 읽혔으면 좋겠네요.

당장 프로덕션에 쓰려면 개선할 부분이 많습니다. 피드백과 기여 환영합니다.

요즘 아이디어를 긴 글로 옮기는게 힘들다. AI와 비교해 최대 10토큰/분이란 저열한 속도에 자괴감이 들고, 그렇다고 AI랑 같이 쓰자니 이것도 합을 맞춰서 같이 쓰는게 어렵단 말이지. 그래서 시도해보려는 방법은 AI한테 인터뷰어 역할을 맡기고 내가 인터뷰이가 되는거다. 주제만 내가 정해주고 세부 사항에 대한 비판이나 질문은 AI한테 맡긴다. 그리고 대화가 끝나고 스크립트를 그대로 공유한다.

나는 모듈끼리 circular dependent한걸 허용하는게 낫다고 생각한다. 코드를 쪼개는데에는 제한이 있으면 안된다.

RxJS의 pipe를 흉내내서 뭔가 만들고 있는데, pipe안에 들어가는 함수가 operation oriented가 되도록 유도한다. 즉, x.pipe(f(y))가 f(y,x)로 해석되어야하니, f는 data oriented가 아닌 operation oriented가 되어야하는 것이다. 근데, 나도 일반적으로 operation oriented를 선호하긴하지만 JS의 관례는 그게 아니다. 그래서 f를 pipe를 통해서 쓰지 않을 경우에 어떤 사람들은 생소하게 느낄거 같다. 나는 x가 this 처럼 사용되고(data oriented), pipe는 메소드 확장의 역할을 맡게 하고 싶다.

어떻게 하는게 맞을까?

tsconfig에 stripInternal란게 있군요?

JS에선 Java처럼 package-level visible property를 못만들다보니, 상호 참조가 많은 클래스를 정의할때 죄다 public으로 해야하는게 별로네. 내부 클래스와 그걸 래핑한 유저한테 노출하는 클래스(또는 인터페이스)를 따로 만들어야 하나.

평소에 OOP 별로다, 상속은 거품이다 비난만 하다가, 막상 클래스 만들어야할 상황이 오니까 기어코 아름다운 상속 구조를 만들어보려 애쓰는 나, 정상인가요?

오늘 동료가 나보고 혹시 ENTP냐고해서 맞다고 했는데 좀 자존심 상한다...

JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?

여행 다녀왔는데 또 가고싶다... 예전에 1인 창업을 위해 베트남에서 생활하는 개발자를 만난적이 있다. 사실 휴양지에 가면 플렉스를 해버려서 그렇지 그걸 참으면 돈을 아낄수 있긴하다. 디지털 노마드의 로망을 1년 정도는 실현해보고 싶은데...

내일 튜사 나오시는분 있나요?

오늘부터 사흘간 중국 칭따오여행합니다

Nix 디버깅은 육체적으로 힘들다. 퇴근할따되면 등이 찌뿌둥함.

(CLI 툴을 쓰다 느낀건데), UX 이슈 중에 no-op과 관련된 것이 특히 까다로운것 같다. 예를들어 유저가 뭔가를 했는데 에러나서 안되면 에러 메시지로 다른 사람에게 물어볼수 있다. 근데 예상한 동작이나 변경이 안 일어났을 경우엔 그게 불가능하다. 어떤 설정을 하는걸 빼먹어서 그렇게 된 경우엔, 운좋게 다른 사람들도 자주 겪는 문제라서 쉽게 답을 찾는 경우가 아니라면, 결국엔 문서를 읽으며 내가 하려는 동작엔 어떤 설정이 요구된다는 사실을 알아내야하는데, 이러면 문서를 사실상 통독하게 된다.

내가 개발자로써 딱히 내세울 커리어는 없지만, 그래도 일평생 XCode 개발에 전혀 기여하지 않았다는 점에서는 자긍심을 느낀다.

평소에 이펙트 시스템의 필요성을 때가 비동기 코드 테스트할때 인듯. 특히 setTimeout등 실제로 현실 시간만큼 기다리는 코드가 섞여있을때 이펙트 시스템이 없으면 테스트에서도 실제로 그만큼의 시간을 기다려야한다. 그러다보니 안 짜게 되고...

https://github.com/bglgwyng/deferred-cleanup-resource-map 이런 라이브러리를 만들었다. ref counting 해서 GC 해주는 map인데, 해제를 임의로 늦출수 있다. LRU 캐시같은걸 일반화한 형태라고 보면 된다.

이름이 참 저질인데, 나도 upyo같은 센스있는 이름을 붙이고 싶었지만, 이게 클로드랑 머리맞대서 나온 최선이다;;

https://horizon-haskell.net/ Nix에서 하스켈 패키지셋을 임의로 만들수 있게 해준다.

새로운 한주를 시작하는 귀중한 월요일 아침 시간을 맥북에 커피 쏟은거 수습하는데 쓰고 말았다...

에디터에서의 undo/redo가 그냥 버전관리랑 통합됐으면 좋겠다. 그러니까 undo 한 다음, redo로 다시 돌아가지 않고 다른 수정을 하면, 그 끝점이 anonymous commit 같은 걸로 남는거지.

튜사에 왔는데 몰입형 공간이 꽉차서 더블 모니터를 못쓰는 관계로, 어쩔수없이 오늘은 하스켈을 좀 해야겠다...

1만 * 1만 = 1억 이 상식인줄 알았는데 아닌가 봅니다? 오늘만난 제 문과친구 두 명이 저걸 모르길래 뭐라했더니 저보고 별것도 아닌걸로 잘난척하지 말라고합니다. 상식... 아닌가요?

AI 도움 받아 글쓰기할때 주로 어떤 방식으로 하시나요?

• 클로드 웹. 모델은 좋은데 인터페이스가 글쓰기 최적화는 아닙니다.
• Cursor/Windsurf 등. 모델이 코딩 고문을 당해서 그런가 글을 잘 못씁니다.

내일도 튜링의 사과 출근해야지

1년전에 하스켈로 프론트엔드 개발을 했었다. 프론트엔드 개발의 70% 정도는 state + reactivity를 다루는 것이라고 생각한다. classic FRP를 구현한 하스켈의 Reflex 같은 라이브러리를 쓰면 이 문제를 우아하게 해결할 수 있다. 근데 문제는 많은 프론트엔드 앱이 어엄창나게 복잡한 state를 가지고 있진않고, 그래서 Reflex 없이도 어느정도 만족할만한 코드가 나온다. 아마 에디터나 게임 같은걸 짜면 Reflex의 우월함을 느낄수 있을것이다.

문제는 나머지 30%에 있다. SSR, CSS 등이 거기에 포함되는데, JS 진영에서는 babel 플러그인의 도움을 받는 반칙을 쓰면서 편리함을 제공하고 있다. 여기서 반칙이란건 "use client" 등의 directive와 Tailwind CSS처럼 babel 플러그인이 JS 코드로부터 CSS 클래스 사용을 추출하는 그런걸 의미한다. 반칙이라고 하는 이유는 사실 JS가 아니고 babel로 업그레이드한 JS++쯤 되는 언어를 쓰는셈이기 때문이다. 근데 반칙이고 자시고 암튼 엄청 편하다. 하스켈 쪽에서 근본있는 방법으로 같은 편리함을 달성하려면 매우 힘들고 그걸 사용하는 사람도 공부를 많이 해야할것이다.

오픈소스 레포에 Windsurf Agent로 짠 Swift 코드로된 PR을 날렸는데, 저자의 코드 리뷰를 복붙해서 그걸 그대로 다시 Windsurf Agent한테 전달하고 있다. 이게 머하는 짓이고...

오픈소스에 토큰으로 기여하는 방법을 제공하는 플랫폼이 있나? Buy me tokens?

XCode는 내가 잘 몰라서 못쓰는건지 그냥 구려서 쓰기힘든건지 아직도 모르겠다...

케데헌 히트치는거보고 문득 든 생각

약 20년 전부터, 한국 인터넷 커뮤니티에 '떡볶이 참 맛있는데 외국인들도 좋아하지 않을까?' 이런 의견이 종종 올라왔었다. 근데 그 질문이 올라오면, 얼마 지나지않아 누군가가 '엣헴...서양인들은 떡의 sticky한 texture를 좋아하지 않습니다ㅎㅎ'이라는 답변을 다는걸 볼수 있었다. 내가 이걸 한두번 본게 아님.

근데 그 답변자에게 궁금한건. 그... 님은 떡복이를 실제로 드셔보셨나요? 떡볶이는 약으로 치면 마약이고 SNS로 치면 틱톡입니다. 감자튀김만으로 300파운드까지 벌크업하는 미국인들이 떡볶이에 저항할수 있을거 같으십니까?

아무튼 결국 20년이 지난 지금, 김구 선생님이 바라던 문화 승리를 목전에 두고 있고 떡볶이도 덩달아 인기를 끌고있다. 그동안 떡뽁이를 수출못했던게 그 sticky texture가 결정적인 문제였던건 아닌것으로? 결론은 그래서 '가장 한국적인 것이 가장 세계적인 것이다'는 아니고

인터넷에는 자신의 '오감'을 속여서까지 아무 소리를 당당하게 하는 사람들이 존재한다는 것이다. 당장 '엣헴'을 한번 하기 위해 생각을 포기하고 스스로를 속인다.

언젠가 tuple이란 이름의 (,)를 로고로 쓰는 서비스를 만들고싶다. 웃긴건 정작 뭐하는 서비스인지는 아직 생각을 안 해놓음;; 대충 사람들을 짝지어주는 데이팅 또는 커피챗 주선 서비스면 이름과 어울리지 않을까 싶은데...

JS에서 Promise는 await으로 값을 읽는 것 외에, 현재 pending 상태를 읽는 등의 동작을 허용하지 않는다. 이거 왜 안되냐고하면 Promise의 의미론과 배경 철학이 어쩌구저쩌구하는 대답이 돌아온다. 내 생각에 그건 틀렸다. 이유는

간단한 대답: 가능하면서 왜 안해줌?

약간더 복잡한 대답

그 제약 조건은 Promise가 callback과 같은 의미의 다른 표현일때는 성립한다. callback이 전달하는 값은 특정시점 = t에 존재하는 것이다. t이후에 그 값을 사용하기위해선 따로 저장을 해놓던가해서 값의 존재시기를 >= t 로 바꾸어야한다.

그런데 Promise는 await을 여러번 하는걸 허용한다. await x; await x; 이런식으로. 값이 없으면 기다리고, 값이 한번 들어오면 그걸 계속해서 돌려준다. 여기서 Promise가 callback이랑 다른게 드러난다. 그리고 실제로 callback과 다르게 동작하기위해 값의 여부 등을 내부 상태로 갖고있을수 밖에 없다.

요약하면, callback과 완전히 상호호환될때 정당화되는 제약을 callback이 아니면서 강요하니까 문제란 얘기다.

화제의 케데헌을 봤는데 재밌고 노래가 좋았다. 일종의 마법소녀물인데, 시간이 짧아서 그런지 마법소녀물의 전형적인 설정들을 '다들 대충 알쥐?' 정도로 빠르게 넘어간다. 그래서 오히려 다 보고나서 마법소녀물에 대해 잠깐 생각을 하게 되었는데.

마법소녀물에서는 소녀들에게 의무가 일찌감치 구체적으로 주어지고 소녀들은 그걸 순순히 받아들이고 이행한다.

소년만화에서는 보통 소년들에게 처음부터 의무가 주어지지 않고 그들 스스로 원피스를 찾겠다거나 호카게가 되겠다거나 하고 선언한다. 유유백서나 블리치처럼 의무가 주어지는 경우에도 약간 임시직의 형태로 주어지고, 주인공 쪽에서도 그걸 순순히 받아들이지 않고 반항한다.

마법소녀물이나 소년만화나 대충 각각 공주랑 왕자가 제자리를 찾는 이야기로 볼수 있다.

마법소녀물에서는 주인공에게 의무를 부여할때 공주의 지위도 같이 준다. 예쁜 드레스도 지어주고 집사도 배정해준다(귀여운 애완동물도 겸하는 경우가 많다).

반면 소년만화의 주인공은 결말에 가까워지기 전까지 반지의 제왕의 아라고른처럼 왕자의 신분을 잃어버린 채로 지낸다. 소년만화의 클리셰로 주인공의 존나쎈 아버지가 있는데, 이게 일종의 승계의 정당성을 부여하는 역할을 한다. 그리고 우리 소년 독자들은 그걸 너무너무 좋아한다.

많은 오픈월드 게임이 '정신을 차려보니 어떤 처음보는 공간에 있다가(감옥/실험실/다른 세계 등등) 결국 어찌저찌 세계를 구함' 이런 전개를 따른다. 근데 처음에 시작하는 곳에서 NPC들이랑 언어가 달라서 말이 안통하는 상황으로 시작하는 게임이 있던가? 여태 해본 게임에서는 말이 다 통했던거 같다.

양심고백: Git CLI 와 Gitkraken에 여전히 모르는 기능이 많아, GitHub 또한 일종의 Git GUI로 쓰고있다;;

토욜에 튜링의사과 남은 시간을 마저쓰러 갈듯합니다

아이폰을 쓴지 어언 10년째. 여전히 텍스트 인풋에서 커서를 이동하는 방법을 모른다;;

이미 늦은 제안같지만... 터미널에 뭔가를 보여주는 방법에, 그냥 stdout에다가 출력하는 거랑, TUI 프로그램들이 사용하는 ANSI Escape Sequences가 있다. 전자는 가장 간단하고 무식한 방법이고, 후자는 무제한의 자유도를 제공하는, 그래서 그위에 TUI를 구현할수 있는 방법이다.

나는 그사이에 적당히 구조화된 출력을 할수있는 방식이 있으면 좋겠다. JS에서 console.group하듯이 말이다. 그래서 출력이 너무 길면 fold/unfold도 할수 있고? 지금 큰 코드베이스에다가 빌드돌렸다가 에러나면 무슨 맥락인지 파악하는데 한세월인데, 그런걸 잘 읽게해주는데 도움이 될것이다.

나는 첫 웹사이트 개발을 C로 했는데(진짜 HTTP 서버를 만듬;;), PHP를 살펴봤다가 너무 배워볼 마음이 안들어서 그때 알고있던 C로 짰다. PHP 해괴한걸 알아본건 잘했는데, 다른 대안을 찾아볼 생각도 안하고(그때도 Java도 있고 Python 웹 서버도 있었음) C로 쓸데없이 차력쇼한건 한심했다. 좀더 똑똑했으면 고생도 덜하기 진작에 좋은걸 많이 배웠을텐데 말이다. 벨 커브 밈이 떠오른다.

RxJS의 cold observable은 처음에 배울때 많이 헷갈린다. 하지만 쓰다보면 익숙해지고 오히려 우아해‘보이는’ 코드를 짤수 있게 된다.

근데 그 우아함이 거짓 우아함이란 생각이 든다. Cold observable은 subscribe 메소드를 이펙트풀하게 만든다. 아닌게 낫지않나? 내가 아는 모든 cold observable 사용은 명시적인 함수 호출(이펙트를 발생시키는)을 하나 추가하는 것으로 피할수 있다.

보통 러닝커브가 있는 기능이 오래 존속하고 있으면 고진감래의 미덕이 있는 법인데 얘는 좀 특이한 경우인듯.

React Native 및 앱 개발 생태계에 대해 욕하고 싶은 사람들이 모이는 연합우주 인스턴스가 있었으면 좋겠다...

요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.

어제 Phanpy라는 마스토돈 클라를 알게됐고 감탄했다. 이상적인 타임라인 UI야...

잘 못만든 선언형 인터페이스보다는 잘 못만든 명령형 인터페이스가 낫다. 후자는 피똥싸면서 뭔가를 어찌저찌 해낼순 있는데, 전자는 아예 뭔가를 하는게 불가능한 경우가 많다.

내일 모각코가 매우 기대되는구만요

방금 또 빌드 캐시 삭제를 일찌감치 시도해보지 않는 오만함 때문에 1시간을 허비했다ㅠㅠ

하다하다 Prisma의 Rust PANIC도 다 보는구나

PANIC: called `Option::unwrap()` on a `None` value

억까 그만해!!!

그동안 멘토링하면서 느낀게, 나한테 암묵지가 별로 없다는 것이다. 전문가는 암묵지가 많다는데, 나는 내 스스로가 매우 간단한 휴리스틱으로 동작한다고 느낀다. 난 전문가가 아닌건가? 내가 그동안 쌓아온 것은 암묵지라기보단 어떤 특정한 사안에 대한 강한 믿음들인거 같다.

나는 리액트에서 성능 자체가 떨어지는 부분보다(제대로 체감한적 없음), 성능을 고려해서 컴포넌트를 일부러 나눠야하는 점이 더 맘에 안든다.

주말에 튜사 모각코하실분 있나요~