내일도 튜링의 사과 출근해야지
Ji-Haeng Huh
@jhhuh@hackers.pub · 45 following · 30 followers
i am the one who knocks
github- @jhhuh
@bglbgl gwyng 이거 이제 정규 이벤트가 되는 건가요?
역시 코드는 추가할 때보다 삭제할 때가 더 타격감이 좋다
@jhhuhJi-Haeng Huh 음… 제가 처음 글을 쓸 때 가정했던 대상과는 좀 다르신 것 같아요.
저도 한 때 포매터에 거부감이 있었는데요, 그 이유는 서식을 원치 않기 때문이 아니라 서식화가 제가 원하는 대로 이뤄지지 않기 때문에 그랬거든요. 포매터가 만드는 서식과 제가 원하는 서식의 불일치가 있었던 거죠. 즉, 포매터의 구현이 문제였다고 생각합니다. 아마도 지행 님의 경우에도 원하시는 서식이 따로 있고, 그 서식을 세밀하게 구현하는 포매터가 없는 것에 대한 거부감이 아닐까 추측해 봅니다.
그런데 제가 글을 쓸 때 가정했던 대상은 따로 원하는 서식이 있기 때문에 포매터를 거부한다기 보다는, 그냥 서식 자체가 어찌 되든 상관 없다고 생각하는데 귀찮게 뭔가를 추가하자고 하니까 거부감을 느끼는 사람들에 가까웠어요.
@hongminhee洪 民憙 (Hong Minhee) 네넵. "가정하신 대상"과는 다른 게 맞습니다.
애초에 “그런 거 쓸 거면 Python 안 쓰죠”라는 말이 담고 있는 인과관계가 단순히 해석되기 어렵다보니 언급하신 집단이 실제 어떤 성격을 갖고 있는지 파악하는 건 일찌감치 포기했습니다. 그래도 이게 단순한 귀찮음을 넘어서 심리적인 거부감이 있는 걸 다르게 표현했을 수도 있겠다는 생각에 이르러 남긴 사족입니다.
사실 저런 종류의 워딩이 캐쥬얼한 대화에서 나온 거면 상관없는데 누군가의 구체적인 제안을 리젝하는데 (부가적인 설명없이) 사용된 거라면 그 자체로 아쉬운 상황이네요.
아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.
@hongminhee洪 民憙 (Hong Minhee) (저를 비롯한) 특정 집단에서 온 사람들이 린터나 포매터에 신경을 덜 쓰는 것은 사실입니다. 사실 신경을 덜 쓰는 것을 넘어 미묘한 심리적 거부감까지 있다고 보는 게 맞다고 생각해요. 특히나 도메인이 많이 녹아 있는 코드 영역에 까지 기계적인 포매팅 룰을 강요해야 하는가에 반응들은 좋게 봐서 "문명의 충돌", 낮춰 보면 "부족의 자존심을 건 싸움박질"의 양상을 띄는 것 같습니다. 이런 이야기가 나올 때마다 생각할 거리로 fastai의 코딩 스타일 가이드(https://docs.fast.ai/dev/style.html)를 한번씩 다시 읽어 보는데 매번 제 관점도 조금씩 바뀌어 가는게 흥미롭네요.
Why not use PEP 8?
I don’t think it’s ideal for the style of programming that we use, or for math-heavy code. If you’ve never used anything except PEP 8, here’s a chance to experiment and learn something new!
My editor is complaining about PEP 8 violations in fastai; what should I do?
Pretty much all editors have the ability to disable linting for a project; figure out how to do that in your editor.
Are you worried that using a different style guide might put off new contributors?
Not really. We’re really not that fussy about style, so we won’t be rejecting PRs that aren’t formatted according to this document. And whilst there are people around who are so closed-minded that they can’t handle new things, they’re certainly not the kind of people we want to be working with!
const light = 300000
@curry박준규 심지어 빛의 속도 299,792,458 m/s 는 근사값도 아니고 참값이죠. (technically speaking)
nn년동안 햇빛과 친하지 않게 살아서, 지금은 뱀파이어와 다른 성향이 생겼습니다. 해만 보면 30분 이상은 슬로우 조깅을 하고 싶어합니다. 롱런할 개발자분들은 햇빛과 친분도를 잘 생각하며 살아야 합니다. 탈나는 사람들 자주 봅니다. 오늘 폭염 경보라는데, 그래도 해볼까 생각 중인데요. 죽진 않겠지요?
@lionhairdino 요 며칠은 해가 지고 나서도 지상의 열이 식지 않아서 뛰기에는 새벽 4-5시가 가장 적당합니다.
요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.
@bglbgl gwyng 여태 Go를 제대로 본 적이 없어서 오히려 갑자기 궁금해지네요.
1년동안 살아남는 거 말고는 한 게 없는 삶이 되버렸구만
@perillamint
서버메이드 깐프 그래도 제일 중요한 과업을 성취하셨네요.
@bglbgl gwyng 네, 그런데 fromJust보다 Option::unwrap()이 훨씬 많이 쓰인다는 느낌이 있습니다. 🤔
@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng Option::unwrap() 떡칠된 코드를 많이 보게 되는 건 (또는 반대로 과하게 Option/Result의 스택이 켜켜이 쌓여있는 걸 보게 되는 건) 러스트에 try-catch가 없어서 그런거라고 생각합니다. 분명 예외적인 상황이라 일반적으로는 exception raise 됐을 만한 상황에서도 많은 함수들이 유유히 None을 내놓고 콜러의 처분을 기다리니 아무래도 unwrap에 손이 잘 나가는 거 아닌가 싶네요.
이와 다르게 하스켈에서는 함수가 Nothing이나 Left e를 내놓을 땐 "비록 콜러가 원하는 바를 이루지는 못했지만 예산 가능한 시나리오"를 의미하는 경우가 많아 fromJust를 쓰려다가도 한번 더 생각하게 되는거 같구요.
뭔가를 잘 설명하는 방법에 대해 생각해봤는데. 일단 내가 어떤 내용을 말하고 싶은 욕구를 참아내야다. 어떤 재치있는 비유를 꼭 써야겠다거나, 아니면 '통찰'을 전달하고 싶다거나.
대신 상대방의 무지에 공감해야한다. 그 무지란게, 많은 경우 진짜 멍청해서 그런게 아니라, 대충 얼개는 파악하고 있음에도 뜬금없는 부분에서 뜬금없는 오해를 하고 있어서 완전한 이해를 막는다거나 하는 경우가 많다. 그래서 그 귀여운 멍청을 함께 디버깅해야한다. 요게 지식뿐만 아니라 공감능력이 필요한 부분.
주말에 튜사 모각코하실분 있나요~
@bglbgl gwyng 아..소중한 제 모각코 첫경험 기회인거 같은데 안타깝게 이번 주말은 서귀포에 있습니다.
Another blog post on homotopy almost ready.
@jhhuhJi-Haeng Huh RTS 플래그는 어떤걸 줘야하나요? 그리고 빌드할때 주는건가요? 사실 패키지 구조에의 문제는 의심스러운게, 멀티 패키지 레포지만 HLS 자체 레포보다도 작을거에요.
@bglbgl gwyng 잘 모르겠어요. 예전에 RTS 플래그를 잘 주면 HLS가 성능이 좋아진다는 글을 봤던 거 같은데 못 찾겠네요. LLM을 많이 써서 할루시네이션이 전염된 건가?
일단 --nonmoving-gc를 써서 메모리 heap사용량을 줄이라는 얘기는 있네요. inline-c를 쓰지 않을까 예상돼서 FFI+TH 관련 이슈에 대해서도 생각해볼 수 있을거 같은데 HLS 작동 방식을 제대로 이해 못해서 정확히는 모르겠습니다.
이웃집에 자녀가 둘이 있다는 건 알고 있었는데, 오늘 아침 아내가 그 집 아들을 만나 인사했다고 한다. 그 얘기를 듣고 그럼 다른 아이는 딸일 확률이 높겠네 라고 말했더니 아내는 별 말 없이 고개를 끄덕였다. 이 때 내 아내가 이과 전공자일 확률은?
기대를 갖고 HLS를 2.10으로 버전업했는데 여전히 너무 잘 터진다. 혹시 우리쪽 패키지 구조에 문제가 있는건가 싶기도한데...
@bglbgl gwyng 혹시 HLS에 RTS 플래그 줘서 튜닝해보셨나요? 멀티 패키지 레포 쓰면 HLS에 무리가 가긴 할 거예요.
10x engineer: "Yeah. NixOS is the best for every use case."
인스타 클론 코딩 만만하지 않은것으로 밝혀져...
@bglbgl gwyng 얼마전에 "OpenMP 런타임 구현이 생각보다 간단하다 새로 짜볼 수 있겠다"는 말을 한 저를 되돌아 보게 되네요.
[속보] OpenMP 런타임 구현 생각보다 만만치 않은 걸로 밝혀져..
@bglbgl gwyng @jhhuhJi-Haeng Huh 팡하하하.. (팡셔널 하하하 라는뜻ㅎ)
@jhhuhJi-Haeng Huh 대신 팡터는 써도될까요?
@bglbgl gwyng 아니, 스테이지 1/2/3은 예전에 클리어하신 영웅캐 아니셨어요? ㅎ Zygohistomorphic prepromorphisms 쓰신다고 해도 인정합니다.
어제 싸지르고 아차 싶었는데, 제가 자격론 운운하는 건 절대 아니고 오히려 반대예요. 뭐든 그냥 하면 되는데 자꾸 뭔 갈 복잡하고 어렵게 생각하는게 만드는 뭔가가 저희 안에 있는거 같아요. 제가 요새 자꾸 stage 2/3으로 돌아가는 거 같아 쓴 반성문입니다.
"팡션 쓰지 마세요"
- 팡션을 써야할 이유도 모르고 쓸 줄도 모르지만 왠지 쓰는 게 멋있어 보여 자신이 찾는게 무엇인지도 모른채 인터넷을 헤매이며 시간만 보내고 있다거나,
- 결국 어렵게 찾아낸 팡션 보다 더 좋은 팡션이 있을지 모른다는 두려움에 빠져 매일 새로운 팡션 상세를 뒤지며 오늘도 시작을 미루고,
- 이에 더해 위의 과정을 통해 얻게 된 나의 피상적이지만 방대한 지식에 왠지 모를 뿌듯함을 느끼며 이 모든 것을 합리화하고 있다면,
팡션 그냥 안쓰는게 제일 좋다고 생각한다. 물론 모두 다 합리적인 선택만 하고 살면 세상이 재미가 없으니 각자 알아서 자기 시간/리소스 걸고 빼팅하는 것에는 무한한 존경과 존중을 보낸다.
평소에 함수형 언어 매니아들이 주장하는만큼 이펙트를 엄격하게 구분하는게 중요하다곤 생각안했는데, local first 앱을 만들다가 네트워크 요청을 포함한 IO와 그렇지 않은 IO를 구분해야하는 이유를 찾았다. 앱의 초기화 로직에 네트워크 요청이 숨어있으면 API 서버 장애시 앱이 아예 안켜지는 문제가 있다. 방금 이거랑 관련된 버그 찾느라 시간을 많이 썼다.
@bglbgl gwyng 그들은 함수형 언어의 "유저"가 아니라 "매니아"였군요 ㅋㅋㅋ 저는 "매니아"에서 빼주세요. 그냥 저는 "유저" 그것도 아니면 "장기 모범수" 정도인 것 같습니다.
공인인증서의 생체인증 기능 말인데요, 이거 개인키를 기기가 아닌 서버에 두고 서명하는 건가요?
@bglbgl gwyng 혹시 공공입찰 들어갈 때 쓰는 바이오토큰 말씀하시는 건가요? 당연히 기기에 들어가 있는 걸로 알고 있는데.. 만에 하나 복사본이 서버에 있을 가능성이 있나요? 생각만 해도 무섭..
0차 닉스 모임을 다녀왔습니다. 공식 중대형 컨퍼런스도 좋지만, 커뮤니티의 소수 인원이 모이는 자리만의 재미가 있네요. 간만에 목쉬게 수다 떨다 왔습니다. 회사 소속 모든 인원이 닉스를 쓰는 회사가 있다니...
@jhhuhJi-Haeng Huh 불나방떼 학습법이라고 하니 일종의 생물학적 Bitter Lesson같네요. 과거 문명 발전에 정체가 생겼을때 그냥 애를 많이 낳아서 돌파해온 셈인가요ㅋㅋ
I really enjoyed the Ruth Asawa exhibition at SFMOMA. Some of these structures remind me a lot of minimal surfaces.
한동안 Hollo를 이용했는데 하스켈 코드 쓰러 잠깐 마음의 고향 해커즈 퍼브에 왔습니다.
welcome :: IO ()
welcome = do
putStrLn "Welcome to Hackers' Pub"
welcome@curry박준규 원글의 버그를 고치셨군요 ㅎ
welcome :: IO ()
welcome = sequence_ $ putChar <$> msg
where
msg = "Welcome to Hacker's Pub\n" <> msg흠, 단문 기능에는 이름에 걸맞게 길이 제한을 두는 게 좋으려나? 대충 500자에서 1,000자 정도로? 🤔
@hongminhee洪 民憙 (Hong Minhee) 으악... 안 돼요... 프로토콜에 없는 제약을 플랫폼이 걸면 해커들은 플랫폼을 탈출하려 듭니다.
@jhhuhJi-Haeng Huh 아 그런식으로 되는 거였군요. 다들 뻔뻔하게 명성을 추구한 사람들인줄 알았는데 반대였네요. 매우 부끄러워집니다ㅋㅋ
@bglbgl gwyng 부끄러우시라고 한 얘기는 아녜요ㅎ 아무튼 저는 앞으로 그걸 "Bgl의 역설"이라 부르기로 했습니다.
사이드 프로젝트에 LLM이 쉬운 문제는 다 해치워주는 바람에 이제 머리 아픈 문제밖에 안남아서 그래서 오히려 진도가 안나가고 있다;; 아직 아무도 이 현상에 이름을 붙이지 않았다면 미리 'bgl의 역설'이란 명칭을 선점하고 싶다.
@bglbgl gwyng ㅋㅋㅋㅋ 좋은 관찰이네요. 근데 누군가 학술 용어에 직접 자기 이름 붙이는 걸 상상해보면 "본인을 3인칭으로 칭하기" 이상으로 과하게 귀여운 행위일 거 같아요.
보통은 "Residual Complexity Reversion in Cognitive Task Automation" (Bgl, 2025)에 제시된 "Paradox of residual complexity"라는 개념이 여러 차례 인용되다가 이를 원전을 읽지도 않고 인용하는 이들이 생길 때 즈음 원래 의도에서 살짝 비틀린 의미를 갖는 용어로 "Bgl의 역설"이라는 이름이 탄생하게 되죠. Bgl은 기회가 날 때마다 그 미묘한 차이를 설명하려 하지만 이내 포기합니다.
리눅스에서 파일의 리비전을 정확하게 구할 방법이 없는거 같다. 혹시 있나요? mtime과 달리 변경될때마다 1씩 증가하는 믿을수있는 값을 원하는데, 알려진 파일시스템 중에서 이 기능을 바로 제공하는게 없어 보인다. 이런게 되면 incremental build를 정확하게 구현할수 있을텐데, 지금은 비슷한 경우에 해시 아니면 mtime 쓰는걸까.
@bglbgl gwyng 유닉스에서 파일의 내용을 바꾼다는 행위가 atomic하지 않아서 그런 것 아닐까 싶습니다. gitfs라는 게 있었던 것 같은는데 거기선 어떤 기준으로 커밋을 하는지 모르겠네요.
최근에 마주친 문제/주제들이 우연히 다들 '양방향' 이란 개념과 관련이 있다. 아래는 거기 관련된 러프/나이브한 생각들이다.
세션 타입
이건 노골적인 예시인데, 말그대로 서버/클라가 양방향으로 통신하는걸 기술하게 해준다.
Propagator
대부분의 프로그래밍 언어에서 x = 3 + 2과 같은 우변을 계산해서 좌변의 기호에 할당하는 기능을 제공한다.
그런데 3 = x + 2 라고 썼을때 x = 1을 해주는 언어는 거~의 없다. 이런 기능이 왜 필요하냐는 의문이 들 수 있지만, 이런 방식을 간접적으로 다들 매일 쓰고 있다. 예컨데 패키지 버전 관리를 생각해보자.
foo: >= 2.0.0
bar: =< 3.1.0 이런 식의 설정 파일을 만지작 거릴텐데, 사실 foo >= 2.0.0, bar =< 3.1.0, ... 같은 부등식을 기술하고 있는 셈이다. 여기서 bar가 foo를 의존성으로 가지면 문제가 좀더 복잡해진다. 패키지 매니저는 조건을 만족하는 foo, bar의 값을 알아서 계산해준다.
요지는, 구체적인 값 대신에 조건을 나열하는 방식은 이미 다들 쓰고 있다는 얘기다. 그리고 패키지 매니징이 아닌 다른 문제에서도 이 방식이 좋은 경우는 흔하지만, 조건을 풀어서 값을 구하는 부분을 짜는게 까다로워서 도입하기 쉽지 않다.
여기서 양방향과 관련된 부분은 좌변과 우변의 정보 교환이다. x = 3 + 2는 x <= 3 + 2로, 우변의 정보가 일방적으로 좌변으로 간다고 볼수 있다. 반면 3 = x + 2는 좌변의 정보가 우변으로 가야한다.
x + 1 = y - 3란 예시를 보자. 이 식만 가지고는 x, y의 값을 구할 수 없다. 하지만 x = 3이란 정보가 들어오면 y = 4란걸 알 수 있고, 반대로 y = 5란 정보가 들어오면 x = 1인걸 알 수 있다. 이런 양방향 정보교환을 기술할수 있게 해주는것이 Propagator 패턴이다. Propagator 자체도 세션 타입과 뭔가 관련이 있을거 같은데, 뭐 찾아보면 오히려 서로 관련 없는게 없으니 일단 패쓰.
프로그래밍에서의 타입
모든 프로그래밍 언어는 메타프로그래밍이 가능하고, 대부분의 프로그래밍 언어는 메타프로그래밍을 할 자격이 없다. 나는 그중에서도 특히 자격이 없는 언어인 Nix로 메타프로그래밍을 하는 상황에 쳐해있다. Nix의 특성상 나뿐 아니라 다른 많은 Nix 유저들이 자연스레 이 토끼굴에 빠진다.
Nix의 에러메시지는 읽기가 참 힘든데, 기능이 매우 부족한 언어에다가 여러 개념을 새로 구현해서 얹어놔가지고, 긴 스택트레이스 중에 내가 관심있는 부분은 끝의 일부인데 거기까지의 흐름을 따라가려면 앞의 상관없는 코드도 대충은 이해해야한다. 이게 양방향 정보 교환이 잘 안되고 있는 부분이다.
알다시피 함수 자체는 단방향 정보이다. 스택트레이스는 함수를 통한 단방향 정보의 전달 과정을 보여준다. 그리고 개발자는 그걸 반대로 뒤집은 형태를 분석해야 하는 상황에 놓인다. 이게 개발자 <=> 코드 의 양방향 정보교환의 수단이 제공되지 않아서 생기는 문제다.
개발자 <=> 코드의 양방향 정보코드의 대표적인 수단은 타입이다. 타입은 코드가 스스로를 변호하고, 개발자의 잘못된 변경으로부터 방어하도록 해준다. 대부분의 언어가 메타프로그래밍을 할 자격이 없다는 얘기가, 코드 생성이라는 개발자 -> 코드의 단방향 정보전달만 기술하고 반대로 코드 -> 개발자 방향의 정보를 모조리 잃어버리는 형태로 이루어지기 때문이다.
그런데 타입안전한 메타프로그래밍은 그자체로 어려운 문제이고 아직은 연구주제에 가깝다고 알고있다. 혹시 그냥 개발자에게 뭔가 알려줄수있는 방법 자체를 primitive로 가질 순 없나? 그게 결국 타입이랑 똑같은 것일까? 여기에 TypeScript에서의(역시!) 무근본한 트릭이 소개되어있는데, 약간 관련있을지도 모른다.
@bglbgl gwyng "타입은 코드가 스스로를 변호(하는 수단이다)" 라는 표현이 너무 좋습니다. Nix의 타이핑이 매우 약하다는 건 주지의 사실입니다만 그 실사용에 있어서 메타 프로그래밍이라고 칭할 것은 IFD 밖에 떠오르지 않습니다. 혹시 그 이외에 어떤 방식을 "meta-programming in nix"라고 부를 수 있을까요?
최근에 마주친 문제/주제들이 우연히 다들 '양방향' 이란 개념과 관련이 있다. 아래는 거기 관련된 러프/나이브한 생각들이다.
세션 타입
이건 노골적인 예시인데, 말그대로 서버/클라가 양방향으로 통신하는걸 기술하게 해준다.
Propagator
대부분의 프로그래밍 언어에서 x = 3 + 2과 같은 우변을 계산해서 좌변의 기호에 할당하는 기능을 제공한다.
그런데 3 = x + 2 라고 썼을때 x = 1을 해주는 언어는 거~의 없다. 이런 기능이 왜 필요하냐는 의문이 들 수 있지만, 이런 방식을 간접적으로 다들 매일 쓰고 있다. 예컨데 패키지 버전 관리를 생각해보자.
foo: >= 2.0.0
bar: =< 3.1.0 이런 식의 설정 파일을 만지작 거릴텐데, 사실 foo >= 2.0.0, bar =< 3.1.0, ... 같은 부등식을 기술하고 있는 셈이다. 여기서 bar가 foo를 의존성으로 가지면 문제가 좀더 복잡해진다. 패키지 매니저는 조건을 만족하는 foo, bar의 값을 알아서 계산해준다.
요지는, 구체적인 값 대신에 조건을 나열하는 방식은 이미 다들 쓰고 있다는 얘기다. 그리고 패키지 매니징이 아닌 다른 문제에서도 이 방식이 좋은 경우는 흔하지만, 조건을 풀어서 값을 구하는 부분을 짜는게 까다로워서 도입하기 쉽지 않다.
여기서 양방향과 관련된 부분은 좌변과 우변의 정보 교환이다. x = 3 + 2는 x <= 3 + 2로, 우변의 정보가 일방적으로 좌변으로 간다고 볼수 있다. 반면 3 = x + 2는 좌변의 정보가 우변으로 가야한다.
x + 1 = y - 3란 예시를 보자. 이 식만 가지고는 x, y의 값을 구할 수 없다. 하지만 x = 3이란 정보가 들어오면 y = 4란걸 알 수 있고, 반대로 y = 5란 정보가 들어오면 x = 1인걸 알 수 있다. 이런 양방향 정보교환을 기술할수 있게 해주는것이 Propagator 패턴이다. Propagator 자체도 세션 타입과 뭔가 관련이 있을거 같은데, 뭐 찾아보면 오히려 서로 관련 없는게 없으니 일단 패쓰.
프로그래밍에서의 타입
모든 프로그래밍 언어는 메타프로그래밍이 가능하고, 대부분의 프로그래밍 언어는 메타프로그래밍을 할 자격이 없다. 나는 그중에서도 특히 자격이 없는 언어인 Nix로 메타프로그래밍을 하는 상황에 쳐해있다. Nix의 특성상 나뿐 아니라 다른 많은 Nix 유저들이 자연스레 이 토끼굴에 빠진다.
Nix의 에러메시지는 읽기가 참 힘든데, 기능이 매우 부족한 언어에다가 여러 개념을 새로 구현해서 얹어놔가지고, 긴 스택트레이스 중에 내가 관심있는 부분은 끝의 일부인데 거기까지의 흐름을 따라가려면 앞의 상관없는 코드도 대충은 이해해야한다. 이게 양방향 정보 교환이 잘 안되고 있는 부분이다.
알다시피 함수 자체는 단방향 정보이다. 스택트레이스는 함수를 통한 단방향 정보의 전달 과정을 보여준다. 그리고 개발자는 그걸 반대로 뒤집은 형태를 분석해야 하는 상황에 놓인다. 이게 개발자 <=> 코드 의 양방향 정보교환의 수단이 제공되지 않아서 생기는 문제다.
개발자 <=> 코드의 양방향 정보코드의 대표적인 수단은 타입이다. 타입은 코드가 스스로를 변호하고, 개발자의 잘못된 변경으로부터 방어하도록 해준다. 대부분의 언어가 메타프로그래밍을 할 자격이 없다는 얘기가, 코드 생성이라는 개발자 -> 코드의 단방향 정보전달만 기술하고 반대로 코드 -> 개발자 방향의 정보를 모조리 잃어버리는 형태로 이루어지기 때문이다.
그런데 타입안전한 메타프로그래밍은 그자체로 어려운 문제이고 아직은 연구주제에 가깝다고 알고있다. 혹시 그냥 개발자에게 뭔가 알려줄수있는 방법 자체를 primitive로 가질 순 없나? 그게 결국 타입이랑 똑같은 것일까? 여기에 TypeScript에서의(역시!) 무근본한 트릭이 소개되어있는데, 약간 관련있을지도 모른다.
@hongminhee洪 民憙 (Hong Minhee) 놀랍지않게도?! 하스켈에도 Backpack이라는 유사한 기능이 있습니다. 근데 누가 이걸로 논문쓰고 졸업한다음 도망간게 아닌가 싶은, 관리가 잘 안되고 있는 기능입니다.
@bglbgl gwyng @hongminhee洪 民憙 (Hong Minhee) 조금 억지스러워 보이는 IsXXX 같은 타입클래스들이 가끔 (혹은 종종?) 눈에 띄는 게 사실 backpack의 보급이 덜 돼서 그런 게 아닐까하는 생각이 듭니다. 런타임 오버헤드도 없어 실행 퍼포먼스의 향상이나 예측 가능성이 좋아지는 것도 기대되구요. 물론 이게 다 안 써보고 안 당해봐서 갖는 나이브한 환상일 수 있습니다ㅎ
@arkjunJuntai Park @hongminhee洪 民憙 (Hong Minhee) 저는 인프라 작업할때 약간 전능한? 느낌도 들어서 재밌기도 한데, 트러블슈팅할때 다른 작업에 비해 유독 힘드네요
@bglbgl gwyng @hongminhee洪 民憙 (Hong Minhee) @arkjunJuntai Park "전능한 느낌"이라고 하니까 Bastard Operator From Hell이 생각나요 ㅎ
좀 다르지만 연관있을 거 같은 느낌이 오랫동안 종이와 펜으로만 일하다 보면 거대한 실험장비를 눈앞에 마주하게 됐을 때 가슴이 두근거리면서 저걸 몰아 볼 수만 있으면 얼마나 좋을까 하는 생각이 들어요. 육중한 무언가를 직접 "operation"하고 싶다는 본능적 욕망이 깊이 자리잡고 있나 봅니다.
길에서 우연히 보게 된 중장비에 마음이 뺏겨 장래희망이 덤프트럭 운전기사가 된 전국의 미취학 아동들에게 "너도? 사실은 나도.."라고 말해주고 싶어요.
‘그냥 tryAny 쓰면 예외는 다 잡을 수 있는 거 아닌가? 왜 ResourceT를 써야 하지?’라고 생각했는데 찾아보니 tryAny로는 비동기 예외를 잡을 수 없다고 한다.
writeGreetingSafeAttempt :: IO ()
writeGreetingSafeAttempt = do
dir <- getDataDir
h <- IO.openFile (dir </> "greeting.txt") WriteMode
_ <- tryAny do
IO.hPutStrLn h "hello"
IO.hPutStrLn h "world"
IO.hClose h@curry박준규 특별한 상황이 아니라면 대부분의 경우에는 bracket/finally로 충분하다고 생각합니다.
안녕하세요? Hackers' Pub에 첫 게시글을 올립니다. 간략한 소개를 위한 사이트를 만들었습니다. 잘 부탁드립니다!
@leetekwoo 포트폴리오 페이지가 인상적이네요. 환영합니다.
Ji-Haeng Huh replied to the below article:
데이터 효율성으로 본 AI와 인간의 비교
bgl gwyng @bgl@hackers.pub
이 글은 AI와 인간의 능력 비교에서 데이터 효율성의 중요성을 강조하며 시작합니다. 현재 AI는 인간에 비해 데이터 효율성이 떨어지지만, 일단 학습된 능력은 복제 가능하다는 점을 지적하며 콜센터 직원과 같은 직업군에 대한 위협은 여전하다고 설명합니다. 데이터 효율성이 중요한 경영인과 연구자는 AI를 유용한 도구로 활용할 수 있지만, 인간의 데이터 효율성이 정말 높은지에 대한 의문을 제기합니다. Yann Lecun의 주장을 인용하여 인간이 받아들이는 데이터 양이 AI 학습에 쓰이는 양보다 적지 않음을 언급하며, 인간은 데이터를 있는 그대로 학습하지 않고 편향에 기반하여 학습한다는 흥미로운 주장을 제시합니다. 마지막으로, AI에게 인간처럼 무모한 결론을 내리도록 가르치는 것이 옳은지에 대한 질문을 던지며, 압도적인 양의 데이터를 통해 더 많은 진실을 알아낼 수 있는지에 대한 고민으로 마무리합니다. 이 글은 AI 개발 방향에 대한 새로운 시각을 제시하며 독자에게 깊은 생각거리를 제공합니다.
Read more →@bglbgl gwyng 인류 지성사에 무언가 큰 브레이크스루를 내는 사람들의 공통점 중에 그런 기질적인 편향 집착이 있는 거 같아요. 뛰어난 사고 능력 자체도 역할을 했겠지만 그건 어쩌면 저런 기질적 위험성을 안고도 일정 나이 이상까지 (직업적으로나 생물학적으로) 생존할 수 있게 해서 그 결과를 세상에 내놓게 하는 보조적인 수단 아닌가 하는 생각도 듭니다. 아직 설득할 근거는 부족한데 본인은 밑도 끝도 없이 확신을 갖고 적어도 10년 이상을 밀어 부쳐야만 그 결과가 나오는 것들이 있잖아요.
그럼 이게 개체 단위에서 경쟁력있는 학습 모델인가 하면 당연히 그렇지 않다고 생각합니다. 하지만 인류 전체를 하나의 앙상블 학습 기계로 생각한다면 꽤나 괜찮게 작동하는 방식이라고 생각합니다. 이름을 붙여보자면 불나방떼 학습법 ?!
@jhhuhJi-Haeng Huh 흠 그런 문제를 생각 못했네요. lazyness를 구현하기 위해서 어차피 __getattr__ 이런거 남용해가며 마개조할 필욘 있다곤 생각했습니다.
@bglbgl gwyng 저는 자다말고 생각나서 callPackage 패턴을 쓰려면 메타클래스를 작성해야겠다고 결론내리고 잠들었습니다.
이름은 생각해보셨어요?pyx? 이건 무슨 확장자같네요. ㅎ
Nix 언어를 새로 만들지말고 그냥 Python DSL 같은걸 썼으면 어땠을까 종종 생각한다. 그 세계선에선 또 그 Python DSL 욕을 주구장창 하고 있겠지만, 적어도 생태계는 더 커지지않았을까. 남바완 Linux 배포판이 됐을 수도 있다.
@bglbgl gwyng 갑자기 궁금해졌는데.. 파이썬 런타임은 매우 많은 attribute를 갖는 오브젝트를 핸들하는데 제한이 없을까요? 예를 들면 수천-수만개?
꼿꼿한 자세에 모니터(32인치, 모니터암 사용중)를 눈높이까지 올려 보는게 대부분 추천 자세로 알고 있는데요. 이렇게 맞춰 놓으면, 항상 몸이 의자에서 흘러내려, 높은 모니터를 보려면 눈을 치켜 뜨면서 보게 되는 안 좋은 습관이 생겨 버렸습니다. 남들한테 다 좋아도, 저한테는 안좋은 건가 봅니다. 그래서, 권장되는 모니터 셋팅을 과감히 무시하고, 가장 낮춰서 썼습니다. 그랬더니, 이 번엔 아래 쪽을 볼 때 불편함이 생겼습니다. 까다롭지요.
그런데, 우연히 노트북 모니터마냥 비스듬히 눕혀 놓고 2~3주째 사용 중인데, 이 거 편합니다. 32인치에 기계식 키보드 달린 노트북 느낌 납니다.
@lionhairdino 아무리 안정적인 자세라도 오래 유지하는게 안좋다고 합니다. 스탠딩 데스크나 짐볼, 안장의자 같은 게 추천되는 이유가 한가지 자세로 지속적으로 사용하기 힘들기 때문이라네요. (근본적으로 일하는 시간 자체를 줄여야...)
예전에 공덕동 창업지원센터에서, 여행용 캐리어에 데스크탑과 일반 모니터를 모두 "캐리"해서 다니시는 분을 봤습니다. 은근, 32인치 노트북이 수요가 있을지도 모릅니다.
@lionhairdino 32인치면 무릎에 올리기엔 무거울 거라서 아마 랩탑이 아니라 "포터블 데스크탑"으로 분류될 거예요 ㅎ 예전에 잠시 오피스를 공유하던 친구가 시력이 많이 안좋았는데 (거의 실명에 가까운 수준) 그런 물건을 들고 다니더군요.
LLM이 자꾸 환각을 일으킨다? 혹시 우리 인류가 마땅히 있어야할 함수를 미리 구현해 놓지 않은 잘못은 없는지, 우리가 만든 언어들의 문법이 그 분의 큰 뜻을 담기에는 너무 편협하게 설계된 건 아니었는지 지금이라도 한번 돌이켜 보자.
Ji-Haeng Huh shared the below article:
논리와 메모리 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 2 편)
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 "논리적"이 되는 두 번째 방법인 논건 대수를 재조명하며, 특히 컴퓨터 공학적 해석에 초점을 맞춥니다. 기존 논건 대수의 한계를 극복하기 위해, 컷 규칙을 적극 활용하는 반(半)공리적 논건 대수(SAX)를 소개합니다. SAX는 추론 규칙의 절반을 공리로 대체하여, 메모리 주소와 접근자를 활용한 저수준 자료 표현과의 커리-하워드 대응을 가능하게 합니다. 글에서는 랜드(∧)와 로어(∨)를 "양의 방법", 임플리케이션(→)을 "음의 방법"으로 구분하고, 각 논리 연산에 대한 메모리 구조와 연산 방식을 상세히 설명합니다. 특히, init 규칙은 메모리 복사, cut 규칙은 메모리 할당과 초기화에 대응됨을 보여줍니다. 이러한 SAX의 컴퓨터 공학적 해석은 함수형 언어의 저수준 컴파일에 응용될 수 있으며, 논리와 컴퓨터 공학의 연결고리를 더욱 강화합니다. 프랭크 페닝 교수의 연구를 바탕으로 한 SAX는 현재도 활발히 연구 중인 체계로, ML 계열 언어 컴파일러 개발에도 기여할 수 있을 것으로 기대됩니다.
Read more →자연 연역의 E/I 룰에서는 항상 가정의 목록이 유지되거나 줄어들어 "가정의 소비(?)"된 정도를 기준으로 증명을 순차적으로 구성하거나 파악하는게 유리한 대신 전건과 후건을 다루는데 있어서 그 대칭성이 보이지 않는다. 대신 이와 동등한 논건대수에서는 추론 규칙에 전건과 후건 사이의 대칭성을 명백히 드러냄으로써 추론 시스템 자체의 특정 구조적인 성질을 이해하는데 유리할 수 있다.
- 증명을 위에서 아래로 읽으면 자연 연역의 경우 가정이 줄어들기만 하는 것이 맞습니다. 다만 프로그램적인 측면에서는 아래에서 위로 (가정이 늘어나는 방향으로) 읽는 것이 더 자연스러운데요, 이는 가정이 늘어나는 것이 프로그램에서 깊은 스코프(scope)로 들어갈 수록 더 많은 변수를 소개하는 것과 같은 개념이기 때문입니다.
- "증명을 순차적으로 구성하기 쉽다"는 사실 약간 애매하기는 합니다. 둘 다에 익숙해지면 논건 대수의 증명이 (기계적으로 찾기에) 더 쉽기 때문에요. 실제로 증명 검색 알고리즘(proof search algorithm, 어떤 판단을 증명하는 증명을 찾는 알고리즘)도 논건 대수에 기반하는 경우가 더 많습니다. 다만 이미 만들어진 증명을 "파악"(혹은 이해)하는 데에 있어서는 (프로그래머로서는) 자연 연역의 함수형 프로그램스러운 증명이 훨씬 쉽지요.
- "대칭성"과 관련한 관찰은 논건 대수의 발전에 있어서 핵심이라고 볼 수 있습니다. 뛰어난 직관을 가지고 계시네요.
@ailrunAilrun (UTC-5/-4) "뛰어난 직관"이라고 말씀해주셔서 감사합니다. (칭찬만 걸러듣는 성향 ㅎ) 근데 직관이라기 보단 원글에서 보여주신 "가정없이는 거짓을 증명하지 못한다"의 네줄짜리 증명의 배경 아이디어를 보고 떠오른 습관적인 "논리적 비약"이었던 거 같아요.
자연연역이 (인간에게 있어서) 프로그램으로 표현하기 좋은 어떤 구조적인 이유가 있지않을까 생각해보다가 제가 뭔가를 억지로 끼워 맞춘거 같네요. 논리적 사고를 더 훈련해야겠습니다. :)
@bglbgl gwyng "온 세상이 nix다"
Ji-Haeng Huh replied to the below article:
논리적이 되는 두 가지 방법 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 1 편)
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 어떤 문장이 "논리적"이라고 할 수 있는지에 대한 심도 있는 탐구를 시작합니다. 일상적인 오용을 지적하며, 진정으로 논리적인 주장은 증명 가능성과 체계의 무모순성이라는 두 가지 핵심 조건을 충족해야 한다고 주장합니다. 특히, "좋은 가정 아래" 논리성을 증명하는 두 가지 방법, 즉 함수형 언어와 유사한 구조를 가진 자연 연역과, 약간의 "부정행위"를 통해 무모순성을 쉽게 보일 수 있는 논건 대수를 소개합니다. 글에서는 명제와 판단의 개념을 명확히 정의하고, 자연 연역을 통해 논리적 증명을 구축하는 방법을 상세히 설명합니다. 특히, 자연 연역과 함수형 언어 간의 놀라운 유사성, 즉 커리-하워드 대응을 통해 논리적 사고와 프로그래밍 언어 이해 사이의 연결고리를 제시합니다. 또한, 자연 연역의 한계를 극복하고 무모순성을 보다 쉽게 증명할 수 있는 논건 대수를 소개하며, 자연 연역과의 구조적 차이점을 강조합니다. 이 글은 논리적 사고의 깊이를 더하고, 프로그래밍 언어와 논리 간의 관계에 대한 흥미로운 통찰을 제공합니다. 특히, 커리-하워드 대응을 통해 논리와 프로그래밍이 어떻게 연결되는지 이해하고 싶은 독자에게 유익할 것입니다.
Read more →@ailrunAilrun (UTC-5/-4) 정말 좋은 글 정말 감사합니다. 아직도 CS관련 글을 보다가 가로로 긴 직선만 나오면 "이거 내가 읽어도 되나?" 싶은 생각이 들면서 읽기를 포기하곤 하는데 기초적인 부분부터 너무 잘 설명해주셔서 끝까지 읽을 수 있었습니다. (사실 두번 읽었습니다.)
자연 연역의 E/I 룰에서는 항상 가정의 목록이 유지되거나 줄어들어 "가정의 소비(?)"된 정도를 기준으로 증명을 순차적으로 구성하거나 파악하는게 유리한 대신 전건과 후건을 다루는데 있어서 그 대칭성이 보이지 않는다. 대신 이와 동등한 논건대수에서는 추론 규칙에 전건과 후건 사이의 대칭성을 명백히 드러냄으로써 추론 시스템 자체의 특정 구조적인 성질을 이해하는데 유리할 수 있다.
라는 생각이 들었는데 이게 올바른 관찰일까요?
"이 내용들이 2 편에서 다룰 본격적인 논리와 자료 표현의 관계에 대해 흥미를 불러일으켰기를 바라며" -> 2편 정말 기대됩니다. ㅎ
에디터의 플러그인도 Nix로 관리하고 싶다. 에디터 쪽에서 지원을 해야하는데, 누군가 총대매고 해줄법도 한데...
@bglbgl gwyng vscode 쓰시죠? 예전 기억을 더듬어보면nix-ld만 잘 설정해서 필요하면 extension들을 ad-hoc하게 깔아서 쓰는덴 큰 문제가 없었습니다. (제 경험상 vscode-fhs는 비추합니다) 저는 그러다 한번씩 pkgs/applications/editors/vscode/extensions/update_installed_exts.sh 스크립트를 이용해서 깔려있는 extension들을 nix-expression으로 뽑아서 vscode-with-extensions로 다시 빌드하곤 했습니다.