lionhairdino

@lionhairdino@hackers.pub · 34 following · 33 followers

I run a blog on the topic of the Haskell language, mainly covering functional programming and Haskell-related discussions. If someone talks about these topics, I act like we're old friends, even if it's our first time meeting.

Blog
lionhairdino.github.io
lionhairdino @lionhairdino@hackers.pub
Public

익숙한 정main, 부sub를 써서 정작용(주작용), 부작용을 같이 보여주면 "부"의 뜻을 인지하는데 도움을 줄 것 같긴 한데, side effect 얘기를 할 때 primary effect를 거론하는 자료도 드물고, 뭔지 궁금해하는 분들도 못봤습니다.(왜 안 궁금해할까요? ㅎㅎ)

어떤 논문은 Side-effect를 Computational Effect 전반을 가리키는 용어로 쓰고, 어떤 논문들은 Effect 중 mutation을 가리키는 용어로만 씁니다. 오래된 논문일수록 전자처럼 쓰고, 요즘은 후자로 자리잡아 가고 있다고 합니다.

그동안 본 번역은 부작용, 부수 효과 정도고, 그 외 생각해 본 번역은 "부차 효과"정도가 있습니다. 맥락에서 특별히 튀지 않으면, 저는 문장에서, 원어에 바로 연결되지 않는 단점이 있긴 하지만, 의미 전달에는 유리하다 생각하는 "비순수 효과"를 쓰기도 합니다. @hongminhee洪 民憙 (Hong Minhee)

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

개인적으로 영단어 “side effect”의 가장 적절한 번역은 “부작용”이라고 생각하고, 실제로 프로그래밍 이외의 분야에서는 여전히 이 번역어를 가장 많이 쓰는 것 같은데… 사람들이 “부작용”을 副作用이 아니라 否(?)作用이라고 착각하는 것을 염려해서인지 프로그래밍 분야에서는 “부수 효과” 같은 번역어를 더 많이 쓰는 듯하다. “부작용”의 “부”(副)는 “사장”–“부사장”할 때의 “부”인데 말이다.

0
1
0
chewing_leopard @chewing_leopard@hackers.pub
Public
Shared by lionhairdino

부끄럽지만 typst로 깎은 이력서와 포트폴리오를 공개합니다: https://github.com/gidongkwon/resume

게임 클라이언트에서 웹 프론트엔드로 커리어 전환을 하는 단계에 있습니다.
혹 피드백주실 것이 있다면 언제든지 좋아요...!

직링크는 아래:
이력서 - https://gidongkwon.github.io/resume/resume-gidongkwon.pdf
포트폴리오 - https://gidongkwon.github.io/resume/portfolio-gidongkwon.pdf

Resume made with typst. Contribute to gidongkwon/resume development by creating an account on GitHub.

GitHub - gidongkwon/resume: Resume made with typst

Resume made with typst. Contribute to gidongkwon/resume development by creating an account on GitHub.

github.com · GitHub

4
0
0
1
0
0
0
0
0
0
0
0
0
0
0
Simon Park @parksb@silicon.moe
Public

많은 프로그래머가 아이디어를 시각화하기 위해 화이트보드나 종이에 손으로 필기를 한다. 기존에도 AI가 사용자의 필기를 기반으로 코드를 작성해주는 연구는 있었지만, 필기와 코드가 분리되어 있다는 한계를 벗어나지 못했다. Code Shaping은 단순히 스케치를 코드로 변환하는 툴이 아니라, 필기와 코드 편집이라는 두 워크플로우를 통합하는 툴. 사용자가 코드 위에 자유롭게 필기함으로써 코드를 편집할 수 있다. 코드를 한줄씩 작성하는 것이 아니라, 2차원 평면을 탐색하며 코드를 편집하기 때문에 피험자들이 선형적으로 인식했던 코드 작성을 공간적으로 감각하게 되었다고. programs.sigchi.org/chi/2025/p

Code Shaping: Iterative Code Editing with Free-form AI-Interpreted Sketching
0
0
0
1
0
0
1
0
0

업자를 위한 아주 인포멀한 모나드 설명

lionhairdino @lionhairdino@hackers.pub

1.

함수형에선, 스트림 [1,2,3]에
(+1)을 map해서 [2,3,4]를 만들고,
(+2)를 map해서 [3,4,5]를 만드는 작업을,
(+2) ∘ (+1)를 [1,2,3]에 map하는 걸로 표현할 수 있어야 한다.

(+1), (+2), ((+2) ∘ (+1)) 함수들은 모두 Int -> Int 함수를 원하는 곳에 넣어 줄 수 있는 함수들이다.

위와 같이, 완벽하게 정보를 유지하진 않지만, 같은 "류"의 작업을 두 번 하는 것을, 한 번 작업하는 것으로 표현할 수 있는 경우도 있다. 예를 들어, 첫 번째 작업으로, "hello"를 로그로 남기고, 두 번째 작업으로, " world"를 로그로 남기는데, 이를 한 번의 작업으로, "hello world"를 로그로 남기는 작업으로 표현할 수 있다. 여기는 로그를 남기는 횟수 정보는 필요 없고, 최종 로그만 필요하다는 인위적 정보 선택이 들어가 있다. 이 인위적 선택(여기선 로그 문자열을 합치는 것)을 수긍해야만 가능하다.

로그를 남기는 작업을 m이라 부를 때, m a를 받는 곳에 m (m a)를 넘길 방법이 생긴다는 뜻이다. 달리 말하면, m (m a)로 표현되는 작업을 인위적인 절차를 거쳐 m a로 만들어도, 내가 필요한 정보는 사라지지 않는다는 뜻이다.

2.

무언가가 하나인데, 유심히 보면 하나가 아닌 경우, 이게 바로 모노이드다. mono는 하나를 뜻하고, ~oid는 "척"하는 걸 말한다. (예. 인간인 척 하는 휴머노이드) 하나인척 하는 게 모노이드다. 수학 책 앞 부분에서 이항 연산, 결합 법칙, 항등원이 있으면 모노이드라는 설명을 하는데, 그래서 모노이드가 뭐에 쓰는 물건인지는 한참 공부해야 알 게 된다.

(아래는 혼자만의 생각입니다.)
모노이드를 바라 보는 눈 중 하나로, "모든 대상을 이항 연산으로 표현"을 들 수 있다.

0을 포함한 자연수들 0,1,2,3,... 들은, + 이항 연산과, 이 연산의 항등원 0이 있으면, 모두 ○ + ○ 한 가지 모양으로 표현할 수 있게 된다.
0 -> 0+0
1 -> 0+1
2 -> 0+(1+1) = 1+1
...
모노이드 구조이기에, 어딘가에서 ○ + ○ 모양을 원한다면, 0,1,2,3,...을 모두 넣어 줄 수 있다.

3.

"어딘가에서 m a를 원한다면, m a, m (m a), m (m (m a)), ...를 모두 넣어 줄 수 있다."를 위와 비교하며 보자.

위에서 얘기한 인위적 선택 작업을 join으로 표현하면,
m (m a) --join--> m a
m (m (m a)) --join--> m (m a) --join--> m a
...
m 반복 작업을 모두 ○ --join--> ○ 모양으로 표현할 수 있을 것만 같다. 그런데, 딱 하나는 표현하지 못한다. join은 m이 두 개 있는 걸, 하나로 만드는 작업이라, m하나를 ○ --join--> ○로 표현하지 못한다. m을 join이 들어간 모양으로 표현하려면, 자연수, + 에서 처럼 0에 대응하는 것이 필요하다. m하나를, m 두 개로 만들되, 최종 결과에 영향을 미치지 않는 pure라는 작업을 만든다. 위 로그 작업을 예로 들면, 로그로 빈문자 ""을 추가하는 작업을 pure로 만든다. 그러면 이제야 비로소, 모든 반복된 m 을 join으로 표현할 수 있게 된다

m a --pure--> m (m a) --join--> m a
m (m a) --join--> m a
m (m (m a)) --join--> m (m a) --join--> m a
...

이제, join절차가 항상 있는 m a를 원하는 곳에 m a도 m (m (m a))도 넣어 줄 수 있게 되었다. "hello"와 " world"를 남기던 두 개의 작업 합쳐, "hello world"를 남기는 하나의 작업으로 표현할 수 있게 되었다.

※ 지금 눈에 명확히 보이진 않지만, m 둘을 합성하는 연산을 .이라 하면, .만으론 모노이드 이항 연산 역할을 못하지만, join의 도움을 받고, id 만으론 항등원 역할을 못하지만, pure의 도움을 받아 모노이드 구조를 이룬다.

결론.

당연히 모든 내용이 담겨 있진 않고, 모나드를 무엇의 모노이드로 보는 내용을 비수학적으로 풀어 봤다. 모노이드는 모두를 하나의 모양으로 표현 할 수 있다는 걸, 보증해주는 거대한 개념이지만, 업자인 나에겐 "그렇게 해도 된다"는 정도의 느낌만 있다. (결합 법칙이 빠졌는데, 나중에 코드를 모듈화 하는 것과 연관지어 보면, 명확한 대응을 알 수 있다.)

모나드는, 조금 다르게 생긴 것을, 당장 필요한 요소만 잘 관리한다면 "같은 걸로 치자"를 멋지게(,어렵게) 형식화한 이론이다.

사족.
저와 대화를 나눠본 분들은 아시겠지만, 제가 비전공자라 용어 선택이나 개념 정의가 매우 인포멀해서 인상을 찌푸리는 경우도 자주 만듭니다. PL 전공자분들처럼 깊숙히 이론을 파고 싶은 게 아니라, 현실에 적용할 수 있을 만큼의 눈만 가지고 싶습니다. 현실을 모델링할 때, "인위적 정보 선택"을 해서 필요한 정보를 남길 수 있는 경우를 알아채는 눈을 길러야 되는데, bind 또는 flatmap, return 또는 pure가 있는 구조가 모나드라고만 배우면, 이런 눈을 가지는데 매우 오래 걸리는 것 같습니다.

비전공 업자분이 보셨다면, 얻어 가시는 아이디어가 있었으면 좋겠고, 전공자분이 보셨다면, 인포멀한 부분에 너무 인상 찌푸리지 마시고, 틀린 개념이 있다면, 부드럽게 조언을 해주시면 좋겠습니다.

※ 모나드 용어는 mono와 triad에 온 게 아닐까 의심한다는 설이 있습니다.(검색해 보면 근거는 미약해 보입니다.) 모나드는 join, return 그리고 위에서 명시적 언급은 안했지만, 펑터의 fmap, 이렇게 세 개 triad의 도움을 받아 모노이드로 만들 수 있는 구조입니다.

※ "정교한" 내용이 아님을 강조하고 선입견이 생기지 않기 위해, 일부러 제목을 달지 않고, 반말(혼잣말)투로 썼습니다.

제목은

  1. 함수형
  2. 모노이드
  3. 모나드

순서 입니다.

Read more →
6
0
0
2
0
0
1
0
0
lionhairdino @lionhairdino@hackers.pub
Public

배포distribute 配布 (유사어 배치排置: 일정한 간격으로 벌여 놓다)
신문이나 책자 따위를 널리 나누어 주다

배치deploy 配置
군대를 전장에 배치하듯, 비즈니스 서비스에서 서버를 현장에 배치한다. 실전을 뛰게 배치한다.

"새로 만든 앱을 배치해서 사용자에게 배포했어"

1
0
0
3
0
0
1
0
0
bgl gwyng @bgl@hackers.pub
Public

'모나드는 모노이드 엔도펑터다'가 이제 무슨 뜻인지는 안다. '모노이드'라는게 >>= 보다는 join을 쓸때 더 와닿는데, >>=를 join보다 한 30배는 더 자주 쓴다. 그래서 저 사실을 평소에 잘 느끼고 살진 못하는거 같다. 하지만 가끔 join으로 타입을 눌러서 맞출때 개꿀따리란 생각이 들긴하다.

1
0
0
0
0
0
0
0
0
0
0
0
lionhairdino @lionhairdino@hackers.pub
Quiet public

생각보다 훨씬 자세하게 명문화된 규칙이 있군요.! 공부하면서 이 예시 저 예시 보다 보면, 버전이 널뛰고, 그러다 보면 HLS 지원이 오락 가락하게 되어, 사실 각 잡고 프로젝트에 쓰는 것 아니면, 의존도가 높지 않게 되어버리더라고요. 그 이유가 버전 지원 때문이란 생각에, 미리 HLS 친화적인 버전을 골라낼 수 있나 했는데, 그러긴 어려울 것 같네요.

0
1
0
0
1
0
1
0
0
0
1
0
0
0
0
0
1
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public

@lionhairdino 들여쓰기를 제외한 토큰을 구분하는 용도로 쓰이는 공백을 그냥 공백이라고 했네요.

들여쓰기가 물론 가독성은 좋지요. 근데 편집할때 불편을 주는 문제가 있고, 에디터가 좀 힘을써주면 양쪽의 장점을 다 취할수있다는 얘기였습니다.

1
1
0
1
0
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public

@hongminhee洪 民憙 (Hong Minhee) 약간 딴 얘긴데, 저는 들여쓰기가 그냥 안좋은 문법요소 같습니다. 코드의 복붙을 unreliable하게 만들어버려서요. 반대로 space sensitive한 문법은 괜찮다고 생각합니다. 복붙시 문제가 생겨도 스페이스 한번 치면 해결되니까요. 들여쓰기 대신에 {} 쌍을 쓰게 만들되, 에디터에서 보여줄때 어떻게 알아서 예쁘게 보여주는게 낫다고 생각해요.

0
1
0
1
0
0
1
1
0
0
0
0
Simon Park @parksb@silicon.moe
Public

나의 퀀트 투자 3개월 수익률... 첫 1개월은 10~15% 정도의 양호한 수익률을 유지하다가 트럼프가 무역전쟁을 시작하면서 나락에 빠졌다. 이런 상황에도 용기를 갖고 다음 3개월을 준비해야 한다...

종목별 수익률 목록. 전체 수익률 -12.45%, 최고 43.07%, 최저 -51.14%.
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

Mastodon 호환 API를 구현할 계획에 대해 문의 주시는 분들이 종종 계십니다만, 아마도 Hackers' Pub은 앞으로도 Mastodon 호환 API를 구현하지는 않을 것 같습니다. 개인적으로 Mastodon 호환 API가 사용성이 많이 떨어진다고도 생각하고, 이미 Hackers' Pub 고유의 기능들 가운데 Mastodon 호환 API로 표현 불가능한 것들이 좀 있기 때문입니다.

장기적으로는 GraphQL을 이용해 웹 프런트엔드도 크게 개선하고, 모바일 앱까지 만드는 걸 염두에 두고 있습니다.

1
0
0
Ailrun (UTC-5/-4) @ailrun@hackers.pub
Quiet public

@lionhairdino 예를 들면 "다양한 시선에서 코드를 이해한다"가 지금 공개한 연작의 2 편에서 논건 대수를 통한 계산의 이해와도 밀접한 연관이 있다고 읽혔습니다. 원래 두번째 주제에 대해서 쓰다가 방향성을 틀었네요.

lionhairdino @lionhairdino@hackers.pub
Quiet public

"여론에 따라" 함수형 추상 기계 관련 글을 쓰고 있었는데, 쓰다 보니 논리와 low-level data representation 이 보였다는 핑계 말씀이지요? 생각할 엄두조차 내지 못했던 주제들, 다 이해는 못하지만 감사히 보고 있습니다. SPJ, 와들러 교수님 등의 교양 수준 강의 활동들을 보다 보면, 왜 국내 교수님(고인물-댓가없이 입문자들에게 도움을 준다는 의미)들은 없나 아쉬운데, 엘룬님 글로 조금 달래지네요. @ailrunAilrun (UTC-5/-4)

1
1
0
1
0
0
Ailrun (UTC-5/-4) @ailrun@hackers.pub
Quiet public

말씀하신 것들을 보아 몇몇 분들은 실제 내용 측면에서는 논리와 저수준 자료표현에 더 관심을 가질 분들이 있는 것 같아 전자를 (먼저?) 다뤄보도록 하겠습니다. 2 편으로 나눠져 올라갈 예정입니다.

1
1
0
2
0
0
0
0
0
0
0
0
lionhairdino @lionhairdino@hackers.pub
Public

완전한 검정 배경에 하얀 글자는 대비가 높아, 눈에 잔상이 남습니다. 눈의 피로를 덜기 위해 다크 모드를 주 톤으로 선택했다면, 대비를 적당 수준으로 낮춰야 합니다. 나이가 올라갈 수록 영향을 받습니다. 모르시는 분들이 많은 것 같습니다.

1
1
0
0
0
0
1
2
0
1
0
0
1
0
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public

앱 디자인을 참고하려고 쓰레드를 깔아봤는데, 볼수록 디자인이 참 좋다. 문외한이 봐도 뭔가 깔끔하고 고수들이 만든게 느껴진다.

근데 그 아름다운 디자인위에 뜨는 컨텐츠들기 그렇게 소음공해일수가 없다. 뭐 틱톡은 어처구니없어서 웃기기라도 하지 이건 정말...

0
1
0
lionhairdino @lionhairdino@hackers.pub
Public

이 때가 좋았지. 신선한 내용들이 가득한데, 글도 잘 써놔서 이해도 곧잘 가고...

1
0
0