C++ 에 대한 회의 ~(-_-)~

Posted at 2010/06/17 19:14// Posted in freetalk
IronPython 을 보고 난 다음 c# 과 .net framework 에 푹 빠져버렸습니다~

리눅스랑 iMAC 에서 거짓말처럼 잘 돌아가더라구요 >ㅁ<)~
http://www.mono-project.com/Main_Page

아직 돌려보지는 않았지만 iPod Touch 랑 iPhone 도 지원한다고 하고
http://monotouch.net/

올해 8월쯤이면 안드로이드까지!! 두둥!
http://androidcommunity.com/novel-monoc-is-developing-monodroid-20100217/




최근 들어 C++ 에 대한 회의가 들고 있었거든요...

boost 활용의 절정이라 할 수 있는 libtorrent 의 난감한 코드라던지...;
STL 썼을때 libcmt,lib 링크 에러라던지, 바이너리 레벨 호환이 안되는 문제라던지...;
다른 언어와의 연동시 c 언어에 비해 매우 불편하다는 점이라던지..; ( C++ - C# 연동은 최악이더군요 ㄱ- )
언제든지 방심할 수 없는 메모리 릭, 크래쉬 ...;
지저분한 인터페이스...;
느린 컴파일 속도...;
쓸데없이 커다란 용량..;


boost 나 차기 c++ 표준이 추구하는 방향은 훌륭해보입니다만;
저수준 언어와 고수준 언어의 사이에서 태어난 c++ 이 가진 근본적인 모순점을 벗어나기에는 힘들어보입니다.

하드웨어와 운영체제를 담당하는 분야는 c언어같은 저수준 언어로 작성하고
컨텐츠는 스크립트 언어나 Java, c# 같은 언어로 작성하는 것이 훨씬 깔끔하죠 ~(-_-)~

컨텐츠를 작성하다 실수로 저수준 영역을 건들여 오작동이나 크래쉬를 만들어내는
과도기 언어 C++ 은 이제 역사의 뒤안길로 사라질 때가 되었다고 생각합니다.
( 물론 완전히 사라지기보다는 c 언어 보조 역할 정도 하게 되지 않을까 싶내요~ )


모든 컨텐츠가 스크립트 언어(JavaScript, PHP, ASP, Python, Ruby, ...)로 작성될리는 없을 것이고
속도나 보안을 요구하는 프로그램은 컴파일러 언어(JAVA, C#, VisualBasic, ...)가 사용될텐데,
JAVA 보다는 C# 쪽이 좀더 가능성이 있어보입니다~

거의 대부분이 플랫폼에서 실행된다는 점은 JAVA 와 C# 이 비슷하지만
가장 큰 시장을 갖고 있는 MS 의 전폭적인 지원이 있는데다,
다양한 언어를 사용할 수 있어서 이미 구축된 코드풀을 사용할 수 있다는 점도 매력입니다.

유일한 단점이 MS 외의 시장에서 거의 사용이 안된다는 점이었는데,
모노 프로젝트로 인해 거의 희석되어 버렸다는 것이 큰 호재로 작용하고 있는 것 같습니다.



ps.
요즘 C# 과 닷넷 프레임워크도 공부하고
게임 엔진 트렌드도 익힐 겸해서

nebula3 포팅중입니다 ♡

http://dev.naver.com/projects/nebula3dotnet/

닷넷 프레임워크에서 지원하는게 많아서 의외로 쉽게 되네요~ ㅎㅎ

IronPython 연동도 해봤는데... 오오 -ㅅ-; 빌드만 한번 더 해주면 끝이네요~
이올린에 북마크하기(0) 이올린에 추천하기(0)
2010/06/17 19:14 2010/06/17 19:14
Tag , , , , ,
코멘트 (2) // 관련글 (0)

점점 단단해져가는 소프트웨어

Posted at 2010/06/09 14:41// Posted in freetalk
이야기 1.

얼마전에 회사 동료분과 이야기하다가 재밌는 이야기를 들었습니다.

그 분은 이전에 전화 교환기 업체에 일을 하셨었는데,
 
그쪽에서 사용되는 소프트웨어는 거의 버전업을 하지 않는다라는 것이었습니다.

왜 그런가 물었더니 새로운 제품의 메뉴얼만 믿고 투입했다가는 무슨 일이 일어날지 모르기 때문이라고 하더군요.

엄청난 테스트를 통해 사용방법을 익히고 직접 메뉴얼을 만들어야 쓸 수 있기 때문에
특별한 이상이 없는 경우 기존 제품을 선호한다고 합니다.




이야기 2.

요즘 와이프가 플래쉬를 익히고 있는 중입니다.

와이프도 도와줄겸해서 플래쉬 액션 스크립트도 익혀보고 있는데

오호; 꽤 괜찮더라구요. 프로그래머 입장에서 말이죠.

본격적인 코딩은 안해봤지만, 잘만 짜면 사실 2D 게임을 플래쉬 이외의 것으로 만드는건 의미가 없겠더군요;

마치 그래픽 프로그래밍계의 파이썬!
... 이라고 표현하면 -_-;; 아무도 모를테니...

A란 기능이 원하면 이미 존재!

B란 기능을 써야하면 이미 존재!

오오 -ㅁ-;;

이런 느낌인거죠.

게다가 요즘 엔진계의 화두인 리소스 스트리밍 로딩은 물론

타임라인에 기반한 4차원 프로그래밍까지! -ㅁ-);; ㄷㄷㄷ;

다만 한가지 문제가 있는데...
잘못 작성할 경우 표면상으로만 잘 돌아가는 것처럼 보이지만
쓸데없는 자원 낭비로 매우 느려질 가능성이 높더군요.

성능 문제를 해결하려면 프로그래밍에 대해 잘하는 사람이 필요한데...
안타깝게도 많은 플래쉬 프로그램이 비전공자에 의해 만들어지는 경우가 많은 것 같았습니다.

아마 잡스횽아가 플래쉬를 싫어하는 건 이런 이유가 아닐까 합니다.
아무래도 Objective C 정도 쓸려면 어느정도 전산 지식을 갖추어야 할테니까요.

어쨌든 이번 사례에서 중요한 점은;

그래픽 디자이너들은 액션 스크립트를 하나의 부품으로 생각하고 있다

... 라는 것입니다.

잘하는(?) 프로그래머가 한번 만든 코드를 잘 보관하고 있다가
비슷한 상황이 오면 그대로 가져다가 사용하자!
이런 느낌이더군요.



이야기 3.

언제나 게시판을 뜨겁게 달구어주는

표준 vs 비표준 확장!

OpenGL vs Direct3D

표준 C/C++ 문법 vs 확장 C/C++ 문법

JAVA, Python, ... (가상 머신 코드) vs C/C++, ...(실제 머신 코드)

STL, boost vs 자체 자료구조

SSL 인증서 vs ActiveX 기반 공인 인증서

HTML5 vs Flash, SilverLight, ...



사실 플라톤과 아리스톨 텔레스 이후 수천년간 내려오던 논쟁입니다. 쉽게 말해...


아름다운 이상 vs 현실은 시궁창

... 라는 것이죠.


정답은 언제나 비슷한 것 같습니다.

현 시점은 언제나 실용적인 것이 이기지만
궁극적으로는 이상향으로 가게되더군요.

다만 이상적인 답을 찾는데 시간이 오래걸릴 뿐...;


어쨌든 중요한 것은 이상적으로 갈수록

점점 추상화되기 때문에 점점 안을 들여다봐야 하는 일이 줄어들어간다는 것입니다.




이야기 4.

초창기 게임을 만들때 해야하는 일은

그래픽 화면 모드를 바꾸고, 이미지 파일을 파싱하고 압축을 해제하는 일이었습니다.

요즘은 DirectX 가 화면을 바꾸어주고, zlib, libpng, libjpg 가 이미지 파싱과 압축 해제를 해줍니다.

특별한 문제가 없는 경우 (대개는 문제가 있다하더라도... )

2nd 나 3rd party 라이브러리를 직접 분석해서 수정하는 일은 별로 없습니다.


최근 프로그래밍 트렌드는 실제 기능적인 부분만 저수준 언어로 작성한 다음

java script 나 python 와 같은 스크립트 언어들로 기능들을 연결하는 것입니다.


이런 것을 글루 언어라고 부르죠.





이야기 5.

요즘은 어떤지 모르겠지만 한창 엔진붐이 일던 시기에...

언OO 이나 유OO 엔진은 모든걸 스크립트로 제어 가능하고  

툴도 훌륭하기 때문에 프로그래머 따위 없어도 기획자만으로 개발 가능하다

라는 걸로 게시판이 뜨거웠던 적이 있었습니다.


최근 스크립트 언어와 플래쉬 엔진 도입 붐의 결과는

디자니어와 아티스트가 스크립트로 전체 모양을 만들기는 힘들다

... 였습니다.
스크립트 도입 의의는 어디까지나 프로그래머의 생산성 향상 차원이고

다른 파트가 어느정도 참여가 가능하다는데 있다고 봅니다



마무리.

프로그래머가 밑바닥부터 시작해서 전체를 다 만드는 일은 없어졌지만

전체 시스템을 이해해서

존재하지 않는 저수준 모듈을 규격에 맞게 추가하거나

여러개의 저수준 모듈을 연동해서 컨텐츠를 만드는 일은 늘어나게 된 것이죠.

개인적으로는 지금 상황이 예전보다 더욱 어려워졌다고 봅니다.

 다른 사람의 생각과 룰을 받아드리고 타협점을 찾지 못하면 아무것도 할 수 없게 되었거든요

어쨌든 요점은 프로그래머가 굶어죽을 일은 없다는 이야기입니다 ㅎㅎ
이올린에 북마크하기
2010/06/09 14:41 2010/06/09 14:41
Tag , , , , , , ,
코멘트 (2) // 관련글 (0)

요즘 윈도우 에러 메시지에 대해서

Posted at 2010/06/08 21:00// Posted in freetalk
최근 애플 제품에 푹 빠진 와이프를 위해 iMac 을 장만했습니다 -ㅁ-)!


박스 뜯고~

전원 누르고~


와! 멋지당♡

하지만... 감탄도 잠시...

와이프의 쇼핑이 안된다는 사소한 치명적인 단점으로 인해;

전체 1000GB 중; 100G 만 OS X 몫으로 남기고 윈도우7 을 설치를 했습니다.


전에 쓰던 윈도우가 엄청난 액티브 엑스의 범람에 엄청 느려졌던 사실을 상기해

이번에 윈도우는 Virtual PC 를 샌드 박스 삼아 사용하기로 와이프를 설득했습니다.

로컬 iexplore 링크는 지워버리고 ㅋㅋㅋ (-_-)v

대신 가상 iexplore 링크를 붙여놓았죠. (처음 킬때 좀 느릴꺼야~♡)



그런데 다음날 와이프가 인터넷이 안된다는 겁니다 -ㅁ-);;

구체적인 문자 디버깅 결과 인터넷이 안되는게 아니고

크롬은 작동하니 익스플로러만 안된다는 사실로 귀결되더군요.

무슨 문제인가 하고

퇴근하고 나서 직접 실행해보니 정말 안되더군요!

아래와 같은 에러 메시지와 함께...

Windows XP Mode - Windows Virtual PC
가상 응용 프로그램을 시작할 수 없습니다.

응용 프로그램이 가상 응용 프로그램으로 실행되지 못하게 차단되었습니다.

차단?

바이러스 프로그램 문제인가?

이것 저것 해봤는데 안되더군요.

구글 검색을 해보니 ... 아래와 같은 답변이 있더군요;



문제 해결 진행 방법

1.외국산과 국산 바이러스 체크 프로그램으로 PC 전체 검사를 해주십시오.(최소한 1개씩 2개의 프로그램을 실행해야합니다)

2.Internet Explorer관련 툴바 및 프로그램들을 제거 해주십시오.

3.아래의 사진과 같이 작업해주십시오.
(주절주절.. 한마디로 익스플로러 초기화 )

4.익스플로러 FIX 설치

5.모든 액티브X 제거

따라서 똑같이 해봤는데 안되더군요.

그래서 스크롤해서 내려보니;

먼저 답해주신 내용을 보았을 때 제 문제점을 제대로 이해하지 못하신 것 같습니다. XP Mode는 Win7과는 상관없는, 별도의 설정과 레지스트리를 가진 하나의 OS이고 Win7 상에서 XP Mode에 있는 IE6을 호출함에 있어 Win7에 설치되어 있는 IE8과 기타 툴바 등등이 무슨 상관이 있는지 모르겠습니다.

아무튼 ActiveX를 모두 제거하였음에도 문제는 해결되지 않았습니다.

ㄷㄷㄷㄷ;

선리플 후감사의 중요성이 느껴지더군요;


질문자도 대응 직원의 삽질에 답답했는지

실행시 내뿜는 메시지--"응용 프로그램이 가상 응용 프로그램으로 실행되지 못하게 차단되었습니다"--를 보았을 때 뭔가 레지스트리 설정이나 권한 등과 관련해서 꼬인 것 같은데요...

외국 사이트에서 검색하고 싶은데 메시지가 한국어로 떠서 검색이 불편합니다.

한국 MS에서 저 메시지의 원문 string을 갖고 있을 것 같은데, 이를 알려 주시면 감사하겠습니다.

그냥 원문 메시지 달라고 하는데; 마지막 답변이 ㄷㄷㄷ;;

해당 문제의 경우 추가적인 발생 원인을 확인해봐야 할 것 같습니다.

가능하시다면 1577 - 9700 (내선번호 3번 기술 지원팀)에서 충분한 상담을 통하여 해결 받으시기를 권장해드립니다.
한마디로 모르겠다 ㄱ-


이후 삽질 끝에 찾은 문제의 원인은

Internet Explore (XP Mode) 아이콘을 작업 표시줄에 강제로 옮긴 것 때문이더군요;

Virtual PC 내 익스플로러 아이콘을 시작프로그램에 넣어주는걸로 해결했습니다.



"복잡한 에러 메시지는 아무도 안 읽음" 이라는 조엘 온 소프트웨어 영향인지

요즘에 나오는 윈도우 에러 메시지는 두리뭉실한 에러 메시지로 알려주는데;

  • 응용 프로그램을 제대로 초기화하지 못했습니다(0xc0000135).
  • 응용 프로그램 구성이 잘못되어 응용 프로그램을 시작하지 못했습니다. 응용 프로그램을 다시 설치하면 이 문제가 해결될 수 있습니다.
  • 지정한 프로그램을 호출할 수 없습니다.

    • 게다가 비영어권일때는 의미가 왜곡되기까지해서...; 원인을 찾아내기가 거의 불가능에 가까워지더라구요 T_T);


    하아-_-; 그냥 문제 해결시켜줄 능력없으면

    옛날 처럼 "R920481 에러입니다." 라고 나타내줬으면 좋겠습니다.





    이올린에 북마크하기(0) 이올린에 추천하기(0)
    2010/06/08 21:00 2010/06/08 21:00
    Tag , , ,
    코멘트 (0) // 관련글 (0)

    프레임워크 시장의 춘추 전국시대!

    Posted at 2010/06/05 16:10// Posted in freetalk
    향후 End-User 플랫폼 시장이 PC 에서 Web 으로 옮겨질 것이라는것은 확실합니다.
    다만 어느 프레임워크가 시장을 장악할지는 확실하지 않습니다.


    20세기 말 JAVA 의 탄생으로 시작된 프레임워크 전쟁은
    MS 가 향후 시장의 완벽한 장악(?)을 꿈꾸며 SUN 의 JAVA 를 몰아내고 .net 으로 삽질하는 사이
    Adobe 가 Flash 로 PC 시장을 장악하면서 패자가 되었습니다.
    Flash 로 만들면 어떤 플랫폼이든 돌아간다는 야망은 거의 실현되는 듯 했습니다만...
    최근 iPod, iPhone, iPad 3 콤보를 성공한 Apple 의 방해로 ...;
    프레임워크 전쟁은 다시 원점으로 돌아가 버렸습니다.


    사실 애플이란 단일 회사가 플랫폼 공개 없이 전체 시장의 50% 이상을 차지 하는 것은 힘들지만
    크게 삽질을 하지 않는다면 애플과 기타의 2:8 이나 3:7 정도의 비율로 시장이 형성될것으로 보입니다.

    기타의 비중이 꽤 높아보입니다만,
    그 중심에 있을 안드로이드의 구글이 MS 와 같은 장악력을 추구하는 회사가 아니기 때문에
    플랫폼 시장은 한동안 춘추전국시대같은 혼란기에 돌입할 가능성이 매우 높습니다.

    애플이 "진"나라, 어도브가 "제"나라, 구글이 "초"나라 정도의 위치로
    "천자"라 할 수 있는 표준 HTML5 를 지키면서 시장 주도권 다툼을 해 나가겠죠 : )



    HTML5 와 AJAX 조합의 가벼운 클라이언트가 대부분의 시장을 장악하겠지만,
    고성능을 요구하는 영역까지 침범하기는 어렵습니다. 기술의 발전 속도를 표준이 따라가기는 힘들기 때문이죠.
    또한 End-User 소스가 모두 공개되는 가벼운 클라이언트 특성상 핵심 소스는 서버를 통해서 처리해야하는데
    반응 속도 문제가 생깁니다.


    즉, 리치 클라이언트 시장은 존재 할 수 밖에 없다는 이야기인데,
    안타깝게도 웹 플랫폼 처럼 통일이 되기는 쉽지 않아 보입니다.

    애플: 코코아 프레임워크 + Objective C

    구글+썬: 자바 프레임워크 + JAVA

    어도브: 플렉스 프레임워크 + ActionScript

    마이크로 소프트: 닷넷 프레임워크 + C#

    프로그래머 입장에서는 어느 하나의 프레임워크가 통일해주거나
    한 프레임워크에서 플랫폼 특화 코드를 알아서 생성해주는 방향으로 발전되는 형태가 가장 바람직하죠.
    대부분의 프레임워크가 VM 기반이기 때문에 사실 기술적인 어려움은 없어보입니다.

    하지만 비즈니스적인 어려움이 존재합니다.
    각 업체들은 자기네 플랫폼이 시장을 장악하기를 원하기 때문이죠.

    문제의 핵심은 애플입니다.
    혼자만 VM 이 아닌 플랫폼 특화 코드인데다, 다른 프레임워크를 거부하는 상황입니다.

    물론 마이크로 소프트도 만만치 않습니다.
    닷넷 프레임워크가 널리 쓰이길 원하면 직접 발로 뛰어서 멀티 플랫폼을 지원해야지
    모바일도 윈도우가 장악하기만을 기다리고 있으니...
    PC 시장 죽지 않는다라는 드립이나 하고 있고 -_-;
    한심합니다.


    결국 프로그래머들이 믿을 것은 미들웨어인데...
    이런 점에서 볼때 Unity3D 가 가장 앞서 나가고 있는 것으로 보입니다.
    각종 웹브라우져와 모바일 플랫폼도 지원하고 있습니다.

    단점이라면 메이저 회사도 아니고; 오픈 소스도 아니라 미래가 다소 예상되지 않는다는 점인데....
    향후 재편되는 프로그래밍 환경에 적응 연습하기에는 충분히 가치가 있다고 봅니다.



    이올린에 북마크하기(0) 이올린에 추천하기(0)
    2010/06/05 16:10 2010/06/05 16:10
    Tag , , ,
    코멘트 (0) // 관련글 (1)

    simple is NOT easy

    Posted at 2010/05/14 14:32// Posted in freetalk
    유명 화가의 그림을 보고 있으면
    마치 어린아이 그림 같다라는 생각이 들때가 있습니다.

    작품 수준이 어린아이가 그린 것처럼 유치하다라는 이야기가 아니라

    결과물이 너무 단순하다보니 그냥 아무 생각없이 빨리 그려냈을 거라고 생각하는 것입니다.


    사실 결과물만 비교하면
    70년 동안 그림만 그려온 화가의 그림과
    태어난지 7년만에 처음 그림을 그린 (그것도 1시간 남짓 사이에)
    어린아이의 그림이 별 차이가 없을지 모릅니다.

    하지만 두개의 그림 사이에는 엄청난 차이가 존재합니다.

    바로 그림이 갖는 의미 때문입니다.



    비슷하게 생긴 단순한 그림이라도

    화가의 그림은 현실의 본질을 통찰한 결과물인 반면

    어린아이의 그림은 현실의 겉면만을 보고 생각을 표현한 것이기 때문입니다.



    간단하게 만드는 것은 쉬운 일이 아닙니다.

    간단하니까 빨리 만들 수 있는 것이 아닙니다.

    흰머리가 나도록 많이 생각하고

    불필요한 것을 수없이 잘라내고

    오랜 시간 동안 다듬은 후에 나오는 것이

    바로 단순한 것입니다.





    결론은...

    쉽게 쉽게

    빨리 빨리

    만들라


    ... 는 말이 제일 싫다는...

    ㅎ ㅎ ㅎ

















    이올린에 북마크하기(0) 이올린에 추천하기(0)
    2010/05/14 14:32 2010/05/14 14:32
    Tag , , , , ,
    코멘트 (1) // 관련글 (0)