@kroisse@hackers.pub · 14 following · 27 followers
나는 코딩을 하는 게 아니야. 그냥 바이브를 타고 있는 거지.
GitHubhttps://purplesyringa.moe/blog/if-i-hear-design-pattern-one-more-time-ill-go-mad/ (한국어 번역)
If I wanted to go mad thinking abstractly about trivial things, I’d study category theory.
But even Java itself, the language so terrible at fostering good architecture, it has become a joke, has had all of those feature for at least 10 years. So can we abolish “command” and “strategy” now, pretty please?
찾아보니까 lambda expression이 처음 도입된 Java 8이 2014년, 그러니까 지금으로부터 딱 11년 전에 나왔다.
https://purplesyringa.moe/blog/if-i-hear-design-pattern-one-more-time-ill-go-mad/ (한국어 번역)
If I wanted to go mad thinking abstractly about trivial things, I’d study category theory.
But even Java itself, the language so terrible at fostering good architecture, it has become a joke, has had all of those feature for at least 10 years. So can we abolish “command” and “strategy” now, pretty please?
오래 전
는 문장을 읽었고 그것에 대해 종종 생각함. 생각해 보면 정말 하는 일이 대개 그런 것에 속한다고 느낌. 어딘가에 있다는 데이터를 모으고 가공하고 정제해서 또 어딘가에 두고 그걸 누군가 가져갈 수 있게 하는 일 끊임 없이 반복함. 데이터의 형식이나 크기나 여러 속성이 다양하고 그래서 다루는 방법과 기술에도 많은 차이가 있지만 어쨌든. 요즘 종종 인용되는 타입 검사는 해결책이 아니라 증상이다(Type Checking is a Symptom, Not a Solution)에 대한 반응들을 보고 직렬화 글과 거기 인용된 인터넷은 디버깅 모드로 돌아가고 있다는 글까지 떠올랐음.
(이 글은 Hackers' Pub에서 제공하는 Markdown 문법 가이드에 익숙해지기 위한 시도로 작성함.)
LWN.net의 What every programmer should know about memory 시리즈를 훑어 보고 나서 든 생각인데, 현대적인 컴퓨터의 메모리 모델이란 건 사용성 관점에서는 놀라울 정도로 투명하게 추상화되어 있으면서 동시에 성능 관점에서는 무시무시할 정도로 새는 부분이 많은 추상화인 것 같다.
인상깊었던 부분 중 하나는, 코드를 실행해 보기 전에는 완벽한 최적화가 사실상 불가능한 메모리 접근 패턴이 드물지 않게 발생할 수 있다는 건데, 이런 부분 때문에 JIT 컴파일러가 AOT 컴파일보다 잠재적으로 더 우수한 성능을 낼 수 있다는 주장이 있었던 걸까 싶다.
이런 비직관적이고 알고리즘 수업 때 배웠던 시간복잡도를 무시하는 듯한 결과 또한 메모리 추상화와 깊이 연관되어 있더라. 학부 때야 메모리 접근 정도는 O(1)이라고 가정하지만, 현실은 그렇지 않으니......
LWN.net의 What every programmer should know about memory 시리즈를 훑어 보고 나서 든 생각인데, 현대적인 컴퓨터의 메모리 모델이란 건 사용성 관점에서는 놀라울 정도로 투명하게 추상화되어 있으면서 동시에 성능 관점에서는 무시무시할 정도로 새는 부분이 많은 추상화인 것 같다.
인상깊었던 부분 중 하나는, 코드를 실행해 보기 전에는 완벽한 최적화가 사실상 불가능한 메모리 접근 패턴이 드물지 않게 발생할 수 있다는 건데, 이런 부분 때문에 JIT 컴파일러가 AOT 컴파일보다 잠재적으로 더 우수한 성능을 낼 수 있다는 주장이 있었던 걸까 싶다.
소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...
@bglbgl gwyng 단순히 링크 용도로만 남겨두는 게 아니라 실행 흐름을 점프시키는 용도로도 활용하면 더 좋겠군요!
키워드는 jmp 아니면 goto로 하면 좋을 것 같습니다.
Git cherry-pick, git rebase 쓰면 뭔가 문제가 있다는 이상한 소리가 도는데,
음 git rebase 안 하고 지저분한채로 git send-email 하면 당신의 패치가 리젝 되기까지 5... 4... 3... 2...
지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.
커뮤니티에서 정치적인 주제를 금지하면 결국 관리자가 보기에만 정치적이지 않은, 자기 입맛에 맞는 정치적인 글만 남더라구요
의외로 잘 안 알려진 도구인데, mise가 정말 좋습니다. 다들 mise 쓰고 행복한 개발 하세요.
젊은 친구가 눈치가 빨라서 좋군 😏
notJoon @joonnot@hackers.pub
이 글은 러스트 컴파일러에 기여할 때 자주 사용하는 명령어와 작업 흐름을 소개합니다. 기본적인 빌드 명령어부터 특정 컴포넌트만 빌드하는 방법, 테스트 실행 및 `--bless`, `--force-rerun` 플래그 활용법을 설명합니다. Stage 시스템(Stage 0, 1, 2)을 구분하여 각 Stage의 역할과 사용법을 안내하고, UI 테스트 작성 규칙과 에러 주석 문법을 상세히 다룹니다. 또한, 직접 컴파일러 실행, 디버그 어설션 활성화, 백트레이스 활성화 등 디버깅 명령어와 컴파일러 버그 수정 워크플로우를 예시와 함께 제시합니다. 마지막으로, 자주 발생하는 문제와 해결법, 빌드 시간 단축 방법, 디버깅용 환경 변수 설정까지 다루어 러스트 컴파일러 개발에 실질적인 도움을 제공합니다. 이 글을 통해 러스트 컴파일러 기여자들이 효율적으로 개발하고 디버깅하는 데 필요한 지식을 얻을 수 있습니다.
Read more →C++ module에 대한 좋은 글을 발견했다. https://lucisqr.substack.com/p/why-nobody-is-using-c-modules
C++ module의 처참한 지원을 놀리기라도 하듯 https://arewemodulesyet.org/ 같은 홈페이지도 있지만, 왜 module이 더디게 발전하는지 알 수 있는 글이었다.
visionOS에서 한국어 입출력에 문제가 없는 터미널 에뮬레이터가 없어서 진지하게 하나 만들어야 하나 고민 중……
그래도 텍스트 에디터를 만드는 것보다는 난이도가 낮지 않을까?
삽을 퍼 보니 CJK 문제가 없는 터미널이 왜 어려운 문제인지 바로 이해가 됨. 쉽지 않겠는데.
visionOS에서 한국어 입출력에 문제가 없는 터미널 에뮬레이터가 없어서 진지하게 하나 만들어야 하나 고민 중……
그래도 텍스트 에디터를 만드는 것보다는 난이도가 낮지 않을까?
C++ Concepts는 마치 mypy나 Pyright 같은 정적 타입 검사기가 없던 시절의 Python 3.x와 같다. 타입 검사를 boolean predicate로 하고 자빠졌다는 점에서. 이런 걸 어쨌든 컴파일 타임에 타입 검사가 되기는 한다는 이유로 정적 타입 언어라고 불러줄 수 있는 건가?
이런 게 예정대로 2007년이나 2010년에라도 나왔으면 감지덕지하면서 썼겠지. 그런데 지금은 2025년이다.
모던 C++도 C++이다.
C++ Concepts는 마치 mypy나 Pyright 같은 정적 타입 검사기가 없던 시절의 Python 3.x와 같다. 타입 검사를 boolean predicate로 하고 자빠졌다는 점에서. 이런 걸 어쨌든 컴파일 타임에 타입 검사가 되기는 한다는 이유로 정적 타입 언어라고 불러줄 수 있는 건가?
모던 C++도 C++이다.
I made a quiz about the JS Date parser. It's very easy and you will score very high.
정말 파파괴의 언어...
I scored 11/28 on https://jsdate.wtf and all I got was this lousy text to share on social media.
제발 TC39 Temporal 주세요
제발
I scored 11/28 on https://jsdate.wtf and all I got was this lousy text to share on social media.
제발 TC39 Temporal 주세요
제발
I scored 11/28 on https://jsdate.wtf and all I got was this lousy text to share on social media.
중고 자몽차(따뜻함) @dvbeetle@hackers.pub
이 JavaScript 퀴즈는 `age` 객체와 `preferences` 객체를 사용하여 각 이름에 대한 나이를 출력하는 문제입니다. `forEach` 메서드를 통해 배열의 각 요소(이름)를 `printAge` 함수에 전달하고, 이 함수는 템플릿 리터럴을 사용하여 "name is age" 형태의 문자열을 콘솔에 출력합니다. Claude Opus, GPT 4.5, Gemini 2.5 Pro와 같은 고급 AI 모델들도 이 문제에서 오답을 냈다는 점이 흥미롭습니다. 이 코드를 통해 JavaScript의 객체 접근과 배열 메서드 사용법을 다시 한번 상기할 수 있습니다.
Read more →
@kodingwarriorJaeyeol Lee 오…
@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee 저걸 읽어 보니 진짜 문제는 Claude Code가 아니라 git worktree와 Dev Containers를 섞어서 쓰려던 저에게 있었다는 걸 깨달았습니다 😂
CLAUDE_CONFIG_DIR 환경 변수는 참고할 필요가 있겠네요. 저게 credentials 정보를 담는 폴더인지, 아니면 그냥 settings.json이 들어가는 자리인지 봐야겠습니다.
이제 La Terminal과 Emacs vterm과 Claude Code와 한국어 IME가 결부된 버그를 신나게 밟아제끼는 중
Anthropic에는 Dev Containers 쓰는 개발자만 없는 게 아니라 Emacs 쓰는 CJK 개발자도 없는 게 틀림없다
그래도 Emacs도 버전이 30쯤 되니까 설정하는 방법도 많이 현대화되긴 했네. 대부분의 설정을 use-package로 구분해서 나누고 최대한 선언적인 구성으로 만들 수 있었음.
내가 2025년에 비전 프로에서 코딩 좀 해 보겠다고 잘 쓰던 VSCode 놔두고 Emacs로 돌아와야 하나 진짜
이제 La Terminal과 Emacs vterm과 Claude Code와 한국어 IME가 결부된 버그를 신나게 밟아제끼는 중
Anthropic에는 Dev Containers 쓰는 개발자만 없는 게 아니라 Emacs 쓰는 CJK 개발자도 없는 게 틀림없다
내가 2025년에 비전 프로에서 코딩 좀 해 보겠다고 잘 쓰던 VSCode 놔두고 Emacs로 돌아와야 하나 진짜
한때 이 문제에 대한 해법으로, 텍스트로 된 소스 코드가 아닌 문법 트리를 직접 편집하는 식의 IDE를 구상한 적이 있었다. 그런데 이제 대 LLM 시대가 와서 AI도 텍스트를 주로 다루잖아. 우린 안 될 거야 아마.
Claude Code가 터미널 앱인 이유가 Anthropic 직원들이 워낙 다양한 환경에서 개발해서였다던데 그 중에 Dev Containers를 쓰는 사람은 없었나 봄.
여기에 Visual Studio Code까지 참전하면 remote tunnel에 접속은 되고 그게 윈도면 WSL까지도 접속되는데 희안하게 원격지에 있는 dev container에는 못 붙는 기묘함을 보임.
역시 코드는 추가할 때보다 삭제할 때가 더 타격감이 좋다
깨알팁: 유효한 유니코드 코드포인트 값의 범위에는 구멍이 있습니다. UTF-16을 위해 만들어진 surrogate pair 영역입니다. 이 영역의 값은 UTF-16 외에서는 의미가 없고 사용될 수 없습니다.
UTF-16이 한 트롤링으로 Byte Order Mark (U+FFFE) 라는 것도 있죠... UTF-16LE인지 UTF-16BE인지 확인하기 위해 바이트 인코딩된 문자열 맨 앞에 넣는 문자인데 (0xFE가 먼저 오면 LE) 어떤 에디터는 이걸 UTF-8 문자열에도 집어넣어서 UTF-8인지 확인하겠다고 설치고 다니는 이하생략
깨알팁: 유효한 유니코드 코드포인트 값의 범위에는 구멍이 있습니다. UTF-16을 위해 만들어진 surrogate pair 영역입니다. 이 영역의 값은 UTF-16 외에서는 의미가 없고 사용될 수 없습니다.
아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.
@hongminhee洪 民憙 (Hong Minhee) 그렇게 php의 길을 걷게 되는데
@bglbgl gwyng 저는 그렇게 알고 있습니다. 그래서 PowerShell 스크립팅을 하드하게 하는 상황이면 유용하다고는 하는데 그 외 바깥 세계로는 널리 퍼지지 않은 것 같아요.
이미 늦은 제안같지만... 터미널에 뭔가를 보여주는 방법에, 그냥 stdout에다가 출력하는 거랑, TUI 프로그램들이 사용하는 ANSI Escape Sequences가 있다. 전자는 가장 간단하고 무식한 방법이고, 후자는 무제한의 자유도를 제공하는, 그래서 그위에 TUI를 구현할수 있는 방법이다.
나는 그사이에 적당히 구조화된 출력을 할수있는 방식이 있으면 좋겠다. JS에서 console.group하듯이 말이다. 그래서 출력이 너무 길면 fold/unfold도 할수 있고? 지금 큰 코드베이스에다가 빌드돌렸다가 에러나면 무슨 맥락인지 파악하는데 한세월인데, 그런걸 잘 읽게해주는데 도움이 될것이다.
@bglbgl gwyng PowerShell이 그런 구조화된 출력을 지향하는데, 그 형식이 .NET object라는 사소한 디테일이 있기는 합니다.
@hongminhee洪 民憙 (Hong Minhee) 브랜치를 옮겨다니거나 다른 커밋을 체리픽하거나 할 때 git worktree는 저장소 하나로 취급되니까 따로 fetch를 안 해줘도 돼서 편했었는데, Dev Container를 계속 쓰려면 별 수 없이 로컬 클론 여러 벌을 쓰는 방식으로 회귀해야겠군요...
Claude Code가 터미널 앱인 이유가 Anthropic 직원들이 워낙 다양한 환경에서 개발해서였다던데 그 중에 Dev Containers를 쓰는 사람은 없었나 봄.
아 근데 Claude Code 너무 Dev Containers랑 찰떡이긴 한데
실수로 클로드가 rm -rf ~/ 날려도 괜찮고
Git worktree와 Dev Containers와 Claude Code의 대환장 조합
git worktree로 나눈 작업본 폴더에서 dev container를 연다 -> 원본 .git 폴더가 컨테이너 밖에 있어서 git이 먹통이 됨
모든 worktree들을 포함한 부모 폴더에서 dev container를 연다 -> devcontainer.json을 저장소 작업본 밖에 둬야함, 서로 다른 브랜치끼리 worktree로 나눠서 컨테이너 단위로 Claude Code를 격리하려던 의도가 무색해짐
worktree를 쓰지 말고 dev container를 같은 작업본에서 여러 번 연다 -> 작업본 폴더는 공유되니까 Claude Code끼리 서로 같은 파일을 수정하면서 카오스가 펼쳐짐
Claude Code가 터미널 앱인 이유가 Anthropic 직원들이 워낙 다양한 환경에서 개발해서였다던데 그 중에 Dev Containers를 쓰는 사람은 없었나 봄.
Git worktree와 Dev Containers와 Claude Code의 대환장 조합
git worktree로 나눈 작업본 폴더에서 dev container를 연다 -> 원본 .git 폴더가 컨테이너 밖에 있어서 git이 먹통이 됨
모든 worktree들을 포함한 부모 폴더에서 dev container를 연다 -> devcontainer.json을 저장소 작업본 밖에 둬야함, 서로 다른 브랜치끼리 worktree로 나눠서 컨테이너 단위로 Claude Code를 격리하려던 의도가 무색해짐
worktree를 쓰지 말고 dev container를 같은 작업본에서 여러 번 연다 -> 작업본 폴더는 공유되니까 Claude Code끼리 서로 같은 파일을 수정하면서 카오스가 펼쳐짐
아 C++ 모듈 쓰고 싶다!!!
사실 거짓말입니다 저는 그저 Rust crate면 충분합니다
아 C++ 모듈 쓰고 싶다!!!
팔자에 없던 C++ 시즌 2. 심지어 이번에는 녹도 슬지 않은 순수한 모오던 C++.
사실 C++보다는 CMake를 써야 한다는 점이 좀 더 고통스럽다.
팔자에 없던 C++ 시즌 2. 심지어 이번에는 녹도 슬지 않은 순수한 모오던 C++.
@bglbgl gwyng Haskell 쓰던 사람으로서 Option::unwrap() 같은 걸 쓸 거면 어째서 Option 타입을 만들어서 쓰는 걸까 싶은 생각이 들 때가 있습니다…
@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng Haskell에도 fromJust 같은 함수가 있는 것과 비슷한 이유가 아닐까 싶습니다. segfault를 내거나 다른 해로운 일이 일어나지 않는 대신 즉시 종료되어 주기는 한다는 점에서 적어도 null 포인터보다는 낫기도 하고요.
서버메이드 깐프 
