개떡같은... .NET

icanfly의 이미지

VC++ 6.0 까지는 그나마 그래도 쓸만했었는데......

VS.NET은 너무 하는군요. 장난감같은 디자인에.... 내가 뭘 하고 있는지도

모를 정도로, 혼란스러움..겹겹이 둘러 쌓여있는듯한 느낌...-_-;

정말 짜증 나는군요.

별로 해주는것도 없으면서 느려 터지기만하고......

집에 컴이 애슬론XP 1800+ 인데...버벅임의 진수군요..

취미 삼아 가끔 기웃거리는 리눅스 개발환경이지만....

(목구멍이 포도청이다보니...흑..요즘은 리눅스를 만지지도 못하네요)

뭐 IDE는 별로 라고 해도 가볍고, 원가 상쾌한 느낌이랄까요..

MinGW 통합환경은 쓰기도 엄청 편하던데...

아.. Win32말고 다른걸로 돈벌고 싶다.T.T 돈도 별로 안되는데..쩝..

그냥 넋두리였습니다.

temper의 이미지

별로 해주는게 없다니요??

닷넷은 VC++과는 개념부터가 다릅니다.
어떤 언어로 개발하던지 결과물이 같게 되는 거지요.

C++,VB, DELPHI 등등 -> MSIL 로 변형 -> CLR 구동
어떤 언어로 개발하더라도(닷넷을 지원하는) IL 로 변형이 된다음에 CRL 상에서 구동되는 겁니다.

느린건 당연한거구요
MinGW와 비교한다는것 자체가 말이 안돼요.

자바를 따라하는것 같아 기분이 매우 나쁘더군요.
특히 MC++ 문법보고 환장하는줄 알았음.
소멸자 사라지고, 자바와 비슷해진 문법. 가비지 컬렉터가 있는 C++ ㅡ.ㅡ;

perky의 이미지

이 글의 제목은 "개떡같은.. .NET"보다는 "개떡같은.. VS.NET"이 더 어울리겠군요. :)

You need Python

jachin의 이미지

VS.net 은 정말 혼란스러워요. ^^;

저도 예전에 베타버전을 시험했었는데...

@_@ 정말 어디서 무엇을 해야 하는지 모르겠더라구요...

아마도 엔터프라이즈급 프로젝트 관리자 정도라면,

쉽게 적응하지 않았을까 하는 생각도 해봅니다.

ageldama의 이미지

.net도 개떡 같던데요;;; 쿨럭(개인취향일까요;;; )

----
The future is here. It's just not widely distributed yet.
- William Gibson

nachnine의 이미지

.NET으로 만들었는지.. 어떤 사이트를 가니

Runtime Module(?)을 십수 Megabyte를 다운받던데.

좀 짜증나더군요.

.NET Framework이 활성화되려면 runtime의 덩치가 좀 작아지던지

아니면 기본으로 포함되어 있는 OS의 보급이 이루어져야 할것입니다

닷넷 닷넷 하는 말은 듣고있지만 여전히 98년도에 나온 VS6를 사용하고

있습니다.

seoleda의 이미지

저도 넘 복잡하고 무겁다고 생각하는데요.

그런데 학생이 아니라면 비주얼툴은 안 쓸 수가 없잖아요.

안타까운 현실입니다만, 대부분의 개발 프로젝트들이 윈도우기반으로 돌아가는지라.

사실 간단하게 비디오방 관리 프로그램 개발하면서 리눅스 깔아서 사용해라..

이런 말도 우끼고.. 어쨌든 윈도우 환경에서 개발하시는 분들이 많을텐데..

어떤식으로 적응하고 계시는지 궁금합니다. ^^

비주얼씨 6.0은 그런대로 적응해서 써보긴 했는데 닷넷은.. 저도 영... 답답해서..

이넘을 하긴 해야 하는데.. 아직까진 알고리즘 개발이 주 목적인지라 vim 과 gcc를 사용하고 있습니다.. ^^

meteors의 이미지

nachnine wrote:
.NET으로 만들었는지.. 어떤 사이트를 가니

Runtime Module(?)을 십수 Megabyte를 다운받던데.

좀 짜증나더군요.

.NET Framework이 활성화되려면 runtime의 덩치가 좀 작아지던지

아니면 기본으로 포함되어 있는 OS의 보급이 이루어져야 할것입니다

Java도 JRE 1.4.2가 14.5MB 정도 됩니다. 그래서 사람들이 잘 안쓰죠.
Java의 문제가 .NET Framework에도 그대로 나타납니다.

Runtime의 크기가 줄어드는 것은 기대하기 어렵고..
새로운 Windows에서는 기본으로 들어있습니다. .NET Framework가 기존의 API를 대체하고.. 기존 API는 하위 호환을 위해 있는 정도죠.

saxboy의 이미지

글쎄요. 상황을 조금만 바꿔서 생각해보면 python 이나 perl 도 비슷하지 않을까요. 이런저런 바인딩을 생각해보면 오히려 더 복잡하지요. 하지만 리눅스커뮤니티에서 python이나 perl 을 별 거부감 없이 사용하는 이유는 대부분의 배포판에서 기본으로 설치해주기 때문이라고 생각하는데, .net 도 마찬가지가 아닐까 합니다.
하지만 .net 은 MS에서 윈도우에 끼워넣기라도 하겠지만, java 는 Sun 에서 어떻게 하지 않는 한은 아직도 멀었다는 생각이 드는군요.

저는 윈도우고 리눅스고 아무리 좋은 프로그램이라도 자바라는 단어만 보이면 바로 닫아버리는데 너무 익숙해져버렸네요.

rainblow의 이미지

아직까진 .NET Framework이 일반화 되지 않았지만, M$가 몇년안에 망하지 않는 이상 .NET도 분명히 한 분야를 차지할거라 생각되네요. 플랫폼의 배포문제도 자연스럽게 몇년 안에 해결이 될테죠.. M$ Window를 안쓰지만 않는다면..

제경험상 웹프로그래밍을 하는데는 분명 생산성이 괜찮았다고 보여지구요, 플랫폼 독립성이라는 java의 잇점도 어차피 웹 프로그램이 서버의 플랫폼을 이리저리 바꿀 필요가 없는 이상 언어독립적이란것도 충분히 메리트가 있다고 보여집니다.
가격적인 측면에서 봐도, java의 APP서버 가격 + Unix 보다는 win2K나 .NET서버에 기본으로 들어있는 COM+ 를 쓰게되면 훨씬 저렴하죠(그렇더라도 Linux에 비하면.. 쩝..)

서버프로그래밍이나 시스템 프로그래밍만을 하지 않는다면, 웹프로그램을 하시는 분께는 훌륭한 대안이 될수도 있다고 생각되는 플랫폼입니다..

그리고 개발도구만을 따지면 아직 visual studio 만한건 없지 않나요? (무겁다.. 라는 문제도 java를 기반으로 하는 다른 개발도구와 견주면.. )
물론 text에디터에서 개발하시는 분께는 너무 무겁겠습니다만..

brianjung의 이미지

윗글에서도 나오지만 펄이나 파이썬 같은 경우도 .Net이나 Java와 거의 다르지 않습니다. 필수적으로 요구되는 라이브러리들 깔면 용량 장난아닙니다.
다만 대부분의 배포판에서 기본적으로 포함이 되서 깔리기 때문에 그런것
뿐이죠.
.Net이나 Java는 따로 설치를 한다는 차이가 있구요.

그리고 이 크기 문제는 사용자와 개발자가 느끼는 체감의 차이가 있는데요.
개발자 입장에서는 10~20메가정도가 상당히 크게 느껴지지만 사용자입장에서는 그다지 큰 용량으로 다가오지 않습니다. 1시간 짜리 디빅 동영상도 6~700메가 되는데, 개발 라이브러리 용량이 20메가면 그다지 나쁜편 아니라고 봅니다.

KLDP는 대부분 사용자입장보다는 개발자입장이 강한듯 합니다.

코퍼스의 이미지

다른 분들에 비해 저는 행복한 사람이라 할 수 있겠네요.
리눅스에서 C로 프로그램 개발하는 사람이니까요.
(물론 임베디드 장비입니다.)

주 개발은 C로 하지만 그 외에 보조적인 툴이나 업무 외(?)의 일은 펄이나 bash 스크립트를 주로 씁니다.
(사실 파이썬은 주로 계산기로 쓰지요-_-;;)

VC는 4.0인가? 5.0인가로 바늘 시계 프로그램 짜보곤 걷어친게 다입니다.^^

음, 임베디드 장비 개발이나 개인의 작은 일을 처리하는 프로그램과,
기업 사무 환경에서 쓰이는 프로그램 등의 방식, 지향하는 바, 개발 방법등이 틀린 건 깊게 인지하고 있습니다만, 자바나 닷넷은 펄이나 파이썬에 비해 너무 느리고 거추장스러운(?) 것 같습니다.

결국, 자바나 닷넷이 기업업무 프로그램에 주로 쓰이는 건 그 환경에 필요한 여러 로직 등이 라이브러리 형태로 잘 지원되기 때문 아닌가요?

즉, 펄이나 파이썬도 확실한 IDE 환경과 함께 비지니스 로직등의 라이브러리 지원이 겸해진다면 닷넷이나 자바를 뛰어넘을 수 있는 것 아닌가요?

(잘몰라서 질문하는 것이 가르켜 주세요)

A few Good Man

meteors의 이미지

코퍼스 wrote:
자바나 닷넷은 펄이나 파이썬에 비해 너무 느리고 거추장스러운(?) 것 같습니다.

결국, 자바나 닷넷이 기업업무 프로그램에 주로 쓰이는 건 그 환경에 필요한 여러 로직 등이 라이브러리 형태로 잘 지원되기 때문 아닌가요?

즉, 펄이나 파이썬도 확실한 IDE 환경과 함께 비지니스 로직등의 라이브러리 지원이 겸해진다면 닷넷이나 자바를 뛰어넘을 수 있는 것 아닌가요?

기업용은 로직 부분은 조금 느려도 상관없습니다.
어차피 Database나 네트웍이라는게 느려서.. CPU는 놀고있으니..
(70년대에는 CPU가 통신 속도를 못따라갔다고 하죠..)

.NET같은 경우는 UI도 별로 느린것을 느끼지 못합니다. OS에서 제공하는 UI 위에 쓰기 편한 껍질을 얇게 깐 정도니까요.. Java의 Swing은 시스템 독립을 강조하다 보니 느리구요. 그래도 P4급에서는 못쓰겠다 정도는 아니지요.

여러가지 클래스나 메소드들이 잘 제공되는 편입니다. 그리고 작업환경이 좋고.. 미들웨어 같은 것들이 잘 받쳐주지요. (펄이나 파이썬은 받쳐주는 미들웨어가 있다는 얘기는 아직까지 못들어봤는데..)

뛰어넘으려면 리눅스와 Windows, Solaris에서 다 잘 돌아가는 미들웨어가 있고.. IDE같은 작업환경은 Windows 또는 리눅스 정도에만 있으면 되겠죠..

그런데 차라리 펄이나 파이썬에서 Java나 .NET VM code를 만들어주는게 더 현실적이라고 생각되네요. Sun, IBM이 미는 Java나 Microsoft가 미는 .NET 처럼 큰 회사가 밀어주지 않으면.. 먹고살기 힘든 현실에서 어렵다고 봐야죠..

icanfly의 이미지

Quote:

C++,VB, DELPHI 등등 -> MSIL 로 변형 -> CLR 구동
어떤 언어로 개발하더라도(닷넷을 지원하는) IL 로 변형이 된다음에 CRL 상에서 구동되는 겁니다.

솔직히 .NET 개념을 잘 모르고 알고 싶지도않지만..(-_-;)
어떤 언어로 개발하더라도 같은 결과를 내는건 아니지 않나요?..

제가 알기론 어떤 플랫폼이더라도 닷넷 플램폼이 이식되어 있으면, 제대로 돌아간다..정도로 알고있었는데...

어떤 언어로 개발해도 중단언어인 MSIL은 같은 코드가 생성되어 지나요?

그런게 가능한건지..

그리고 솔직히 닷넷플랫폼이 시간이 지난다 하더라도 리눅스, 유닉스환경으로

포팅될거같지는 않은데요. 어차피 윈도우즈 환경에서만 돌아가는거라면...

기존의 네이티브 어플리케이션이나 결과적으로 똑같지 않나요?

괜히 느려지기만하고..

MS의 거대하고도 야심찬 .NET 프로젝트를 잘 이해못하는 저로썬 의문 투성입니다.

근데 솔직히 이것저것 다 두드려 뭉쳐 놓으니까, 개발하기는 편합니다.

코드 단 5줄로 오라클DB내용을 긁어와서 리포팅하는 프로그램이 완성되니 그것도 각종 오피스파일로 내보내기가 되는....

좋긴 좋은데..개떡같은건 맞잖아요..^^

참 그리고 MinGW를 언급한건 직접적인 비교라기 보다는.....

아시다시파 MinGW통합환경이 VS6를 거의 카피한 환경이라 쓰기 편하단

말을 한것인데.... 역으로 생각하면 통합환경의 편리성은 VS6가 우수했다는

말이 되는데요. 사실 가끔 GDB같은걸 커맨드식으로 돌려도보는데 솔직히 그쪽도 적응하기 어렵긴 마친가지고...DDD같은 걸 돌려봐도 왠지 껄끄러운 느낌은 들고... VS6정도면 어려모로 딱 좋겠다 싶은 생각입니다.. ^^

brianjung의 이미지

개떡같죠...

kuma의 이미지

VS.NET 은 .NET 개발 환경을 포함하는것 아닌가요?

VC++ 은 그대로 VC++ Ver 6.0 에서 Ver 7.0 으로 올라와서 ( C99 를 아직도 다 지원하지 못한다고 판단되지만 ) .NET 개발 환경을 포함 하는것 뿐이지 않나요?

UI 컴포넌트는 .NET 때문에 느려졌는 확인을 못했지만 여전히 API 나 기타 MFC Class 는 여전히 6.0 과 똑 같은 결과를 내는것 같습니다. ( .NET 2003 에서 컴파일 한것과 VS 6.0 에서 컴파일 한것을 사이즈와 코드 디버깅을 해보면 같은것 같습니다. )

확연히 느껴지는 느림이란 IDE ( .NET 개발환경 ) 구동시 시간이 많이 걸린다는 것과 편집시 버벅임입니다.

위분 글중에 실행 화일이 10~20메가 늘어나는것은 문제가 되지 않는다고 하셨지만 제 생각에는 다른 견해를 가집니다.

비디오 화일이 600~700메가 하는것과 실행화일이 10~20메가 늘어나는것은 경우가 틀리다고 생각합니다.

비디오 화일은 순간 순간 계속 로딩을 시켜서 동영상을 보는것이지만 실행화일은 사이즈가 크면 스왑이 발생하게 되므로 가능한 불필요한 라이브러리는 제거하고 작게 만들려고 노력들을 합니다. 물론 경우에 따라 조금 틀리겠지만 ^^
( 컴쟁이는 항상 메모리와 CPU 시간의 노예 아닌가요? ^^ )

꼬랑지 :
.NET 개발환경을 쓰기 위해선 P-4 에 DDR 512MByte 이상이 요구되는것 같습니다. ( P3 이고 DDR 이 아니어도 메모리 512MByte 이상이면 불편함은 크게 느낍니다. )

icanfly의 이미지

말씀하신거 처럼...
C++을 제외한 .NET 개발 도구들은 .NET 환경을 벗어 날수 없는것으로 알고있습니다.

C#.NET같은 애들은 배포할때 .NET FX가 없으면 징징 대지요. C++은 여전히 이전과같은 명맥을 유지하지만, 솔직히 왜 그렇게 했는지 잘 모르겠지만,

MS에서는 신생개발자나 기존 개발자들을 VB.NET, C#.NET으로 이전을 빠르게, 많이 시켜서 더이상 .NET환경이 아니면 개발할 수 없게 하려는 의도가 있지 않나 생각됩니다. MSDN 같은데 보면 예제 코드들이 이젠 거의 VB, C#으로만 되있고, C++은 취급도 안해주더군요.
VB, C#만 알고있는 개발자들이 많이 생겨나면, 저절로 MS배는 불러 오겠지요. 꼭 그렇게 까지 안해도 지금도 상황은 별로 다른거같지 않지만, 그래도 확인사살이라는 의미가 있지 않을까요..순전히 제생각이었습니다...

rainblow의 이미지

음.. 저도 윈도우 쪽에서 하다가 linux로 플랫폼을 변경하고, 지금 공부중이지만,..
(윈도우에서 개발했지만, 어차피 서버프로그래밍을 했던터라, UI랑은 별 관계는 없었고,
결정적으로 잘 모릅니다. -_-;; )
사실 개발자 입장에서야.. 편한걸 쓰면 되는거죠..
개발자들 끼리 자신의 언어나 플랫폼으로 보면 많은 토론들 하고, 어떨때는 감정싸움으로까지
번지기도 하는데.. 제입장에서는 ..
어떤게 선이다, 어떤게 악이다.. 라는 기준은 없지 않나요?

편하고 불편하고의 기준도 그사람이 어디서 시작했는지가 더 중요하지 않나요?
저는 MFC를 거의 못쓰지만, MFC부터 프로그램을 시작한 분은 테스트를 하기 위해서도
UI가 있는 프로그램을 만들더군요.
그렇다고 그런 분이 테스트 프로그램을 만드는 속도가 console에서 command로 돌리는
간단한 테스트 프로그램보다 느리다거나 하는건 모르겠습니다.
어차피 자기한테 익숙하니까요.
unix console에서 개발하신분들에게는 vi같은 tool이 최고의 개발도구가 되겠지만, 익숙한 사람에게는
visual studio처럼 프로젝트 관리해주고, tree구조로 프로그램 일목요연하게 보여주는게 없으면
무척 불편하죠. 말그대로 불편한거죠..
머 개떡같을것 까지야..

개발환경은 제 회사 컴터는.. P3 933에 512 M 인데 구동시간이 오래 걸려서 그렇지 일단 띄워놓고 보면
느리다는 생각은 안들던데요.. 다른분은 ibm 128m 놋북에서도 참고 개발하시기도 하구요..
참, 그리고 .NET을 개발하기 위해서 반드시 Visual Studio가 필요한건 아닌걸로 알고있습니다.
오히려 고수들은 커맨드 라인에서 해볼것을 권하던데요..

배포 환경은.. 쩝.. java도 마찬가지고.. .py파일 혼자는 안 돌지 않나요?
오히려 우리나라 같이 많은 사람이 window를 쓰는 곳에서 java나 python으로 개발하면 배포파일의 덩치가 더 커지겠죠.. .NET은.. 쩝.. 앞으로 나올 윈도우 운영체제에는 플랫폼 배포는 불필요할거구요..

어차피 남의나라 tool인데, 언어는 tool 이상도 이하도 아니라고 생각합니다.
자기가 익숙한거를 알맞은 분야에 적용해서,
잘 쓰기만 하면 된다는 생각입니다.

perky의 이미지

bedro2001 wrote:
어차피 남의나라 tool인데, 언어는 tool 이상도 이하도 아니라고 생각합니다.
자기가 익숙한거를 알맞은 분야에 적용해서,
잘 쓰기만 하면 된다는 생각입니다.

python은 제가 지적재산권에 약간(전체 62표중의 1표)의 영향을 미칠 수 있으니 약간은 남의 나라 툴이 아니라고 보셔도 됩니다. ;) 물론 61/62는 남의 나라.. :oops:

You need Python

Risty의 이미지

학교 연구실에서 개발 도구를 VS.net으로 쓰고 있습니다.

2002년에 입학하면서 컴퓨터가 펜4 1.6기가, 램 256짜리가 나왔는데, 며칠만에 용산에 가서 램 256메가를 하나 더 샀습니다. 랩에서 만드는 프로그램의 개발 단위가 DLL이라서, 참조도 하고 고쳐야 할 것도 가끔 보여서 IDE를 여러개 띄워야 하는 경우가 많았는데, 한 세개 쯤 띄우면 256메가 시스템에서는 도저히 버벅여서 못 쓰겠더군요.

VS 6과 비교해서 편한 점도 많고 결과물도 괜찮았지만, 메모리 많이 먹는 문제는 도저히 어쩔 수 없더군요.

wildkuz의 이미지

:twisted:

닷넷이 매력적이라고 느낀 사람은 저밖엔 없는 것 같네요. --;
다른 언어에서 만든 클래스도 상속받을 수 있고, 바로 디버깅도 가능하고, xml shema도 자동으로 만들어주고,...... ^^;

JPython이나 JScheme을 컴파일 하면 JVM 에서 돌아가듯이, MSIL로만 만들수 있다면 웬만한 언어들은 닷넷 CLR에서 돌릴 수 있겠죠. 실제로 다른 언어 컴파일러(닷넷용)를 가져다 붙이기만 하면 되구요.

그리고 .net for linux인 Mono프로젝트도 있습니다.

You may say I'm a dreamer.
But I'm not the only one.

B00m의 이미지

저는 요즘 .net 2003 로 VC++7.1 을 쓰고 있는데 얼마전에 툴의 버그때문에 한 3시간을 고생한적이 있습니다..

저희 회사 개발자 이야기를 들어보니 아직 VC7은 버그가 많아 회사 정책적으로 아직 사용을 하지 말자는 얘기를 하더군요

VC6 은 컴파일러쪽에 아직 지원안되는 문법도 많고 STL 도 표준과 좀 다른것도 있어 사용하기 싫은데 고민 중입니다..

그리고 .net 개발툴이 무거운건 사실입니다. 예전에 VC6은 5개씩 뛰우고 쓰고 했는데 VC7은 두개만 뛰어도 넘 벅차더군요.. 하지만 하드웨어가 계속 좋아지니 이런 문제는 곧 해결되니라 봅니다..

hyunuck의 이미지

icanfly wrote:
Quote:

C++,VB, DELPHI 등등 -> MSIL 로 변형 -> CLR 구동
어떤 언어로 개발하더라도(닷넷을 지원하는) IL 로 변형이 된다음에 CRL 상에서 구동되는 겁니다.

솔직히 .NET 개념을 잘 모르고 알고 싶지도않지만..(-_-;)
어떤 언어로 개발하더라도 같은 결과를 내는건 아니지 않나요?..

제가 알기론 어떤 플랫폼이더라도 닷넷 플램폼이 이식되어 있으면, 제대로 돌아간다..정도로 알고있었는데...

어떤 언어로 개발해도 중단언어인 MSIL은 같은 코드가 생성되어 지나요?

그런게 가능한건지..

그리고 솔직히 닷넷플랫폼이 시간이 지난다 하더라도 리눅스, 유닉스환경으로

포팅될거같지는 않은데요. 어차피 윈도우즈 환경에서만 돌아가는거라면...

기존의 네이티브 어플리케이션이나 결과적으로 똑같지 않나요?

괜히 느려지기만하고..

MS의 거대하고도 야심찬 .NET 프로젝트를 잘 이해못하는 저로썬 의문 투성입니다.

근데 솔직히 이것저것 다 두드려 뭉쳐 놓으니까, 개발하기는 편합니다.

코드 단 5줄로 오라클DB내용을 긁어와서 리포팅하는 프로그램이 완성되니 그것도 각종 오피스파일로 내보내기가 되는....

좋긴 좋은데..개떡같은건 맞잖아요..^^

참 그리고 MinGW를 언급한건 직접적인 비교라기 보다는.....

아시다시파 MinGW통합환경이 VS6를 거의 카피한 환경이라 쓰기 편하단

말을 한것인데.... 역으로 생각하면 통합환경의 편리성은 VS6가 우수했다는

말이 되는데요. 사실 가끔 GDB같은걸 커맨드식으로 돌려도보는데 솔직히 그쪽도 적응하기 어렵긴 마친가지고...DDD같은 걸 돌려봐도 왠지 껄끄러운 느낌은 들고... VS6정도면 어려모로 딱 좋겠다 싶은 생각입니다.. ^^

1. 일단 어떤 랭귀지던(닷넷을 지원하는) MSIL로 변형되어 실행되는건 맞습니다.
하지만 정확히 똑같은 IL 로 생성되는건지는 잘 모르겠군요. (큰 차이가 없으리라고 생각되어집니다.)

2. .NET을 이해하지 못하신다고 하셨는데, 생각보다는 간단한것 같습니다.
J2EE 하고 비슷하다고 보시면 됩니다. (화가 날정도로 모방해서 만들었으니 당연히)
눈에띄게 다른점이 있다면 멀티랭귀지 지원이라는점....

3. '개떡같다' 고 하셨는데 생산성 측면에서보면 그렇지 않습니다.
같은일을 다른도구로 한다고 생각해 보세요... @.@~~~~
개발자를 바보로 만든다고 하신다면 동의합니다.(닷넷이 말고, 비주얼 스튜디오가)

죠커의 이미지

저는 VS.net이 무거운 빼고는 크게 욕먹을 만한 부분은 없는 것 같던데요.

.net도 생각보다는 가볍구요.

죠커의 이미지

icanfly wrote:
어떤 언어로 개발해도 중단언어인 MSIL은 같은 코드가 생성되어 지나요?

gcc 역시 RTL이라는 중간언어를 컴파일 과정에 사용합니다. 이 중간언어를 인터프리터에 실행하느냐 아니면 기계언어로 번역하느냐의 차이겠지요.

물론 중간 언어 자체의 한계로 구현하기 힘든 상황이 나올 수 있겠습니다만 JAVA의 Byte code에 비해서는 MSIL은 더 유연합니다.

icanfly wrote:
참 그리고 MinGW를 언급한건 직접적인 비교라기 보다는.....

아시다시파 MinGW통합환경이 VS6를 거의 카피한 환경이라 쓰기 편하단

MingW 통합환경이라는 것은 Dev-Cpp을 의미하시는 것 같은데요. Visual C++ 6.0과 Dev-Cpp 모두 좋은 툴은 아니라고 봅니다. 그나마 Visual C++ 6.0은 만국민의 툴 Visual Assist가 있군요.

lacovnk의 이미지

.net 개념은 매력있지 않나요? :) 주력언어?인 c#의 GUI 프로그램 만들기도 재밌어보이고..

툴의 무거움은 툴의 문제이겠죠 :)

2005 express edition 써봤는데 vs.net 2002보다 훨씬 낫더군요. 시간이 약이려나..

그나저나 개발툴이 너무 친절하거나, 너무 겹겹이 쌓여있는 건 동감합니다. 그냥 간단한 interface도 제공하면 좋을텐데...

그냥 editplus로? :)

ydhoney의 이미지

lacovnk wrote:
.net 개념은 매력있지 않나요? :) 주력언어?인 c#의 GUI 프로그램 만들기도 재밌어보이고..

툴의 무거움은 툴의 문제이겠죠 :)

2005 express edition 써봤는데 vs.net 2002보다 훨씬 낫더군요. 시간이 약이려나..

그나저나 개발툴이 너무 친절하거나, 너무 겹겹이 쌓여있는 건 동감합니다. 그냥 간단한 interface도 제공하면 좋을텐데...

그냥 editplus로? :)

editplus는 사실 디버깅하기에 약간 불편하지요. ^^

editplus를 gdb와 함께 효과적으로 연동할 수 있는 방법이 있다면 하는 생각을 하곤 합니다.

단순히 gcc와뿐만이 아니라 아무래도 편집기들의 특성상 전용 IDE에 비해서 불편한것은 사실입니다. 어쩔수 없는 점이겠지요? ^^

cppig1995의 이미지

.exe 와 같은 실행 파일 대신 MSIL,
.exe 를 그냥 실행하는 것 대신 .NET 이 MSIL 을
즉시 컴파일 (JITC; Just-in-Time Compile) 하는 것뿐입니다.

그나저나, 비디오방 관리 프로그램 정도라면
전 Turbo C 2.0 을 적당히 이용해
(curses 비슷한) conio 라이브러리를 써서
MS-DOS 로 개발하고 싶습니다만. :twisted:

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

배추의 이미지

rainblow wrote:

어차피 남의나라 tool인데, 언어는 tool 이상도 이하도 아니라고 생각합니다.
자기가 익숙한거를 알맞은 분야에 적용해서,
잘 쓰기만 하면 된다는 생각입니다.

그러면 운영체제나 cpu 는요?

제아이디와비번은 배추, 12ws 입니다.

kalstein의 이미지

저도 MS를 이뻐라~ 하는건 아니지만 나쁜짓은 나쁜거고, 좋은건 좋은겁니다. 특히나...편하디편한 IDE와 MSDN의 구축은 개발자 입장에서 매우 칭찬해줄만한 것이라고 봅니다만.

개발환경이 vs.net 2003이라고 해도 MFC라던가 그냥 C++ 개발시엔 MS에서 vc++ 7.1 컴파일러를 매우. 아주. 특이하게도. :wink: ANSI C++ 표준안에 gcc보다 더욱 표준스럽게 만들어줘서...(7.0버젼도 상당히 표준안에 가깝습니다만 더욱 가까워진....2005버젼의 8.0은 더더욱 -.-;; MS가 갑자기 이상한 짓을 하는듯한 느낌이 들죠? ㅎㅎ) 꽤 만족해 하고 있습니다.

다만...VC++로 Managed code, 즉 .NET 어플리케이션을 만들때가 좀 문제인데요. 그부분만은 참 개떡-_-같죠...문법이 개판입니다. 아주 쓰기 어렵죠. 그 덕택에...2005버젼부터는 기존의 .NET 문법을 버리고 C++/CLI 라는 새로운 문법을 들고 나왔는데....자세히는 보지 않았지만 2003버젼에 비하며 너무나도 깔끔해 졌더군요. 실제로 사람들도 많이 기대를 했구요. 반응들도 좋아보이더군요.
약간 무거운건...인정해야죠. 6.0에 비하면 무진장 무겁죠...그치만 요새 일반적인 사양에 비한다면 그렇게까지 무거울 건 없다고 봅니다.

그리고 닷넷 관련 배포문제. 닷넷 런타임 모듈이 20메가 가량해서 불평을 하시는데...글쎄요? 업데이트를 꾸준히 하시는 클라이언트라면 닷넷 모듈은 이미 인스톨 되어있을 가능성이 무진장(!) 높습니다. 기본 업데이트로 넣어버렸거든요. 그리고...2003을 쓰는 서버라면 기본적으로 되어있구요.

문제는....95,98버젼을 사용하는 클라이언트가 문젭니다. 닷넷이 아예 안깔리거든요 -.-;;; 가끔...2000이상에서 깔았는데 오동작하는 컴터가 있다더군요. (몇년동안 윈도 재설치를 안한 컴퓨터들) 그런게 가장 큰 문제죠...

솔직히...그냥 에디터로는 울트라 에디터를 사용중인데...참 편하긴 합니다만...아무래도 코딩 전용 에디터가 아닌, 범용 에디터란 점에서 한계가 분명히 있습니다. 젤 좋은 방향은....역시....VS 6.0에다가 컴파일러만 2005버젼용으로 까는게 행복할듯 싶습니다만....가능한가요? 잘 몰라서 그냥 2003 or 2005를 사용중입니다 ^^;


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

kalstein의 이미지

kuma wrote:
VS.NET 은 .NET 개발 환경을 포함하는것 아닌가요?

VC++ 은 그대로 VC++ Ver 6.0 에서 Ver 7.0 으로 올라와서 ( C99 를 아직도 다 지원하지 못한다고 판단되지만 ) .NET 개발 환경을 포함 하는것 뿐이지 않나요?

UI 컴포넌트는 .NET 때문에 느려졌는 확인을 못했지만 여전히 API 나 기타 MFC Class 는 여전히 6.0 과 똑 같은 결과를 내는것 같습니다. ( .NET 2003 에서 컴파일 한것과 VS 6.0 에서 컴파일 한것을 사이즈와 코드 디버깅을 해보면 같은것 같습니다. )

확연히 느껴지는 느림이란 IDE ( .NET 개발환경 ) 구동시 시간이 많이 걸린다는 것과 편집시 버벅임입니다.

위분 글중에 실행 화일이 10~20메가 늘어나는것은 문제가 되지 않는다고 하셨지만 제 생각에는 다른 견해를 가집니다.

비디오 화일이 600~700메가 하는것과 실행화일이 10~20메가 늘어나는것은 경우가 틀리다고 생각합니다.

비디오 화일은 순간 순간 계속 로딩을 시켜서 동영상을 보는것이지만 실행화일은 사이즈가 크면 스왑이 발생하게 되므로 가능한 불필요한 라이브러리는 제거하고 작게 만들려고 노력들을 합니다. 물론 경우에 따라 조금 틀리겠지만 ^^
( 컴쟁이는 항상 메모리와 CPU 시간의 노예 아닌가요? ^^ )

꼬랑지 :
.NET 개발환경을 쓰기 위해선 P-4 에 DDR 512MByte 이상이 요구되는것 같습니다. ( P3 이고 DDR 이 아니어도 메모리 512MByte 이상이면 불편함은 크게 느낍니다. )

구동이 느리고 메모리 많이 먹는건...VM의 한계로 보여집니다만...자바도 어쩔수없죠? 그래도 자바보단 돌아가는게 빠릅니다; (자바도 SWING인가...그런 스탠다드모드 말고...좀 빠르게 돌리는게 있다더군요. 그거쓰면 비슷하겠죠?) 글구...실행 메모리를 많이먹는건...글쎄요. 엄청난 차이가 있어보이진않습니다...그리고 스와핑은 여기저기 랜덤하게 전역적으로 프로그램 코드가 실행되지않는다면 큰 이슈가 되진 않습니다.

B00m wrote:
저는 요즘 .net 2003 로 VC++7.1 을 쓰고 있는데 얼마전에 툴의 버그때문에 한 3시간을 고생한적이 있습니다..

저희 회사 개발자 이야기를 들어보니 아직 VC7은 버그가 많아 회사 정책적으로 아직 사용을 하지 말자는 얘기를 하더군요

VC6 은 컴파일러쪽에 아직 지원안되는 문법도 많고 STL 도 표준과 좀 다른것도 있어 사용하기 싫은데 고민 중입니다..

그리고 .net 개발툴이 무거운건 사실입니다. 예전에 VC6은 5개씩 뛰우고 쓰고 했는데 VC7은 두개만 뛰어도 넘 벅차더군요.. 하지만 하드웨어가 계속 좋아지니 이런 문제는 곧 해결되니라 봅니다..

VC7은 좀 자질구레한 버그가 있었다고 하더군요. 그래서 고쳐서 나온게 VC7.1입니다. vs2002 -> vs2003 이죠. VC6쓰려면...특히 STL쓰시면...STLPort 안쓰면 좀 난감하죠;; 이것저것 안되고 느리기까지...ㅋㅋ VC7.1에선 다 해결되서 STLPort 쓸일은 별로 없더군요.


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

tinywolf의 이미지

저도 2003.net 사용하기 시작한지 얼마안되었지만..
클래스 위자드가 없어서 잠시 당황스럽기도 했으나..
지금은 그럭저럭 잘 사용하고 있습니다.

vc++6을 그다지 심도깊게 사용하지 않아서 그럴지도 모르겠으나..
제일 처음 화면배치나 단축키 스타일을 vc++6으로 맞춰놓고 사용하니.
프로젝트 셋팅에서 조금 헤맸지만..
vc++6보단 좋아보이던데요..

ㅡ_ㅡ;

unipro의 이미지

작년에 visual studio 6에서 작업할 땐, 제공하는 IDE툴을 사용했습니다. 올해 지금은 visual studio 2005를 쓰면서 프로그래밍을 emacs로 하고 있습니다. 디버깅만 visual studio로 하고 있습니다.

emacs와 visual studio6는 익숙한데, vs 2005는 아직 시간이 필요한 것 같습니다. 작업하면서 느낀 건데, 윈도우즈에서 Makefile도 굉장히 쓸만한데요.

처음 visual studio 6를 접했을때도, 편집은 emacs로 작업하고 나머지를 vs6로 했었는데, 점점 vs6에 익숙해지면서 완전히 vs6로 넘어갔었죠. 지금도 대강 그때와 비슷하지만, 컴파일 환경을 emacs에 세팅을 했기때문에, vs2005를 디버깅툴만 사용하고 있습니다.

vs2005에 적응을 못하는 가장 큰 이유는 기능이 방대해지고 덩치가 커진 것이 아닐까 합니다. vs2005가 익숙해질때까지는 회사 프로젝트는 당분간 emacs로 할 계획입니다.

내 블로그: http://unipro.tistory.com

kimkh0304의 이미지

저는 vs.net 2003 마음에 듭니다..
vc 6.0 을 쓰다가 vs.net 2003 으로 바꿨는데.. 가끔 느려지는 거 외엔 불편함은 없더군요...
요즘은 2003의 새 기능에 익숙해져서인지 6.0 를 다시 쓰려고 하면 너무 불편하네요.. 다이얼로그 편집 기능이나 IntelliSense등..
얼마전 무료로 배포된 2005 Express Edition도 그리 무겁지도 않고 기능도 더 많아진 것 같네요..

배추의 이미지

그러고보니 "조엘 온 소프트웨어"도 .net에 대해
뭐라 그러더 군요. 문제가 있긴 있나 보네요.

제아이디와비번은 배추, 12ws 입니다.

happyjun의 이미지

배추 wrote:
그러고보니 "조엘 온 소프트웨어"도 .net에 대해
뭐라 그러더 군요. 문제가 있긴 있나 보네요.

아마 조엘의 불만은 .net이 엑셀을 이용해서 만들지 않았기 때문일겁니다. :D

----------------------------------------
http://moim.at
http://mkhq.co.kr