12月 6日 서울에서 開催되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題)라는 主題로 發表를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型 프로그래밍에 關心 있으신 분들의 많은 參與 바랍니다!
lionhairdino
@lionhairdino@hackers.pub · 73 following · 80 followers
여행 기분내며, 여기 저기 낙서하는 https://yearit.com 을 운영 중입니다.
지금까지 다루어 봤던 언어는 아래와 같습니다. MSX Basic Z80 Assembly Pascal GW-Basic C Macromedia Director Visual Basic PHP Flash Actionscript C++ Javascript
그리고 지금은, 하스켈을 비즈니스에 쓰려고 몇 년간 노력하고 있습니다. 지금 상태는, 하스켈 자체를 연구하는 게 아니라, 하스켈 (혹은 함수형 언어) 이해가 어려운 이유를 연구하는 아마추어 연구가쯤 되어버렸습니다. 하스켈 주제로 블로그를 운영 중이지만, 아직은 하스켈 프로그래머라고 자신 있게 말하진 못하고 있습니다. 가끔 이해에 도움이 될만한 측면이 보이면, 가볍게 아이디어를 여러 SNS에 올려보곤 하는데, 그다지 프로그래머에게 쓸모 있는 내용이 포함되진 않는 것 같습니다.
Blog- lionhairdino.github.io
- YearIt
- yearit.com
생태계에서 툴들이 저마다 파싱하고, 환경 잡고 그러던 게, 이제 한 곳에서 지원할 수 있게 됐다... 라고 보면 되는 건가요? (원래 그렇게 하고 있는 줄 알았습니다.) 
@ailrunAilrun (UTC-5/-4)
@lionhairdino 원래는 --with-compiler라고 ghc를 대체하는 녀석을 써야해서 ghc를 흉내내야했는데 이젠 ghci만 흉내내면 된다... 가 된 거지요.
lionhairdino shared the below article:
하스켈을 잘 모르는 프로그래머도 이해하기 쉬운 하스켈 코드 작성법
박준규 @curry@hackers.pub
이 글은 하스켈 코드의 가독성을 높이기 위한 실용적인 팁을 제시합니다. 저자는 하스켈 입문자들이 흔히 겪는 어려움을 해결하고, 코드를 더 쉽게 이해할 수 있도록 6가지 규칙을 제안합니다. 핵심은 달러 기호($) 사용을 자제하고, 연산자는 결합 가능한 것만 사용하며, do 표기법을 적극적으로 활용하는 것입니다. 또한, 렌즈 라이브러리 사용을 미루고, where와 let을 사용하여 코드를 구조화하며, 포인트 프리 스타일을 적절히 사용하는 것이 중요하다고 강조합니다. 이러한 규칙들을 따르면 하스켈 코드가 더욱 명확해지고, 함수형 프로그래밍에 익숙하지 않은 개발자들도 쉽게 이해할 수 있게 됩니다. 이 글은 하스켈의 진입 장벽을 낮추고, 더 많은 사람들이 이 언어를 배우고 활용할 수 있도록 돕는 데 기여합니다.
Read more →Ailrun (UTC-5/-4) replied to the below article:
공허한 참
박준규 @curry@hackers.pub
하스켈의 `all` 함수에 빈 리스트를 넣었을 때 왜 `True`가 반환되는지에 대한 의문을 "공허한 참(Vacuous truth)"이라는 개념을 통해 탐구합니다. 흔히 '구현이 그렇게 되어 있으니까'라고 생각할 수 있지만, 저자는 이 현상을 논리적으로 분석합니다. `all` 함수의 구현 방식과, 빈 리스트에 대한 연산 결과가 전체 결과에 미치는 영향을 설명하며, 공집합의 모든 원소가 짝수라는 명제가 참인 이유와 유사한 논리적 근거를 제시합니다. 이를 통해 코드와 수학 간의 연결고리를 발견하고, 마지막으로 ChatGPT가 생성한 유머러스한 이미지를 곁들여 독자에게 즐거움을 선사합니다.
Read more →@curry박준규 all을 다음과 같이 정의하면 문제가 무엇일까요?
all p [] = False
all p [x] = p x
all p (x:xs) = p x && all xs이 질문에 대한 대답 중 all의 의미에 관한 것이 있을 겁니다. 논리적으로 "모든 ...에 대해"를 어떻게 이해해야 하는냐에 대한 것 말이지요.
공집합을 직접 사용하는 것이 가장 간단한 예시겠지만, 좀 더 논리학에서 자주 사용되는 예시로는 "20세기의 모든 프랑스 왕은 대머리다"가 있겠습니다. 이는 무의미하게 (Vacuously) 참인데요, 왜냐면 19세기를 마지막으로 프랑스에는 더 이상 왕이 없기 때문이지요. 즉, 일반적으로 "모든 ...에 대해"에서 "..." 부분이 (결과적으로) 공집합일 경우 "모든 ..."에 의해 수식된 본문이 어떤 문장인지와는 상관 없이 참이라고 이해한다는 것이지요.
이미 지원할 곳들을 조금 선정하긴 했지만, 여전히 프론트엔드 개발자로 일할 수 있는 곳들을 찾고 있습니다. 기존에 고장나있었던 cv를 조금 고쳐놨습니다 (원래 read cv 산이었던 것을 백업받아 홈페이지에 합체...)
Hackers' Public @ Seoul 1회차 모임 (1차 모집)
서울에서 열리는 Hackers' Pub 오프라인 밋업, "Hackers' Public @ Seoul"이 2025월 9월 14일(일) 처음으로 개최됩니다. 처음 열리는 밋업인 만큼, 참여하는 많은 분들이 재밌게 느낄 수 있는 소재 위주로 연사자 분들을 섭외했습니다.
- 일시 : 9월 14일 (일) 오후 3시 ~ 오후 6시
- 장소 : 서울특별시 성동구 상원길 26, 튜링의사과
- 주제
강연이 끝나고 난 뒤에 자유롭게 네트워킹하는 시간을 가질 예정입니다. 각자 얘기하고 싶은 주제를 들고 오시면 좋습니다.
참여 신청
오프라인 밋업은 여기서 참여신청이 가능합니다. https://event-us.kr/hackerspubseoul/event/110961
- 모집 기간
- 1차 모집 : 8월 27일 ~ 9월 1일 (Hackers' Pub에서만 모집)
- 2차 모집 : 9월 3일 ~ 9월 7일 (Hackers' Pub 외부에서도 공개적으로 모집)
주의사항
- 본 행사는 Hackers' Pub에서 진행하는 오프라인 행사이며, Hackers' Pub 계정을 가지지 않은 분이 신청하셨을 경우 환불처리될 수 있습니다.
- Hackers' Pub 외부에서 유입하시는 경우, 각 모집기간이 끝나고 24시간 안에는 Hackers' Pub에 가입이 되어 있으셔야 참여자로 확정됩니다.
오랫동안 getpocket.com 을 사용해 왔는데 몇 달 전 서비스 셧다운을 했네요. 일단 csv로 그간 모아 놓은 링크들은 다운받을 수 있는 거 같은데 어디로 옮겨 탈지 결정을 못내려서 그냥 불편하게 지내고 있습니다. 혹시 좋은 대안 서비스 추천해주실 분 있으실까요?
lionhairdino shared the below article:
파서 콤비네이터: 하스켈 초보자를 위한 파싱
박준규 @curry@hackers.pub
이 글은 하스켈 초보자를 위한 파서 컴비네이터에 대한 입문 튜토리얼입니다. 파싱은 프로그래밍에서 흔히 발생하는 작업이지만, 정규 표현식이나 문자열 조작만으로는 복잡한 형식을 다루기 어렵습니다. 저자는 `Text.ParserCombinators.ReadP` 라이브러리를 사용하여 파서 컴비네이터를 소개하고, 이를 통해 더 읽기 쉽고 유지보수가 용이한 파서를 작성할 수 있음을 보여줍니다. METAR 보고서 파싱 예제를 통해 `satisfy`, `many1`, `<|>`, `option` 등의 기본적인 파서 콤비네이터 함수를 설명하고, 펑터와 모나드의 개념을 활용하여 파서를 구성하는 방법을 안내합니다. 또한, 파싱된 데이터의 유효성을 검사하고, 결과를 더 의미 있는 데이터 타입으로 변환하는 방법을 제시합니다. 이 튜토리얼을 통해 독자는 파서 컴비네이터의 기본 원리를 이해하고, 실제 데이터 파싱 작업에 적용할 수 있는 능력을 얻게 됩니다. 마지막으로, 저자는 독자들에게 배운 내용을 바탕으로 전체 METAR 보고서를 파싱하는 라이브러리를 만들어 Hackage에 제출해 볼 것을 권장하며, 파서가 없는 데이터를 만났을 때 `ReadP`를 자신 있게 사용할 수 있기를 바랍니다.
Read more →
튜사에서 해커스펍 방문판매를 하는 광기의 현장
lionhairdino shared the below article:
내가 지금 바이브코딩을 하고 싶어도 못하는 상황이라 답답한데
bgl gwyng @bgl@hackers.pub
이 글은 앱 개발 과정에서 프론트엔드, 백엔드, 그리고 라이브러리 개발에 AI를 활용하는 경험과 고민을 담고 있습니다. 특히, 간단한 CRUD 작업은 이미 자동화가 가능하지만, 복잡한 mutation 개발에는 테스트 환경 구축이 선행되어야 AI의 도움을 효과적으로 받을 수 있음을 강조합니다. 또한, 라이브러리 개발 자동화의 잠재적 위험성을 지적하며, 이는 코드의 '축적'이라는 특성상 현재 AI 수준으로는 어렵다고 분석합니다. 궁극적으로, 코드 에이전트 사업의 미래와 협업을 통한 코드 축적의 중요성을 역설하며, Gen AI를 넘어선 Zen AI의 필요성을 제기합니다. 이 글은 AI 개발 도구의 현황과 한계를 현실적으로 진단하고, 미래 개발 환경에 대한 깊이 있는 통찰을 제공합니다.
Read more →lionhairdino shared the below article:
How to pass the invisible
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
This post explores the enduring challenge in software programming of how to pass invisible contextual information, such as loggers or request contexts, through applications without cumbersome explicit parameter passing. It examines various approaches throughout history, including dynamic scoping, aspect-oriented programming (AOP), context variables, monads, and effect systems. Each method offers a unique solution, from the simplicity of dynamic scoping in early Lisp to the modularity of AOP and the type-safe encoding of effects in modern functional programming. The post highlights the trade-offs of each approach, such as the unpredictability of dynamic scoping or the complexity of monad transformers. It also touches on how context variables are used in modern asynchronous and parallel programming, as well as in UI frameworks like React. The author concludes by noting that the art of passing the invisible is an eternal theme in software programming, and this post provides valuable insights into the evolution and future directions of this critical aspect of software architecture.
Read more →
같은 얘기 한 적 있는데, 유전자 발현(expression)을 계산(evaluation)하거나 평가(evaluation)하지 않듯이, 표현(expression)을 평가(evaluation)는 해도 계산(evaluation) 또는 (표현의) "값을 구한다(evaluate)"고 하지 않듯이, 식(expression)도 평가(evaluation)하지 않고, '값을 구한다(evaluate)'거나 계산(evaluation)했으면 좋겠다고 생각해 봅니다.
⚠️긴급⚠️ 정신건강 위기를 겪고 있는 잇창명을 도와주세요. (구체적인 자살 언급 있음 주의) eatchangmyeong.notion.site/1f7f07f5faae...
⚠️긴급⚠️ 정신건강 위기를 겪고 있는 잇창명을 도와주...
안녕하세요, 업으로 프로그래밍을 하고 있는 컴퓨터 학부생 김무훈입니다.
현재 3년차 웹 프론트엔드 개발자로서, 다가오는 7월부터 함께할 정규직 포지션을 적극적으로 찾고 있습니다.
최근 학과 사무실에서 졸업 요건을 확인한 결과, 전공 필수 한 과목과 전공 선택 2학점(총 5학점)이 남아있음을 확인했습니다.
본래는 다음 2학기까지 수료 후 내년 2월에 졸업할 예정이었으나, 교수진과 상의한 결과 취업 및 재직이 확정된다면 수업 이수 방식을 보다 유연하게 결정할 수 있다는 긍정적인 답변을 받아 적극적으로 조기 취업을 추진하게 되었습니다.
이는 전공 필수 과목의 경우에만 해당이 되는 문제이고, 전공 선택 2학점의 경우 앞으로의 여름 학기 현장 실습 또는 다음 학기에 개설되는 하나의 원격 강의로 대체하여 문제가 없는 상태입니다.
지금까지의 업무 경험과 프로젝트는 아래의 포트폴리오에서 확인하실 수 있습니다.
📌 경력기술서 겸 포트폴리오 페이지: https://www.frontend.moe/portfolio/
좋은 인연을 찾을 수 있도록, 많은 관심과 연락 부탁드립니다!
뉴럴넷을 설계할수 있는 GUI를 프로토타이핑 해야하는데 좋은 방향이 생각이 안난다. 첨에 착수할땐 자명하다고 생각했는데, 막상 시작하고나니 의외로 참고할 물건도 적고 난감한 상태다.
lionhairdino shared the below article:
논리와 메모리 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 2 편)
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 "논리적"이 되는 두 번째 방법인 논건 대수를 재조명하며, 특히 컴퓨터 공학적 해석에 초점을 맞춥니다. 기존 논건 대수의 한계를 극복하기 위해, 컷 규칙을 적극 활용하는 반(半)공리적 논건 대수(SAX)를 소개합니다. SAX는 추론 규칙의 절반을 공리로 대체하여, 메모리 주소와 접근자를 활용한 저수준 자료 표현과의 커리-하워드 대응을 가능하게 합니다. 글에서는 랜드(∧)와 로어(∨)를 "양의 방법", 임플리케이션(→)을 "음의 방법"으로 구분하고, 각 논리 연산에 대한 메모리 구조와 연산 방식을 상세히 설명합니다. 특히, init 규칙은 메모리 복사, cut 규칙은 메모리 할당과 초기화에 대응됨을 보여줍니다. 이러한 SAX의 컴퓨터 공학적 해석은 함수형 언어의 저수준 컴파일에 응용될 수 있으며, 논리와 컴퓨터 공학의 연결고리를 더욱 강화합니다. 프랭크 페닝 교수의 연구를 바탕으로 한 SAX는 현재도 활발히 연구 중인 체계로, ML 계열 언어 컴파일러 개발에도 기여할 수 있을 것으로 기대됩니다.
Read more →
부끄럽지만 typst로 깎은 이력서와 포트폴리오를 공개합니다: https://github.com/gidongkwon/resume
게임 클라이언트에서 웹 프론트엔드로 커리어 전환을 하는 단계에 있습니다.
혹 피드백주실 것이 있다면 언제든지 좋아요...!
직링크는 아래:
이력서 - https://gidongkwon.github.io/resume/resume-gidongkwon.pdf
포트폴리오 - https://gidongkwon.github.io/resume/portfolio-gidongkwon.pdf
3년차 웹 프런트엔드 개발자입니다. 잠시 10주 여름 방학 동안 계약직으로 일할 수 있는 직장을 찾고 있습니다. (6월 마지막 주부터 8월 마지막 주) http://frontend.moe/portfolio/
올해 2학기까지 수료하면 졸업 예정이라, 학부 졸업 이후 정규직 전환 조건으로도 희망하고 있습니다.
lionhairdino shared the below article:
함수형 언어의 평가와 선택
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 함수형 언어의 핵심 개념을 람다 대수를 통해 소개하며, 함수형 언어의 평가 방식에 대한 깊이 있는 이해를 제공합니다. 람다 대수의 기본 요소인 변수, 함수, 함수 호출을 설명하고, 값에 의한 호출(CBV)과 이름에 의한 호출(CBN)의 차이점을 명확히 분석합니다. 특히, 폴 블레인 레비의 "값 밀기에 의한 호출(CBPV)"을 소개하며, 이 방식이 CBV와 CBN을 모두 포괄할 수 있는 강력한 도구임을 강조합니다. CBPV가 함수와 함수 호출을 스택 기반으로 어떻게 다르게 해석하는지, 그리고 이를 통해 람다 대수를 기계 수준으로 컴파일할 때 얻을 수 있는 이점을 설명합니다. 항수 분석과 같은 최적화 기법을 CBPV를 통해 어떻게 더 명확하게 표현할 수 있는지 보여주며, GHC 컴파일러의 중간 언어로서 CBPV의 중요성을 부각합니다. 이 글은 함수형 언어의 깊은 이론적 배경과 실제 컴파일러 구현 사이의 연결고리를 탐구하고자 하는 독자에게 유용한 통찰력을 제공합니다.
Read more →洪 民憙 (Hong Minhee) replied to the below article:
함수형 언어의 평가와 선택
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 함수형 언어의 핵심 개념을 람다 대수를 통해 소개하며, 함수형 언어의 평가 방식에 대한 깊이 있는 이해를 제공합니다. 람다 대수의 기본 요소인 변수, 함수, 함수 호출을 설명하고, 값에 의한 호출(CBV)과 이름에 의한 호출(CBN)의 차이점을 명확히 분석합니다. 특히, 폴 블레인 레비의 "값 밀기에 의한 호출(CBPV)"을 소개하며, 이 방식이 CBV와 CBN을 모두 포괄할 수 있는 강력한 도구임을 강조합니다. CBPV가 함수와 함수 호출을 스택 기반으로 어떻게 다르게 해석하는지, 그리고 이를 통해 람다 대수를 기계 수준으로 컴파일할 때 얻을 수 있는 이점을 설명합니다. 항수 분석과 같은 최적화 기법을 CBPV를 통해 어떻게 더 명확하게 표현할 수 있는지 보여주며, GHC 컴파일러의 중간 언어로서 CBPV의 중요성을 부각합니다. 이 글은 함수형 언어의 깊은 이론적 배경과 실제 컴파일러 구현 사이의 연결고리를 탐구하고자 하는 독자에게 유용한 통찰력을 제공합니다.
Read more →
Jira, Linear 등 일정 관리 앱이 풀어야할 가장 어려운 문제는, 사용자 중 상당수는 애초에 일정 관리를 하기 싫어하는 사람이라는 것이다. 안타깝게도 나도 거기 포함되는데, 문제는 그런 사람일 수록 일정 관리가 꼭 필요하다. 나중에 프로젝트가 복잡해지면 일정 관리 앱을 켜는 거 자체를 꺼리게 된다. 이걸 어쩌면 좋지.
lionhairdino shared the below article:
같은 것을 알아내는 방법
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 일상적인 질문에서부터 컴퓨터 과학의 핵심 문제에 이르기까지, '같음'이라는 개념이 어떻게 적용되고 해석되는지를 탐구합니다. 특히, 두 프로그램이 '같은지'를 판정하는 문제에 초점을 맞춰, 문법적 비교와 $\beta$ 동등성이라는 두 가지 접근 방식을 소개합니다. 문법적 비교는 단순하지만 제한적이며, $\beta$ 동등성은 프로그램의 실행을 고려하지만, 계산 복잡성으로 인해 적용이 어렵습니다. 이러한 어려움에도 불구하고, 의존 형 이론에서의 형 검사(변환 검사)는 $\beta$ 동등성이 유용하게 활용될 수 있는 중요한 사례임을 설명합니다. 이 글은 '같음'의 개념이 프로그래밍과 타입 이론에서 어떻게 중요한 역할을 하는지, 그리고 이 개념을 올바르게 이해하고 구현하는 것이 왜 중요한지를 강조하며 마무리됩니다.
Read more →@ailrunAilrun (UTC-5/-4) 저는, 상단의 카테고리 중 "게시글만"을 보고, 다른 서비스와 차별점이 이거구나 싶었습니다. 개발자 선수분들이 "투고"한 것들이, 적당한 속도로 쌓여 가면 좋겠습니다.
@lionhairdino 재활의 시발점으로 요새 하고 있는 일인 Conversion checker에 대한 글이나 좀 써 보아야겠습니다.
해커스펍을 스마트해지기 위한 용도로 쓰고 있다. 대수롭지 않은 생각도 어디안쓰면 쓸데없이 머릿속에서 리플레이된다. flush를 자주 하자...
RE: https://social.silicon.moe/@realgsong/114300412588845941
디지털 접근성에 관심 있는 분들이 계시려나...
구린 영어 실력에 LLM을 빌어서 일단은 혼자 하고 있지만...
예전처럼 평가 중심이 아닌 구현 방법 중심의 글을 좀 생산하고 싶다고...
일단 계획은 이런데... 같이 할 사람 있으면 좋겠다고 생각합니다아아...
생일 선물 받았다!
보통은 Ruby 코드를 작성할때 irb 같은 대화형 인터페이스를 사용하는 것이 일반적이지만, Bash 스크립트와 섞어서 사용할때 one-liner 스크립트를 작성하면 더욱 빛을 발휘합니다. 여기서 one-liner 스크립트란 한줄짜리로 실행하는 스크립트라고 이해하면 됩니다. ruby one-liner 스크립트로 작성할때는 다음과 같이 시작합니다.
$ ruby -e "<expression>"여기서 -e 옵션은 one-liner 스크립트의 필수요소인데, 파라미터로 넘겨준 한줄짜리 Ruby 코드를 evaluation해주는 역할을 합니다. 여러분이 **파이프 연산자**에 대한 개념을 이해하고 있다면, 이런 트릭도 사용할 수 있습니다.
$ echo "5" | ruby -e "gets.to_i.times |t| \{ puts 'hello world' \}"
# =>
# hello world
# hello world
# hello world
# hello world
# hello world표준라이브러리를 사용하고 싶을때는 -r 옵션을 사용할 수도 있습니다. 이 옵션은 ruby에서 require를 의미하는데, 식을 평가하기전에 require문을 미리 선언하고 들어가는 것이라 이해하면 됩니다.
예를 들면, 이런 것도 가능합니다 .
$ echo "9" | ruby -rmath -e "puts Math.sqrt(gets.to_i)"
# => 3.0위의 스크립트는 아래와 동일합니다.
$ echo "9" | ruby -e "require 'math'; puts Math.sqrt(gets.to_i)"
# => 3.0이런 원리를 이용하면, JSON/XML/CSV/YAML 등의 포맷으로 출력되는 데이터를 어렵지 않게 처리할 수 있습니다. one-liner 스크립트를 작성하는 방법에 대해 자세히 알아가고 싶다면, https://learnbyexample.github.io/learn_ruby_oneliners/one-liner-introduction.html 여기를 참고해주시면 좋을 것 같습니다.
이에 관해서, 25분-30분 정도 분량의 글을 정리해서 올릴 것 같은데 커밍쑨.....
https://newsletter.posthog.com/p/50-things-weve-learned-about-building
PostHog가 성공적인 제품을 만들면서 깨달은 50가지 교훈 (뉴스레터에서 지금까지 발행해놓은 것들 오마카세처럼 모아놓음)
그 중에서 마음에 드는 것들을 몇개 뽑아보자면...
- 신뢰는 투명성에서 온다. Build in Public 같은 것이 도움이 될 수 있음
- 시장에 내놓지 않으면 검증 조차 할 수 없음. 일단 시장에 내놓고 반응을 살펴볼 것
- 개밥먹기를 통해서 고객에게 전달되기 전에 문제점을 빠르게 인식하고 개선할 수 있는 흐름을 만들 것
닉스(Nix)를 써보려고 Nix Pills라는 글을 읽기 시작했다. 화면에 Hello, world!를 출력하는 패키지 hello를 닉스로 설치하는 방법이 나오더라.
nix-env -i hello저런 하찮은 프로그램이 패키지로 존재하는지 처음 알았다.
혹시 해키지에도 저런 게 있는지 검색을 해봤는데 있더라.[1] 2010년에 Simon Marlow가 업로드했다. 그런데 특이한 점이 이 패키지의 소스 코드 저장소 주소가 darcs.haskell.org라는 것이다. darcs를 호스팅하는 곳은 hub.darcs.net만 있는 줄 알았는데 haskell.org에도 있었구나⋯ 그런데 이 사이트 UI도 아예 없고 그냥 디렉터리 리스팅이 나오는데 hub.darcs.net으로 이전하시면 안 되려나.
Body Doubling(모각코, 모각작)이 ADHD인이 작업을 끝내는데 도움이 된다는 내용
일본에 Fediverse Linux Users Group이라는 모임이 있는데, 거기서 〈국한문혼용체에서 Hollo까지〉라는 이상한 주제로 오늘 발표를 합니다…
RE: https://hollo.social/@hongminhee/019603c7-b5ef-7d81-bbd4-4c37d46edce9
조던 엘렌버그라는 수학자가 쓴 '틀리지 않는 법'이란 책이 있는데, 재밌고 읽어볼만하다.
그 책에서 컴퓨터가 수학자가 하던일을 할수 있게되면 어떡하냐에 대해 저자의 해결책을 제시하는데 원래 하던일을 컴퓨터한테 맡기고 수학자들은 더 고차원적인 일을 하면 된다고 한다. 한 10년 전에 읽었을때도 그냥 대책없고 나이브한 생각으로 보였다. 근데 요즘은 (실제로 어떻게 될지랑은 상관없이) 저런 나이브한 마음가짐을 일부러라도 가지고 일해야 뭐라도 해낼듯.
해키지(Hackage)[1]에 패키지를 업로드하면 자동으로 빌드, 문서 생성, 테스트가 진행된다. 그런데 이게 시간이 좀 걸린다.(체감상 10분 정도) 이 과정이 자동으로 완료되기 전에 참지 못하고 수동으로 문서를 업로드하면 자동으로 진행되던 것들이 모두 중단된다. https://github.com/haskell/hackage-server/issues/1376
하스켈 패키지 저장소 ↩︎
일하기 싫어서 빈 망고 파일만 30분째 노려보는 중
@pbzweihander쯔방 
제프딘이 컴퓨터를 째려보면 OS가 움찔해서 프로그램이 완성된다 하는 밈이 생각나요
빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.
lionhairdino shared the below article:
스태키지 큐레이션이 성공할 수 있었던 것은 하스켈이라는 언어와 생태계의 특징도 컸습니다.
juxtapose @xt@hackers.pub
인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270
스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.)
하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠.
그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.)
그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다!
("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.)
이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요.
스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process 라든지 f 같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다.
그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠.
어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2 이런 거 하나도 관리 안 하고 그냥 mypkg 라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.