Profile img

이찬행

@2chanhaeng@hackers.pub · 69 following · 54 followers

1
0
0
0
0
0
0
0
13
1
1
2
0
0

최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~

WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.

@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.

솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.

우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.

https://github.com/lifthrasiir/wah/ 정식으로 공개했다. 현재 4800여줄. WebAssembly 1.0 거의 완전 지원, 2.0은 SIMD를 포함해 8~90% 정도 지원하는 정도까지 왔다. 하지만 아직 API 문제를 완전히 풀진 못해서 모듈 링킹이 안 되는 치명적인 문제가 있다...

8
6
1
1
0
1
0
0
3
1
0
0
2
0
2
1
4
1
6

이찬행 shared the below article:

Optique 0.5.0: Enhanced error handling and message customization

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

Optique 0.5.0 is now available, bringing enhancements to error handling, help text generation, and overall developer experience while maintaining full backward compatibility. The update introduces better code organization by refactoring the large `@optique/core/parser` module into three focused modules: `@optique/core/primitives`, `@optique/core/modifiers`, and `@optique/core/constructs`. Error handling is improved with automatic conversion of default value callback errors into parser-level errors, and the new `WithDefaultError` class allows for structured error messages. Customization of default values in help text is now possible via an optional third parameter to `withDefault()`, enabling descriptive text instead of actual values. Additionally, the release provides comprehensive error message customization across all parser types and combinators, allowing context-specific feedback. These improvements aim to make Optique more user-friendly, especially for building CLI applications that require clear error messages and helpful documentation, making this release a significant step forward for developers using Optique.

Read more →
5
1

Rock Firefinch

A small brown and reddish waxbill with a blue-gray and black bill, and black under the tail. There are a few white spots along the shoulder. Found mainly in dry, rocky habitat with grass and bushes, but also ventures into savanna and galley forest habitats during the dry season. Usually in pairs or small groups. Very similar to African Firefinch, but has a more two-toned bill, is brighter overall, and has a more reddish back in both sexes. Also similar to Black-bellied Firefinch, but has less extensive black on the belly, and males are further separated by the gray patch on top of their head. Vocalizations include soft “teew” whistles, a descending trill, “tep” notes, and “pit-pit-pit” calls.

Link: ebird.org/species/rocfir1
Photo Location: Cameroon

Picture of Rock Firefinch
1
1
1
1
2
0
0
1

이찬행 shared the below article:

[잘라먹는 프로그래밍 언어론] 타입 체계는 명제 논리와 닮아있다 (커리-하워드 대응)

RanolP @ranolp@hackers.pub

이 글은 함수 타입, 합 타입, 곱 타입과 논리 연산의 대응 관계를 탐구하며, 특히 부정(negation)을 타입 시스템에서 어떻게 표현할 수 있는지에 대해 설명합니다. "P가 아니다"는 "P이면 거짓이다"와 동치라는 점을 이용하여, 타입 이론에서 값이 없음을 거짓으로 해석하고, 이를 통해 "정수를 0으로 나눌 수 없다"는 명제를 타입으로 표현하는 방법을 제시합니다. `div_by_zero :: Int -> ⊥`와 같은 표현을 통해 타입 체계와 명제 논리 간의 커리-하워드 대응을 보여주며, 타입 시스템이 논리적 추론과 어떻게 연결되는지에 대한 통찰력을 제공합니다.

Read more →
10
6

파이썬의 진정한 초능력
------------------------------
PYCON UK 2025에서 Hynek Schlawack가 발표한 "Python의 진정한 초능력" 키노트 요약입니다.

발표자는 프레젠테이션을 시작하기 전에 자신의 경력을 간략하게 소개하며, 특히 14년간 PyCon 커뮤니티에서 활동하며 경험했던 '증오스러운 우정'에 대해 언급했습니다.

---

## Python 2에서 3으로의 전환…
------------------------------
https://news.hada.io/topic?id=23241&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
2
2

난 어릴땐 안정을 추구하는 어른은 도태된거라 생각햇거든
근데 으른일 나이가 되어보니 안정의 중요성을 알겟음
당장 내일 다음달 내년에도 먹고살수잇는지 불확실한삶
이거 서더레스장난아님
이러고는 몬산다

1

그렇습니다. 우울하지 않은 사람도 "우울할 때에는 상담하기"를 평소에 열심히 외워 둘 필요가 있습니다. 왜냐?

심리학에는 결핍의 덫(scarcity trap)이라는 개념이 있는데요. 사람은 시간이나 금전 등 어떤 자원이 결핍(scarce)되면, 심리적 압박을 받아 시야가 좁아집니다(tunnel vision). 이로 인해 올바른 결정과 실행을 못하게 됩니다. 그러면 자원의 결핍(scarcity)이 더 심해집니다.

이렇게 얘기하면 떠오르는 전형적인 예시가 있습니다. 열악한 노동 조건과 저임금에 시달리는 노동자가, 스트레스 때문에 퇴근 후 술이나 도박 등의 즉각적 쾌락에 돈과 시간과 건강을 다 탕진해 버리는 것이죠. 하지만, 높은 소득과 지위를 누리던 대기업 간부도 투신자살을 해서 충격을 주곤 합니다.

사람이 이 덫에 빠지게 되는 계기가 한두 가지가 아닙니다. 환경적 요인으로 인해 우울감이 발생하기도 하고, 반대로 우울감이 사회생활에 지장을 초래해 환경적 요인을 조성하기도 합니다. 그리고 어떤 식으로든 이 덫에 빠지면,

- 심리적 압박으로 시야가 좁아지고
- 그로 인해 어리석은 판단을 하게 되고
- 그 어리석은 판단으로 인해 더욱 궁지에 몰리고
- 심리적 압박이 더 커키고
- 더 어리석은 짓을 저지를 수가 있습니다.

이 악순환이 누적되면, 돈 많다는 사람들에게도, 똑똑하고 가방끈 길다는 사람들에게도, 얼마든지 비극이 일어나는 것입니다.

우울장애의 가장 큰 무서움이 이것입니다. 현대 사회가 개인에게 도움을 제공하는 모든 체계에는 전제가 있습니다. "개인이 적어도 이기적 동기는 잘 가지고 있을 것." 우울감이 지속되면 이 전제가 깨집니다. 스스로에게 이로운, 이기적인 판단조차 제대로 할 수 없게 됩니다.

그러니 "우울할 때에는 상담하기"를 기억합시다. 평소에 외워 두지 않으면, 우울할 때에 떠오르지 않습니다.

물론 한국은 우울장애에 대한 인지적 관점이 많이 부족한 사회입니다. 그러나 연락처 목록을 뒤져 보면 한두 명 정도는 믿고 이야기할 사람이 있을 것입니다.

주변 사람들을 못 믿겠다면, 일면식도 없는 전문가를 찾읍시다. 한국의 정신과 전문의나 상담심리사 등, 우울한 사람에게 도움을 줄 분들의 숙련도나 전문성은 뜻밖에도 전반적으로 뛰어난 편입니다. 믿고 도움을 청해 봅시다.


RE: https://gameguard.moe/notes/acyejg21pqcx00xl

1
1

이찬행 shared the below article:

NestJS로 풀어보는 SOLID 원칙

Jaeyeol Lee @kodingwarrior@hackers.pub

이 글은 NestJS를 사용하면서 마주할 수 있는 소프트웨어 설계의 복잡성을 SOLID 원칙을 통해 해결하고자 한다. SOLID 원칙은 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존 역전 원칙(DIP)으로 구성되어 있으며, NestJS의 Controller, Service, Repository 구조를 통해 SRP를 실현하고, Interceptor를 통해 OCP를, 인터페이스를 통한 LSP, Guard, Pipe 등을 통해 ISP를, DI 컨테이너를 통해 DIP를 구현하는 방법을 설명한다. 각 원칙 위반 사례와 개선 사례를 비교하여 코드의 응집도, 유지보수성, 확장성, 유연성을 높이는 방법을 제시하며, 다이어그램을 통해 각 원칙이 적용된 코드 구조를 시각적으로 보여준다. 이 글을 통해 독자는 NestJS를 사용한 개발에서 SOLID 원칙을 적용하여 더 나은 소프트웨어 설계를 할 수 있을 것이다.

Read more →
4
0

이찬행 shared the below article:

하스켈을 잘 모르는 프로그래머도 이해하기 쉬운 하스켈 코드 작성법

박준규 @curry@hackers.pub

이 글은 하스켈 코드의 가독성을 높이기 위한 실용적인 팁을 제시합니다. 저자는 하스켈 입문자들이 흔히 겪는 어려움을 해결하고, 코드를 더 쉽게 이해할 수 있도록 6가지 규칙을 제안합니다. 핵심은 달러 기호($) 사용을 자제하고, 연산자는 결합 가능한 것만 사용하며, do 표기법을 적극적으로 활용하는 것입니다. 또한, 렌즈 라이브러리 사용을 미루고, where와 let을 사용하여 코드를 구조화하며, 포인트 프리 스타일을 적절히 사용하는 것이 중요하다고 강조합니다. 이러한 규칙들을 따르면 하스켈 코드가 더욱 명확해지고, 함수형 프로그래밍에 익숙하지 않은 개발자들도 쉽게 이해할 수 있게 됩니다. 이 글은 하스켈의 진입 장벽을 낮추고, 더 많은 사람들이 이 언어를 배우고 활용할 수 있도록 돕는 데 기여합니다.

Read more →
11
13
1
0
0
0