bgl gwyng

@bgl@hackers.pub · 61 following · 63 followers

슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.

GitHub
@bglgwyng
shootee
www.shootee.io

Nix를 보며 알수있는건, 사람들이 메타프로그래밍을 하기 좋은 언어로 메타프로그래밍을 하는게 아니라, 런타임이 좋은 언어로 메타프로그래밍을 한다는 것이다.

Nix의 런타임이 좋다는건 일반적인 의미에서(성능이 빠르다거나) 좋다기보다는 '재현가능한 캐싱되는 빌드'라는 런타임이 아주 많은 동작을 커버하는데 Nix가 그걸 구현했다는 얘기다. 그러니까 사람들은 큰 프로그램을 쌓아올릴 대들보가 될만한 런타임이 있으면 거기서 부터 메타프로그래밍을 시작해버린다. Nix가 언어는 구리고(애초에 엄청 잘만들려고 한거같지도 않음) 메타프로그래밍을 잘하기위한 어떠한 장치도 없음에도 가장 아래에 위치할수있어서 그 역할이 맡겨져버린다.

그래서 유용한 런타임과 오브젝트 언어(또는 DSL)을 표현할 문법에 대한 좋은 아이디어가 있으면, 좀더 나은 메타프로그래밍을 하기위한 언어를 만들수 있을거라고 생각한다.

0

사실 알고보니 이것도, 저것도 모나드였다... 하는 예시는 많은데 Category의 예시는 뭐가 있을까? 그럼 설명이 훨씬 편해질텐데 말이다.

좀 인위적이지만 쉬운 예시를 하나 만들어보자면, 어떤 함수의 실행에 비용을 부여하는 것이다.

data Costful a b = Costful (a -> IO b) Int

f :: Costful Int String
g :: Costful String Bool

요런 정의를 생각해볼때 f . gfg의 동작은 합성하고, 비용은 +한 것이 될것이다.

instance Category where
 Costful f c1 . Costful g c2 = Costful (f . g) (c1 + c2)

요렇게 말이다. 이때 f . g의 비용은 함수를 실행하기 전에도 알수있다.

반면 그냥 f, g를 모나딕한 함수로 정의하고 f >=> g 이런식으로 합성했을땐, 함수를 실제로 실행하기 전에는 비용을 알수 없다. >=> 또는 >>=의 정의를 생각해보면 쉽게 알수 있다. Category 인스턴스는 정적인 정보를 추가로 가지고 있는 함수, 또는 함수보다 표현력이 약한데 비스무리한거(그래서 정적인 정보가 더많은) 것을 다룰때 유용하다.

0

ActivityPub은 눈팅만 하고있었는데, 슈티에 피드를 넣기로 결정하고나니 ActivityPub를 써볼 기회가 생겼다. 따로 페디버스 서버를 팔지, 아니면 다른 방법을 쓸지(있긴 한가)를 고민해봐야한다.

0

쉘스크립트처럼 oci 컨테이너들을 조합하는 언어가 있으면 좋겠다. 컨테이너는 샌드박싱된 파일시스템을 입력으로 받아 출력으로 쓰고, 그런 컨테이너들을 (| pipe operator로 stdin/stdout을 잇듯이) 조합하는 것이다. 그리고 이때 각 컨테이너가 필요로하는 입력 파일/디렉토리들에 대해 일종의 타입 체크를 해서 no such file or directory가 뜨는것을 막아줄수 있을것이다.

사실 yaml등으로 작성하는 CI/CD 설정 파일들이 비슷한 기능을 하고있는데, 이걸 좀더 멀쩡한 언어로, 로컬에서도 쓸수있으면 좋겠다.

0
0

나는 모나드를 설명하기가 어려운게 그냥 대부분의 언어에서 (HKT의 부재로) Monad를 정의를 못해서라고 생각한다. Haskell에 대한 경험이 없는 친구들한테 모나드를 설명하면 잘 알아듣는다. 근데 끝나고 그게 그럼 클래스냐 디자인 패턴이냐 이런 질문이 이어진다. 자기가 쓰고있는 언어에서 어떻게 쓸수있는지를 묻는셈인데, 여기서 '굳이 따지면 디자인패턴 같은거다' 라고하면 실망하는게 느껴졌다.

같은 이유로, Haskell 사용자에게 카테고리 이론의 유용함을 설명하고싶다면 Category 인스턴스의 활용부터 시작하는게 맞다고 생각한다.

0
0
0