News 08/03/2023 .02 : reactjs, rust, zig, hiring, nes
"리액트가 날 인질으로 잡고 있어요"
https://emnudge.dev/blog/react-hostage
…말해 뭘할까 싶은데. 🙈
포스팅 자체는 react, hooks 같은 것들의 complexity에 대한 이야기이지만.
오히려 흥미롭게 생각하는 것은, 과거 한국에서 '퍼블리셔'라고 하던 사람들이 어떻게 되었는가 생각해보며, 함께 지금의 '프론트엔드 개발자', 혹은 '앱 개발자', '리액트 개발자', '자바스크립트 개발자'들이 앞으로 어떻게 될지 상상해본다.
대부분의 현재의 저런 테크/키워드들은 완전히 사라질거 같고, 그렇다면 다른 직종으로 우회하거나, 변화된 상황에 맞춰가겠지 싶다.
"헛소리/bullshit 없이 엔지니어링 재능이 있는 사람을 고용하기"
https://jes.al/2023/03/how-to-hire-engineering-talent-without-the-bs/
…뭐 homebrew 만들었지만, binary tree inverse을 화이트보드 코딩하라고 던져 놓고 마음에 안든다고 거절한 인터뷰는 전설이지. ㅎㅎ
사실 안티패턴스럽게, 어떻게 하면 더 나쁜 상황과 못된 사람들인지 자랑하려고 들기만 하는게 문제인거 같아. 그렇게 굴어야만 잘될거라고 전제하는게 보통이지만. (그리고 그 보통이 유익한지는 의심스럽다만)
이 글에서 인터뷰 대상자의 어떤 특성들을 눈여겨 보고, 필요한 것이 무엇인지, true positive을 찾아내는게 중요하다고 잘 설명하는거 같아.
최근 읽은 책은 1998년도에 쓴 책이었었는데, 글쓴이의 깊은 안목에 대해 많이 놀랐었다. 그저 별거 아닌 컴퓨터시스템 체험기 같은 것들을 소재로 삼았지만, 현재 전세계적인 테크, 스타트업, 글로벌화 같은 이슈들을 이미 그때에 그 원인이 무엇이었는지까지 분석해 설명해주고 있었다. …어쩌면 그런 안목을 보여줄 수 있었던 이유는, 이미 나보다 연륜이 당시에 많으셨을거고, 그리고 그보다는 테크기업/시장이 훨씬 오래 되었고, 주주자본주의에 기반하여 동작하는 미국사회였기 때문일거 같아. …물론 지금 시대의 한국도 그 연장이겠지만.
…여하튼, 다시 돌아와서, 저 링크의 이야기처럼 시도라도 하려고 할만큼 성숙해질 수 있을까 싶기도 하다.
"NESFab is a new programming language for creating NES games"
https://pubby.games/nesfab.html
gameboy이나 nes용 toolchain을 만들어서 공개하거나 하는 사람들이 종종 인터넷에 보인다.
어차피 이제는 target system에 대해 빌드가 gcc/clang만으로도 쉽게 할 수 있기는 한 시대이지만.
이게 이상한 괴벽이라고만 하기 어려운게, 게임을 만들기 위해서 필요한 도구들이 컴파일러나 어셈블러 이외에도 스프라이트 그리기 도구나 맵편집기 같은거 등등 많이 필요할테고, 효용면에서도 여전히 작고 창의적인 게임을 만들기에, 그래서 갖고 놀고 즐기기에 나쁘진 않은거 같아.
"zig이 rust보다 빠르고 안전할 수 있는 경우"
https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
사실 이미 c++은 최근의 표준에서 더 그만의 영역을 확고하게 해나가고 있다고 생각한다.
개인적으론, cpp2, cppfront 같은 시도들이 의미있지만, c++ 표준에서 반영되듯이, c++은 자기가 정말로 어떤 특징이 있고, 다른 어떤 언어들과도 차별되는 비대칭적인 장점이 있는지 잘 이해하고 있는거 같아. (물론 그런걸 잘 이해하는 분들이 표준위원회에서 작업들을 하고 계시겠지)
'modern c++' 표준부터, 최근의 c++ 표준스펙들의 추세들은, 사실 함수형프로그래밍 같은 유행(…그것도 한 20~30년 정도 늦어서야 유행을 타는) 트렌드를 어느 정도 반영해주는 척을 하지만, 그보다는 오히려 modern cpu architecture이나 simd 같은 영역, 혹은 caching/predictive-execution 같은 것들을 잘 지원하기 위해서 발전해 온 것 같아. …어차피 90년대부터 stl이 있었었고, 함수형프로그래밍이나 그런게 이제서야 그러는게 '아.. 그래요?' 같은 느낌이었으니.
그리고 그런 기계에 더 적절한 방식으로 내 코드에 반영될 수 있는 기능들은 c언어 표준에서부터 세세하게 많고, 컴파일러가 더 똑똑하게 최적화를 해줄 수 있도록 발전해온거 같다.
…여튼, rust은 그런 '함수형프로그래밍'의 트렌드와 그 의도와 기대를 잘 반영해준거 같아. 컴파일러가 알아서 잘, 안전하고 빠른 코드를 뽑아주도록 하자. 그러면서 사용자는 우아한 수준의 abstraction으로 코드를 작성하도록 해주자. rust특유의 메모리모델 때문에 우아하지 못하고 생각할수도 있겠지만, 충분히 깔끔하고 멋진 코드를 짤 수 있고, 또 그게 컴파일되면 확실히 zero-cost abstraction스러워 보인다.
반면, zig은 명확하게 이해될 수 있는 코드, 그래서 조금은 작성할 때에 우아함에 신경쓰지 말라고 이야기 해준다. 컴파일러와 자기 코드를 읽는 사람(자기자신과 동료 모두)를 고려해서 언어를 만든거 같아: https://ziglang.org/documentation/0.1.1/#zen