Testors.Net

* 구글 툴바는 IE 나 파폭의 점유율을 낮추기 위한 음모임이 틀림 없어. 요새 IE 다운버그의 거의 대부분은 모두 구글 툴바가 일으키고 있거든. 그 증거로 정작 자기들 브라우저인 크롬에는 구글 툴바가 없단 말이지...!

* P-CAMP&대안언어축제에서 실시간 문서화 도구로 구글 Sites 를 이용하고 있었는데 마지막날에 갑자기 구글로부터 블럭되는 사태가 발생. 봇탱이가 블럭한거라면 이유라도 찍어줘야 하는거 아니겠슴미? 구글 캘린더에서 관리하던 팀 스케쥴이 통채로 날아간 사태도 있었고... 그때도 그랬지만 아마 이번에도 문의 메일을 날려봤자 1주일쯤 지나서야 답장이 날아올 거란 말이지. 구글은 아무리 생각해도 개발사지 서비스사는 아닌것 같아. 이래서 Google Apps 같은걸 기업에서 쓰면 안되는 거라니깐....

http://gpgstudy.com/forum/viewtopic.php?t=21219

에서 이어짐.

그러니까 C/C++ 에서 comma 연산자는 expression 에서 등장했을때 대략 세가지 (혹은 그이상의) 의미를 지닌다.

1. 두 expression 를 묶어서 하나의 expression 으로 만든다.
2. argument 의 구분자로 쓰인다.
3. operator overloading 으로 1도, 2도 아닌 무언가 다른 동작을 만들 수 있다.

결국 comma 가 코드에 등장했을때 그게 정확히 무슨일을 할지 그 코드만 봐서는 쉽게 알수 없다. 따지고 보면 1 과 2 는 모호하다. 이를테면 아래 코드에서

위 코드는 func 에 1과 2 두개의 argument 를 던지는 코드일수도 있지만 1,2 를 comma 를 이용한 하나의 expression 으로 본다면 func( 2 ) 로 해석될 수도 있다. 이런걸 방지하려면 규칙에 예외를 추가해야 된다.

난 이런걸 별로 좋아하지 않는다. 내친김에 다른 언어들의 경우도 살펴보자.


참고로 난 루비를 가장 좋아한다. python, perl 은 학습 도중에 짜증이 솟구쳤었는데 ruby 는 모든것이 직관과 의도대로 동작했기 때문에 아무것도 학습할 필요가 없었기 때문이다.

서광열님의 블로그를 보다가 문득 OCaml 을 들여다 봐야 겠다는 생각이 들었다.


왜냐하먄 나는 "C++, Java, C# 처럼 어설픈 정적 타이핑하는 언어를 보던 사람" 이고 때문에 Ruby 의 동적 타이핑이 굉장한 장점으로 느껴지기 때문이다. 해서 '제대로 된 정적 타이핑을 하는 언어' 를 배워보기로 마음먹었는데 그중 OCaml 이 가장 매력적으로 보였다.

Ruby 의 경우는 '배워야겠다' 라고 마음먹은 순간 이미 더이상 배울게 없는 아주 신선한 경험을 했었는데 OCaml 은 어떨런지 모르겠다. 그러고 보니 Ruby 로 이것저것 하기 시작한 뒤로 C++ 로 뭔가를 만든다는 것 - 사고를 코드로 기술한다는것 - 이 미칠듯이 고통스럽다. fulltime ruby job 을 원한다는 deepblue 님의 이야기 가 어떤 것인지 약간은 이해가 갈것 같기도..

여튼 혼자 배우면 될것을 거창하게 블로그에 써놓은 이유는 금연을 공개적으로 선포하는 이유와 비슷하다. 혹시 틈나게 되면 OCaml 의 신선한 특징들을 요약해서 올려볼까 한다.

관련한 몇가지 읽을거리들 :
* C++ vs OCaml: Ray tracer comparison
* 명시적 정적 타이핑(typing)의 종말
* OCaml Tutorial (한글) 

3년 넘게 써온것 같은데...
자주 다운되는 버그는 제외하고, 아래와 같은 문제점들이 있다.


참고로 현재 버전은 Version 7.5.0.2672 이다.

총평을 하자면...
 
그래픽/기획 리소스 관리에는 별로 대안이 없는것이 사실이나
솔직히 소스코드 관리 하기에는 multi-checkout 상황에서의 merge 기능 빼고는 돈주고 쓸만한 물건은 아닌것 같다.

Goose 는 duck typing 의 duck 에서 따왔다. C++ 위에서 duck typing 을 구현해 행위 기반 다형성을 이루는 것을 목표로 하고 있다. 물론 referece counting 역시 지원한다. Duck 이 아니라 Goose 인 이유는 결국은 duck 이 되지 못할 것이라는 일종의 비관이 담겨 있기도 하다.

프로젝트 시작하던날 술기운에 약 700여줄의 코드를 작성했는데 그 결과 현재 C++ 위에서 뭔가 java 와 ruby 가 뒤섞인듯한 아래와 같은 문법을 지원한다.

결과는 아래와 같다.



루비에서 많은 부분을 따 왔다. printf() 포메팅 사용시 to_xxx() 를 사용해야 하는 불편함은 4바이트 타입 및 문자열의 경우 해결될 수 있겠지만 과연 그래야 하는지는 의문이다.

static binding 으로부터 벗어나야하기에 메세징을 채용했는데 그 동작은 Objective-C 의 것과 유사해질듯 싶다. 객체가 처리하지 않는 메세지를 받을 경우 Objective-C 처럼 그냥 조용히 침묵해줄 예정이다. 대부분 메세지의 결과로 self reference 를 리턴할 것이기 때문에 루비에서 자주 사용했던 아래와 같은 문법들도 사용이 가능할 것이다.



receiver 가 괄호 안에 들어가면 아래와 같이 좀 더 예쁜 모양이 되었을 테지만 C++ 에서는 아래 문법을 지원해낼 방법이 없다.



콤마를 사용해 아규먼트의 체인을 구성하는 것도 방법일것 같은데 한번 시도해볼 가치가 있을것 같다. 여튼 현재 메시징 방식 선택 문제 외에 여러 다른 숫자타입간의 정밀도를 유지하는 부분을 해결 중이며 남은 기술적 이슈들은 다음과 같다.

심볼을 어떻게 해결할 것인지는 아직 별달리 뾰족한 방안이 떠오르지 않는다.

여튼 프로젝트가 성공적으로 완료된다면 게임 개발에 있어서 아이템 인벤토리라던가 스킬 퀵슬롯, 기타등등 성능은 전혀 중요하지 않지만 설계가 밥먹듯이 변경되는 그런 컨텐츠 코딩에 어쩌면 사용될 수도 있을거라고 본다. C++ 로 컨텐츠 프로그래밍을 하면서 컨테이너의 타입을 정의하고 관계를 설정하는 일이 정말 진저리가 났는데 BS 는 TC++PL 에서 클래스를 디자인하고 관계를 설정하고 계층을 고민하는 것이 유익할 것이라고 했지만 그것은 명세가 변하지 않을때의 이야기다. 게임 개발은 명세가 밥먹듯이 변하는 분야다. 물론 C++ 에서 이런 삽질을 하지 않고 스크립트로 뽑아낼 수는 있지만 스크립트 채용으로 인한 마샬링 비용 및 바인딩 역시 번거롭기는 마찬가지다.


* 위 글은 3/14 일에 작성하였던것인데 오늘 발굴해서 공개한다. Goose 는 요새 일이 바빠서 전혀 손을 못대고 있다. -_-;;;

코딩질에 허덕이고 있어 왠지 업무에 도움이 될까 싶기도 하고, 무엇보다 썩어가는 머리를 되살려 보고자 작은 프로젝트를 시작해 보려 한다. 요사이 워낙 여유가 없어 시간을 얼마나 투자할 수 있을지는 모르겠다. 프로젝트 이름은 Goose 인데 이름만으로 어떤 프로젝트인지 간파하는 방문객이 있다면 술을 살 용의가 있다.

http://gpgstudy.com/forum/viewtopic.php?t=18965

C++ 이 얼마나 짜증나는 언어인지를 단적으로 나타내 주는 쓰레드.

boost 에서 제안하는 형식은 그야말로 재앙 수준이다.

저런 코드를 작성하느니 나는 차라리 c++0x 를 기다리련다.

나의 관점에서는 비회원이 처음 제시한 해결책이 현재 C++ 의 수준에 가장 어울린다고 본다.

http://www.oreillymaker.com/ o아저씨가 던져준 O'Reilly Maker 라는 사이트이다.

텍스트 몇줄 긁어넣으면 그럴듯해 보이는 책 표지를 뽑아 준다. 방문할때마다 랜덤한 표지가 나오도록 되어 있는데 내가 접속했을때의 표지는 이것이었다.


텍스트가 누구의 작품인지 모르겠지만 그 센스에 존경을 보낸다. 나도 뭔가 하나 만들어 보려 했으나 저 'Holy Code' 보다 훌륭한 작품은 떠오르지 않아서 포기했다.

바로 얼마 전까지만 해도 이쪽 필드에 '디자인 패턴' 이란것이 열병처럼 번지던 때가 있었다. 내 입장에서 정의를 내리자면 '디자인 패턴' 은 '이름' 일 뿐, 그 이상도 이하도 아니라는 것이다.

요새는 XP 와 Agile 이 화두인것 같은데 그 정신은 훌륭하지만 현상은 분명 과열되었다. 과연 시간이 흐른뒤에 어떤 평가를 내릴 수 있을런지 모르겠다.

부디 모든이에게 미혹을 떨쳐버릴 수 있는 혜안이 함께 하기를...

덧. 웹 2.0이 무엇인지는 아직도 궁금하다. 제발 누군가 명쾌히 설명할 수 있는 분이 있다면 이 포스팅에 리플을 달아 주시라..

Ruby In Steel ( http://www.sapphiresteel.com/ ) 이란 물건이 있다. Visual Studio 를 Ruby IDE 로 쓸 수 있도록 해 준다. 트라이얼을 다운받으면 30일간 사용이 가능하다.

MS 에서는 루비를 .Net 화 하는 IronRuby ( http://www.ironruby.net/ ) 프로젝트를 진행중이다.

두녀석이 짬뽕되니 아래와 같은 환상적인 결과가...!

http://www.sapphiresteel.com/IronRuby-Visual-Designer
http://www.sapphiresteel.com/static/mov ··· n_1.html (동영상)

C# 은 이제 안녕. 루비 만세~~

그래픽 카드를 바꿀때가 되어서 무엇으로 고를까 알아보았는데 이거 원 숫자가 크다고 좋은게 아니고 뒤에 알파벹이 어떻게 붙는가에 따라서 완전 달라진다. 그런데 그게 별로 일관되지 않고 메이커마다 규칙도 완전 달라서 이름만 보고는 도무지 성능을 알아볼 수가 없었다.

이럴때는 늙은이 모드로 전환해서 "비싼게 좋은거다." 라고 간단하게 생각해 버릴수도 있겠지만 안그래도 머리가 썩어가는데 이런곳에서까지 타협하고 싶진 않았다. 어쩐지 2~3년 뒤에도 똑같은 고생을 해야할것 같아 parkoz 의 3DMark DB 와 다나와 가격검색을 메쉬업해 그래픽 카드 비교차트를 생성하는 봇탱이를 만들어 보았다. 데이터는 아래 3개 차트로 구분된다.

• 순수 성능 비교 차트

국내출시/단종 여부에 관계없이 순수히 그래픽 카드의 성능만을 기준으로 만들어진다.

• 가격 대비 성능 차트

국내 출시되어 현재 신품 구입이 가능한 그래픽 카드들 중 가격 대비 성능이 높은 순서대로 만들어 진다.

• 추천 비디오 카드 차트

가격 대비 성능은 좋지만 성능이 지나치게 낮아(평균의 80% 이하) 최근에 구입하긴 무리가 있거나 혹은 성능이 좋다 해도 가격이 너무 높아(평균 가격 이상) 구입하기에 좋지 않은 녀석들은 제외한 리스트이다.

결과를 보니 가격대비 성능이 두배 이상까지 차이가 난다. 역시 "비싼게 좋은거다." 접근법은 최적과는 거리가 멀다. 그런데 별로 진지한 고민 없이 채택한 "평균의 80% 이상의 성능", "평균 가격 이하" 라는 조건이 제법 쓸만한것 같다. VGA 뿐만 아니라 대부분의 아이템들에도 공통적으로 적용될 수 있는 필터가 아닐까 싶다.

본 차트는 1주일에 한번씩 자동 갱신된다.

</

순수 성능 비교 차트

추천 비디오 카드 차트 가격 대비 성능 차트