간만에 정말 재미있는 글... 배울 점이 많습니다.

c++ 모듈과 연동할 일이 생겨서 이리저리 검색하다가 뜻밖에 재미있는 글을 발견했습니다…

2013년도 어떤 사이트의 질문과 그 댓글이고요.

문제의 발단은 누군가의 c++과 c#의 자료구조에 대한 질문인데, 그 댓글들에서 많은 것을 느낍니다.

시간 나실때 재미삼아 한번 주욱 읽어보시길 추천드립니다.

http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&page=1&sn1=&divpage=2&sn=off&ss=on&sc=on&select_arrange=last_comment&desc=desc&no=2652

좋아요 6

몇년이 흐른 뒤에도 성지순례를 가는 분이 계시네요…ㅎㅎㅎ

좋아요 3

허허 별 생각없이 열었다가 시간을 엄청 빨아먹는군요 T_T

아니 그냥 추가/삭제가 빠른 모델하고 조회가 빠른 모델하고의 장단점만 알았어도…

좋아요 5

링크 열어 보고 댓글 대충 보는데
진짜 시간 순삭이네요ㅎㅎ

좋아요 5

전…아직 이 글을 처음보는걸로 봐선 아직 C#의 퍼포먼스에 관해 검색을 덜했나봅니다…ㅎㅎ

토론 댓글이 너무 길어져서 혹시 라도 이 글을 보고 저 링크에 들어가서 글을 보실 분들께 가이드 차원에서 남깁니다.

댓글을 보다보면, 뿌요뿌요, n…2, smileeagle 이렇게 세분이서 주축으로 토론이 되고 있으며, 주로 뿌요뿌요님의 말에는 n…2이 분이 동조를 해주시고 smileeagle님의 말은 많은 분들이 동조를 해주고 계시네요 (언어적 차원보다는 개발일도 회사의 일이라는 차원에서)

따라서 글의 토론 '내용’을 보시는 분들은 저 세분의 글만 따로 검색해서 보시면 될 것 같으며 나머지 댓글은 주로,

또 부활했다, 성지순례다 등등의 글입니다. (의미없다는 뜻)


또 하나 느낀 건 역시 C++쪽에는 언어적 특성으로 코어한 곳이라 그런가 실력 좋은 고인물들이 계시네요.

다들 C# C#하면 '생산성’이 반드시 대두되는 문제인데, 사실 생산성도 객체지향 같은 개발 패턴을 정해두지 않고 절차 지향식으로 생각의 흐름대로 짜면 일단 돌기야 하겠지만 개판인 코드일거라는 생각입니다.

따라서 일단 프로그램이 동작 가능하게 끔 코드를 빨리 짤 수 있다는 문법을 넣어주고 로직에 집중하게 만들어준 만큼, 오히려 저는 프로젝트 초반의 빨리 짜기만 하는 스피드보다는 유지보수 중점의 패러다임에 중점을 놓고, 프로세스의 스피드보다는 함께 일하는 팀원들이 유지보수할 때 팀원의 소중한 시간을 줄여줄 수 있는 코드를 작성 하도록 하는 관점이 중요하다고 생각합니다.

저는…C++은 해본 적도 없고, C#으로 저 토론에 나오시는 분들처럼 대단한 개발을 해본적은 없지만 제가 쌓아오면서 C#으로 느낀 건 이것입니다.


그리고 토론 글의 저자이신 뿌요뿌요님은 토론글에도 나오지만 아래 링크처럼 결론을 내리셨다고하니 2탄으로 보셔도 될 것 같습니다.

Modern C++ 과 C# 이젠 확실히 말할수 있네요 (gamecodi.com)

결국 왜 MS에서 Dictionary에 키가 아닌 노드 자체로 지우는 방법을 끝까지 넣어주지 않았는지는 의견인 분분한 채로 결론이 안났네요. (이쯤되면 MS에서 등판해서 해결해주면 좋…)


정리는 잘 안되었지만, 이 세상에 고수는 참 많다는 점을 느낄 수 있는 글이 었습니다.

재미있게 잘 봤습니다.

공유 감사드립니다.

좋아요 3

왜… 우리 회사에선 링크가 안열리는거니!!! 'game’이란 단어 때문이니!! ㅠ

퇴근길에 읽어보겠습니다!

좋아요 5

깔끔한 정리 감사합니다.
제가 @Vincent 님처럼 간략한 설명을 곁들일까 고민을 하다가 그냥 재미있는 글이라고, 쭈욱 다 읽어보시라고 한 이유는
기술적인 부분에 대한 것도 있겠지만, 질문을 하는 자세, 토론을 하는 자세, 세상엔 나보다 잘난 이가 참 많다… 등등등…
이런 감정적인 부분들까지도 많은 것을 느끼게 해주는 좋은 글 같아서 공유하게 됐습니다^^

그리고 (이쯤되면 MS에서 등판해서 해결해주면 좋…) 이 부분에서 빵 터졌네요…ㅋㅋ
짐작컨대, smileeagle이라는 분의 말씀대로 아마 ‘가능은 하지만’ 위험한 장난감이기에.
그리고 관리되는 코드에 대해 닷넷에서는 명확한 기준이 있어서 그런게 아닌가 싶어요…

좋아요 5

네 저도 웬만하면 글에는 맥락이라는 게 있으니 그냥 쭉 정독하는게 좋을 것 같습니다. (우리 개발자들…Context라는 단어 … 참 좋아하잖아요?)

다만 내용만 쏙쏙 하고 싶으신 분들도 계실꺼라 정리차원에서 ㅎㅎ

얼마 전에 저도 사실 느꼈던 부분인데…저도 잘은 못해도 개발자라는 짬을 먹고 있어서 그런가 일반 사람들하고 대화할 때 좀 힘든 면이 있습니다.
저 역시도 토론할 때 내용이 아무리 좋더라도 접근성이 좋도록 문맥을 정리하고 어투를 좋게하는 게 반드시 필요할 것 같고… 오히려 개발자이기 때문에 내용은 당연히 기본이고, 이런 부분에 대해서 신경을 많이 써야 하지 않을까 생각합니다…반성하게 됩니다 ㅠ

좋아요 3

처음엔 아무 생각없이 댓글 4~5개 읽다가 40~50개를 읽게 되는 글이죠…ㅎㅎㅎ

좋아요 3

다른 의미의 스노우볼 효과가 느껴지네요…

얼마전에 dictionary 코드 봤을때 엘리먼트 개수나 해시 충돌 횟수에 따라 동적으로 버킷 개수를 늘려주던데 그래서 O(1)에 수렴하는게 아닌가라는 생각이 불현듯 드네요.

좋아요 3

아… 그러겠네요… 저도 잘 몰랐는데 저번에 써주신 글 보고 많은걸 깨달았습니다!
감사합니다 :grinning:

좋아요 3