HN에서 이걸 보게 되어 반가움 :D
서버를 잠깐 재부팅하게 되어 미안함. 지난번 같은 일이 있었을 때 배운 교훈 덕분에 DigitalOcean droplet 크기를 조정했음
멋지긴 하지만, 문자 수로 제한을 두면 멀티바이트 유니코드 문자를 이용해 ASCII 문자를 압축하는 메타게임이 생김
예를 들어 eval(unescape(escape\<<97 wide characters>>`.replace(/u../g,'')))` 같은 형태로 97개의 유니코드 문자를 194개의 ASCII로 복원하는 식임
차라리 Ford Prefect와 Mr Prosser의 대화처럼 “194자를 140자에 넣었다고 치고 그냥 보여주자”는 식의 합의가 있었으면 함
데모파티의 4096바이트 제한처럼, 실제로는 Crinkler로 12~20KB를 압축해 맞추는 것과 비슷한 논리임
Dwitter 같은 사이트를 보면 인간의 창의성에 대한 신뢰가 새로워짐
제약이 있으면 오히려 다양성이 폭발함. 시각적 착시, 짧은 문장, 예상치 못한 방향으로의 실험 등
제약은 집중을 유도하고, 실패의 비용을 낮춰 실험을 장려함
대부분의 플랫폼은 기능을 추가해 창의성을 확장하려 하지만, 오히려 복잡하게 만듦 제약이 즐거움을 만든다는 규칙을 자주 떠올림
언제 제약이 더 나은 결과를 만들었는지, 또 언제 제약이 허구처럼 느껴지는지 궁금함
트위터 초창기 시절 140바이트 코드 골프에 깊이 빠졌던 적이 있음
그 경험이 내 코드 사고방식을 완전히 바꿨음
작은 커뮤니티에서 바이트 절약 기법을 공유하며 Mandelbrot 렌더링부터 Sudoku 솔버까지 만들어봄
10년 후 내 회사 코드베이스에서 예전에 만든 UUID 구현체를 발견했을 때 정말 놀라웠음
관련 링크: YouTube 영상, Byte-saving techniques, UUID gist
오늘 처음 알게 된 사실:
js_func`string`
이게 유효한 JS 문법임. js_func가 tagged template literal로 호출됨
이제 console.log\weeee`` 같은 걸 써볼 예정임
몇몇 라이브러리는 이 문법으로 JSX 유사 문법을 빌드 과정 없이 지원함
예: htm, lit.dev
나도 최근 이 기능을 코드 내 이미지 생성기에서 사용했음
작은 SVG 데이터를 인라인 코드로 저장해 13KB짜리 샘플러를 만들었음 예시 링크
이 문법이 SQL과 GraphQL 템플릿에서 쓰이는 이유를 이제야 이해함
예:
sql`SELECT * FROM users WHERE id = ${userId}`
gql`query GetUser { user(id: ${userId}) { name email } }`
Dwitter를 좋아하지만 eval 사용은 막았으면 함
대신 더 많은 단축키를 추가했으면 좋겠음. 예를 들어 s는 Math.sign을 의미하지만, 더 확장할 수 있었음
이런 플랫폼은 먼저 존재해야 규칙을 ‘깨는’ 방법이 생김
나중에 바꾸면 고정된 목표가 사라져 매력이 줄어듦 beta.dwitter.net은 인코딩 접근성을 개선하면서도 고정 목표를 유지함
Math.sin이나 CSS 색상 인코더 같은 예외는 실용적 이유로 추가된 것임
Dwitter 2에서는 더 많은 사전 정의 문자를 포함해 사용자가 직접 확장할 수 있게 하자는 논의도 있었음
결국 중요한 건 창의성임. 규칙을 비틀더라도 그 자체가 창의적인 행위임
점수 계산 방식을 UTF-8 바이트 단위로 바꾸면 eval 문제를 근본적으로 해결할 수 있음
문자열 리터럴로 데이터 압축은 가능하겠지만, 전체 코드 압축은 줄어들 것임
dwitter.net을 오래 사용해왔는데, eval 허용에 만족함. 규칙은 규칙(혹은 규칙 없음)임
Hacker News 의견들
서버를 잠깐 재부팅하게 되어 미안함. 지난번 같은 일이 있었을 때 배운 교훈 덕분에 DigitalOcean droplet 크기를 조정했음
예를 들어
eval(unescape(escape\<<97 wide characters>>`.replace(/u../g,'')))` 같은 형태로 97개의 유니코드 문자를 194개의 ASCII로 복원하는 식임차라리 Ford Prefect와 Mr Prosser의 대화처럼 “194자를 140자에 넣었다고 치고 그냥 보여주자”는 식의 합의가 있었으면 함
데모파티의 4096바이트 제한처럼, 실제로는 Crinkler로 12~20KB를 압축해 맞추는 것과 비슷한 논리임
예전 인터뷰를 찾아봤는데 흥미로움: Medium 인터뷰
진짜 마법은 커뮤니티에 있음: Discord 커뮤니티
애니메이션 GIF
자세한 내용은 Autohotkey 포럼 글 참고
제약이 있으면 오히려 다양성이 폭발함. 시각적 착시, 짧은 문장, 예상치 못한 방향으로의 실험 등
제약은 집중을 유도하고, 실패의 비용을 낮춰 실험을 장려함
대부분의 플랫폼은 기능을 추가해 창의성을 확장하려 하지만, 오히려 복잡하게 만듦
제약이 즐거움을 만든다는 규칙을 자주 떠올림
언제 제약이 더 나은 결과를 만들었는지, 또 언제 제약이 허구처럼 느껴지는지 궁금함
그 경험이 내 코드 사고방식을 완전히 바꿨음
작은 커뮤니티에서 바이트 절약 기법을 공유하며 Mandelbrot 렌더링부터 Sudoku 솔버까지 만들어봄
10년 후 내 회사 코드베이스에서 예전에 만든 UUID 구현체를 발견했을 때 정말 놀라웠음
관련 링크: YouTube 영상, Byte-saving techniques, UUID gist
js_func가 tagged template literal로 호출됨이제
console.log\weeee`` 같은 걸 써볼 예정임예: htm, lit.dev
작은 SVG 데이터를 인라인 코드로 저장해 13KB짜리 샘플러를 만들었음
예시 링크
예:
eval사용은 막았으면 함대신 더 많은 단축키를 추가했으면 좋겠음. 예를 들어
s는Math.sign을 의미하지만, 더 확장할 수 있었음나중에 바꾸면 고정된 목표가 사라져 매력이 줄어듦
beta.dwitter.net은 인코딩 접근성을 개선하면서도 고정 목표를 유지함
Math.sin이나 CSS 색상 인코더 같은 예외는 실용적 이유로 추가된 것임
Dwitter 2에서는 더 많은 사전 정의 문자를 포함해 사용자가 직접 확장할 수 있게 하자는 논의도 있었음
결국 중요한 건 창의성임. 규칙을 비틀더라도 그 자체가 창의적인 행위임
eval문제를 근본적으로 해결할 수 있음문자열 리터럴로 데이터 압축은 가능하겠지만, 전체 코드 압축은 줄어들 것임
eval허용에 만족함. 규칙은 규칙(혹은 규칙 없음)임