Hacker News 의견

• 이 코드의 매크로들은 공통 연산을 압축하기 위한 것임
  나는 J Incunabulum을 먼저 읽고 나서 이 코드를 봤는데, C에 익숙한 프로그래머들이 중간부터 읽기 시작하면 초반의 매크로 정의들이 혼란을 줄 수 있음
  매크로들이 서로를 기반으로 쌓이기 때문에 코드가 빠르게 추상화의 사다리를 오름
  특히 Iterate 매크로(i)가 마음에 드는데, 장황한 루프를 한 글자로 줄여줌
  이런 밀도 높은 코드가 읽기 어려운 이유는, 수십 줄 안에 수많은 추상화를 만들고 바로 사용하는 방식 때문임
  그래서 한 글자씩 천천히 읽어야 함
  수백 개의 얇은 파일로 구성된 대규모 코드베이스에서 일해본 입장에서는, 이런 극단적인 압축성이 오히려 신선하게 느껴짐

  • 나도 Incunabulum을 읽고 비슷한 생각을 했지만, 변수 이름을 이모지로 바꿔보니 훨씬 이해가 쉬워졌음
    이모지 버전 코드 이미지를 보면 알 수 있듯, 문제의 일부는 정보 밀도뿐 아니라 문자 형태(orthography) 에 있음
    현대 언어들은 식별자에 기호나 이모지를 쓰지 못하게 하는데, 이런 시각적 구분이 가능했다면 훨씬 읽기 쉬웠을 것임
    또 대부분의 에디터가 구문별 색상(syntax highlighting)을 쓰지만, 토큰 기반 색상(각 식별자마다 고유 색상)이 더 유용할 때가 많음
    Sublime Text의 “hashed syntax highlighting”이 그 예임
    이렇게 바꾸니 코드의 구조가 한눈에 들어왔음
  • 개발자들이 오히려 거대한 코드베이스를 선호하는 것 같음
    나는 하위 디렉터리 없이 grep *.[ch]로 바로 찾을 수 있는 구조를 좋아함
    Java 프로젝트는 특히 작은 파일이 너무 많고 내용이 빈약해서 찾기가 힘듦
    IDE가 있으면 낫겠지만 나는 안 씀
    Whitney는 인터뷰에서 모든 코드를 한 페이지에 담고 싶다고 했고, 그의 “IDE”는 Windows 콘솔과 Notepad라고 함

• Arthur Whitney의 C 코드를 이해하려면 먼저 APL 계열 언어를 배워야 함
  그렇지 않으면 단순히 이상한 C 스타일로 보일 뿐임
  Whitney는 C를 APL처럼 쓰려는 것임
  공백이 없고, 한 글자 이름을 쓰며, 한 줄 함수로 구성된 스타일은 APL에서도 동일함
  Pascal 프로그래머가 #define begin { 같은 걸 쓰는 것과 비슷하지만, Whitney는 그보다 훨씬 독창적임

  • APL 사용자 입장에서도 이건 이상하게 보임
    Whitney가 만든 K 언어는 이런 스타일을 쓰지만, 한 줄 함수는 전통적인 APL에서는 불가능했음
    매크로나 삼항 연산자, 암묵적 변수명 같은 건 APL에 없음
    APL의 본질은 불변 배열 연산인데, Whitney의 C 스타일은 그 철학과는 다름
  • “Pascal 프로그래머가 C로 넘어와서 #define begin { 하는 것 같다”는 말에 대해, “아, Stephen Bourne처럼 말이지”라고 농담함
  • 처음엔 함수형 언어처럼 보였는데, 곧 C 전처리기의 공포를 떠올리게 됨
  • 이미 글의 서두에서 “Whitney의 C는 APL에서 영감을 받았다”고 설명하고 있음
    단순 요약 댓글이 많다는 지적임
  • J를 배우는 것도 괜찮을 것 같음
    APL보다 접근성이 높고, 일반 키보드로 입력 가능한 기호를 쓰기 때문임

• Shakti를 찾아보다가 Wikipedia 링크가 k.nyc로 리디렉션되는 걸 봤는데, 페이지에는 ‘k’ 한 글자만 있음
  소스를 보니 정말 <div>k</div>뿐이었음
  이건 HTML 버전의 Whitney식 미니멀리즘 같음 — 불필요한 건 모두 제거하고, 컴파일러가 암묵적으로 처리하도록 맡긴 느낌임

  • k

• 이 블로그 글은 Whitney의 코딩 스타일에 대한 평가와 상관없이 훌륭한 분석글임
  작성자가 8시간 만에 쓴 것치고는 깊이가 있고, 결론 부분이 특히 인상적이었음
  원문 링크

• Stephen Bourne이 C를 Algol처럼 만들려던 시도가 떠오름
  mac.h 예시와
  expand.c 예시를 보면 비슷한 감성이 느껴짐

• 모든 분야에는 “best practice”가 있지만, 그건 평균적인 경우에만 잘 맞음
  특정 상황에서는 오히려 반대로 가는 게 더 나을 때도 있음
  결국 집단 지혜는 기본값으로 삼되, 스스로 생각하기 시작하면 그 틈이 보이기 마련임

  • 그래서 “best practice”라는 표현이 싫음
    사실은 평균적인 수준의 절충안일 뿐임
    효율성과 성능을 희생하고 유지보수성과 일관성을 얻는 거래임
  • 좋은 제품을 만드는 것과 코드베이스의 가독성이나 학습 곡선은 별개임
    한쪽이 잘된다고 해서 다른 쪽도 자동으로 따라오는 건 아님

• 코드에 대해 공격적으로 굴지 않고 균형 잡힌 시각을 보여줘서 좋았음
  재미있게 읽었고, 나중에 다시 읽어볼 생각임

• 이런 코딩 스타일이 특정 패러다임인지 궁금했음
  실제 프로젝트에서 이런 코드를 본 적은 거의 없고, “business card ray tracer” 같은 예외만 있음
  Whitney가 만든 J 언어의 소스 코드도 비슷하게 극도로 압축된 스타일을 가짐

  • 맞음, 이건 Whitney의 고유한 코딩 스타일임
    그의 배열 언어 인터프리터들에서 일관되게 쓰이며, 몇 페이지 안에 전체 구현을 담는 것으로 유명함
    관련된 HN 논의들을 모아둔 메타 댓글 링크도 있음
  • “이런 코드를 실제로 본 적 없다”는 말에, “운이 좋았음”이라고 답함
    이건 더 이상 C가 아니라, C 위에 새로 만든 내부 DSL 같은 언어임
    C는 단지 첫 번째 컴파일 타깃일 뿐임
  • J, K 같은 APL 계열 언어와 유사함
    비ASCII 기호를 쓰고, 극단적인 밀도로 많은 정보를 한 페이지에 담을 수 있음
    익숙해지면 추상화 계층이 줄어드는 장점도 있음
  • 비슷한 접근으로 만든 co-dfns 관련 영상도 있음
    C는 아니지만 비슷하게 고밀도 스타일로 작성됨
  • 농담처럼 “이건 OCC(Obfuscated C Code)”라고 부름

• 다음 매크로 정의들을 보면

  #define _(e...) ({e;})
  #define x(a,e...) _(s x=a;e)
  #define $(a,b) if(a)b;else
  #define i(n,e) {int $n=n;int i=0;for(;i<$n;++i){e;}}
  

  이런 식으로 공통 연산을 압축하는 매크로들이지만, 너무 과감해서 “** 전쟁 범죄급 코드**”라고 농담함

  • 일부 매크로는 문법적으로도 잘못됨
    예를 들어 #define $(a,b) if(a)b;else는 괄호가 없어 버그 유발 가능성이 큼
    단순히 게으른 작성임

• 이런 매크로 사용은 좋은 예라고 생각함
  겉보기엔 무섭지만, 사실 간결한 선언형 C 스타일임
  다만 밀도가 높고, 생소한 매크로 문법 때문에 읽기 어렵게 느껴질 뿐임
  “oo”는 아마 무한대 오류 상태나 디버그용 출력일 가능성이 있음

  • 나도 이런 매크로들이 유용하다고 생각함
    DO(n, code) 같은 간단한 반복문 매크로가 있으면 좋겠음
    작은 연산 단위(예: opcode, forth word, APL 연산자)를 한 줄로 표현하면 전체 구조를 한눈에 볼 수 있음
    코드의 ‘사이 공간’ 에서 의미를 읽는 게 중요하다고 느낌
  • “좋은 매크로 사용”이라는 말에 단호히 “아니오”라고 반박함