Common Lisp이 LLM 시대 최고라는 글에 해커뉴스 반응: 디버거 재개는 C#도 되고, 매크로는 토큰만 늘린다

글 쓴 사람인데 편하게 물어봐도 됨.

대부분 언어는 에러 나면 프로그램이 죽는데 Common Lisp은 안 죽고 스택이랑 변수 다 보이는 디버거가 뜸. LLM한테 디버거를 가리키면 고치고 이어서 실행함. 근데 웹서버 같은 데서도 항상 이어서 실행이 되나?

Clojure로 비슷한 생각 해봤는데 두 가지 궁금함. LLM 시대에 매크로 잘 써먹고 있나? 그리고 이미지 기반 개발에서 모델이 상태 헷갈려 하진 않나? sed로 파일 고치는 건 좀 멍청해 보이긴 함.

코드 생성 비용이 0에 가까워지면 같은 스펙을 여러 언어로 동시에 구현해서 서로 교차 검증하는 n중화 시스템으로 갈 거라고 봄. 다수결 게이트를 두면 구현 버그나 JVM 결함까지 잡히고, 쿼럼 차면 바로 답을 돌려줌.

Smalltalk이나 Erlang으로도 되지 않나? LLM 있으면 DSL 안 만들어도 일은 되는데 매크로가 뭘 해줌?

LLM이 일하는 데 DSL이 필요 없다는 건 맞는데, DSL에는 만든 사람의 취향이 담긴다는 게 포인트임.

CL에서 DSL 만들면 토큰이 준다는 건 데이터가 있어야 하는 주장 아님? LLM에 새 DSL 매뉴얼도 넣어야 하니 오히려 토큰이 더 들 수도 있음.

Smalltalk은 이미지 기반이라 되고, Erlang은 크래시 내고 다시 시도하는 쪽이라 결이 다름.

웹 앱을 LLM으로 만든다 치면 웹 프레임워크가 vanilla 언어보다 토큰 적게 들고, 그게 어셈블리보다 적게 드는 것과 같은 이치임.

에이전트가 코드를 내가 읽는 속도보다 빨리 뽑아내서 내가 병목임. 매크로를 잘 짜면 오히려 읽기 쉬워지고, 오래된 프로젝트에 돌아왔을 때 에이전트가 매크로 읽는 걸 도와줌.

사람이 읽어야 하니까 코드가 길면 그만큼 읽는 시간이 늘어남. 짧은 게 좋음.

라이브러리 지원이 약해서 내가 유지보수할 코드가 늘어나는 게 문제임.

코드 생성이 싸지고 좋아지면 필요한 라이브러리를 포팅하면 되지 않나.

C# + Visual Studio 써본 적 없는 사람 같음. JavaScript도 됨. 솔직히 JS가 개발 도구는 제일 좋음.

그건 디버그 빌드일 때 얘기고, Common Lisp은 프로덕션에서도 된다는 뜻 아닌가.

예외가 스택을 unwind하지 않는다는 얘기임. 못 잡은 예외라도 그 줄이나 값을 고치고 스택 자리에서 재개할 수 있음.

dependently typed 언어에 제대로 된 매크로 시스템 있었으면 함. LLM 맥락에선 간결함이 사람 맥락보다 더 중요함.

LLM이 Lisp 매크로를 잘 쓴 게 놀라움. backquote-comma 계산 같은 짜증나는 부분을 척척 뽑아줌. 매크로 발상은 내가 하고 구현은 버튼 하나로 맡기는 분업이 됨. 이게 진화의 막다른 길인지는 모르겠음.

Lean 보면 됨. 내가 제일 좋아하는 lisp인데 lisp은 아님. 명령, 매크로, 문법을 다 뜯어고칠 수 있음.

Lean이 SotA 메타프로그래밍 시스템을 가진 dependently typed 언어고, Lean 자체가 그 시스템으로 쓰임.