bgl gwyng

@hollo 아 어찌저찌 고쳤습니다ㅎㅎ

앱개발해야하는데 아이폰 터치가 고장나서 아무것도 못한다. 억까가 끝이 없구나.

프론트엔드 개발을 한 6년정도 하면서 생긴 아직 풀리지 않은 의문으로, 템플릿과 공식 문서에선 그렇게 세련되고 예쁜 컴포넌트들이 왜 import해서 내 프로젝트에서 쓰면 개촌스럽고 못생겨지냐는 것이 있다.

단문으로 짧게 쓰려했는데 분량 조절에 실패해서 그냥 메모리 덤프를 해봤다. 머리에 별로 든게 없어서 한 페이지면 충분했다.

구글이 AlphaEvolve란걸 내놨는데, AI로 새로운 알고리즘을 찾아내서 구글 인프라에 적용시켰다고 한다.

논문을 보니 Gemini 2.0 기반으로 했다는데, 몇번 채팅으로 시험해봤을때 인상적이지 않았던 2.0으로도 이런 결과를 낼수 있다는게 놀랍다. 새로 나온 훨씬 똑똑한 2.5로 하면 어떤 결과가 나올까?

AI의 재귀적 자기 개선이 먼 미래의 일이었던 과거에는, 이런식의 자기 개선 시작되면 그땐 정말로 게임오버일거라고 생각했었다. 아마 나말고도 많은 사람이 그랬을 것이다. 근데 막상 자기 개선이 시작되고나니 이 속도를 어떻게 평가해야할지 모르겠다. 사실 구글이 AI를 통해 인프라를 개선한게 이번이 처음은 아니고 한 3년전부터 있던일이다. 지금 이게 얼마나 빠른거야?

낮에 피쳐 쫙쫙 찍어내고 일이 잘되야 남은 체력으로 자기전에 사이드 작업을 하는데, 낮에 트러블슈팅으로 시간 다 날리고나면 자기전에 코드를 보는거조차 싫어진다. 이거 때문에 reactive joinable table 진도가 2주째 안나가고 있다.

React Native(와 휘하의 써드파티 라이브러리들)는 개발자로 하여금 꼼수를 고안해내기를 끊임없이 요구한다.

유려한 transition animation을 정확하게 구현하려면, transition 후의 레이아웃을 미리 계산해야하는데 이를 위해 일종의 offscreen dry rendering을 해야한다. 실제로 web의 animation 라이브러리 중에 임시로 DOM 트리 만들어서 offsetX같은거 읽는 방식이 있는걸로 안다. 근데 이런 동작을 브라우저 렌더링 엔진이 효율적으로 처리하고 있는지 모르겠다. 혹시 web이 아닌 UI 라이브러리 중에 layout에 대한 primitive를 사용자에게 잘 노출시켜놓은 예시가 있을까?

CCL이라고 일종의 함수형 configuration 언어가 있는데, 여기 소개에 기존 configuration 언어들을 평가하는 단락이 있는데 웃겨서 가져와본다.

TOML

Tom’s Obvious Minimal Language means it’s obvious only to Tom.

XState Store 좋아보인다. 진짜 이거 하나로 상태관리 다 때울만하겠는데?

Figma보다 나은 디자인툴을 만들기 위해서 뭐가 필요할까? 여러 축으로의 개선이 가능하겠지만, 근본적으로 더 우월한 뭔가를 만들고 싶다면 Figma가 내부적으로 쓰는 디자인 언어보다 나은걸 만들어야 한다. 즉 flexbox + CSS + 뭐시기 보다 나은 디자인 언어가 필요하다. 반대로 그런 언어를 이미 알고있다면 그걸 기반으로 GUI 툴을 만드는건 역시 야심찬 작업이긴해도 비교적 자명한 일이 된다. 어떤 툴이든 그것이 내부적으로 쓰는 언어를 능가하는 기능을 제공할순 없다.

라우터 로직을 죄다 XState로 옮기면 무슨 문제가 있을까요? 파일 기반 라우팅 같은건 쓰고 있지 않고, 크게 매력을 못느낍니다.

무언가가 프로그래머블하다는 것은 문제가 생겼을때 디버깅을 해야한단걸 의미한다. 전세계에 프로그래밍을 좋아하는 사람들은 수백만명 정도 있고, 디버깅을 좋아하는 사람은 정확히 0명 있다.

• Nix의 개발새발 빌드 에러메시지를 읽고 있는 누군가

Hell이라고 쉘 스크립팅을 할 수 있는 하스켈 방언이 있네.

Nix 언어를 새로 만들지말고 그냥 Python DSL 같은걸 썼으면 어땠을까 종종 생각한다. 그 세계선에선 또 그 Python DSL 욕을 주구장창 하고 있겠지만, 적어도 생태계는 더 커지지않았을까. 남바완 Linux 배포판이 됐을 수도 있다.

빌드 고치는 것과 같이 결과물을 확인하는데 시간이 오래걸리는 일을 하는 날엔 엄청 비효율적으로 일하게 된다. 이상적으로 생각하면 빌드 돌려놓고 그사이에 다른일 하면 되긴하는데, 나는 컨텍스트 스위칭이 너무 느려서 그게 잘 안된다. 잘 하는 사람은 실제로 병렬로 일을 처리할 수 있나?

뉴럴넷을 설계할수 있는 GUI를 프로토타이핑 해야하는데 좋은 방향이 생각이 안난다. 첨에 착수할땐 자명하다고 생각했는데, 막상 시작하고나니 의외로 참고할 물건도 적고 난감한 상태다.

비올때 엘리엇 스미스 틀어놓고 코딩하고 있으면 기분이 괜찮다.

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

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

혼자서 일하면 끔찍한 관리자 밑에서 일하는 경험과 끔찍한 프로그래머를 관리하는 경험을 동시에 할수 있다. 개꿀~

나는 버전 올리기 강박증같은게 있는데, RN 초기에 불안정한 라이브러리들 많이 쓰다가 생긴거 같다. 일단 버전 올린다음에 빌드 터지는지 기존 기능 잘돌아가는지 확인하는데, 이거하느라 쓰는 시간도 꽤 된다. 실제로 시간을 아끼고 있는지(모르던 버그를 모르고 해결해서) 아닌지 모르겠다.

.cursorrules나 .windsurfrules 등의 파일에 프로젝트에 대한 설명을 써놓는것도 도움이 되나요? 공심 홈페이지의 가이드라인을 보면 코딩스타일 등의 지침만 써놓아서요. 어차피 알아서 일종의 인덱싱을 할테니 필요없을까요?

잉 drizzle에 Live Query 지원이 되네요? [join된 테이블의 reactivity에 문제가 있는데] 이건 고치면되는 버그같고요? 지금 만들고 있는거 왜 하고있지? 제가 원하는 추가 기능을 넣으려면 새로 짤 필요가 있을순 있지만 말이죠.

실제로 방금 어떤 사례를 발견했냐면, 계산이 살짝 까다로운 값에 대한 테스트를 만들라고 시켰더니 코드를 한 백줄 뱉어내는데

expect(x).toBe(42)

이렇게 값에 대한 테스트를 안하고

expect(typeof x).toBe("number")

이러고 넘어가려고 했다. 손바닥 이리내.

join을 지원하는 reactive한 SQLite client 개발 거의 다 되어간다. 혹시 중간에 관두는걸 막기위해 남긴다.

AI가 짠 코드의 테스트코드를 AI한테 짜게하고 있으니 Who watches the watchman? 이 떠오르는 것이다.

.vscode/settings.json으로 확장 켜고끌수 없나 찾아봤는데 해당 이슈가 8년째 오픈이란걸 알게되었다.

똑같은 인터페이스에 대한 여러 구현체에 대해 같은 테스트를 적용하기위한 좋은 방법이 뭘까요? vitest의 경우에 test.each(implementations) 이런식으로 할수 있다는데, 이러면 구현체가 늘어났을때 테스트 파일을 수정해야하는점이 마음에 안든단 말이죠. 지금 구현체를 인자로 받아 테스트를 정의하는 함수를 만들고 각 구현체 마다 .test.ts파일을 만들어서 호출하는 방식을 고려하고 있습니다. 더 좋은 방법이 있을까요?

SolidJS는 React처럼 Reactivity 코어가 분리되어 있지않은거 같다? solid-three, solid-native 등의 프로젝트들이 있는데 2년넘게 관리되고 있지않다.

LLM 시대 이후로 생산성과 관련해서 스트레스를 더 많이 받는거 같다. 당신이 오늘 허투루 보낸 하루는 누군가가 올바른 프롬프팅으로 +10K LOC를 할수있는 하루였다, 같은 생각을 퇴근하면서 한다.

요즘 잡일은 AI 시키고, 그사이 어려운 일을 AI랑 힘을 합쳐 해결해야하는 시대인데, 내가 하루종일 어려운일을 할 체력이 없어서 머리비우고 할수있는 잡일도 일정량 직접 한다. 파일 상하차라던가.

Relay로 offline db sync를 하고 있었을땐, Relay가 Node의 Id나 Edge의 Cursor가 Opaque란 가정을 하고있는게 걸림돌이라고 느껴졌다. SQLite에 저장하려면 어차피 id로 부터 composite key를 구해야하고, 거기엔 또 order도 존재하는데 Relay는 이런데 전혀 무관심하다. 하지만 일반적인 웹사이트 렌더링에는 저런 가정이 전혀 무리가 없다.

Signal같은건데 incremental update도 되고 GC도 가능한 무언가를 만들려고 했더니 이런 정의가 나왔다. 혹시 비슷한거 알고 계신분 있나요?

type Dynamic<Value, Delta> = {
	read(): Value;
	disconnect(): void;

	updated: Observable<Delta>;

	fork(): Dynamic<Value, Delta>;
};

그동안 Relay를 offline db sync 용도로 쓰고있었는데(첨부터 그러려고 했던건 아니고, API 두벌 만드는걸 피하다보니 그 역할도 떠맡음), 그래서 Relay가 킹론상 좋다는건 아는데 실질적으로 장점을 못누리고 살았었다. 근데 지금 추가하는 기능에서는 Relay를 본래 용도에 맞게 쓰고있는데, 설계 고민도 줄여주면서 코드가 쭉쭉 나온다.

그동안 하던 앱/웹 작업이 아닌 라이브러리 개발이라서 verification이 훨씬 쉬워서 본격적으로 에이전틱하게 쓸수있었다. 테스트코드도 자동으로 쭉쭉 뽑으면서 나는 거의 관리감독만 한다. 에이전틱하게 쓸때의 생산성이 최소 10배는 되는데, 반대로 1/10의 생산성을 가지는 어시스턴트 모드에서의 좋고나쁨이 뭐가 그리 중요할까.

Windsurf 커서보다 불편하다고 계속 불평했는데, 그냥 과제하나 맡기고 에이전틱하게 쓰니까 똑같이 잘한다. AI 에디터에서 UI 개선한다고 아웅다웅하는게 참 부질없는거 같다. 빅테크에서 모델 개선하는동안 가만히 놀수는 없으니까 하는건가...

어릴때 알고리즘 문제풀면서 시꺼먼 터미널만 보다가 저기 있는 예시 따라해서 GUI 프로그램이 뜨는거보고 즐거웠던 기억이 난다.

RE: https://hackers.pub/@aioo/01968b3c-a3cb-78dc-b781-c25e01650ec3

.windsurfrules를 채워넣었는데 이게 효과가 있는지 없는지 모르겠다. 혹시 좋은 방법 있나요? 이것도 어떤 잘알려진 방법을 따라 LLM이 쓰게하는거보다 더 잘할 방법이 없을거 같다.

그로센딕이 김장을 할줄 알았다는 이야기는 알고 있었는데(한번 들으면 못까먹음), 이렇게 본격적일 줄은 몰랐다. 한국인인 나보다도 김치에 대해 더 잘 안다.

휴일인지 깜빡하고 출근해버렸다ㅋㅋ

방금 동탄에서 마을버스타는데 브레이크가 고장나서 다음버스로 갈아탔다. 근데 기사분이 회사쪽 관리자랑 통화하는데, 관리자가 일단 조심해서 차고지로 돌아와보라고 하는것이다. 정 안되면 렉카를 부르자고 했다.

이 무슨 개똘추같은... 안그래도 비까지 오는데 사고나면 누가 책임질건가. 암튼 그 기사님이 무사히 돌아가길 빈다.

멘티를 서울숲하스켈에 보냈었는데, 거기갔다 왔더니 이제 JS 코드짤때 커링을 알아서 잘 활용한다. 사실 내가 그분께 주는 피드백이 '좀더 함수형으로 짜라' 이상도 이하도 아닌데(이거 들키면 안됨), 방법을 하나하나 가르치려니 너무 피곤해서 하스켈을 배우게 시켰다. 리턴 확실하구만.

'모나드는 모노이드 엔도펑터다'가 이제 무슨 뜻인지는 안다. '모노이드'라는게 >>= 보다는 join을 쓸때 더 와닿는데, >>=를 join보다 한 30배는 더 자주 쓴다. 그래서 저 사실을 평소에 잘 느끼고 살진 못하는거 같다. 하지만 가끔 join으로 타입을 눌러서 맞출때 개꿀따리란 생각이 들긴하다.

Hacker's Pub에 어울리는 추가 기능이 뭔가 생각해봤는데, 프로그래밍 언어를 토픽으로 필터링할수 있음 좋겠다. Markdown의 코드블락으로(python 등) 상당히 커버되지 않을까?

뒤늦은 서울숲하스켈 조교 후기: 왠지 모르겠는데, 다들 운동을 열심히 하시는지 몸이 굉장히 좋으셨다. 건강한 신체에 건강한 정신이 깃든다를 실천하고 계신 분들이었다.

...는 농담이고(근데 사실입니다), 커리큘럼이 내가 상상하던 방향이랑은 꽤 달라서 흥미로웠다.

마지막 회차에 하스켈로 웹서버를 띄우는 것을 목표로 진행중이었는데, 이를 위해 Monad Transformer(Monad는 진즉에 해치우고), Tagless Final, Lens를 모두 소개한 상태였다. 근데 저 개념들이 '왜 하스켈에선 이거 안 돼요? 왤케 불편해요?' 같은 질문을 회피하지 않으려면 꼭 가르쳐야 하는 부분들이긴 하다. 가령, 'Monad만 배우면 이제 하스켈에서 명령형 코딩 할수 있다'라는 이야기가 이론상은 맞는데, Monad Transformer나 Algebraic Effect 같은거 안쓰면 웹사이트등 실제로 쓸모있는 프로그램을 사실상 짤수가 없다. 그래서 가르치긴 해야한다.

문제는 저걸 다 가르치려면 상당히 빡셀테니, 나는 만약에 내가 하스켈 부트캠프를 한다면 일단은 저런걸 회피하고 하스켈의 멋진 부분에 집중하는 커리큘럼을 짜야겠다고 그동안 생각했었다. 근데 또 이건 어찌보면 기만이기도 하다. 그런데 서울숲하스켈에서는 어찌저찌 다들 따라오도록 구성을 잘하신것 같다 하스켈을 이질적인(긍정적으로든 부정적으로든) 프로그래밍 언어로 소개하는게 아니라, 언젠가 본인의 작업에 활용할 언어의 후보로 올리게끔 하려면 저런 내용들을 다 다뤘어야 할것이다.

암튼 그동안 수고많으셨습니다. @eunmin은민

develop :: Maybe Coffee -> IO Code
develop Nothing = pure Garbage
develop (Just fuel) = do
code <- think fuel >>= implement
filter (writtenIn Haskell) code

그때 하스켈학교 디스코드에서 코드 백일장 열어서 나온 것들을 조합해서 만들었다.

RE: https://hackers.pub/@bgl/01967fa1-dee1-76ca-93bc-1778c0dc9a75

서울숲하스켈보고 예전에 카카오 하스켈부트캠프했던게 생각났다. 그때 굿즈도 만들었다. hoxy 갖고싶은분 계시면 마플에 새로 주문넣어서 보내드립니다.

러스트가 어렵다는 이야기가 숙고없이 재생산 되는거 같긴 합니다. 제가 러스트를 별로 안써봐서 실제로 얼마나 어려운진 모르겠습니다.

그런데 말씀하신 모나드, 트레잇, 오너십 등의 개념들과 클래스는 좀 차이가 있다고 생각합니다. 그러니까 자바에서 클래스 때문에 어떤 코드를 못짜게 되진 않잖아요? 자바를 하면서 클래스를 제대로 쓰지않고도 뭔가 만들순 있습니다. 반면 전자의 개념들은 잘못된 코드를 짜는걸 막고, 초보자 입장에서 뭔가 하고싶은게 있는데 그게 금지되는 상황에서 어렵다는 느낌을 (필요이상으로 크게) 받을수 있다고 생각합니다.

RE: https://yuri.garden/notes/a75i1vf42f

한달간 써본결과 Cursor >> >Windsurf 란 결론을 내렸다. 근데 Cursor는 프로젝트를 켜지를 못한다는(...왜???) 사소한 문제가 있어서 못쓰고 있다.

Protected Route에 대해 좀 생각을 더 해봤는데, 난 처음엔 React Native Navigation에서만 쓰는 해괴한 방식인줄 알았다. 근데 좀더 생각해봐도 별로긴하다. 라우터란게 결국 전체 상태중에 path만 별도로 관리해주는 건데,

app :: State -> View
--- router 도입
app :: (Path, State) -> View
--- Protected Route
app :: State -> Path -> View

여기서 대충 말해서 Path -> View가 라우터라 할수 있겠다. Protected Route는 State로부터 라우팅 룰을 동적으로 바꿔버리는 방식이다. 근데 애초에, 라우팅 룰을 정적인 정보로 만들고(즉 ->가 아님) 활용할게 아니라면 라우터를 쓸 이유가 뭘까? 그냥 Path를 일반적인 다른 상태와 똑같이 취급해도 상관없을 것이다. 근데 react-router도 그렇고 애초에 라우팅 룰을 정적인 정보로 알수있는 설계로 되어있지가 않다. Tanstack Router는 예외다.

근데 이러면 그냥 XState 쓰면 되지 않나? 상태/전이에 대한 정적인 정보를 가지고 있고, 또 React Native에서의 라우팅에는 화면 전환이 단순한 Path 변경이 아닌 어떻게 화면을 전환 시킬지(애니메이션 등)도 기술해야하는데, 이 역시 XState 이벤트로 넣으면 된다.