어제 깨끗히 닦아주고 오늘 다시 순결한 키보드를 더럽히기 시작함
키보드 워밍업(?)을 위해 여러가지에 대해 잡글을 한번 싸줌
* 프로그래밍 언어
프로그래밍 언에에 흔히 '성능' 찾는 뉴비들이 있는데, 프로그래밍 언어 자체는 너의 영혼과도 같아서 성능을 논할 수가 없는 거밍. 성능을 논하려면 알고리듬이나 최소한 프로그래밍 언어 구현을 대상으로 해야 되는거고, 언어의 구현은 너의 몸뚱아리와 비슷하다 보면 됨. 몸짱 되려면 존나 힘들듯이 구현 제대로 하려면 존나 힘듬거임
과거 단순한 시스템들이 프로그래밍 대상일 때는 언어 구현 하나만 보고 선택을 하곤 했지만, 이제는 그런 간단한 문제들을 해결하는데 밥벌이를 제공하는 경우는 거의 없지. 물론 아직도 제한된 하드웨어를 사용하는 경우 특정 언어 구현에 종속되어서 속도 쥐어짜기를 해야 될 경우는 있겠지만 이런 일감은 이미 자리 꽤찬 생키들이 떨어져 나가기 전에는 잡기도 어렵고 그런 자리를 잡자고 시간과 노력을 투자하는 건 인생의 낭비임
지금은 언어나 구현 자체보다는 종합적 프로그래밍 환경이 중요한 때가 되었다. 라이브러리, 프레임워크, 가상머신, 커뮤니티, 개발환경, 뭐 이런 것들.
* JVM
얼마전에 JVM GC 최적화에 대해 하루 정도 시간을 보냈다. 과거 썬(지금은 오라클) 이 생키들의 GC 알고리듬 설명을 읽어보면 존나 명확하게 이게 왜 말이 되는지 알게 됨. 물론 구현은 쉽지 않겠지만.
JVM은 4갠가 5개 정도의 GC 알고리듬 구현을 제공하는데, 이 중에 서버에서 택할 수 있는건 CMS와 G1GC.
원래는 CMS - concurrent mark and sweep - 이것만 존재했는데, G1GC - garbage first gc - 가 5년 정도 전부터 실험을 거쳐서 현재 최종 서버용 권장 GC 알고리듬 구현이 됨.
니들이 프로그래밍 언어를 선택하는데, 그 언어가 GC가 필요한 언어다, 이러면 꼭 JVM 구현체를 택해라. 동일 알고리듬 다른 언어로 구현된 니 프로그램이 느리다 그러면 그건 십중팔구 GC의 차이로 생기는 문제임.
* 구현체 성능과 GC
개발 대상이 복잡해지고, 메모리를 언제 회수해야 될지 명확하지 않은 것이 요즘의 복잡한 개발 대상임.
흔히 엮이는게, DBMS, Web proxy, Web application server, Client UI(browser) , 네트워크, ... 이런 것들이고 그 일부에 니가 만들 시스템이 존재하는 건데 보통 병목현상은 DB나 네트워크에서 생김. 니 시스템 성능이 빨라야 되는 건 사실인데, 그게 다른 것들에 부하를 걸만큼 빨라지면 안되는게 현대적 프로그래밍이야. 니가 만든게 존나 빨라서 DB에 존나 많이 쿼리를 보낸다고 해봐라.
-> DB 메모리가 존나 필요하게 되거나 스왑을 하게 됨 -> 느려짐 -> 빠른 니 코드가 더 많은 쿼리를 쌓아버림 -> 존나 메모리 더 필요함 -> 메모리 다 소진 할 때까지 반복 -> 세그폴트. 네트워크도 마찬가지.
그래서 GC를 쓰는 언어를 써야 되는 것이 자연스로운 기술의 변화가 되어버림. 그런데 GC에 기반한 언어도 각양각색이야.
니가 파이똥이나 루비똥이나 이런 초보적 GC 알고리듬을 쓰는 언어를 쓴다고 쳐봐. 언어 자체도 인터프리터인데, GC까지 병신임.
* 유행
이 바닦이 유형이 있어. 니가 한번 제대로된 유행에 올라타면 10년은 잘 나가게 됨. 최근 트렌드는 functional, immutable 이런거임. 이게 처음에는 함수형 언어로 시작했는데, 그 이후로 immutable DB - 기존 DB에 update와 delete가 없다고 보면 됨, immutable container image - docker, ... 이런거 까지 확장 되고 있는 추세임.
이런 변화는 어쩔 수 없다. 얼마 전까지는 OOP 였지만, 이거 이미 20년 정도 해처먹고 난 생키들이 여러가지 문제점들도 알게되었고, 계속 돈 많이 받는 자리 유지하려면 이제 새로운 걸 제시하고 계속 돈 많이 받아 내야 할 때가 됨.
니가 그런 새로운 걸 제시하는 생키가 아니라면 항상 주위를 잘 살피고 주시하다가 그런 움직임이 보이면 잽싸게 새로운 걸 습득하고 올라타라. 가끔 갤에 파이똥, 루비똥 이런거 쳐들고 오는 생키들 있는데 그런 건 이미 단물 다 빨렸고, 니가 지금 시작해서 이미 꿰찬 생키들 자리에 올라갈 기회가 0에 가깝다.
요즘 언어 유행은 Clojure, JavaScript(ES6), TypeScript, Go, Scala, 이런 등등인데 이중에 Clojure, Go, Scala 정도가 새로운 자리 꿰찰 수 있고 나머지는 아무리 잘해도 이미 꿰차고 있는 생키들 딱가리임.
이 중에서도 최근 트렌트를 따르려면 함수형 언어를 택해야지, OOP는 이제 주로 딱가리 용이고 새로 시작되는 것들 중 함수형 기술들을 이용하는 일을 하는 게 니가 좋은 자리를 꿰찰 기회가 많다.
* 현대적 언어 선택 알고리듬
1. GC가 되는 언어를 택해라
2. JVM 에서 되는 언어를 택해라
3. OOP 보다는 홤수형, mutable 보다는 immutable
끗
3 줄 읽고 아래로 스크롤
무슨 말을 하려는진 알겠는데, 너 역시도 알고리즘을 논할 때 성능을 떼곤 이야기 하지 않잖아. 내가 보기엔 요즘 애들은 성능에 너무 무관심해 문제.
성능이 빨라진다면 당연히 더 멋진 스케쥴링이나 부가서비스를 도입할 수 있는 여지도 생기지. 물론 충분한데 더 뺄 필욘 없겠지만, 재사용성을 생각한다면 다른 플랫폼에 이식하지 마란 법이 없고, 스토리지 속도도 빨라지는 추세 아닌가?
바닦 <- 오타.
난 한번도 유행을 쫓질 않았더니 유행에 끌려가질 않더라. immutable 에 대해선 동의.
프갤 현자들... 아꼬서?
코세/니 말도 이해는 함. 알고리듬에는 성능이 필요한게 대부분인데 왜냐하면 문제 자체가 존나 어렵고 풀려면 컴퓨터로도 느리기 때문이지. 스토리지가 아무리 빨라져도 병목현상은 역시 IO에 있고 필요이상으로 빨라지려면 불필요하게 복잡도가 높아질 수 있다고 봄. 니가 못미더운 라이브러리 이런걸 다 손수 만든다면 이야기는 달라질 수 있지만, 그것은 니 문제에 대한 최적화가 되기 때문에 스케일에서 불리한 경우가 대부분 이라고 본다. 현실은 우리는 걍 우리가 맡은 일을 빨리 잘 하는거지
내가 보는 미래는, 맡은 일을 처리하는게 아니라, 일을 만드는거라.
추상도가 높으면 범용적이겠지만, 당장 유용하지 않고, 당장 유용한건 재사용성이 떨어지고, 그게 딜레마지.
최적화를 특정 시스템 종속적으로 접근하는건 오랜 시간이 걸리고 답이 없어 보이는 문제이지만, 그런 경험들이 사물과 시스템을 이해하는데 도움이 된다.
트랜드를 탈 생각하지 말고 트랜드를 넘을 생각을 하라는거지. 그러기 위해서 필요한건 통섭밖에 없고, 부단한 삽질이 필요하다.
ㄴ 일을 만들어도 마찬가지. 니가 DB를 쓰면 거기가 병목현상이 일어날 거고, 니가 네트워크를 쓰면 거기가 병목이 일어날 거고, 이가 파일 I/O를 하면 거기가 병목이 일어날 거다. 난 돈 받고 하는 일은 실험적인 것은 거의 안쓰기 때문에 빠르고 정확하게 끝내지. 만일 내가 하고 싶은 일을 하게 되면 실험적인 것들을 해서 위험이 커지게 됨. 위험을 줄이려면 기존 라이브러리 등을 당연히 가져다 쓰고 실험적인 것은 최대한 한곳에 집중시키는 게 나의 전략인디?
빨리 성장하는 손쉬운 언어는 빨리 도태된다. 그것 또한 딜레마지. 현상만 놓고 논할 순 없지만 말야.
병목이 일어났다는걸 아는게 중요하고, 알았을 때 해결책을 갖고 있는게 중요한거지.
코세/니 말도 일리는 있다만, 나는 미래에는 1% 현재에는 99% 비중을 두는 주의라
MBTI 뭐 나오니?
ESTJ?
안해봐서 모름. 인생의 낭비는 디시질로 족해 ㅎㅎ
3분이면 되는데
사람을 이해하지 못하면서 일을 만들기란 쉽지 않지.
나의 프로그래밍 철학: 제일 느린 병목보다 한 걸음만 빠르게 하자 ... 뭐 실제로는 제일 빠른 병목이 되겠 지만, 최소한 저런 생각이라고나 할까? ㅎㅎ
그게 꾸준히 반복되면 건강한 사이클이지.
하지만 그게 우수한 땔감 마인드라고 보는거.
이래도 땔감 저래도 땔감 이라면 많이 받는 땔감이 되어라 - 빌게이츠
코세덕에 순결한 키도드 워밍업 잘 함 ㅎㅎ
내가 약간 엘리트주의인지도.
뛰어난 프레임웍 사용자와 뛰어난 프레임웍 제작자가 되는 법은 완전히 상대방의 관점에서 생각해 보는거야.
사용자로 살지 말고 제작자의 입장에서 사물을 대하길 바람.
ㄴ 난 내가 만든 프뤠임워크만 신뢰하지 나머지는 철저히 사용자로 남길 원함. 맘에 안드는 딴 생키가 만들어 논거 손대기 시작하면 헬게이트 오픈이지. 구글이 있으니까 삽질은 최소로 할 수 있지만. 여튼, 누가 돈 대면 프레임워크도 만들어 줄 수 있지만, 그런 건 돈이 안되는게 대부분이라 ㅎㅎ
그 이야기가 아님.
넘으란거지 하나씩.
바퀴를 리뉴얼 하란 소리.
니가 만든 자동차가 도로 위가 아닌 늪이나 진창, 얼음밭 위를 달리게 하고 싶으면 스크류드라이버 시스템을 만들란거야. 도로 위는 어차피 레드오션이니까.
얌마 해야되면 하는거지, 할수있는데 안하는 것과 하고싶은데 못하는 것과는 다르지. 제대로 돈받고 하는 일은 뭐든 거의 다 해주거든요. 하지만, 그런 일에는 실험적인 건 포함 안시키지 (돈받는 거니까 안전빵으로 가려고), 돈이 안되기 때문에 하고 싶은데 못하는 건 있지 121.44.*.*
그래서 니가 열심히 클로져 굴려서 네가 생각하는 연봉상승률로 나이 50까지 저축할 수 있는 돈이 얼만데?
내가 보기엔 니가 하는 일이 먹고 살기 위한 일이지 돈이 되는 일은 아님.
지금 우리 닷넷이 무시했음?
먹고 사는 일이 불필요하다는게 아냐. 지금가지 이야기 한게 그거임. 하나씩 뛰어 넘으라고. 고여있으면 망함.
지금까지.
@관노 5V 와 3.8V 이야기는 전위차로 전류 생성하는 이슈랑 좀 무관해 보임. 어차피 5V 2.1A 처럼 충전기의 출력을 이야기할땐, 바깥에서 전위차가 만들어져 있다는 이야기.
얌마 돈이 중요하지만 현재를 즐길수 있을 때 즐기는 것도 중요하지. 준비는 되었고 기회가 오면 돈이야 더 될수 있는거고. 남은 문제는 운빯ㅎ
돈 이야긴 니가 꺼낸거얌마.