@bglbgl gwyng 이 변화는 Paterson-smaller 제약들(Constraints), 즉 어떤 정렬 순서(Well-order)에 의해 더 작은 제약들만 확장하겠다는 확장 순서의 변화고, 이를 제외하면 양상자(quantifier)와의 상호작용은 크게 변하지 않았습니다. 따라서 설명하신 것과는 다른 방식으로 오류가 발생하게 되지 않았나 싶습니다.

bgl gwyng
@bgl@hackers.pub · 84 following · 100 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub
- @bglgwyng
shootee
- www.shootee.io
@ailrunAilrun (UTC-5/-4) 말씀하신대로 저 변경사항이 오류랑 관련이 없는거 같아 아리송한 와중에, 저게 9.4 -> 9.6의 컴파일러 변경 사항이 저거밖에 없어서 오리무중에 빠졌네요. 빨리 재현 코드를 만들어봐야겠습니다.
@bglbgl gwyng 어떤 코드에서 어떤 에러가 나나요?
@curry박준규 좀 큰 코드인데 딱 관련된 부분만 빼서 정리하려면 시간이 걸릴거 같습니다ㅠ
https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6#superclass-expansion-is-more-conservative
내가 9.4 -> 9.6 마이그레이션에서 겪고 있는 문제가 이거랑 관련이 있는거 같은데(확실치 않음)... 9.4에서는 c :: Type -> Constraint
일때 forall c. c Int
뭐 이런 조건이 있으면, 모든 c
에 대해 c Int
가 존재하는게 말이 안되는데도 실제로 c Int
꼴로 쓰이는 c
만 고려해서 타입체크를 통과시켜줬던거 같다(이것도 확실하지 않음). 근데 9.6에선 당연히 거부당한다.
위의 내 이해가 맞다면 9.4의 constraint solving 완전 무근본이었단건데, 이건 또 믿기 어렵다(하스켈의 설계 결정에 대한 신뢰 유지한다고 하면). 어디서 내가 잘못 파악한거지.
@bglbgl gwyng 몰래 Nix 영업은 안 하셨나요?
@curry박준규 음 해커스펍 초대를 드릴까했다가 깜빡했네요
그냥 커피랑 간식만 먹다가 왔다. package.yaml 잘못 수정한거랑 constructor import 빼먹은거 고쳐드린게 전부.
RE: https://hackers.pub/@bgl/01965764-69ba-7e46-934f-ab8450c2486c
@bglbgl gwyng 고생이 많으십니다! 세미나는 어떤가요?
@curry박준규 7시 시작입니다. 후기남길게요ㅎㅎ
이제 서울하스켈숲 세미나 조교하러 간다
레코드 및 튜플 제안도 그렇고 어째서 JavaScript는 동등성 연산을 커스텀하게 구현할 수 있게 하지 않고 변죽만 울릴까? Symbol.equality
랑 Symbol.hash
같은 거 정해주고 Map
이든 Set
이든 내부적으로 그거 쓰게 하면 좋을 것 같은데.
@hongminhee洪 民憙 (Hong Minhee) 그러게요.
Map
Set
에 대해서만 Symbol.equality
등을 사용하는 동작만 추가하면 breaking change도 전혀 없네요.
@lionhairdino 아하ㅋㅋ 뭐 그냥 농담이었습니다. 사실 잘하고 못하고의 문제보다는 대충 막 짜놓고 돌아가면 뒤도 돌아보지않는 그런 경향이 보여서요 ㅋㅋ
@lionhairdino 근본적으로 성향이 좀 다른듯합니다.
제가 못해서 욕먹은 경험이 있어 편드는 거 아닙니다 ;-) @bglbgl gwyng
@lionhairdino 아하ㅋㅋ 뭐 그냥 농담이었습니다. 사실 잘하고 못하고의 문제보다는 대충 막 짜놓고 돌아가면 뒤도 돌아보지않는 그런 경향이 보여서요 ㅋㅋ
한 사람의 안목이 큰 이득으로 돌아 올 때, 정당한 대우에 대한 고민이 듭니다. 구름빵 라이센스가 생각납니다. 누군가 옆에서 그럴 겁니다. 교촌 세트 두 번은 먹어야지!? @bglbgl gwyng
@lionhairdino 제가 한건 기초적인 수정이라 거기에 대해 큰 보상을 바라진 않습니다. 반대로, 치킨먹으며 1시간이면 고칠 문제를 오랫동안 방치한 그 팀의 물리학자들에게 응당의 처벌이 가해지기를 바랍니다.
친구가 외국 반도체회사에 다니는데 이름만 들으면 다 아는 세계에서 손꼽히는 회사다. 1년 전쯤에, 친구가 자기 팀에서 예전부터 쓰고있는 시뮬레이션 코드가 너무 복잡해서 리팩토링 하고 싶다고 나를 찾아왔다. 한 2, 3000줄 되는 Numpy 코드였다.
나는 시뮬레이션의 의미 자체는 전혀 이해를 못하니(이래서 보안문제도 익스큐즈 할수 있었을 것이다), 그냥 코드의 모양만 보고 이상한 부분을 조금씩 고쳐나갔다. 그... 전형적인 물리학자들의 실험실 코드였다(코드를 못짜는건 이해를 하는데, 거기에 대해 한치의 부끄러움도 느끼지 않는다는 점이 뒷목을 잡게 만든다). Numpy 함수도 제대로 활용을 못해놨길래, 나도 Numpy 잘 못쓰지만 대충 이런 함수가 아마 있겠지... 하고 검색해서 찾아내서 교체하고 이런걸 반복했다.
이것저것 고친 다음에 잘돌아가나 한번 실행을 해봤는데, 이럴수가. 시뮬레이션이 1000배 빨라졌다. 아니 뭐, 한 2배 3배 빨라졌으면 내 솜씨라고 자부할텐데, 1000배 빨라진거는 그냥 원래 코드가 똥통이었다고 해석할수 밖에 없다. 구라안치고 정말 1000배다. 1000배의 성능향상의 보답으로 나는 교촌치킨웨지콤보세트를 현장에서 받아먹었다.
그 이후에 어떤 일이 있었냐. 기존 시뮬레이션 코드로는 하루에 시뮬레이션을 2, 3번정도밖에 돌리지 못했는데, 1000배 빨라지고 나니까 결과가 수십초만에 나오니 하루에 수백번 돌릴수 있게 된것이다(내가 고친 코드가 전부는 아니어서 1000배 향상은 아닌데, 가장 큰 병목이긴 해서 결국 100배 이상이라는 듯). 그때부터 100배 많아진 데이터를 처리하기 위한 인프라가 필요해졌다. 그래서 거기 개발팀이 데이터베이스와 데이터 파이프라인 구축을 시작하게 되었다고 한다. 그 팀에서는 일종의 특이점이 시작된것이다;;
결론: 교촌치킨웨지콤보 세트는 개맛있었다.
바이브 코딩에 줄곧 Claude Sonnet 3.7만 쓰다가, 오늘 Gemini 2.5 Pro를 써 봤는데, 코딩을 더 잘 하는지는 잘 모르겠지만 응답 속도 하나만은 훨씬 빨라서 좋다. 바이브 코딩을 하다가 결국 답답함을 못 참고 내가 직접 코딩하게 되는 까닭 중 하나가 기다림의 지루함이었는데, 그 부분이 많이 완화된달까?
@hongminhee洪 民憙 (Hong Minhee) Sonnet Thinking이 아닌데도 Gemini가 더 빠른가요?
Cursor가 안켜지는 문제가 있어서(;;) Windsurf로 바꾼지 한달째인데, 얘는 일반적인 질문을 해도 구분을 못하고 레포를 검색해서 답하려고 한다. 예컨데 '파이썬 3와 2의 차이가 뭐야?' 이런 질문을 해도 답변을 하기위해 하스켈 레포를 뒤진다음에 뭔 해괴한 대답을 지어내서 한다. 그래서 질문할땐 앞에 프롬프팅을 따로 해줘야하는데 이게 참 귀찮다. 일전에 AI 에디터 고만고만한데 왜 투자하고 키우려하는지 모르겠다고 했는데, 암튼 지금 당장은 이런 바로 느낄수 있는 차이가 있다.
하스켈 패키지 서버 에러 나서 라이브러리 문서를 못보니까 코딩을 못하네!
@curry박준규 Nix쓰시면 로컬 hoogle 셋업 하시면 되지않아요?
As someone who has developed several #ActivityPub software implementations (Fedify, Hollo, BotKit, and Hackers' Pub), I believe one of the most frustrating features to implement in the #fediverse is #custom_emoji.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:
) as the alt
text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
그나저나 LLM이 의식이 있거나말거나 얘가 방금 cabal의 c코드 빌드 에러를 one shot으로 고쳐줬다. 알아 들을진 모르겠지만 암튼 고맙다 친구야...
RE: https://hackers.pub/@bgl/01964e66-4755-7b53-a82f-fbd362c876ff
@bglbgl gwyng 그런데 사실 스스로 이외에는 사람들도 의식이 있는지 아주 확신할 수는 없죠… ㅋㅋㅋ 사실 사람한테 의식이 없을 수도 있다는 것은 너무 비현실적인 회의일 수도 있지만, 강아지는 어떤가, 새는 어떤가, 벌레는, 버섯은… 같은 식으로 나아가다 보면 LLM한테 의식이 있다고 볼 수도 있는 건가, 싶은 생각도 들긴 합니다. ㅎㅎㅎ
@hongminhee洪 民憙 (Hong Minhee) 사실 그렇긴하죠ㅋㅋ 저는 정확히말하면 확신이 있다기보단 LLM이 의식이 없기를 희망?하는 편인데, 이게 LLM에 딱히 원한이 있어서가 아니라, LLM에 의식이 있으면 뭐 Nginx도 의식이 있다는걸 인정해야한다고 생각해서, 그 사단이 나기 전에 어떤 경계가 있었으면 좋겠습니다.
동료가 ChatGPT랑 사적이고 감정적인 대화도 점점 더 많이 나누고 있다고 한다. 그리고 그런 서비스 만들면 잘될거같다는데(이미 발전된게 꽤 있음). 근데 나는 도저히 저런 대화를 AI랑 못하겠던데 좀 신기하다. 이건 내가 LLM이 의식이 없다고 꽤 강하게 확신해서 그런거 같은데, 의식이 있다고 생각하는 사람들과 (절대 다수의) 그딴거 1도 신경안쓰는 사람들은 잘만 쓸것이다.
@bglbgl gwyng 저는 서브모듈 자주 쓰는 편이라 그런지 이젠 편하긴 한데, 자주 안 쓰면 그럴 것 같긴 해요.
@hongminhee洪 民憙 (Hong Minhee) 그럼 제 문제인거 같군요ㅋㅋ 지금이라도 어떻게든 머리에 넣어봐야겠습니다.
git submodule은 맨날 다시봐도 또 까먹는데 이게 내 문제일까 git submodule의 문제일까...
bgl gwyng shared the below article:
웹 접근성이 UI 설계에 중요한 이유
김무훈 @iamuhun@hackers.pub
웹 접근성의 중요성과 WAI-ARIA 표준을 바탕으로 한 의미론적인 UI를 설계한 사례를 블로그에 공개했습니다.
전문성 검증이 필요한 분야이다 보니, 퇴고 과정에 접근성 전문가 @resistan 님의 도움을 받았습니다.
나
는 이렇게 앨범이 나뉘는거 정말 짜증난다고 생각해...
설정이나 명세를 튜링완전한 언어로 기술하면 안되지 않나, 튜링완전한 언어는 프로그램을 짤때 써야하지 않나란 의견이 있는데, 난 오히려 반대라고 생각한다.
설정/명세를 기술한 코드는 그걸 평가해서 어떤 값을 한번 구하면 끝이고, 임의의 입력에 대해 종료함을 보장할 필요가 없다. 그리고 그 코드의 실행은 서비스 단에서 이루어지는게 아니고, 서비스를 만들고 운영하는 과정에서 이루어지기 때문에 종료되지 않는것에 대해 훨씬 안전하다.
반대로, 실제로 돌아가는 프로그램(말이 좀 이상하지만 excuse부탁드림)이야말로 튜링완전한 언어로 짜면 안된다. 우리가 튜링완전한 언어로 개발하는 이유는 우리가 만드는 프로그램을 기술하는데 필요한 자유도가 얼만큼인지 모르고 작업해야하기 때문에 그렇다. 종료하지않는 엉터리 코드를 짤 가능성을 받아들이면서도, 당장 뭔가 만들긴해야하니까 그런 선택을 하는 것이다.
즉 튜링완전성은 메타프로그래밍을 할때만 허용되는것이 (적어도 이론적으론) 정당하다고 생각한다.
RE: https://hackers.pub/@bgl/019647a2-cd0c-7311-97ce-95b59e5a0696
@bglbgl gwyng 아하, 그렇군요! 인프라 구성을 선언적이지 않은 언어로 작성하는 것에 대한 우려도 조금 드는데, 그런 면에서는 어떤가요?
@hongminhee洪 民憙 (Hong Minhee) Pulumi가 TS로 선언적인 DSL을 만들어 놓았고 그걸 쓰는 식입니다. 대신 범용언어 기반이다보니 그 중간중간 필요한 못된짓을 할수있따는 장점을 취할수 있지요.
@xiniha
@hongminhee洪 民憙 (Hong Minhee) 그렇지요. 하지만 One code to provision them all을 꿈꿨던 (과거의) 저는...
@hongminhee洪 民憙 (Hong Minhee)
@xiniha 지금 빌드까지 Pulumi 스크립트 안에 들어가있는데, 사실 이건 Nix바르면 다시 멀쩡한 설계가 되긴합니다ㅋㅋ
@bglbgl gwyng
@hongminhee洪 民憙 (Hong Minhee) 컼 플루미로 k8s 만지는 것보다는 Helm/Kustomize가 더 정석적 초이스 아니려나요
@xiniha
@hongminhee洪 民憙 (Hong Minhee) 그렇지요. 하지만 One code to provision them all을 꿈꿨던 (과거의) 저는...
@hongminhee洪 民憙 (Hong Minhee) Apache Libcloud는 이번에 처음 봤는데 마음에 드는데요? 클라우드 인프라에서 네트워크랑 VM 인스턴스 등 low level한 자원들만 쓰면서 나머지는 Nix기반으로 프로비저닝하는 방식을 상상했는데(그러면서 더 싼 서비스로 비용최적화), 그런거 만들때 쓰면 좋겠네요.
@hongminhee洪 民憙 (Hong Minhee) 근데 Pulumi는 서로 다른 클라우드 서비스의 자원들간에 어떤 공통된 추상화를 넣진 않습니다. 그냥 같이 쓸수있을 뿐이에요.
@bglbgl gwyng 오… 뭔가 옛날 Apache Libcloud가 떠오르네요. 한 번 살펴보겠습니다.
@hongminhee洪 民憙 (Hong Minhee) Apache Libcloud는 이번에 처음 봤는데 마음에 드는데요? 클라우드 인프라에서 네트워크랑 VM 인스턴스 등 low level한 자원들만 쓰면서 나머지는 Nix기반으로 프로비저닝하는 방식을 상상했는데(그러면서 더 싼 서비스로 비용최적화), 그런거 만들때 쓰면 좋겠네요.
@bglbgl gwyng 잘 모르는데, 홈 서버에서도 쓸만할까요?
@hongminhee洪 民憙 (Hong Minhee) Pulumi 자체는 그냥 인프라용 React같은 거구요. React에 React-DOM이랑 React Native가 있듯이, Pulumi에도 여러 드라이버가 있습니다. 개중에 k8s 드라이버도 있어서 k8s띄운다음에 그위에 TS 코드로 프로비저닝 할수도 있고요. 또 홈서버를 쓰더라도 CDN은 붙이고 싶으실수 있는데 이때 AWS든 CF든 드라이버 깔아서 CDN 붙이면 됩니다. 가장 큰 장점은... 그냥 TS코드로 하다보니 자동완성등 인텔리센스가 최상급이라는 점?
거의 7년 가까이 DevOps에서 손을 뗀 채 지냈더니 이제 DevOps를 어떻게 하는 건지 도통 모르겠다. 처음부터 다시 배워야 하는 상황.
@hongminhee洪 民憙 (Hong Minhee) IaC 위해서 뭔가 새로 배우기 귀찮으시다면 Pulumi 추천드립니다.
Hackers' Pub은 현재 원격 콘텐츠에 포함된 온갖 이미지를 캐시하지 않고 원격 URL 그대로 서빙하고 있는데, 일부 ActivityPub 구현은 계정 프로필 사진이 바뀌면 기존 프로필 사진을 아예 삭제해 버려서 가끔씩 원격 계정의 프로필 사진이 로딩이 안 되고 깨지는 문제가 발생하고 있다. 음… 귀찮아서 캐시를 안 하고 있었는데 역시 캐시를 하긴 해야 하나?
@hongminhee洪 民憙 (Hong Minhee) 우선 엑박 뜨는것만 피해도 보기 좋을거 같습니다.
VS Code였나, 옛날의 Atom이었나 Ctrl+S를 한번 누르면 그냥 저장, 두번 누르면 포맷하도록 설정할수 있었던거 같은데. 또는 Ctrl+S 누르면 soft(?) 포맷, 두번 누르면 hard 포맷도 가능했던거 같다. 이거 편한데 지금은 하는 방법을 모르겠다. 클로드한테 물어보면 직접 키바인딩을 만들라는데 이렇게 안하고도 가능했던거 같은데?
OpenAI가 Windsurf를 30억 달러에 산다는 루머가 있는데, 솔직히 난 잘 이해가 안되서 사람들의 의견이 궁금하다(Cursor는 얼마전에 100억달러로 평가받았다)
어제 출시된 o3가 코딩스타일은 별론데 디버깅을 매우 잘한다고 한다.
위 계정은 HVM 만드는 사람의 것인데, 나는 새 모델이 나올때마다 저 사람이 하는 벤치마크를 체크한다. 사실 구체적으로 뭐하는지는 잘 모르는데,
- 충분히 어려운 과제로 테스트한다는 점
- 진짜로 자기가 할일을 대체할수 있는지 확인할만큼 밀어붙인다는점
- 결과를 세세하게 공유한다는 점
에서 참고할만하다.
아침에 쇼츠넘기다가 Italian Brainrot이란걸 알게됐는데 진짜 뇌가 썩을거같다. 인류의 미래가 어두컴컴하다.
reflex-frp 등 FRP 라이브러리들을 쓰면서 배운점은, fire-and-forget이 유용한 패턴이고 많은 코드를 fire-and-forget 방식으로 짤수있음에도 우리는 평소에 그걸 포착하지 못하고 fire-and-remember(but don't use after?) 방식으로 짜고 있다는 것이다. 그리고 더 중요한건, fire-and-forget를 primitive로 삼기에는 fire-and-forget이 안 통하는 순간에 곤란한 점이 많다는 것이다. 그래서 actor 'framework'란 접근에 대해서는 흐린눈을 하고 보게된다.
지금 JS 멘토링하면서 Promise를 가르치는데 은근슬쩍 모나드도 같이 가르치고 있다(모나드 자체를 언급하진않음). 누구나 마음속에 부리또 하나씩을 품고 살아가니깐...
메시지가 자동으로 번역되는 채팅앱이 있으면 좋겠는데, 아마 디스코드가 곧 지원할거 같다.
여태 모나드 가르칠때 그냥 do notation부터 알려주고 알아서 써보라고했는데 절반정도는 잘 따라왔다.
문법적으로 <-
를 넣어야할 위치만 아는 상태에서도 코드를 웬만큼 짰다.
즉, next token prediction은 휴먼에게도 좋은 학습 방법이다.
RE: https://hackers.pub/@xt/01963d1e-e20c-77c5-a395-69c592137fb3
저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $
를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.
"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."
이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ
(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)
RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf
저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $
를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.
"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."
이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ
(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)
RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf
@bglbgl gwyng
@curry박준규 적은 키워드로 표현 가능한 상황이 더 많다면 "디자인(Design)이 더 잘 되었다"고는 할 수 있다고 봅니다. 언어가 발전한다는게 디자인을 개선한다는 것과 직결되어있지 않은 경우가 더 많으니 말입니다. (많은 경우 표현력의 증대나 자주 사용되는 표현의 단순화에 더 집중하죠)
@ailrunAilrun (UTC-5/-4)
@curry박준규 그래서 do notaion, proc notation 등을 추가하는거랑,
OverloadedDotRecord
같은 문법 확장을 구분해서 보는게 좋다고 생각합니다. 전자의 경우들은 각각 대응하는 Monad, Arrow 등의 개념을 발견하고나서야 추가할수 있었을테고, 후자는 (정확한 역사는 모르겠지만) 그냥 불평불만이 하도 많다보니 땜빵한거에 가깝게 보입니다.
@bglbgl gwyng 이게 생각해보니 ‘문법이 복잡하다’, ‘문법 요소가 적다’라는 표현이 구체적이지 않은 것 같습니다. 갑자기 언어 확장이 떠오르면서 ‘문법 안 복잡한 거 맞나?’ 싶네요. 그래서 표현을 좀 바꾸면 저는 사전에 정의된 키워드가 적을 수록 좋다고 생각합니다.
@curry박준규 더 primitive한 의미론을 포착해서 문법 요소로 만들고 그걸로 다양한 정의를 하게 하는게 낫다는 점에선 동의하는데요. 말씀하신 기준을 그대로 적용해버리면, 모든 언어들이(하스켈도 포함) 발전할수록 점점 키워드가 추가되는데, 그때마다 점점 더 안 좋아졌다고 하면 좀 이상하죠.
@curry박준규
@bglbgl gwyng 저도 예전에 Lisp나 Smalltalk 좋아했을 때는 문법 요소가 최대한 적은 걸 선호했는데, 나이가 드니까 문법 요소를 극도로 줄이는 건 미학의 영역일 뿐 실용적이진 않다는 생각이 들어 Haskell 정도가 딱 적당하다고 느끼게 됐네요.
@hongminhee洪 民憙 (Hong Minhee)
@curry박준규 저도 Lisp을 첨에 봤을땐 감탄했는데요. 지금 보면 그냥 파서짜기 싫었나보다 정도의 생각이 듭니다ㅋㅋ
@bglbgl gwyng 한편 저는 문법 요소가 가능한 적어야 좋다고 생각합니다. 그래서 하스켈을 처음 봤을 때
Bool
이 라이브러리인 게 좋았어요.
data Bool = False | True
@curry박준규 근데 따지고보면 하스켈도 문법 복잡하죠. 각각 다 역할이 있어서 그렇지만요.
하스켈에서 $
가 infix operator가 아니라 문법 요소여야 한다는 얘기에는 동의하는 사람들이 꽤 있다. 근데 1 + $ 2 + 3
도 1 + (2 + 3)
으로 변환되어야 한다고 하면 다들 싫어한다ㅋㅋ 근데 나는 저것도 좋다고 본다.
미드 쇼츠보다가 깨달았는데, 우리나라는 왜 검찰이 임명직일까? 배경이 뭘까? 🤔
@annyeong안녕 혹시 보고계신게 빌리언즈 인가요?
RN에 새 런타임이 옛날거보다 오히려 느리다는 이슈를 제보했는데, 솔직히 좀 황당하다. 그냥 대기업이 오픈 소스 메인테인을 못한다...는 아니다. 난 단순히 잡버그/미구현기능 많은거는 망치가 부족한가보다 정도로 이해한다.
근데 요 이슈는 RN 메인테이너 쪽에서 지난 1+년간 새 런타임으로의 마이그레이션을 적극적으로 권유했는데, 이런 기본적인 문제가 파악안되고 있었던거면 흠... 저 정도 규모의 프로젝트를 운영하는게 어떤지 잘 몰라서 뭔가 더이상 말을 얹기는 어렵겠지만, 쨋든 설명이 더 필요하다 느낀다.