Claude Sonnet 3.7이 JavaScript 코딩은 잘 하는 것 같은데, TypeScript 코딩은 별로네…
bgl gwyng
@bgl@hackers.pub · 83 following · 99 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub- @bglgwyng
shootee- www.shootee.io
@hongminhee洪 民憙 (Hong Minhee) 제 관찰과 달라서 의외네요. TS 타입을 맞춰서 짜는걸 잘 못한다는 말씀인가요, 아니면 타입레벨 프로그래밍을 잘 못한다는 말씀인가요? 사실 저는 3.7이 후자를 그 이전의 모델과 달리 매우 잘해서 좀 놀랐습니다.
@bglbgl gwyng 근데 이제 사실 Deno도 Bun만큼 Node.js 호환성을 지원하긴 해요. 하지만 이미 Bun에게 사용자를 많이 뺏기긴 했으니 소 잃고 외양간 고치기긴 했죠.
@hongminhee洪 民憙 (Hong Minhee) 기억이 맞나 모르겠는데, Deno가 npm 모듈중에서 ESM + Only JS는 일찌감치 지원하지 않았나요? 이정도면 나름 최선을 다한건데...
흑흑… 안돼! (Hackers' Pub은 Deno로 돌아가고 있습니다…)
개인적으로는 Node.js 호환성만 좇고 있는 최근의 Deno 업데이트가 (현실적으로 쓰기 편해지는 것은 맞지만) 조금 실망스럽긴 하다. 그냥 처음의 기조 그대로 밀어붙였다면… 뭐, 오히려 지금보다도 덜 쓰였겠지? 어려운 문제긴 하네…
개인적으로는 Node.js 호환성만 좇고 있는 최근의 Deno 업데이트가 (현실적으로 쓰기 편해지는 것은 맞지만) 조금 실망스럽긴 하다. 그냥 처음의 기조 그대로 밀어붙였다면… 뭐, 오히려 지금보다도 덜 쓰였겠지? 어려운 문제긴 하네…
@hongminhee洪 民憙 (Hong Minhee) 저는 에전에 TS 스트립트 용으로 쓰려고 노력했었는데, 클라이언트 라이브러리가 돌아가는게 없어서 포기했었거든요. 그래서 바로 Bun으로 갈아타서 npm 패키지 썼었습니다. 저랑 비슷한 경로로 Deno 대신 Bun 쓰는 분들이 꽤 될거같아요.
그냥 Markdown 파서로 AST 만든 다음에 최상위 노드 기준으로 분할하게 만드는 중… 어떻게 번역 기능 만드는데 쪼개기(chunking) 로직 구현하는 게 제일 오래 걸리냐…
@hongminhee洪 民憙 (Hong Minhee) 오잉? 그냥 원본 마크다운 서식 존중해서 출력해 하면 말을 안듣나요?
취약점 관련 기여는 처음 해봤는데 새롭다
그동안 하던 앱/웹 작업이 아닌 라이브러리 개발이라서 verification이 훨씬 쉬워서 본격적으로 에이전틱하게 쓸수있었다. 테스트코드도 자동으로 쭉쭉 뽑으면서 나는 거의 관리감독만 한다. 에이전틱하게 쓸때의 생산성이 최소 10배는 되는데, 반대로 1/10의 생산성을 가지는 어시스턴트 모드에서의 좋고나쁨이 뭐가 그리 중요할까.
Windsurf 커서보다 불편하다고 계속 불평했는데, 그냥 과제하나 맡기고 에이전틱하게 쓰니까 똑같이 잘한다. AI 에디터에서 UI 개선한다고 아웅다웅하는게 참 부질없는거 같다. 빅테크에서 모델 개선하는동안 가만히 놀수는 없으니까 하는건가...
어릴때 알고리즘 문제풀면서 시꺼먼 터미널만 보다가 저기 있는 예시 따라해서 GUI 프로그램이 뜨는거보고 즐거웠던 기억이 난다.
RE: https://hackers.pub/@aioo/01968b3c-a3cb-78dc-b781-c25e01650ec3
이 사이트가 아직도 살아있구나. http://www.soen.kr/ (구 winapi dot co dot kr)
알고리즘 공부하시는 분과 이야기 나누다가 생각나서 오랜만에 들어가봤는데 여전한 모습이었다. 정올 공부할 때나 윈도 프로그램 개발할 때 자주 들락거리던 사이트인데 반가운 마음...
많은 프로그래머가 아이디어를 시각화하기 위해 화이트보드나 종이에 손으로 필기를 한다. 기존에도 AI가 사용자의 필기를 기반으로 코드를 작성해주는 연구는 있었지만, 필기와 코드가 분리되어 있다는 한계를 벗어나지 못했다. Code Shaping은 단순히 스케치를 코드로 변환하는 툴이 아니라, 필기와 코드 편집이라는 두 워크플로우를 통합하는 툴. 사용자가 코드 위에 자유롭게 필기함으로써 코드를 편집할 수 있다. 코드를 한줄씩 작성하는 것이 아니라, 2차원 평면을 탐색하며 코드를 편집하기 때문에 피험자들이 선형적으로 인식했던 코드 작성을 공간적으로 감각하게 되었다고. https://programs.sigchi.org/chi/2025/program/content/189580
.github/copilot-instructions.md, .cursorrules, .windsurfrules, CLAUDE.md… 이것 말고도 많이 있을텐데, 어차피 들어가야 하는 내용은 다 거기서 거기. 지금은 한 파일에 적고 심볼릭 링크로 같은 곳을 바라보게 하고 있지만, .editorconfig처럼 그냥 어떤 식으로든 표준화가 되었으면 좋겠다.
@hongminhee洪 民憙 (Hong Minhee) 결국 에디터 레벨에서 '.cursorrules나 .windsurfrules 같은 파일을 찾아서 거기에 쓰인 지침을 따라줘'라고 프롬프팅하게 될거 같습니다;;
.github/copilot-instructions.md, .cursorrules, .windsurfrules, CLAUDE.md… 이것 말고도 많이 있을텐데, 어차피 들어가야 하는 내용은 다 거기서 거기. 지금은 한 파일에 적고 심볼릭 링크로 같은 곳을 바라보게 하고 있지만, .editorconfig처럼 그냥 어떤 식으로든 표준화가 되었으면 좋겠다.
.windsurfrules를 채워넣었는데 이게 효과가 있는지 없는지 모르겠다. 혹시 좋은 방법 있나요? 이것도 어떤 잘알려진 방법을 따라 LLM이 쓰게하는거보다 더 잘할 방법이 없을거 같다.
그로센딕이 김장을 할줄 알았다는 이야기는 알고 있었는데(한번 들으면 못까먹음), 이렇게 본격적일 줄은 몰랐다. 한국인인 나보다도 김치에 대해 더 잘 안다.
bgl gwyng shared the below article:
업자를 위한 아주 인포멀한 모나드 설명
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의 도움을 받아 모노이드로 만들 수 있는 구조입니다.
※ "정교한" 내용이 아님을 강조하고 선입견이 생기지 않기 위해, 일부러 제목을 달지 않고, 반말(혼잣말)투로 썼습니다.
제목은
- 함수형
- 모노이드
- 모나드
순서 입니다.
휴일인지 깜빡하고 출근해버렸다ㅋㅋ
웹 앱들이 카메라, 위치 등 권한을 어떤 방식으로 요청하고 있는지, 사용자가 이에 어떻게 반응하는지에 관한 연구. 많은 웹 사이트가 사용자에게 아무런 맥락없이 권한을 요청한다. 기본적으로 사용자에게 권한이 왜 필요한지 설명하면 허용률이 높아졌고, 긍정적인 톤으로 권한을 요청하면 허용률이 18% 증가한다. 텍스트만 보여주기 보다는 UI 요소가 있을 때 허용률이 더 높았는데, 오버레이(+41%) 또는 전체화면(+33%)으로 권한을 요청하면 허용률이 늘지만 사용자의 불만족도 높아졌다. https://programs.sigchi.org/chi/2025/program/content/188217
글이 좀 서툴러 보이더라도 ai 안 거치고 직접 쓴 글들이 글 맛이 있어서 좋긴하다.
방금 동탄에서 마을버스타는데 브레이크가 고장나서 다음버스로 갈아탔다. 근데 기사분이 회사쪽 관리자랑 통화하는데, 관리자가 일단 조심해서 차고지로 돌아와보라고 하는것이다. 정 안되면 렉카를 부르자고 했다.
이 무슨 개똘추같은... 안그래도 비까지 오는데 사고나면 누가 책임질건가. 암튼 그 기사님이 무사히 돌아가길 빈다.
In all my years of doing physics, I never figured out the intuitive meaning of the lagrangian (or the action). Why should the difference between kinetic and potential energy play such a prominent role? What separates kinetic from potential energy?
I was always afraid to ask this question, not to sound stupid. 😕
@bglbgl gwyng 이 글은 하스켈 학교에 공유하면 안 되겠군요!(들키니까)
@curry박준규 아마 거기 안계실겁니다ㅋㅋ
멘티를 서울숲하스켈에 보냈었는데, 거기갔다 왔더니 이제 JS 코드짤때 커링을 알아서 잘 활용한다. 사실 내가 그분께 주는 피드백이 '좀더 함수형으로 짜라' 이상도 이하도 아닌데(이거 들키면 안됨), 방법을 하나하나 가르치려니 너무 피곤해서 하스켈을 배우게 시켰다. 리턴 확실하구만.
@bglbgl gwyng 하스켈 툴링에 많이 익숙해져야겠군요 이런,,,
@kodingwarriorJaeyeol Lee 일단은 스타터 템플릿을 믿고, 요상한 이름의 설정들이 손짓하는걸 꾹참고 무시하고 나아가는걸 추천드립니다
@bglbgl gwyng 흠... 고민이 되네요. https://peerdh.com/blogs/programming-insights/using-ghcjs-for-haskell-to-javascript-compilation-in-web-applications-3 이런건 있는 것 같은데, Purescript By Example 같은 리소스는 어디 없나요?
@kodingwarriorJaeyeol Lee 저는 Reflex를 썼었는데 추천하기엔 약간 거시기한 부분이 있습니다(라이브러리의 자체의 문제는 아니지만요). miso가 이쪽으로 가장 인기있는거 같습니다.
@bglbgl gwyng 하스켈에 JS 컴파일도 있었어요????
@kodingwarriorJaeyeol Lee 넵 9.10인가에 추가되었어요. 첨에 궁금해서 Hello World 빌드해봤는데 20MB인가 떠서 휴지통 직행했는데요, GHC의 최근 체인지로그에 많은 개선이 공유되었습니다.
프론트엔드하면서 하스켈 공부한다하면 역시 PureScript로 공부하는게 낫겠군.
@kodingwarriorJaeyeol Lee 근데 그사이 하스켈의 JS 컴파일도 많이 개선되어서, 그냥 하스켈로 하는것도 괜찮다고 생각합니다. PureScript의 특장점이 따로 어떤게 있는지는 잘 모릅니다.
@bglbgl gwyng 네 러스트로 구현 중이에요
파서 콤비네이터 패키지 이름을 pccc로 정했는데 생각해보니까 이게 개인통관부호의 약자였다
'모나드는 모노이드 엔도펑터다'가 이제 무슨 뜻인지는 안다. '모노이드'라는게 >>= 보다는 join을 쓸때 더 와닿는데, >>=를 join보다 한 30배는 더 자주 쓴다. 그래서 저 사실을 평소에 잘 느끼고 살진 못하는거 같다. 하지만 가끔 join으로 타입을 눌러서 맞출때 개꿀따리란 생각이 들긴하다.
자녀계획 3명 정도로 계획하면?
.
.
.
.
.
.
.
.
미래애셋 ^^
Hacker's Pub에 어울리는 추가 기능이 뭔가 생각해봤는데, 프로그래밍 언어를 토픽으로 필터링할수 있음 좋겠다. Markdown의 코드블락으로(python 등) 상당히 커버되지 않을까?
```python``` 같은걸 의미하는 거였습니다
Hacker's Pub에 어울리는 추가 기능이 뭔가 생각해봤는데, 프로그래밍 언어를 토픽으로 필터링할수 있음 좋겠다. Markdown의 코드블락으로(python 등) 상당히 커버되지 않을까?
오픈 엑세스에 올라와 있는 논문들 중 소프트웨어 공학과 관련된 내용들을 편집하여 책으로 낸 것이다. 원문이 논문이라 그런지 몰라도 주장이 그렇게 혁신적이거나 새로운 것은 없다 다만 연구를 통해서 본인들의 주장에 대한 근거를 확보했다는 것이 유의미하다. 바꿔 말해 이 책에서 말하는 것들은 믿고 따라도 되는 어느 정도의 과학적 근거가 있는 이야기들. #독서
소프트웨어 엔지니어링 생산성 돌아보기
http://aladin.kr/p/7zTVn
@hongminhee洪 民憙 (Hong Minhee) 
@bglbgl gwyng 어떤 깨달음을 얻으셨나요!
@curry박준규 아직 소화하는 중입니다... 제품에 녹여보겠습니다
저는 소셜 서비스의 핵심이 ‘좋아요(Like)’라고 생각합니다. 저는 제가 페이스북에서 처음으로 ‘좋아요’를 많이 받아서 너무 신났던 감정을 잊을 수 없습니다. 그리고 저는 지금도 ‘좋아요’의 노예⋯(사람들은 그런 너를 관종이라고 부른단다.)
@curry박준규 아덕분에 중요한걸 깨달았습니다.
쓰레드앱에 있는 문화 중 이해 안 가는 거 . 반말로 말하기. 이걸 왜 문화랍시고 퍼뜨리고 있는지 이해 안된다. 격식 없다기 보다는 그냥 예의 없어 보이는데...
엔드포인트 솔루션이나 네트워크 장비를 운영하다 보면 그 솔루션 본연의 역할을 지고지순(?) 하게 지키기보다는 뭔가 민원을 해결하는 예외 처리에 리소스를 투입할 때가 많은데 그럴 때마다 뭔가 법을 어긴 것 같고 마음이 안 좋다.
10만년 만에 오픈소스 기여해봄. 러스트로 UI 개발해본건 처음인데 언어보단 UI가 더 까다로웠다 https://github.com/faiface/par-lang/pull/42
러스트가 어렵다는 이야기에는 러스트의 특징을 이질적으로 느끼는 경우가 많아서도 있겠지만…어렵다는 말의 재생산이 어렵다는 이미지를 더 굳히는 것 같기도 합니다. 일종의 악순환이라고도 생각하는 게…어렵다는 이미지를 가지고 보면 개념 익히는 것도 어렵고 컴파일 에러를 해결하는 과정도 좀 더 고되게 느낄 수 있거든요. 러스트에 대한 이미지를 어렵다고 생각할수록, 갖고있는 배경지식이 러스트와 이질적일수록 어렵다고 느끼는 사람들이 많은듯합니다
뒤늦은 서울숲하스켈 조교 후기: 왠지 모르겠는데, 다들 운동을 열심히 하시는지 몸이 굉장히 좋으셨다. 건강한 신체에 건강한 정신이 깃든다를 실천하고 계신 분들이었다.
...는 농담이고(근데 사실입니다), 커리큘럼이 내가 상상하던 방향이랑은 꽤 달라서 흥미로웠다.
마지막 회차에 하스켈로 웹서버를 띄우는 것을 목표로 진행중이었는데, 이를 위해 Monad Transformer(Monad는 진즉에 해치우고), Tagless Final, Lens를 모두 소개한 상태였다. 근데 저 개념들이 '왜 하스켈에선 이거 안 돼요? 왤케 불편해요?' 같은 질문을 회피하지 않으려면 꼭 가르쳐야 하는 부분들이긴 하다. 가령, 'Monad만 배우면 이제 하스켈에서 명령형 코딩 할수 있다'라는 이야기가 이론상은 맞는데, Monad Transformer나 Algebraic Effect 같은거 안쓰면 웹사이트등 실제로 쓸모있는 프로그램을 사실상 짤수가 없다. 그래서 가르치긴 해야한다.
문제는 저걸 다 가르치려면 상당히 빡셀테니, 나는 만약에 내가 하스켈 부트캠프를 한다면 일단은 저런걸 회피하고 하스켈의 멋진 부분에 집중하는 커리큘럼을 짜야겠다고 그동안 생각했었다. 근데 또 이건 어찌보면 기만이기도 하다. 그런데 서울숲하스켈에서는 어찌저찌 다들 따라오도록 구성을 잘하신것 같다 하스켈을 이질적인(긍정적으로든 부정적으로든) 프로그래밍 언어로 소개하는게 아니라, 언젠가 본인의 작업에 활용할 언어의 후보로 올리게끔 하려면 저런 내용들을 다 다뤘어야 할것이다.
암튼 그동안 수고많으셨습니다. 
@lionhairdino @bglbgl gwyng 너무 큰 비약인지는 모르겠으나 보면서
https://hazel.org/build/dev/ 이 떠오르네요. 편집기가 code를 맘대로 바꾼다는 측면에서 말이지요.
@ailrunAilrun (UTC-5/-4) @lionhairdino 아 이거 찾는중이었습니다ㅋㅋ hegel로 아무리 검색해도 안나왔는데 hazel이었네요.
들여쓰기와 공백에 민감?한 게 다른 건가요?
하스켈은 들여쓰기가 슈거 문법 같은 거라 들여쓰기 없이 괄호와 세미콜론으로 작성할 수 있는데, 익숙해서 그런가 들여쓰기가 더 가독성이 높은 느낌도 듭니다. @bglbgl gwyng
@lionhairdino 들여쓰기를 제외한 토큰을 구분하는 용도로 쓰이는 공백을 그냥 공백이라고 했네요.
들여쓰기가 물론 가독성은 좋지요. 근데 편집할때 불편을 주는 문제가 있고, 에디터가 좀 힘을써주면 양쪽의 장점을 다 취할수있다는 얘기였습니다.
저도 비슷한 생각인데, Haskell이나 Rust는 코너 케이스를 다루지 않고는 컴파일도 못 하게 금지하는 경우들이 꽤 많고 (그래서 좋은 언어지요), 빠르게 해피 패스만을 검증하고 싶을 때는 Python 같은 널널한 언어(복잡하고 규모가 큰 소프트웨어를 만들 때는 나쁜 언어가 되지요)가 쉽게 느껴질 수 있다고 생각합니다. 즉, Haskell이나 Rust가 어렵다고 말할 때의 어려움은 개념적 이해의 난도라기 보다는 시행착오의 커브의 경사를 얘기하는 것 같아요.
비슷한 측면에서 저는 Python의 들여쓰기를 강제하는 문법이 프로그래밍 초심자에게 좋은 습관을 처음부터 정착시키는 데에는 일조할 수 있겠지만, 결코 쉽지는 않다고 생각합니다.
RE: https://hackers.pub/@bgl/01967f97-67ab-7a98-a6e5-16cb3ef31856
@hongminhee洪 民憙 (Hong Minhee) 약간 딴 얘긴데, 저는 들여쓰기가 그냥 안좋은 문법요소 같습니다. 코드의 복붙을 unreliable하게 만들어버려서요. 반대로 space sensitive한 문법은 괜찮다고 생각합니다. 복붙시 문제가 생겨도 스페이스 한번 치면 해결되니까요. 들여쓰기 대신에 {} 쌍을 쓰게 만들되, 에디터에서 보여줄때 어떻게 알아서 예쁘게 보여주는게 낫다고 생각해요.
develop :: Maybe Coffee -> IO Code
develop Nothing = pure Garbage
develop (Just fuel) = do
code <- think fuel >>= implement
filter (writtenIn Haskell) code그때 하스켈학교 디스코드에서 코드 백일장 열어서 나온 것들을 조합해서 만들었다.
RE: https://hackers.pub/@bgl/01967fa1-dee1-76ca-93bc-1778c0dc9a75
서울숲하스켈보고 예전에 카카오 하스켈부트캠프했던게 생각났다. 그때 굿즈도 만들었다. hoxy 갖고싶은분 계시면 마플에 새로 주문넣어서 보내드립니다.
Hackers' Pub 저장소에 보내주신 
- https://github.com/hackers-pub/hackerspub/pull/44
- https://github.com/hackers-pub/hackerspub/pull/45
- https://github.com/hackers-pub/hackerspub/pull/46
- https://github.com/hackers-pub/hackerspub/pull/47
여러분의 많은 기여 감사합니다. 🙏
참고로 현재 hackers.pub에 배포된 게 어떤 버전인지 알고 싶다면 https://hackers.pub/nodeinfo/2.1에 들어가셔서 software.version을 보시면 됩니다. 버전의 마지막 부분인 빌드 넘버가 Git 커밋 해시입니다.
러스트가 어렵다는 이야기가 숙고없이 재생산 되는거 같긴 합니다. 제가 러스트를 별로 안써봐서 실제로 얼마나 어려운진 모르겠습니다.
그런데 말씀하신 모나드, 트레잇, 오너십 등의 개념들과 클래스는 좀 차이가 있다고 생각합니다. 그러니까 자바에서 클래스 때문에 어떤 코드를 못짜게 되진 않잖아요? 자바를 하면서 클래스를 제대로 쓰지않고도 뭔가 만들순 있습니다. 반면 전자의 개념들은 잘못된 코드를 짜는걸 막고, 초보자 입장에서 뭔가 하고싶은게 있는데 그게 금지되는 상황에서 어렵다는 느낌을 (필요이상으로 크게) 받을수 있다고 생각합니다.