Profile img

bgl gwyng

@bgl@hackers.pub · 99 following · 124 followers

GitHub
@bglgwyng
13
0
0

오늘 발견한 흥미로운 링크들: Matt 타입스크립트 선생님은 종종 Effect 에 대해 트윗하는데 주로 이펙트를 찍먹해보시고 이걸 강의로 만들까말까 만들까말까 하신다. Michael EffectTS 의 BDFL 은 종종 맷 선생의 트윗에 답글을 달아 이펙트 얘기를 풍부하게 가꿔주신다.

오늘은 이펙트의 굿파츠에 대한 얘기로 스레드가 열렸다. https://x.com/mattpocockuk/status/1936083553483157714

나도 EffectTS 도입을 하고 싶지만 여러모로 기존 바닐라JS 스펙과 다른 모양의 코드가 나와서 여러모로 망설이고 있다. (내 기준 이펙트는 실행 코드를 작성하기 보다 실행 계획을 작성하는 개념으로 접근하고 있다) 프로덕션 코드를 새로 만든다면 EffectTS 도입을 고려하고 있지만 학습 난의도가 있어 이를 위해 함께 스터디하고 코드 마이그레이션 계획도 세워야하는데, 그럴 여유는 보통 없는게 현실.

아직은 neverthrow 부터 사용해보는 정도가 지금의 최선이라고 생각한다. 나는 throw 기반의 조건 제어 코드가 불편하다. try catch 안에서 if 절로 throw 하는 코드를 볼 때마다 불만이다. 복구할 수 있는 에러는 throw 하지 않는게 옳다고 생각한다. 물론 언어의 문제도 있지만... 그렇게 스레드를 읽던 중 effectively 라는 애매한 이름의 Alegbraic effects 를 구현한 라이브러리가 공개되어 있다는 것을 발견했다. 작성자 본인도 뻔뻔하게 홍보한다고 어필하고 있다. ;) effectively

EffectTS 라는 이름도 애매하지만 Effectively 는 더 애매하다. 인기가 많아지기 전에 그럴듯 한 이름으로 브랜딩되면 좋겠다. 아, 그렇게 생각하는 이유는 TS 씬에 이런 라이브러리/프레임워크가 자주 거론되면 좋겠다는 생각 때문이다.

얘기하고 싶은 것은, 아이러니하게 이 effectively 의 readme 가 매우 간결하고 읽기 쉽게 EffectTS 에 대해 소개하고 있기 때문이다. effect.website 의 문서는 뭔가 개선이 필요하다. 없는게 없이 다 있지만 실제 읽다보면 어려운 부분이 많고 더 많은 설명이나 예제가 필요한 경우가 생긴다. 미카엘 본인도 문서 개선 필요는 공감하는 것 같다. (해당 스레드 발언 추정) 그리고 또 다른 유저가 포스트를 안내해주셨는데, Effect-like code without Effect 짧게 읽기 좋다. 게다가 이 포스트가 담긴 사이트의 프로덕트도 유용해 보인다.

시작부터 Result 나 Optional 을 제공하는 언어가 많은 소프트웨어 엔지니어들에게 높은 선호도를 가지는 이유가 있다고 본다.

5

@bglbgl gwyng 역시 아무래도 1이 제일 큰 것 같고, 3의 경우엔 제가 tree-sitter를 쓰기보다는 parser-combinator로 하나하나 짜다 보니 생각을 못했네요. 2도 있으면 매우 편리하지만 critical하지는 않다는 점 동의합니다. TS에서 HKT를 지원...했었나요? 스테로이드라고 한다면 fp-ts 같은 라이브러리를 말하는 걸까요?

2

타스나 러스트로도 구현을 해보긴 했는데 영... 러스트로 구현하는 사람들도 많은 걸 봐서 러스트는 skill-issue일 확률이 있지만, 타스는 미묘하게 아쉬운 부분이 계속 있는데 그건 아마 static typing이 아니라서일거야

@d01c2Hyunjoon Kim 1. ADT 지원 여부 2. HKT 지원 여부 3. (장난감 언어 개발이 아닌 툴링도 제대로 다 만드는 시도에서) tree-sitter 바인딩 유무

1 >> 3 >> 2 정도로 중요한거 같네요. 러스트는 1, 3이 있어서 부럽고 하스켈엔 3이 없어서 제가 야크셰이빙하는 중입니다. 타스에 스테로이드 먹이면 1, 2, 3 다 되지 않나요?

1

내가 Git 쓰다가 왕대빵 커밋 똥히스토리 남기는 전형적인 패턴이다.

  1. 간단한 기능 A를 추가하려고 한다.
  2. A를 추가하려면 기존의 설계 B를 고쳐야한단걸 깨닫는다.
  3. B를 고친다.
  4. A를 추가한다.

이렇게 3, 4의 변경이 한데 들어가 있는 무근본 커밋이 탄생한다. 2 -> 3 사이에 stash를 하면 간단히 해결되는 문젠데 매번 까먹고 실천을 못한다.

5

Nginx의 njs에 QuickJS 엔진 추가되니 기능이나 문법 제약도 거의 없어서 출근해서 해볼 성능 테스트만 제대로 되면 좀 복잡한 로직 필요한 리버스 프록시는 이걸로만 짤거같음. JS모듈들 대충 번들로 만들고 import해서 다 쓸수 있어서...

6
4
1
3
2

오늘은 projects.org 파일에서 내 노트 중 프로젝트를 찾아 리스트로 띄워주도록 스크립트를 짰다. org agenda도 좋던데 기능이 풍부해서 익히기 어려워서, 내가 신경쓰고 싶은 기능만 작게 만들었다.

org는 주피터 노트북이나 엘릭서 라이브북처럼 실행 스크립트를 파일 내에 넣어버릴 수 있고, 접어서 깔끔하게 결과만 볼 수 있어서 좋다.

projects.org 파일의 모습. SRC 블록은 접혀있고, 진행중, 완료, 폐기된 프로젝트들이 리스트업되어있다.SRC BLOCK을 펼친 모습. 프로젝트 목록을 뽑아내기 위한 Elisp 스크립트가 담겨있다.
3
0
2
2
1
0
0

두달내내 발표자료를 깎지 않을까.. 싶네요.. 파이콘(세션 발표, 커뮤니티 소개 발표) / 우부콘(세션 2개) / 모각작모임 라이트닝 토크. 요렇게 5개를 준비하게 생겼습니다.

전반적으로 내용은 얼추 완성이 되긴 했는데, 피그마로 만들었던 자료를 구글 슬라이드 기반의 템플릿으로 하나하나 다 옮겨야 함...

그리고 Claude Code로 실험을 좀 많이 하게 될 것 같아요

6

Zed는 아직 쓰지도 않는데도 요즘 보기드문 장인정신이 느껴지는 소프트웨어라 호감이 간다. 지금 쓰고있는 Windsurf는 VS Code 포크떠서 AI 채팅만 추가했는데 하루에 3번 터져서 에디터를 재시작해야한다(AI 채팅 패널이 터지는거라 VS Code가 아닌 Windsurf 문제로 보임). 5조 투자받은건 어따썼니??

5

4년만에 하는 웹개발... 난 그저 간단한 퀴즈 푸는 사이트를 만들려고 했던것 뿐인데... 살면서 boilerplate만 한 10번쯤 만드는것 같음. 만들어두면 또 한동안 웹개발 할 일 없어서 방치되고, 그 사이에 온갖 라이브러리가 사라지면서 못쓰는 코드가 되어버림. 프레임워크들도 엄청나게 많이 바뀌어있고.

이번에 작업한거: 4년전에 만들어둔 boilerplate인데 좀 최신화를 했습니다. Django + Vue 조합. 기능이라고는 겨우 로그인해서 'Home' 문구 하나 볼 수 있는 웹페이지인데 어쩌다가 이렇게까지 복잡해졌을까요...

https://github.com/theeluwin/pocket-galaxy

7
2

지금 GraphQL Client로 Altair를 쓰고있는데, 요즘 이런 류의 API 테스트 툴에 살짝 회의가 든다. 쓰다보면 일찌감치 스크립팅을 하고싶어지고 그건 그냥 JS로짜면 된다. API 테스트 환경도 그냥 개발 환경과 같이 관리하면 되서 오히려 더 편하다. Postman은 조금밖에 안써봐서 모르겠다.

1
16
6
4
0
11

펑터를 지하철 노선으로 설명해도 좋을거 같다. 서울의 지하철 노선도를 외우고 있는거랑 서울의 지리에 대해 빠삭한 거랑은 거리가 멀다. 그리고 지하철만으로 서울의 모든 곳을 구석구석 돌아다닐수 없다. 중간에 내려서 걷거나 버스를 타야 한다. 하지만 효율적인 경로를 찾는데 큰 도움이 된다는 사실은 부정할수 없다.

F : 지하철 노선도 -> 서울에서 F는 지하철 노선도를 참고해 현실에서 실제로 지하철을 타는 행위가 된다. 우리는 서울의 지하를 돌아다니고 싶어서 지하철을 타는게 아니다. 서울을 돌아다니고 싶은데 여기에 지하철의 도움을 빌리는거다.

프로그래밍도 어떤 경로를 찾는것으로 이해할 수 있다. f : a -> b란 함수를 구현하는 것은 a에서 출발해서 b에 도착하는 길을 찾는 것이다(도착만 한다고 장땡이 아니란 점에서(=타입만 맞는 쓸모없는 함수를 구현하기) 위에서 든 지하철 비유랑 갈라지기 시작한다).그런데 함수(경로)는 무수히 많고 그중에 내가 원하는걸 하나 찾아내는건 어려운 일이다. 이때 좀더 단순한 이해하기 쉬운 지도와(다른 카테고리), 그 지도를 따라서 움직이는 방법(펑터)를 알고있으면 도움이 된다. 펑터 F : C -> DD라는 넓은 영토를 돌아다닐때 C라는 지도의 도움을 받는 방법으로 볼수있다.

1

제텔카스텐이니 세컨드브레인이니 하지만, 정작 우리나라에서 만든 창의적 방법론에는 무관심한 듯.

우리나라에서 제텔카스텐 기법을 극대화하신 분은 다산 정약용 선생 아닐까? 여유당 전서, 흠흠신서, 목민심서, 경세유표 등등 엄청난 저술 활동을 해낸 분. 여유당 전서는 500권이 넘는다. 제텔카스텐을 창안(?)한 루만도 고작(?!!!) 300편의 논문만 썼다.

예전 다산 선생을 다룬 책에서 제텔카스텐 기법을 본 적이 있는데...

4
3
1
0
0

한 2년전부터 XState 대충 알고 쓰면서 느끼는 점들.

  1. 처음부터 정의가 verbose하고 그걸 작성하는게 수고로운건 알고있었다. 하지만 LLM을 믿고 쓰기로 결정했는데, 지금 2025년에도 여전히 LLM이 상태머신 설계를 잘 못한다. 얘한테 설계를 맡겨놓으면 뭐랄까, 성의가 없다고까지 느껴진다. 왜 그런거지?

  2. Snapshot은 subscribe할 수 있다. 근데 그 Snapshot을 유발한 Transition이 같이 전달이 안된다. 사실 이게 필요했던 핵심 기능이었어서 이게 안된다는걸 알고 매우 당황했다. Transition에 반응하는건 오로지 상태머신 내에 설계된 action을 통해서만 가능하고, 상태머신을 구독하는 쪽에서는 안된다. 왜 이렇지?

  3. 상태머신을 확장하는 방식이 제한적이다. 이미 정의해놓은 action, actor들을 다른걸로 override하는 방식을 제공하는데, 상속 비스무리하다는 점에서 한계가 느껴진다. 실제로 사용하면서도 그 한계를 느꼈다.

종합하면 아직까진 수지타산이 안 맞다.

3
3
3
6

요즘 '이건 잘못된 코드지만 당분간 고칠일이 없기를 기도하자'고 하며 넘어간 코드들에서 나온 버그들을 계속 고치는 중이다.

과거의 나의 정확한 안목에 뿌듯해하며 동시에 피눈물을 흘리고 있다.

8

이뿐만이 아니다. 예스24는 낙후된 시스템을 운용하는 것으로 전해진다. 단적인 예로 사이트 개발에 '닷넷 프레임워크'를 사용하고 있다. 닷넷 프레임워크는 현재는 잘 사용하지 않는 개발 언어로 윈도 서버에서만 운영 가능하기 때문에 개발자의 외면을 받고 있다.

닷넷 프레임워크는

  • 현재는 잘 사용하지 않는 -> 아님¹
  • 개발 언어로 -> 아님²
  • 윈도 서버에서만 운영 가능하기 때문에 -> 아님³
  • 개발자의 외면을 받고 있다 -> 일단 점유율은 아님¹

예를 확인 없이 내세운 기사네요 🙃

@nyeongAn Nyeong (安寧) .NET이랑 .NET Framework가 서로 다른 물건이예요. .NET은 .NET Core가 리브랜딩된 거고, 10년 전에 .NET Framework를 대체했습니다. .NET Framework는 Windows에서만 돌아가는 것도 사실이고요. .NET Core, 즉 현재의 .NET은 .NET Framework와 브랜드 측면에서는 연속성이 있지만, 기술적으로는 아예 새로 만들어진 구현입니다. 오픈 소스라는 점도 다르고요. 전반적으로 .NET Framework는 레거시 기술이 맞아요.

4

Biome v2—codename: Biotype is here! The first type-aware linter that doesn't require tsc

🔐 Type-aware lint rules
🧑‍🚒 Plugins
📚 Monorepo support
📝 Revamped, configurable import sorting
🧐 Linter domains
🙅‍♀️ Bulk suppressions
👩‍✈️ Analyzer assist

1
1
0

데이터에 대한 modality, 가령 동기/비동기, 더 나아가 캐시됨, 캐시되었지만 stale됨 등에 대해 일반적인(polymorphic) 함수를 만드려면 HKT가 필요하다. Relay와 같은 현존하는 JS 상태관리 라이브러리들은 저런 modality를 한번에 다 지원하는 대신, 확장에 열려있지 않는 구조로 되어있다. 타입을 제대로 지원못한다고 해서 구현을 못하는건 아닐테니, HKT 없음이 주된 이유는 아니겠지만 말이다.

2

최근 TS 코딩중에 async/sync에 대해 polymorphic한 인터페이스를 제공하려하다보니 HKT의 필요성을 느끼게 되었다. 해결책은 그냥 synchronous만 제공하기로;;

2

그리고 하스켈 클라이언트 예제 코드에 해커즈 퍼브 주소를 은근히 적어 넣었다!(깨알 광고)

{-# LANGUAGE OverloadedStrings #-}

module Main where

import Data.Default
import Web.Finger.Client

query :: Query
query = def { qryTarget = resource }
  where
    resource = ResAccount (Account "curry" "hackers.pub")

main :: IO ()
main = do
  manager <- newManager
  result <- webfinger manager query
  print result
10
5
4