윈도우즈용 개발툴 비교

geekforum의 이미지

이곳이 리눅스에 주로 관련된 곳이라는 것은 잘 알고 있지만, 개발자들이 많이 오시는 걸로 알고 있습니다. 개발자 분들이시라면 리눅스에서만 개발하시는 분들도 있겠지만 대부분은 윈도우즈 환경에서도 한두번쯤은 개발을 해본 분들이 아마 대부분일 거라 생각합니다.

그래서 말인데요, 윈도우즈용 개발툴들의 장단점을 비교 분석해 보는 것도 괜찮은 이야기거리가 되지 않을까 합니다.

어차피 개발툴이라는 것은 각각의 용도에 맞게 골라서 선택하면 되는 것이고, 중요한건 어떤 툴을 사용하느냐가 아니라 어떤 알고리즘과 설계 구조를 가지고 얼마나 효과적으로 동작하는 프로그램을 얼마나 빠르게 생산할 수 있는가가 관건이라고 봅니다만, 저같이 잘 모르는 사람은 과연 지금 시장에 나와 있는 수많은 툴들이 어떤 용도에 잘 맞는지, 실제로 그 툴을 사용해서 개발을 할 때 어떤 장단점을 가지고 있는지 미리 경험을 해보신 분들의 조언을 들어 보고 참고하는 것이 시행착오를 줄일 수 있는 길이 아닐까 해서 글을 올립니다. 많은 의견 부탁드립니다....

익명 사용자의 이미지

VC++ 나쁘다고.하지마세요~~..
편집기로..왓따임당~~.
특히..임베디드장비개발에선,,
그런 좋은 편집기 구하기도 힘듬니다!!
역시..MS~~..
편집기도...좋슴니다!!
덕분에..일 편하게 하구여~~
ㅡ.ㅡa...
얼른..포팅작업 끝내야지..T.T;

익명 사용자의 이미지

엄청나게 무거운 에디터지요^^;
C++ 빌더 6의 경우 키맵을 VC++로 바꾸면 VC++와 거의 동일한 환경에서 코딩이 가능합니다. 코드 컴플리션 기능도 매우 강력하게 변경되었구요. 사실 VS환경 지원부분은 전에도 있었지만 블럭셀렉트 후 탭키로 인덴테이션 하는 기능같이 자주 쓰이는것인데도 지원이 안되는 부분이 있었습니다. 이 부분이 이번에 보완이 되었다는군요.
아무튼.. 코딩툴로써의 VC++의 잇점도 이제는 많이 퇴색되어가는 느낌입니다.

익명 사용자의 이미지

정말 무거운가요? 제가 느끼기에는 울트라에디터랑 VC++ 6.0의 무거움은 비슷한데.. 아크로에디트보다는 오히려 더 빠른 듯. 뜨는 속도, 파일 로딩 속도, 많은 파일, 큰 파일 편집시 속도 저하 정도 등등 속도 면에서 VC++은 제가 접해본 윈도우용 IDE 중 최고인 것 같습니다. 심지어 대부분의 에디터보다 더 쾌적하게 느낄 정도죠. 제 컴이 펜2 233인데 제 컴에서 VC++ 6.0은 아무런 불편함 없이 돌아갑니다. JBuilder를 쓸 때 무지막지한 짜증을 느끼는 것과는 대조적이죠. C++ Builder는 안 써봐서 모르겠지만 여기 사람들이 좋다고 말하는 걸 보니 한 번 써보고 싶군요. 가격이 얼마나 하나요? -_-

익명 사용자의 이미지

JBuilder와 VC++의 비교는 너무 하셨네요. ^^
아직은 Java로 많은 부분이 짜여져 있는 JBuilder가 VC++의 속도를 따라올 수 없겠죠.
Java로 짜여져 있는 IDE들이 왠만한 Windows 환경에서는 아직은 짜증을 유발하더군요.
Sun의 Forte의 겨우도 Solaris(SPARC)에서는 그래도 쓸만한데, Windows에서는 참기 힘들죠.^^
VC++을 그냥 에디터로 쓰기에는 너무 무겁고, 별다른 이점을 찾을 수 없던데...
저 개인적으로는 Source Insight라는 source 분석 프로그램이 Windows환경에서는 차라리 속도나 기능면에서 최고라고 생각합니다.

익명 사용자의 이미지

JBuilder는 짜증날만하죠..느리니깐요.:)
JBuilder가 자바로 만들어 졌거던요:>

익명 사용자의 이미지

음..저도 한 때는 C++빌더를 사용했습니다.

글을 쭉 읽어보니깐 C++빌더를 사용해보신 분들은
공통적으로 동감하는 부분있는 것 같군요.

한마디로 쉽다는 거죠.

윈도우쪽 C++관련 책을 서점에 한번 찾아 보십시요.
비주얼씨++와 C++빌더 비율이 어떻게 될까요?
아마 몰라도 90%이상이 비주얼씨++가 차지하고 있다고
전 생각합니다다만.

제가 하고싶은 말도 C++빌더 쉽다는 겁니다.

비주얼씨++ 책 10권 볼 것을 씨++빌더 책 한권 보면
된다는 겁니다.

제 착각인지 모르겠습니다만.

익명 사용자의 이미지

쉬운게 어떻다는 거죠?

VCL이 쓰기 쉽다는 것은 그만큼 MFC 보다 API를 class 화 잘했다는겁니다.

그리고 필요하다면 C++빌더에서도 MFC로 프로그램 할수 있구요. VCL이 있기때문에

소스를 가져다 쓰는 경우 빼고는 그런 경험 하고 싶지 않겠지만요. 아시죠? MFC의

깊은 수렁^^;

게다가 C++ 빌더 6 버전에 포함된 VCL의 다른형태 CLX 는 최소한의 소스 수정으로

유닉스에서도 프로그램이 실행될수 있게 합니다. 리눅스에서 돌아가는 프로그램은

BSD, Solaris 에서도 쉽게 돌아가죠.

익명 사용자의 이미지

동감입니다.
MFC 무지 어렵지만 VCL 보다 결코 강력하지도 않습니다.
오히려 VCL 쪽이 여러 장점이 많죠.
MFC를 많이 쓰는 것은 MS에서 만들었다는점이 큽니다.
하지만 성능이야 어차피 둘다 API를 랩해놓은건데 크게 다를게 없죠.

cedar_의 이미지

[참고]Borland C++Builder 6 가 드디어 발표됐습니다!

볼랜드, C++ 윈도우/리눅스 크로스플랫폼 개발툴 C++Builder 6 발표
글쓴이 : 박지훈.임프 (cbuilder) 읽음 : 116 2002-02-06 오전 12:11:54

다운로드 : cbuilder6.gif (2KB)


캘리포니아 스코트밸리, 2002년 2월 5일 - 볼랜드는 오늘 진정한 C++ 비주얼 개발 환경에서 웹서비스를 이용한 e비즈니스 애플리케이션의 고속 개발을 지원하는 볼랜드

익명 사용자의 이미지

windows와 linux의 cross-platform이란건
이번레 release된 c++ builder에서 linux 실행파일을 만들수있다는 소리는아니겠죠?
앞으로 개발될 리눅스용 c++ builder(?)에서 이쪽 소스를 가져가 그대로
compile하면 만들어진다는 뜻인가요?

cedar_의 이미지

예! 정답입니다.
리눅스용 C++빌더는 'Borland C++ Linux'라는 이름으로
2/4분기 중에 출시됩니다.
즉, Borland C++Builder 6와 Borland C++ Linux와의 관계는
델파이6와 카일릭스2의 관계와 같습니다.
C++Builder 6가 델파이6처럼
CLX(Component Library for Cross-Platform)을 탑재했다는 얘기지요.

하여튼 Borland C++ Linux가 빨리 나와서, 리눅에서도
gcc, make의 불편한 환경에서 벗어나, 진정한 IDE와 RAD개발을 했으면 좋겠습니다.

익명 사용자의 이미지

음.... 불란서 사람이 공개한 LCC 는 개발툴로서의 가치가 어느정돈가요?
굉장히 심플하던데....
간단한 GUI툴도 있구...

제가 잘 몰라서 여쭈어 봅니다.
상용 제품을 만들어 내는걸 위한게 아니라, 쓸만한 윈도우용 어플리케이션 만들어 내는데 유용한 것인가요?

만일 그렇다면 굳이 상용 윈도우 개발툴을 고집할 필요는 없지 않을까 하는 생각이 불현듯. 드네요...

그러니깐, 화공과 실험실 같은데서 윈도우 가지고 메인 플랜트 콘트롤러 따위로 쓰는 정도 말입니다.

이런 경우라도 굳이 VC 나 C++ 빌더 등을 써야 할까요?
(이것들은 정품 패키지 가격이 100만원 이상이니깐요)

익명 사용자의 이미지

LCC는 C 에 윈도우용 API 기반인데요, .. 나름대로 마법사 기능을 지원하고 있긴 하지만, 순수 API로 짜여진거라 .. 저같은 초보는 쓰기가 좀 힘들더군요 .

.. Devcpp 도 쓸만하죠.

문제는 도큐먼트가 영어로 되어있고-_-; 자료 구하기가 그렇게 쉽지 않다는 점이 ..

tcler의 이미지

전 mingw(gcc의 윈버전)를 사용하는데 개인적으로 필요한 프로그램을 작성하는데는 전혀 불편함이 없습니다.
( 주로 하는일이 무선통신에 관계된 시뮬레이션 프로그램인데 mingw를 이용해서 시뮬레이션 처리 루틴을 만들고 tcl/tk(mingw용)를 이용해서 gui를 만들고 에디터는 meadow(emacs의 윈도우 버전), 디버거는 insight)

이정도 프로그램은 괜히 비싸게 돈주고 컴파일러를 살 필요가 없다고 봅니다.

익명 사용자의 이미지

잠깐 쉬는 의미에서 진정한 슈퍼 프로그래밍 그루의 모습은......? ^^

c:\>copy con program.exe

익명 사용자의 이미지

하하하

10년 전에 그런 식으로 몇글자 써넣었더니 재부팅이 되는 프로그램이 되더군요 -_-;;

MZ로 시작해서 특수글자 몇개 썼더니... ;

익명 사용자의 이미지

어떠한 컴파일러든지 우월한건 없다고 봅니다...

자신의 프로그래밍의 목적/목표와 자신만의 개발 스타일, 경향, 자신만의 노하우 등...

무슨 컴파일러든지 자기에 맞는게 따로 있다고 봅니다.. (횡설수설인가. . ㅡ,.ㅡ)

위에서 말한 C++ builder, visual C++, delphi, pascal, gcc..... 모두 훌륭합니다...

그런데, 글 목록을 아래로 내려오면서 처음에 제시했던 초점에 벗어나는 것 같더군여.....ㅡ.ㅡ;;

익명 사용자의 이미지

어떠한 컴파일러든지 우월한건 없다고 봅니다...

자신의 프로그래밍의 목적/목표와 자신만의 개발 스타일, 경향, 자신만의 노하우 등...

무슨 컴파일러든지 자기에 맞는게 따로 있다고 봅니다.. (횡설수설인가. . ㅡ,.ㅡ)

위에서 말한 C++ builder, visual C++, delphi, pascal, gcc..... 모두 훌륭합니다...

그런데, 글 목록을 아래로 내려오면서 처음에 제시했던 초점에 벗어나는 것 같더군여.....ㅡ.ㅡ;;

가출소녀의 이미지

아쉽게도 볼렌드 C++ 툴에관한 책은 얼마 없죠 -_-;;

괜찬은 툴인데도... M$에 밀려서리.. 안타까울뿐...

유독 우리나라에서만 찬밥 신세를.. -_-;;

익명 사용자의 이미지

물론 이것도 좋고 저것도 좋다는 다원주의, 상대주의도 좋지만, 지금은 툴을 비교하는 토론이니까 어느 게 더 나은지를 말하는 게 초점이 아닐까요.
자기에게 맞는 게 있는 건 사실이지만 vi가 vim보다 낫다고 말하는 사람은 없지 않을까요-_- 분명히 툴간에 장단점이 있고 그걸 논해보는 것만도 선택에 도움이 될 수 있죠. 언어 토론 같은 이야기 나오면 꼭 모든 언어는 다 각자의 쓰임새가 있기 때문에 대등하다는 식의 논지를 펴는 분이 많은데, 그런 유연한 생각을 가지는 것도 중요하지만 각론으로 들어가서 뭐가 좋고 뭐가 나쁜지 따져보는 것도 의미 있는 일이라고 생각합니다.

익명 사용자의 이미지

알고리즘이 중요하다는 걸 알고 있다면, gcc를 배우고 난후 소스 분석으로 시간을 보내는 것이 최고가 아닐까요?

익명 사용자의 이미지

절대 그렇지 않습니다. 툴의 사용법을 제대로 배우는 것은 정말로 중요한 것입니다.
제대로된 프로그램을 짜기 위해서는 언어, 알고리즘, 자료구조, 디자인 패턴, 방법론, 툴의 사용법 모두를 다 공부를 해야하는 것이지 어느 하나에만 치중해서는 제대로된 프로그램을 짜기 힘듭니다. gcc만 쓸 줄 알아서는 제대로된 프로그램을 만들어낼 수 없습니다. make도 배우고 autoconf도 배우고 ld도 배우고 gdb도 배우고, rcs, cvs도 배우고 vi, emacs도 배워야 제대로된 프로그램을 만들어낼 수 있습니다. 윈도우도 마찬가지, C++과 알고리즘에 아무리 능통해도 툴을 쓸 줄 모르면 윈도우 프로그램은 제대로 만들기 어렵습니다. 아무리 언어와 알고리즘을 잘 알고 툴을 잘 써도 디자인 패턴에 대한 공부가 없으면 대규모 프로젝트에서 스파게티 코드를 만들 수 밖에 없습니다. 다 균형이 맞아야하는 법입니다. 어느 하나를 지나치게 중시하는 것도 어느 하나를 경시하는 것도, 좋은 프로그래머로 가는 길이 아닙니다.

익명 사용자의 이미지

툴은 자신이 수행하는 일에 알맞고 익숙한 걸로 하면 되겠죠.

저 같은 경우 클라이언트 쪽보다는(주로 windows겠군요..)

서버 프로그래밍(거의 네트웍 이지만..)을 하다보니

그냥 gcc, gdb, make로 작업하고 있습니다.

하지만 어떤분을 보니 network program도 visual tool로 작성

해서 가져오시더군요. 수많은 define들..

여튼 자신이 ANSI코드를 작성할수 있고 해야할 일이 뭐냐등

의 여건에 맞춰 편한걸로 하면 되겠죠.

익명 사용자의 이미지

이런, 주제가 윈도우 개발툴들간의 비교였군요 -_-;

지송합니다.

익명 사용자의 이미지

Borland가 무서운 이유는 끊임없는메모리 누수에 Invalid access violation Error닷 ㅋㅋㅋ

음 글고 VC의 무서움은 누구나 익히 알고있는 순식간에 나타나는 System의 Down 현상에 MFC란 깊고 깊은 늪이다 음하하

음냐 젤 개발하기 쉬운 툴은 PowerBuilder이었는데 이넘의 무게는 공포에 떨게하고 살갖에 닥살이 돋게 한다. 흐흐 글고 가끔씩 NULL값을 잘못처리하면 나타나는 무서움이란 흐흐흐 당해본 놈만이 안다..

익명 사용자의 이미지

뭔가 잘못 알고 계시군요,,

끊임없는 메모리 누수라 그건 순전히 프로그래머 몫입니다.

프로그래머의 잘못을 툴의 잘못생각하시는 분이 몇분 계시는데

경력이 되고 좀 실력이 있는분은 절대로 이런예긴 안합니다.

cedar_의 이미지

Borland C++ Builder 5.0부터는 CodeGuard 라는 런타임 에러 검출 툴이
디버깅 툴로 기본 포함되어 있어 메모리 누수 탐지를 쉽게 할 수 있습니다.

익명 사용자의 이미지

허걱 글쿤요 3.0이후엔 델프만 썼어서리 ^__^;

익명 사용자의 이미지

그죠그죠? 씨빌더 너무 져은데.. 3.0에서 하드웨어쪽 손보다 그 이후로 손을 놓아버렸으니. 아까워요.. 또 그 쪽 프로젝 할 기회가 있었으면...

씨빌더는 VB이제 시작한 쌩초보에게도, 10년 경력 왕고수에게도 만족을 줄 수 있는 환경이라 생각합니다.

그리고 '볼랜드' 라는 이름은 일종의 '브랜드 네임'화 되어버렸구요. 현재 회사 이름은 '인프라이즈' 일껍니다.

스펠이 어케 되드라..-_-;

회사 이름 바꾸고 나서도 볼랜드 명성때문에 상품명에 표기하는 것으로 알고 있는데 맞나요?

정확한 사연을 아시는 분은 아래 리플을.. ^^

익명 사용자의 이미지

그게요.. Inprise로 바꾸었다가. 다시 Borland 로 바꾸었습니다. 시기는 정확히
기억 안나네요. 해깔리시죠? ^^;

워낙에 브랜드의 가치가 높아서

http://www.borland.com

익명 사용자의 이미지

빌더는 1.0부터 시작했습니다. 제가 1.0부터 써왔으니까염..^^
근데 1.0은 컴파일 속도가 무지하게 느렸습니다. ㅡㅡ;
그리고 델파이가 3.0이 나오고 4.0이 나올려는 시점에 빌더 3.0이 나왔습니다.
이건 델파이와의 버전을 맞추기 위해서 2.0을 뛰어넘은 거죠...^^

익명 사용자의 이미지

Visual C++ 4.3부터 써왔습니다.
Delphi 1.0부터 써왔습니다.
C++ Builder도 3.0부터 써봤습니다. 아마 빌더는 3.0이 시작인것으로 기억합니다.

지금은 무엇으로 짜든 상관없이 다 편안합니다.

저는 gw-basic, quick-basic, turbo-c, turbo c++, turbo-pascal, masm, tasm, delphi, vc++, c++builder순으로 배우고 사용했습니다. 참 여러가지 경험도 해보고 우여곡절도 많았습니다. 그리고 윈도우 3.1나오고 윈도우용 프로그램 개발하는것은 너무나도 높은 벽이었습니다. 우습게도 그 벽을 넘는데 도움받은 개발툴은 윈도우를 개발한 ms사의 제품이 아닌 볼랜드 재품이었습니다.

윈도우용 개발툴 로 vc++을 접했을때 1년동안 어둠속을 해매였습니다. 뭐 이따구다 다 있다 하면서.. 그후 vc++을 그럭저럭.. 회사내에서는 가장 잘 쓰는 정도까지 진행되었습니다. 그러다 짬잠히 delphi를 더 배우고 나서 윈도우용 프로그램 개발의 감이 잡히더군요. 아.. 이거다. 지금까지 삽질했구나.. 하는 생각이었습니다.
그 후로는 visual c++이든 delphi든 unix에서든 어디서든 가능한한 델파이 스타일로 짭니다. 고거 할만 합니다.

저는 볼랜드 제품에 손을 들어줍니다.

디버깅중에 trace into를 mfc함수에 해보신적 있습니까? visual c++의 MFC 소스를 보면 배울것이 없습니다. 보면 압니다. 도저히 알수 없는 내용들... 사람 돌아버리게 합니다. 디버깅이 불가능합니다. 내가 뭘잘못했나 자신만 원망하게 만들지요.

VCL소스를 보셨습니까? 볼만합니다. 배울것도 많습니다.
if문 , case문 무쟈게써델것을 set(집합)타입으로 간단히 써버린 것을보고 놀래자빠질뻔했습니다.

컴포넌트들이 form의 DC handle을 빌려다가 쓰더군요. 그거 처음알고 놀랬습니다. 그런 놀라움은 찾아보면 끝도 없습니다.

MFC의 돌아버리는 사용법에 질린 사람들은 delphi보면 정말 기가막힐것입니다. visual c++은 frame work라는 틀이 있어서 편할때도 있지만 그것이 오히려일을 방해하는경우도 많습니다. 알아야하는것도 너무 많았습니다.

사용법 몰라서 힘들어하며 시간 허비하느니 몰라도 쓰는 툴 쓰는것이 여러모로 좋다는 생각입니다.

볼랜드 제품들의 장점은 훌륭한 라이브러리, 훌륭한 컴파일러, 직관적 사용법 이라고 생각합니다.
MS 제품들의 장점은 OS와 가까이 있다. MS에서 제공하는 소스들을 바로 쓸 수 있다.

가끔 친구중에 이렇게 물어보는 넘이 있습니다.
야. 교수님은 vc++이 윈도우용 프로그램짜는데 가장 강력하다고 하는데 vc++은 어렵잖냐 멀로 하는것이 좋겠냐?

저는 이렇게 대답합니다.
교수가 vc++밖에 모르나보다. ms신봉자인가 보다. 프로그램 짜보기는 했다냐? 강력하다는 의미가 도대체 뭐라냐?

다른툴 써보지도 않고 어떤 툴이 최고라고 생각하시는(특히 vc만써보고 그게 짱이라고)분들은 다른 툴들도 깊이있게 들여다 보시기 바랍니다. 특히 알고리즘이 아닌 윈도우 인터페이스때문에 고생하시는 분들은 볼랜드 제품 적극 추천합니다.

주저리 주저리 졸려서 썼습니다.

익명 사용자의 이미지

VCL, 정말 잘 만들었습니다.
Delphi 를 쓰면서 경악을 금치 못했던 것입니다.
편리한 인터페이스도 좋았지만, VCL 을 쓰면 쓸 수록,
소스를 뜯어 보면 볼수록 너무나 경악할 정도로
잘 만든 라이브러리라는 생각이 들었습니다.

그런데 델파이 CD 에 C++ Builder 데모가 같이 들어 있었습니다.
이건 어떤가 하고 깔아봤더니 세상에, C++ 인데 VCL 을 쓰는 겁니다.
C++ 로 코딩하는데 이렇게 편리한 느낌을 가져본 적은 단연코 처음이었습니다.

VCL, 이거 물건입니다 물건.

익명 사용자의 이미지

C++ Builer 는 1.0 부터 입니다. ^^

임택균의 이미지

C++ Builder와 Delphi의 이야기가 분산되어 있어 이곳에 그냥 답장을 올립니다.

델파이는 이전 터보파스칼이 그러하였드 파스칼 계통의 언어가 얼마나 포터블하고 가벼우며 적은 시스템 자원에서 빠르게 동작할 수 있는가를 보여주는 그 단편적인 예 입니다.

또한 오브젝트-파스칼의 경우 이미 RAD툴로서의 평가는 NeXT Step에서 이루어졌던 것으로 기억합니다. 그리고, C++ Bulder를 정통 C++ 컴파일러로 분류하셨는데, 제 생각으로 그 정통성 보다 RAD툴로 가기 위한 오묘한 언어확장이 있었느데, 이것이 너무도 훌륭한 것 같습니다. 언어 확장은(키워드가 지금은 생각이 나지 않네요.) 변수 대입이 함수를 콜하는 것입니다. 즉 코딩을 하는 사람은 윈도우 박스의 어떠한 프라퍼티를 변경하는 것으로 생각하고 코딩을 하지만, 그것이 함수를 부르는 구조가 됩니다. RAD툴에서 함수의 소용돌이 속에 빠지지 않고, 절묘하게 코딩을 할 수 있는 기발한 방법입니다.

임택균.

익명 사용자의 이미지

NeXT 사의 NEXTSTEP에서, 또 그이후의 OPENSTEP에서도 Objective-C를 사용했지 파스칼을
쓴 적은 없습니다. 그리고 대부분의 유닉스에서는 파스칼을 사용하지도 않고 있지요.

cedar_의 이미지

C++ Builder는 '정통' ANSI C++ 컴파일러로서도 상당히 우수합니다.
M$ VC++ 의 경우 ANSI C++ 표준은 정확히 지키지 못하는 점 땜에
문제가 많죠.(VS.NET에서는 어느 정도 해결되었다고는 하는데...)
예를 M$ VC++에서 STL을 완벽하게 쓰는데는 여러가지 문제점이 있고,
서비스팩 패치를 해도 문제는 남아있습니다.
제대로 해결하려면 Dinkunware에서 파는 상용 라이브러리를 구입해야하지요.
C++ Builder의 경우는 특별한 설정 없이 바로 표준 STL을 쓸 수 있고,
STLport 같은 확장 STL 라이브러리도 쉽게 설치해서 쓸 수 있습니다.
(M$ VC++에 설치하려고 시도했지만 실패했습니다. T.T)

또한 그러면서도 "RAD툴로 가기 위한 오묘한 언어확장"도 훌륭하지요.
위에서 님이 쓰시려고 하신 키워드는 __property 키워드 일겁니다.

cedar_의 이미지

오타: Dinkunware -> Dinkumware
발음은 '딩컴웨어'라고 하는군요.

익명 사용자의 이미지

개발툴에 대한 정확한 비교분석은 나름대로 해보시면 재미있는 점을 발견하실겁니다. 그러나 아래의 개발툴은 상업적으로 판매하는 S/W의 일종이기 때문에 시장의 지배력이나 영향력이 서로 다른건 알고 계셔야 합니다. IT시장 전체적으로 인정해주는 그런 툴을 사용하는게 좋을듯 싶습니다.

Visual C++
모든 윈도우 프로그래밍 개발에 쓰인다. 배우기도 힘들고 시간도 오래걸리지만 배워두면 윈도우에서 프로그래밍은 거의 무적에 가깝다고 할수 있겟습니다. 리눅스에서 GCC/G++이 있듯이 윈도우에서는 Visual C++이 있다고 보시면 됩니다. 사실 툴보다는 MFC나 윈32 API등의 라이브러리를 이해하시긴게 좋겟씁니다.

Visual Basic
모든 윈도우 프로그래밍 개발 및 DB나 일반 응용프로그램 개발에 많이 쓰이며 RAD툴이라고 합니다. 어떤 결과물을 내는데 개발 생산성이 빠르다는 얘기입니다. 그러나 사람들은 베이직이 너무 쉽다고 하면서 외면하시는데 많이 써보시면 사뭇 다른 느낌을 받을 것입니다.

Delphi
예전에는 DB나 일반 응용프로그램 개발에 많이 쓰였으며 웹애플리케이션 개발에는 요새 좀 쓰이는듯 합니다. RAD툴로도 신선한 충격을 줬떤 역사가 오래된 제품입니다. 제가 예전에 들은 얘긴데 s/w개발업체의 한 간부라는 사람이 델파이를 단순히 DB툴로만 이해하고 있는 사람도 있더군요. -_-+

C++ Builder
쉽게 Delphi의 C++버전이라고 보시면 됩니다. 델파이에서 되는건 전부 됩니다. 심지어는 델파이 소스 보고 C++로 그대로 옮겨적으면 될 정도입니다. (언어나 문법 구조적인 차이는 있지만...) 저의 사견을 말씀드리자면 이같이 환상적인 툴은 본적이 없습니다. 개발 생산성 또한 높으며 DB나 일반 응용프로그램 개발, 웹애플리케이션 개발, 컴포넌트 개발등 아주 폭넓은 개발을 지원해주는 툴입니다. 볼랜드사의 기술력을 인정하게 되는 좋은 툴입니다.

Power Builder
DB 프로그램 개발에는 거의 최강자였던 툴입니다. 이툴도 웹애플리케이션 개발을 지원해주긴 하는데 요새 기업환경의 추세가 웹쪽으로 많이 바꾸기 때문에 아직도 많이 쓰는지도 모르겠습니다.

JBuilder
자바로는 일반 애플리케이션 만드는 일이 별로 없는듯 싶습니다. 컴포넌트 라이브러리 같은건 만들어서 판매도 하긴 하던데 단일 애플리케이션은 좀 찾기 힘들더군요. 기업환경이 웹쪽으로 진화하면서 특히나 자바를 많이 쓰는데 그중 국내에서 호평을 받은 툴입니다. 그러나 아직도 JDK만 가지고 노트패드에서 개발하는 사람도 있다고 합니다. 요새 자바는 엔터프라이즈 환경이나 임베디드, 모바일 환경에 더욱 강세인듯 싶습니다. 임베디드나 모바일쪽은 어떤 툴을 주로 사용하는지는 모르겠습니다. ^^;

.NET
요새 한참 주가를 올리고 있는데 그게 우리나라만 그런지 외국도 그런지는 모르겟습니다. 한마디로 플랫폼이라고 정의를 내리더군요. 자바와 많은 비교를 하면서 서로의 장단점을 기사로 실은 잡지가 많더군요. 먼 미래를 생각해보신다면 .NET도 생각해보셨으면 합니다. 기존에 Visual C++이나 Visual Basic을 쓰던 사용자도 수용하며 C#을 만들어 새로운 개발자도 수용하고 있으며 Python도 포팅된다고 하니 기대해볼만한 합니다.

그러나 아무리 좋은 툴(도구)을 가져다 써도 자신이 잘못쓰면 그건 별 소용없다는 것입니다. 결국 베이직으로도 훌륭한 S/W를 개발할수 있습니다. 가능한 이야기입니다. 그러나 그렇게 개발된 S/W가 시장에 먹혀드느냐가 문제일것입니다. 결국 현재 시장이 원하는 그런 개발툴을 이용하여 개발하시는게 중요하며 툴마다의 장단점을 잘알고 계시다면 프로젝트를 하시는데 필요한 툴이 어떤 건지를 쉽게 선택할수 있을 것입니다.
그리고 어떤 툴이나 라이브러리를 사용했던 같은 결과물(S/W)를 만들어 낼수 있다는걸 잊으시면 안됩니다.
이재형님 말씀대로 "어떤 알고리즘과 설계 구조를 가지고 얼마나 효과적으로 동작하는 프로그램을 얼마나 빠르게 생산할 수 있는가가 관건"이라고 봅니다.

cedar_의 이미지

아래의 글은 꽤 옛날(1999년)글이네요.
같은 분이 올해 쓰신 글을 허락받아 올립니다.

========================================================

박지훈.임프랍니다.
제가 아는 현실을 말씀드리지요.

일단... VC 사용자들이 대부분 C++Builder에 대해 알지도 못하면서 함부로 말하는 경우가 많은데..
두가지 이유가 있습니다.
VC 사용자들은 다들 한번쯤은 VB를 돌아보게 되는데, VB를 써보면서 VB의 형편없는
코딩기반 프로그래밍 능력에 조금씩 질리는 경우가 많습니다.
그래서 VB 처럼 RAD 프로그래밍 툴을 보게 되면 VB와 같을 것이라고 단정해버리는 경우가 많습니다.
또 한가지 이유는... MS에서 고의적으로 그렇게 소문을 내고 있습니다.
몇차례 MS의 세미나를 참석했을 때 C++Builder에 대해 험담하는 것을 들은 적이 있습니다.
표준이 아니라는 둥.. 세세한 제어가 안된다는 둥.. 그런 얘기들요.

하지만 진실과는 너무나 반대의 얘기입니다.
C++Builder는 Turbo C에서 Borland C++을 거쳐 발전해온 정통 C++ 컴파일러입니다.
쉽게 설명하자면, Borland C++에 Delphi의 RAD 엔진을 얹은 것이 C++Builder라고 보시면 됩니다.

아시다시피 Borland C++은 VC와의 몇년간의 치열한 컴파일러 전쟁끝에 뒤로 밀려난 C++ 컴파일러입니다.
VC에 비해 Borland C++이 결코 뒤지지 않음에도, 단순히 OS를 만드는 회사의 컴파일러가 나을 것이다라는
막연한 개발자들의 생각과, OS의 신기술을 모두 VC를 통해 발표하는 MS의 좀 비열한 방법에 의해
Borland C++이 밀려났던 것입니다.

Borland C++이 VC에 비해 기능적으로 결코 밀리지 않았던 만큼, 그 업그레이드 버전인 C++Builder도
VC에 밀리지 않습니다.
오히려, C++Builder는 Borland C++의 OWL과 델파이의 VCL, VC의 MFC를 모두 포함한, 엄청나게
강력하고 방대한 기능을 제공하는 통합 C++ 개발툴이라고 할 수 있습니다.

Win32 프로그래밍에서 C++Builder가 VC보다 못하다...?
전혀 사실이 아닐 뿐 아니라 오히려 거짓입니다.
C++Builder에서는 Win32 코드를 VC와 똑같이 소화하는 것은 물론, MFC로 작성된 VC 소스코드까지도
컴파일할 수 있습니다. (C++Builder에서 MFC 코드를 쓰려면 조금은 불편한 점도 있습니다만.)

이제 델파이를 쓰게 되셨다구요.
프로그래밍 언어를 제외하고 델파이는 C++Builder와 똑같습니다.
말씀드렸다시피, Borland C++에 델파이를 얹은 것이 C++Builder이기 때문입니다.
게다가 C++Builder에서는 델파이 코드를 똑같이 컴파일하거나 한 프로젝트에서 cpp 소스와 pas 소스를
모두 포함해서 실행파일을 만들어낼 수도 있습니다. (실제로 제가 그렇게 많이 합니다.)
그러므로 델파이를 하시게 되었다고 하더라도, 전혀 접해보지 않은 언어를 쓰게 된 것은 아니라고
생각하시면 됩니다. C++Builder를 조금이나마 공부해보셨으니, 이제 파스칼 언어만 조금 익히면 되는 것
아니겠습니까. 파스칼 언어가 모양은 C++과 많이 달라보여도, 실제로 써보면 C++과 대단히 비슷합니다.
(물론 세부적으로는 다른 점들도 꽤 많이 있습니다.)

MFC만 쓰실때는 거의 Win32 API를 모르고는 코딩이 불가능하죠.
하지만 C++Builder나 델파이는 Two-way tool이라는 컨셉 아래, 모든 문제를 해결함에 있어
코딩 기반으로 해결할 수도, 컴퍼넌트를 배치하고 코딩은 약간만 하는 RAD 기반으로 해결할 수도 있습니다.
코딩기반으로만 해결한다면 성능을 극대화시킬 수 있을 것이고 , RAD 방식으로 해결한다면 생산성을
높일 수 있습니다. (상황에 따라 적절히 섞어서 사용하는 것이 가장 좋습니다.)
그러므로 Win32 API를 몰라도 C++Builder나 델파이를 충분히 잘 활용할 수 있지만,
Win32 API에 익숙하다면 더욱 더 넓은 폭의 선택에 따라 더 나은 코드를 작성하실 수 있습니다.

그러므로.. VC를 오랫동안 사용하셨는데 이제 델파이나 C++Builder를 사용하시게 되더라도 절대
걱정하실 필요가 없습니다. 단적인 예를 들자면, 제가 운영하고 있는 볼랜드포럼의 C++Builder 고수들을 보면
대부분이 과거 VC만 사용하다가 우연한 기회에 C++Builder를 알게 되어 심취하신 분들이 대부분입니다.
처음에 한두달 정도는 좀 익숙하시지 않아서 헷갈리실 수도 있습니다만, 그 정도만 지나면
오히려 처음부터 델파이나 C++Builder만 사용해온 분들보다 더 빨리 배울 수 있습니다.

개발툴에 대한 이야기는 이만하면 충분한 소개가 되었다고 보고요.
그리고...

전문 개발툴을 선택하는 문제와 앞으로의 진로를 가늠하시면서 고민하시는 일이 많으시리라 생각합니다.
사실 많은 분들이 그렇습니다.
다수의 사람들이 가는 길을 따라가지 않으면 불안해지는 것은 사람의 당연한 심리입니다.
하지만 현실은 반드시 사람들의 막연한 추측이나 안도감과 일치하지는 않습니다.
델파이나 C++Builder 사용자가 상대적으로 적기는 하지만, VC나 VB 프로그래머를 원하는 직장이
그렇게 충분하지도 않습니다.

어차피 개발자 시장의 규모라는 것은 그 개발툴을 사용하는 기업의 숫자와 함수관계에 있기 때문에,
C++Builder나 델파이를 사용하는 사람이 많아지면 원하는 기업도 그만큼 많아지고
개발자가 적어지면 원하는 기업도 적어집니다.
그러므로 상대적인 취업의 기회는 사용하는 개발툴이 더 많이 쓰이는 것이냐 아니냐와는 크게 관련이
없습니다.

물론, 상대적으로 적게 쓰이는 개발툴을 주로 쓴다면, 엄청나게 넓은 취업시장에서 그 개발툴 개발자를
원하는 기업을 찾기가 좀 어려워지는 단점은 있습니다.
하지만 무조건 취업 자체가 최우선 목표이고 연봉이나 근무조건 등등의 다른 기업상황은 전혀 상관하지
않는 사람은 없을 것이기 때문에, 어차피 자기에게 맞는 기업을 찾기 위한 어려움은 동일합니다.

초보 프로그래머로서의 길이 무어냐고 물으셨는데...
어떤 개발툴이든 각자의 장단점이 있기 마련이고, 각자의 취업 시장이 있습니다.
그러므로 자신에게 가장 맞고 또 자신이 하려는 일에 가장 맞는 개발툴을 선택하는 것이 왕도라고 할 수 있습니다.
멋모르는 초보개발자들이 모두 MS나 자바로만 달려간다고 그걸 무작정 따라가는 것은 흐름이나
대세를 따르는 것이 아닙니다.

대학이나 교육센터의 주변에 있는 사람들(들어가려고 하거나 현재 그 안에 있거나 막 나온 사람들)은
잡지나 신문등에서 떠드는 이야기만 줏어들어서 막연히 그렇게 믿고 있을 뿐, 현실을 거의 모릅니다.
물론 경력 개발자의 경우에도, 제대로 알고 있는 것은 자기가 있는 곳의 주변뿐인 경우가 많습니다.
일단 취업을 하고 보는 것이 중요한 것이 아니라 앞으로의 진로가 정말 중요하다는 것을 확실히 자각하고 계시다면,
주변 한두사람의 이야기만 듣고 쉽사리 이리저리 흔들리지 마시고, 폭넓은 사람들에게 이야기들을 들어보신 후
결정은 완전히 스스로 하셔야 합니다.
결정하시는 데 있어 주변 사람들의 의견이 자신의 주관보다 더 큰 영향을 미쳐서는 안되겠지요?

도움이 되셨기를 바랍니다.

Jeehoon Imp Park
http://www.borlandforum.com/

익명 사용자의 이미지

죄송하지만..
VCL과 델파이에 대해서 자세히 설명해 줄 수 없을까염...
넘 몰라서리......ㅜ.ㅜ...

^^*...꼭...부탁드립니다.

익명 사용자의 이미지

툴만으로 본다면 ..
사실 델파이만큼 직관적인 툴이 없지 않을까요 ?..
( Borland C++ Builder 도 뭐 같은 툴이나 다를바 없죠 .. )
직관적이라는 얘기는 같은 시간을 투자했을때 ..
좀더 나은 생산성을 보일수 있다는 얘기와 ..
일맥 상통한다고 봅니다 ..

물론 VC++하는 분들이 많은-_-a 느낌이라 ..
공동작업을 한다거나 할 상황이라면 ..
쓰이기 어렵겠지만요 ..

음-_- 옛날 어느 게시판에서 ..
'프로그래밍은 vi와 gcc만 있으면 되죠 -_-/' 하시던 ..
어떤 분의 글이 떠오르는군요 .. ^^;
물론 유닉스쪽이었지만 ..;

..sDia..

익명 사용자의 이미지

전 Cygwin 이 좋더군요
리눅스의 개발 환경을 거의 그대로 가져와서.. ^^;

익명 사용자의 이미지

저는 전체적인 면에서 생각을 봤습니다.
언어의 난이도나 제어능력... 여러가지요...
아무래도 Windows에선 Visual Studio군의 언어들을
따라갈게 없다고 봅니다.

익명 사용자의 이미지

실력없는 목수는 공구를 탓한다

익명 사용자의 이미지

그렇습니다 진정한 최고는 개발툴 안따집니다 빈손으로 하지요..
010101101011...(기계어 직접 입력중)

앗 버그 발생했다! 오늘도 야근이구나..

익명 사용자의 이미지

진짜 기계어 직접 입력을 해본 적이 있는데 나름대로 재밌더군요--; 어셈이 기계어를 직역한 거기 때문에 Instruction set이 많지 않은 간단한 머신은 직접 오브젝트 코드를 입력해서 할 수 있죠. 오히려 어셈블 안하고 바로 실행할 수 있다는 장점도-_-

딴지가 아니고 그냥 잡설입니다-_-+ 저두 도구의 중요성은 절감합니다. 전 이맥스를 배우는 것이 C++ 배우는 것만큼 중요한 일이라고 생각하는 사람이거든요.--;
윈도우에서도 C++ 자체를 배우는 것 못지 않게 IDE의 제대로된 사용법을 익히고 각종 툴을 제대로 쓸 줄 아는 게 중요하죠. 생산성과도 직결되구요. 개인적으로 비주얼 씨 6.0의 막강함에서 느낀 감동을 잊을 수가 없군요.

임택균의 이미지

제가 예전에 어셈블 코딩을 했는데, 제가 처음부터 IBM 어셈블러를 배울때 C코드를 어셈블 코드로 출력해서 해서 배웠습니다. 물론. 어셈블러 짜다가 막히면 C언어로 함수 만들어 확인하고 코드를 만들었죠 :-)

그 덕에 제가 짠 어셈블러 코드는 다른 사람들이 모두 이야기하는 속도가 빠르지 않았습니다. 그냥 생각이 나는 군요.

--
임택균.

임택균.

girneter의 이미지

실력있는 목수에게도 공구는 중요한 겁니다.

이승엽이도 쳐보니까 좋다는 배트가 있을테고
황영조도 신어보니까 달리기 좋다는 운동화가
있을겁니다.
(물론 일반인이 그런 공구를 쓴다고 그들처럼
되는건 아니지만)

질문 올리신 분도 개발자에게 툴보다는 설계와
알고리즘이 훨씬 더 중요하다는 사실을 잘 알면서 질문을 올리신 건데 굳이 그렇게 삐딱하게 답할 필요가 있을까요?

개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?

익명 사용자의 이미지

저 다니는 회사경우엔 NC 쪽 일도 하거든요..
흔히 "제어"라고 부르는 경우죠...

그래서 Borland C++ Builder를 주로 사용합니다.
Visual C++보다는 기계쪽 제어하기 용이하고, 전체적으로 쓰기 편하다는 얘기를 하시더군요...

저는 웹쪽하고 network쪽으로 주로 하는 중인데요...
C나 C++은 하지만, GUI를 해 본적은 없는 인간입니다만...
전번에 영상을 전송하는 모듈을 만들어야 할 일이 있어서..
손을 대기 시작했는데....

처음에는 visual C++ 쪽으로 손을 대다가...
결국엔 Borland C++ Builder 쪽으로 선회했습니다... ㅡ.ㅡa

여러가지 이유가 있었지만...
가장 큰 이유는....
Borland C++ Builder 쪽이....
좀 더 직관적인 형태로 설계되어 있어서...
쓰기 좋았다는 점이죠....

MFC는 그 체계를 이해하기가 정말 힘들었던 반면에...
VCL은 그냥 보고 쓰기만 해도 되었던 점이나...

Visual C++로는 어느정도 지식이 있어도 아무것도 할 수 없었던 반면에, Borland C++ Builder로는 아무런 사전 지식 없이도 간단한 소프트웨어를 만들어낼 수 있었기 때문에...

뭐, 학습시간이나 이런저런 것들을 고민하다가...
과감히 Boralnd 쪽으로 기울어 진거죠....

Visual C++로 MFC 쪽 플밍 하시던 울 팀장님은 Visual C++ 쪽이 깊이 들어가면 더 나은 점이 있다고 하시기는 하십니다만..... 물론, 허접한 전 알 도리가 없네염~~ ^^;

하지만, 확실한 건 Borland의 VCL 쪽이 훨씬 직관적이고 쓰기 좋았다는 겁니다.. 물론 제 경험 내에서 드리는 얘기라 스스로도 신빙성이 없습니다만~~ ^^;

linuz의 이미지

음... 그 팀장님이 과연 볼랜드 툴에대해서 깊이 있게 들어가보셨나 몰겠군요...

뭐가 더 낫다는 거죠?

익명 사용자의 이미지

음... 분명 깊이 들어가면 Builder보다는 VC++이 심도가 있습니다.
그리고 구조도 VC++이 조금은 나은듯 하구염...
Builder는 기본적으로 Doc/View구조가 아닙니다. 물론 Doc/View구조처럼 쓸수는 있습니다만...
기본적인 구조에서 오는 한계도 조금은 있지요.
VC++을 쓰다보면 얼마나 합리적인 구조인가를 느끼거든여.
앗.. 물론 저도 Builder팬입니다..^^a

익명 사용자의 이미지

역시 MS에서의 작업이라면
Visual C++과 Visual Basic이 아닐까 합니다.

Visual C++로 컴포넌트를 만들어서
Visual Basic으로 결합(?)시키면
아주 이상적인 방법이 되겠지요.

익명 사용자의 이미지

That is what .Net suggest..!

익명 사용자의 이미지

Borland C++ builder 에선 이게 한꺼번에 가능하죠^^;

익명 사용자의 이미지

음... 이곳에는 보통 IT 쪽의 개발자 분들이 많으실 걸로 생각합니다.
그래서 대부분 DB 가 어쩌구~ 하는 것 같은데요.
저는 좀 마이너한 말씀을 드리려구요.

제 경우는 시스템 인티그레이션을 좀 해 보았습니다.
물론 IT 의 SI 가 아닙니다.
반도체 장비 같은걸 만들때, 여러가지 하드웨어 부터 시작해서
소프트웨어까지 모아!모아서 기계 만드는 인티그레이션이죠.

이 경우(FA 죠), 장비 개발하는 엔지니어는 최신 개발툴에
대해 상당히 버거움을 느낍니다.
왜냐면 전문적인 프로그래머가 이런 일을 맡아서 한다면
좋겠지만, 그런 사람이 개발팀에 충분히 확보되어 있는
경우가 적거든요. 특히 작은 회사에서요.

그럴 경우, 하드웨어 제어까지 가능하면서 쉽고 익숙한
것으로 해야 되는데... 당근 C 죠.
윈도우 프로그래밍을 ANSI-C 가지고 짤 수 있을까요???
그런 개발툴도 있습니다.

National Instrument 같은 계측장비 회사에서 파는 제품들
따위죠.
비쥬얼 베이직 수준으로 쉬운 GUI 빌더가 제공되고,
코딩은 ANSI-C 로 되구요.
라이브러리는 FA 위주로 제공되고...

그밖에 코딩 자체를 없애버리고 블록만 갖다붙여 프로그래밍
하는 툴들도 있쟎아요.
이건 복잡한 알고리즘을 짜기엔 부적합하지만, 문법에 구애됨이
없이 맘대로 쉽게 구성할 수 있죠.

왜 FA 말씀을 드리냐면, 이쪽 분야에서 수년전부터 PC 기반
제어로 주류가 바뀌고 있기 때문이죠.
물론 이경우 윈도우를 대부분 많이 쓰고요.
유닉스를 쓰는 경우도 있습니다만 윈도우로 넘어가는 추세입니다.

왜냐면, 각종 PCI 나 VXI 같은 주변장치와의 인터페이스에서
윈도우 드라이버(라이브러리)는 거의 필수로 제공됩니다만
유닉스/리눅스 드라이버는 잘 제공이 안되거든요.

그래서리... 정리하자면,
FA 쪽에서 많이 쓰는 개발툴은.....

당근 비쥬얼 씨뿔뿔이지만 이보다 더 편한 것들도 많다는 점..
사실 저같은 경우는 비쥬얼 씨뿔뿔은 커녕 씨뿔뿔 자체도
잘 모르는데도 제품 개발에 별 어려움을 몬느꼈습니다.
심지어 OpenGL 을 사용할 경우라도 말이죠.

익명 사용자의 이미지

NatioalRose를 말씀하시는거 같은데염.. 맞죠? ^^a
저도 써봤는데염...ㅡㅡ;
저는 문자코드보다 그게 더 이상하더라구염...
게다가 속도도 조금 느린거 같구염....

익명 사용자의 이미지

Microsft Visual C++를 적극 추천합니다.

익명 사용자의 이미지

참고로 전 학생이며 초보자입니다..^^;

제가 잘못 알고 있어도 너무 공격적인 리플 않달리길..

이건 자바 IDE 애기인데

우리나라에서 나온 블루엣이라는 자바 비주얼 툴이 처음에

델파이로 개발 했다가 자바로 다시 개발하고 있다고 합니다.

J빌더 역시 3.0까지는 델파이와 비주얼씨의 라이브러리

이용하다가 3.5에서 100% 자바로 다시 씌여 졌습니다.

자바로 스타 오피스역시 MS-오피스의 강력한 도전자가 되었으며

그전에 많은 있던 많은 응용 프로그램 들이 자바로 다시 쓰여

지는 현상은 목격하게 되었습니다.

그래서 자바가 좋다는건 아니구..

이식성이 높은 툴이 어쨋들 장수하리라는 생각이 듭니다.

자바

델파이/카일락스

비주얼 스튜디오.넷? <- 아직 알순 없지만..그래두..

대략 이정도가 주류가 되리라 생각합니다

비주얼 베이직은..문법 다 바뀌었으니 새로배워야 겠네요 ^^;

Gtk나 Qt는 외국은 모르겠구 우리나라에서는..

배우기엔 좀 위험하지 않을까..

파이썬은? 잘 모르겠네요..

익명 사용자의 이미지

만들려고 한다는건 아직도 ing 란 말씀인가요?

제가 한 2년-3년전에 블루엣 초기(거의)버전을 쓴적이 있었는데..

그때의 광고 문구가 순수 자바로 만든 자바툴 이였는데 말이죠...

익명 사용자의 이미지

델파이로 맹글어졌다고 알고 있습니다

익명 사용자의 이미지

비줠씨는 비줠씨로 만들어집니다.

델파이는 델파이로 만들어집니다.

그래서 블루엣도 자바로 만들려고 하는 것이겠죠..

익명 사용자의 이미지

여기 프로그래밍 질문/답변 란에서 퍼왔습니다....원 글은 볼랜드포럼(http://www.borlandforum.com/)에 있는 글이라는군요.

--------------------------------------------------------------------

모 대학 컴퓨터공학과 졸업을 앞둔 대학생입니다.

cbuilder 님의 단답형 회신을 원합니다.

요즘 프로그래밍 업체에서 많이 사용하는 개발툴들의 비율은 얼마나 될까요?

또한 앞으로의 전망은 어떨까요?

마땅히 물어볼 곳이 없어서 이렇게 조심스레 질문합니다.

단답형 회신이라도 고맙게 받겠습니다.(시간이 나신다면 조언도...)

감사합니다.

임펠리테리입니다.

먼저, 개인 메일로 보내주신 내용을 허락없이 공개적으로 게재하는 데 대해서
양해 말씀을 드립니다. 그냥 답신메일로 보내드리려고 하다가, 비슷한 고민을 하시는
분이 적지 않을 것 같고, 또한 이러한 내용은 직접 관계가 없더라도 다른 많은 분들께도
참고가 되리라 생각해서입니다. 제 홈페이지가 한두 분을 위한 공간이 아니라, 많은
프로그래머/예비 프로그래머 분들께 도움이 되기를 바라는 공개적인 자리라는 것을
생각하셔서.. 부디 넓은 아량으로 용서를 부탁드립니다.

질문하신 내용은 저도 답변 드리기가 조심스럽습니다.
정확한 상황은, 정말 통계조사나 해보아야 가능할 겁니다.

더욱이...
프로그래밍 업체라고 하여도, 구체적인 성격에 따라 조금씩 사용하는 프로그래밍 툴이 다를 뿐
아니라, 특정 툴을 강요하지 않는 업체도 적지 않습니다.

하지만.. 많이 답답해하시는 것 같아, 천리안에서 프로그래머 포럼을 2년 가까이 운영하고 있는
경험에 비추어 제가 아는 한도내에서는 정확히 알려드리려고 해보겠습니다.

가장 많이 사용되는 툴은 역시 비주얼 베이직과 델파이일 겁니다. 둘 중 어느 툴의 점유율이
높을지는 사실 실제적인 조사를 하지 않으면 알 수 없습니다. 비주얼베이직을 사용하는 사람은
비베 사용자가 더 많다고 하고, 델파이를 사용하는 사람은 델파이유저가 더 많다고 말합니다.
하지만 대략 제가 예상해 볼 때는, 델파이가 약간 정도는 더 많지 않을까 하고 생각하구요,
두 툴의 점유율은 대략 전체 소프트웨어 시장의 30%를 약간씩 넘어서는 정도로 점유하고 있을
겁니다.

그다음으로 파워빌더를 들 수 있습니다. 파워빌더는 요즈음에 있어서는 새로운 사용자가 많이
늘어나지는 않을 것으로 예상됩니다만, 디비 프로그래밍에 있어서는 툴 자체의 장점 외에도,
사이베이스 사의 전폭적인 지원을 받기 때문에(파워빌더가 사이베이스사의 작품입니다)
사이베이스로 개발을 고집하려면 역시 파워빌더가 최적이기 때문이죠. 하지만 융통성없는 RAD
툴이라서.. 제가 알고 있는 몇분들을 포함해서, 서서히 사용자가 줄어들고 있는 추세인 것으로
알고 있습니다.

일반적인 예상보다는 비주얼씨 프로그래밍을 하는 업체는 적을 것으로 생각합니다.
전체 시장의 15%선을 크게 넘지 못할 거구, 10%선을 겨우 넘지 않을까 싶습니다.
공부하기 시작하는 학생층이 많다고 해서 이 툴을 사용하는 프로그래머가 많다고 생각하는데는
무리가 있기 때문이죠. 실제로 많은 사람들이 중간에서 포기하는 것을 보았고.. 또 비주얼씨는
시스템 프로그래밍의 용도가 아니라면 생산성이 너무 떨어져서, 만약 같은 프로젝트를 비주얼씨와
다른 툴로 비교해보면, 비주얼씨의 공수(개발일자 곱하기 투입인원으로 계산합니다)의 면에서
너무 떨어집니다.

몇몇 상용 패키지 프로그램이 비주얼씨로 개발되었다고 해서 비주얼씨의 시장이 클 것이라고
생각하는 것은 오산입니다. 국내 패키지 소프트웨어 시장은 전체 소프트웨어 시장에 비하면 정말
미미할 정도니까요.

자바 시장이 요즘 급속히 크고 있습니다. 전체의 10%선 정도일 거 같습니다.
이쪽은 아직 자바 언어 자체가 어느정도까지 유효할지 모르기 때문에 잠재적인 성장의 한계를
추측하기가 어렵습니다.
자바를 홍보하는 사람들의 말 그대로 믿기는 무리입니다.
자바는 팔방미인이 될 수는 있습니다만, 팔방미인이 모든 분야를 다 잘 할 수는 없고..
자바 시장은 아직 정착되지 않은, 성장 과정의 시장이기 때문에 단정적으로 얼마나 클 거라고
생각하기 어렵습니다. 회의적인 추측과 낙관적인 추측이 가장 많이 오가는 언어죠.
자바를 선택하는 것은 다분히 모험적이며.. 위험성도 그만큼 크다는 말입니다.
자바는 아직까지는 유행성을 벗어나지 못하기 때문에, 거품이 가라앉았을때 어느정도 시장을
점유하고 있을지 알수 없습니다.
(자바 언어에 감정이 있는 건 아닙니다. 제 애인도 자바 강사랍니다.. ^^)

C++Builder는, 역시 제가 가장 좋아하는 툴입니다만.. (모든 면에서 만족스러운 툴입니다.)
그 성능이나 편리함이 많이 알려지지 않은 관계로, 시장 점유율은 전체의 5%도 채 되지 않을
겁니다.

아직 도스 기반의 프로그래밍을 하고 있는 업체도 드물지는 않습니다.
주로 하드웨어 제어나, 그밖에 특별히 윈도우즈로 넘어갈 필요가 없는 분야가 몇 있습니다.
FA와 같은 분야 말이죠.
하지만 이들 분야도 아주 조금씩은 윈도우즈로 넘어가고 있는 추세입니다.

하지만, 앞에서 말했다시피, 특정 언어를 고집하지 않는 업체도 있습니다.
저희 회사 같은 경우에는 델파이와 빌더 어느쪽이든지 환영입니다. 사실 두 툴은 상호 연결이
용이하니까, 특별히 한가지를 고집할 필요가 없거든요.

취업을 위해서 프로그래밍 언어를 선택하시려고 하시는 것인지요...?
제가 이 답신 메일에 대해 어느정도 도의적인 책임을 진다고 생각할 때..
취업을 가장 우선과제로 생각한다면, 제가 현재로서 가장 추천하고 싶은 것은 델파이입니다.

점유율면에서 비주얼베이직도 비슷합니다만, 비주얼베이직은 저수준 제어같은 깊은 곳의
프로그래밍 방법은 아예 거세(이 표현이 가장 정확합니다) 되어있는 툴이라고 생각하니까요.
가장 빠르고 편하기는 합니다만, MS에서는 반 고의적으로 비주얼베이직의 기능을 많이 제한해
놓았습니다. 당연히 비주얼씨와의 시장을 갈라놓기 위한 정책이죠. 간단히 말하면, 마케팅 전략의
일환입니다.

또한, 사용하는 언어가 파스칼이기는 합니다만, 오브젝트 파스칼은 C++과 비교해서 조금도 뒤떨어
지지 않을 뿐 아니라, 오히려 대부분의 경우 성능이 조금 더 낫습니다. 이것은 C++ 맹신론자들조차
도 인정하는 사실입니다.
또한 C++을 아신다면 배우기도 어렵지 않구요. 구조가 비슷합니다. 저 또한 빌더를 쓰면서
곁눈으로 파스칼을 공부한 것이, 지금에 와서는 델파이만으로도 프로그래밍을 할 수 있을 정도가
되었으니까요.

더욱 더 좋은 것은, 델파이를 사용할 줄 알고, 또 C++ 문법을 안다면, C++Builder로도 쉽게 옮겨
갈 수 있다는 겁니다.
C++Builder와 델파이는 완전한 쌍둥이 툴입니다. 사용하는 언어만 C++과 파스칼로 다를 뿐이죠.
(사실 그 언어의 차이가 적지 않습니다만..)
심지어는 C++Builder의 기본 라이브러리인 vcl조차도 델파이에서 사용하는 파스칼로 작성된 소스
를 그대로 사용합니다. 정확히 말해서, 델파이는 C++Builder의 부분집합입니다. 빌더에서는
델파이로 작성된 프로젝트, 컴퍼넌트들을, 몇가지 사소한 예외가 있기는 합니다만, 거의 그대로
사용할 수 있습니다.

볼랜드가 이 두가지 주력 툴을 바라보는 마케팅 전략은 다분히 유동적입니다.
애초에, 볼랜드가 작년 델파이 4를 내놓기 전에, 4 버전을 내놓고는 대대적인 홍보를 거쳐서
주력 방향을 C++Builder로 옮겨가려고 했었습니다. 하지만 델파이 유저들은 완고했고..
그래서 "팔리는 제품을 개발한다"라는 너무도 당연한 명제 아래 아직도 델파이 5까지 발표하고
있는 겁니다. 하지만 앞으로의 방향은 어떻게 될지 알 수 없습니다. 장기적으로는 델파이가
C++Builder에 포함되어버릴 가능성도 아직 다분합니다.

다시 말해서, 당장 취업을 생각해야 한다면 델파이를 공부하는 것이 최선입니다.
하지만 C++을 틈틈이 잊지 않을 정도로 공부해두면 C++Builder로 시장이 급변하는 경우에도
능동적으로 대처할 수 있습니다. 물론, 만약 입사가 결정된 회사에서 C++Builder를 "알기 때문에"
환영한다면, 굳이 C++Builder를 두고 델파이를 공부할 필요는 없겠습니다.

프로그래밍 툴 자체의 우수성만을 생각한다면, C++Builder는 최강입니다.
성능면에서 비주얼씨와 대등합니다. 비주얼씨가 할 수 있는 일은 빌더가 '모두' 똑같이 할 수
있습니다.
생산성면에서 델파이보다 월등합니다. 델파이의 치명적인 약점(사용하는 언어가 파스칼이므로,
많이 널려있는 C++코드를 사용하기 위해서는 직접 소스를 파스칼 코드로 바꾸어주어야 한다는 점)
을 해결한 툴입니다. 심지어는 비주얼씨로 작성된 프로젝트 소스조차도 손 한번 대지 않고 그대로
사용할 수 있습니다.

참고가 되었는지 모르겠습니다. 제가 할 수 있는 한에서는 최대한 객관적으로 적어보려고
애썼습니다. 빌더에 대한 찬사가 너무 많아서 조금은 의심스러우실지도 모르겠습니다만, 빌더로
프로그래밍을 하시는 분들이 공통적으로 느끼는 점입니다.
간과할 수 없는 점이 하나 있습니다. C++Builder는 다른 툴들에 비해 가장 나이가 어린 관계로,
(97년 2월 발표) 대부분의 C++Builder 사용자분들이 과거에 다른 툴들을 사용하다가 전향해서
넘어온 분들이라는 것입니다.
저또한 과거에 비주얼씨와 비주얼베이직을 썼고, 이 두가지 툴의 장점을 고루 가진 툴이
C++Builder이므로 미련없이 C++Builder를 선택한 것입니다.

만약 개인적으로 아시는 분이 비주얼베이직이나 파워빌더를 사용하는 업체에 계셔서 그쪽으로
취업이 가능하다면 당연히 그 툴을 공부하시는 것이 좋겠습니다. 앞에서도 말씀드렸다시피
취업이라는 관점을 우선하여 말씀드리는 것이기 때문입니다.

어쨌든, 잘 생각하셔서 후회없을 좋은 선택을 하시기 바랍니다.
제 두서없는 답변이 조금이라도 참고가 되셨으면 좋겠습니다.
그럼 이만...

익명 사용자의 이미지

c++ builder와 delphi는 상당히 많은 장점들을 가지고 있습니다. VC++, VB 에서는 볼 수
없는 좋은 점을 많이 가지고 있지만, 단점들도 많이 있는데요.

첫째가 소스가 공개된 소프트웨어의 부족 입니다. VC++로 작성된 예제 코드는 사방에 널
렸지만, c++ builder 의 예제 소스는 많이 부족합니다. 이건 치명적이라고 생각 됩니다만, 이 문제를 극복할 수 있는 방법이 아주 없는것은 아닙니다.

c++ builder는 delphi source를 그대로 사용할 수 있습니다. 델파이는 공개된 프로그램
이 vc++ 못지 않게 많죠. 그런 코드들을 들여와서 그대로 사용할 수 있으니까... ^^
( 하지만, 아주 가끔은 c++ builder에서 동작 않는 delphi code가 있기는 합니다 )

이정욱의 이미지

글 잘 봤습니다,

그런데 이 글은 제 생각에는 현재 상황과 비교할 때

한 1년쯤 시간차가 있지 않나 싶네요. :)

익명 사용자의 이미지

잘..알고..계시듯이..툴이.중요하다고는..생각이..안드는군요.. 어차피..툴은..사용하기..쉽게.해주기..위한..도구일..뿐이니까요..당연히..언어에..중점을.두어야..할듯..
사용하는..언어가..무어냐에..따라..툴의..선택이..달라질순..있겠죠...C를..한다면..MFC나..파스칼이면..델파이..베이지이면..VB등...ㅡㅡ;..
정말..중요한.건..알고리즘이니까요..결국..어떤..언어를
사용하는..가도..그리..큰..문제는..아닐..것입니다..
결국..필요한때..적합한..툴을..사용해서..구사하는..능력이..필요할테고..
실제로..한..가지..잘하면..다른것도..쉽게..느껴질테니까요.. 물론..전문으로..하나는..필수고..다른..언어들도..재미삼아..이리저리..보시면..많이..도움이..될것이라..생각되는군요.

익명 사용자의 이미지

토론 제안하신 분도, 언어와 알고리즘의 중요성은 당연히 아실것이라고 생각됩니다.

지금은 툴에대한 토론입니다.

익명 사용자의 이미지

툴...무지 중요하죠...언어만큼 중요한게 툴입니다...개발의 속도뿐만 아니라 프로그램의 안정성, 견고함까지 결정하는 게 툴입니다. 물론 툴이 알고리즘이나 아키텍쳐를 제공해주지는 못하지만 프로그램을 얼마나 완성도 있게 해주냐를 결정할 때가 많습니다. 예를 들어, 프로그램을 개발할 때 Memory Leak이나 Invalid Access따위를 Test할 수 있느냐? Profiling을 해주냐? 따위는 알고리즘에 못지 않게 정말 중요한 요소입니다. 또 Network을 통한 버전 관리 역시 툴이 편하냐 아니냐가 사소하지만 개발 Process를 결정할 때가 많습니다. 물론 이런걸 직접 프로그래머가 신경써서 처리하거나 간단하게 개발할 수 있겠지만 그 중요성을 무시해서는 안되죠....그냥 제 생각입니다...

익명 사용자의 이미지

동감 입니다, 알고리즘이나 아키텍쳐가 우선임에는 분명하지만

툴도 그만큼 중요하죠. Test, profiling, 버전 관리등 만 놓고 생각해도

너무 중요하죠 :)

익명 사용자의 이미지

VC와 C빌더
윈도체제를 알고 API를 알고 두 개를 같이 작업을 하는 저로써는 역시 C빌더 (- -)
결국엔 목적에 따라 빠르게 진행할 수 있는 고성능 툴이 C빌더임에는 틀림이 없는 사실이고 결코 vc와 겨루어 질만한 이유가 전혀 없는게 사실입니다. 사실 굳이 VC를 택하란 권유는 하고 싶지 않습니다. 왜냐면 써본 사람들은 사실을 잘 알기 때문이죠. 편견없이
두개의 툴과 작업진행시 이점등을 나열해 봤을때 아직은 툴만을 따지고 본다면 역사와 전통의 볼란드 사를 따라오려면 아직 MS는 많은 세월이 필요한 것 같습니다.물론 아직 c빌더가 낳다라는 것은 현재 저로써는 진행형의 표현을 하고 싶네요. 나중에 바뀔지 모르니까 ^^*