강력한 프로그래밍 언어의 조건?

권순선의 이미지

http://slashdot.org 에 흥미로운 이야기거리가 올라와서 이곳에 그대로 옮겨 봅니다. slashdot의 기사내용은 관련 링크를 참조하십시오.

A not-so Anonymous Coward queries: "My company is about to start development on a new project, and I have to decide on a language and development environment. My boss gave me a set of criteria which needs to be filled: intuitive and easy to use IDE; simplified GUI design and event handling; advanced error handling; advanced object oriented design including multiple inheritance, abstract classes, and garbage collection; full support for operator and function overloading; and portable (at compile-time) across various platforms. I have already looked at C++, Java, C++, C#, Eiffel, and even VB.net; I may be missing something but as far as I can tell all of these languages are missing something from this list. Is there a language available that has all of these features? I thought that someone from Slashdot would be able to point me in the right direction?" If you were to design a language from the ground up, what features would you include and why?

조기태의 이미지

말씀하시는 '함수형 언어'에 대한 명확한 개념이 없어서 질문 드리는 겁니다.

garbage collection, generics, anonymous class, stateless component 등이 함수형 언어에서 왔다고 하시는데 저로서는 아무리 짐작해도 객체지향과 같은 공통적인 사상을 찾기 어렵더군요. 간략하게라도 함수형 언어와 객체지향 언어의 개념 비교를 해주실 수 있는지 궁금합니다. (위의 헤스켈의 예는 흥미롭더군요)

거의 전적으로 자바만을 다룬 제가 이해하는 위의 특성들이 가지는 장점은,

(1) 가비지 콜렉션 - 메모리 관리를 자동화 해줌으로써 개발자에게 불필요한 저수준의 디테일을 처리하는 부담을 덜어준다.

(2) generics - Collection 등의 처리에서 아이템의 형에 대한 선언을 컴파일 타임에 처리하기 때문에 모호성과 런타임에러의 위험을 없앤다.

(3) anonymous class - 이벤트 핸들러, Runnable(쓰레딩 가능한 클래스) 등과 같이 어느 특정 메소드만 오버라이드할 필요가 있을 때 구현을 보다 쉽게 해준다.

(4) stateless component (stateless session bean) - 두 가지 경우로 나눌 수 있습니다. 하나는 컴포넌트가 표현하는 것이 호출하는 객체의 identity와 크게 상관 없는 업무의 특정 "프로세스"에 해당할 때이고, 두 번째는 호출자와 관계있는 프로세스를 구현하고 있지만 stateful session bean을 쓸 때 발생하는 오버헤드가 문제가될 때 사용합니다.

이 정도로 이해하고 있지만 네 가지의 공통점은 쉽게 짐작하기 어렵군요. 특히 (4)번 같은 경우는 객체지향 언어의 단점을 보완하는 특성으로 생각하긴 좀 무리가 있는 것 같습니다.

함수형 언어에 대해 좀 더 구체적으로 알면 도움이 될 것 같군요...

익명 사용자의 이미지

객체지향형 언어와 함수형 언어가 서로 대치되는 건가요?
저도 궁금합니다...
제가 이해하기로 객체지향이라는 개념은 숨기기와
재사용하기라는 아이디어를 구체화하기 위한 것이라고
봅니다. 가비지 콜렉션은 리스프를 개발할 때 기술적인
필요성 때문에 만들어진 것이다가 객체지향이라는 철학의
카테고리로 끌어 들여진 것이겠죠?
(제 말의 요지는, 객체지향을 구현하기 위해 가비지 콜렉션이
고안되고 개발된 것이 아니라 가비지 콜렉션이 쓰이고 있었는데,
저거 객체 지향 개념에 어울리는 기술인거 같다고 생각하여
학자들이 끌고 왔다는 것입니다.)
클래스 개념도 최초의 아이디어는 어디인지 잘 모르겠습니다만,
당시 실험실 언어로 리스프가 널리 사용되었었기 때문에 리스프
상에서 많은 객체 지향 실험이 이루어졌던 것으로 알고 있습니다.
지금 리스프의 표준이라 할 수 있는 common lisp에도 CLOS라고
객제 시스템이 있습니다. CLOS를 주로 사용하는 사람에게는 리스프도
객체지향 언어라고 할 수 있으리라고 생각합니다.
뭐가 문제가 되는 것인지 알쏭달쏭하네요~~

익명 사용자의 이미지

OOP와 함수형은 대치되는 개념이 아닙니다.
함수형(functional)과 명령형(imperative)가 대치라고 하면 대치겠죠..
현재 실상에서 많이 쓰이는 c++, java같은 언어가 모두 명령형이기에 oop 언어로
착각이 되기 쉽습니다. 이것은 잘못된 생각입니다.

oop 언어란건 존재하지 않습니다. 모든 언어가 oop의 성격을 띌수 있으며,
자바나 씨뿔뿔과 더불어 함수형 언어들도 oop의 성격을 가지고 있습니다.
oop 언어라고 쉽게 불리는 자바나 씨뿔뿔과 같은 언어들은 과거 언어들에
비해 oop 개념을 더 많이 쓴다는데 oop라고 불리워진다고만 생각하시면
편하실겁니다.

벌써 너무나 진행된 논쟁이기에 제가 덧붙일건 없을듯 싶군요..

익명 사용자의 이미지

brainfuck... 농담이에여-_- 노려보지들마셍.

스카리의 이미지

최고가 되던 최상이 되던.. 개발자는 개발을 위해 언어를 선택할때마다
그 시점에서 가장 '적절한' 언어를 선택해야만 합니다.
'적절한'이라는 단어의 의미는 그 개발자가 어떤 입장인가에 따라서
달라지겠죠.

회사에서 월급을 받으며 일하는 개발자라면 아마도
기대되는 퍼포먼스와 함께 개발비용, 개발속도도 생각해야할겁니다.
저같이 놀고 먹는 학생이라면, 퍼포먼스와 재미.. 정도?를 생각하겠네요.

못을 박는데는 망치를 쓸 수도 있고 돌을 쓸 수도 있지요
못을 박는다는것만 보면 망치가 최상의 선택이고,
물제비를 뜰때는 망치보다(!!) 납작한 돌이 최상이듯
그때마다 다른겁니다.

자바, C#, C++, C 이런 도구들이야 열거하면 뭐합니까.
각각 나름대로의 장점이 있고 쓰이는데가 있지요.

하물며 각 언어의 차이도 제대로 모르는 개발자가 태반인데
-특히 C/C++ 은 아예 거의 같은 언어로 생각하는 사람들이
너무나 많더군요 :-(

최상, 혹은 최고의 언어는 뭔가를 이야기하기보다는
가장 범용적인 언어가 무엇인가를 생각해보면
아마도 C 정도가 되지 않을까 싶습니다.

많은 사람들에게 아직도 C는 '거쳐가는 언어' 이고..
저처럼 시스템 프로그래밍을 공부하는 사람에게는
유일하면서도 필수인 언어가 C 죠.

최소한 두가지이상의 언어에 대해 '완벽하게' 이해하지도
못하고 어떤 언어가 최상인가를 따지는것은
좀 우습기도 합니다. ^^;

개발자로써 엘리트코스를 밟은 사람이라면, 자기 욕심이 많은 사람이라면
최소한 10여개의 언어는 거쳐가지 않나요?
그중에 어떤 언어가 최고라고 말할만큼 그 언어들에 대해서
잘 알고나서 토론을 한다면 더 유익한 토론이 될거 같네요..

그냥 잡답입니다.

익명 사용자의 이미지

가장 강력한 언어라..

배우기 가장 어렵고 복잡하고 코드가 복잡해서 남들이 알아보면 어려워 보이는..
쿠쿠

익명 사용자의 이미지

ㄴ ㅑ ㅎ ㅏ ㅎ ㅏ..

ㅍ ㅏ ㅅ ㅋ ㅏ
ㅡ ㄹ

이 최 고 얌!!! -_-;;

좋은 언어와 최고의 언어는 분명히 다른것이겠죠..

익명 사용자의 이미지

앗 글씨 망가졌다~;;

파스칼 .. 알라뷰~~~;;

-_-;; 지성..

tweni의 이미지

1. C언어
2. Assembly
3. C++

1은 Unix, Linux의 시스템을 이해하는데 뿐만 아니라 다양한
종류의 시스템 프로그램을 작성할 수 있는 최적의 언어이다.

적어도 시스템 프로그래머나 시스템 엔지니어라면 반드시 아
주 자알~~~ 해야만 하는 언어라고 생각한다.

2쓰임새는 많지 않으나...

반드시 알아야 할 언어. 말이 필요없지 않나요?

특히 Linux나 Window에서 노시는 분들, 간지로운 곳을 시원
하게 긁어줄 것은 역시 이 언어 밖에는 없다고 생각됩니다.

3 C가 파워풀하고 유용하기까지 하지만 역시 한가지 빠진게
있다면 OOP아니겠습니까?

기왕 OOP를 하겠다면 OOP의 원조격이면서 어느정도(!) 유용
한 이 랭귀지를 강추해야겠죠?

그외의 랭귀지, 툴은 위 세가지 언어의 파생(?) 정도로 생각
합니다.(표현이 심한가?)

몇가지 더 열거하자면...

JAVA --> 쓰임새는 많으나, 속도가 느리고 시스템을 깊이있
게 공부하여 내공(?)을 쌓기에는 역부족.

또한 C++ 공부한 사람이면 순식간에 습득가능하다.

C# --> 쓰임새가 많은 것 같으나, 솔직히 위 세개 언어에 능
숙하다면야 거저 먹고 들어갈 것 같음.

쓰임새로 보면야 답변이 다 틀릴 수 있으나 시스템을 이해하
는 것을 기준으로하면 제말이 정답에 가깝지 않을까 생각합
니다.

익명 사용자의 이미지

전제를 이렇게 놓고 시작하는게 낫지 않겠습니까?
어느 언어가 범용적인 프로젝트 수행에 가장 최적인가?
그러면 객관적으로 일반 어플은 C++,웹 기반 서비스는 자바가
가장 많은 표를 얻지 않을까요?
(어느 언어가 최상이냐기 보다는 어느 언어가 시장의 선택을 가장
많이 받느냐가 기준이라 해야 겠습니다)

>1. C언어
>2. Assembly
>3. C++
>
>1은 Unix, Linux의 시스템을 이해하는데 뿐만 아니라 다양한
>종류의 시스템 프로그램을 작성할 수 있는 최적의 언어이다.
>
>적어도 시스템 프로그래머나 시스템 엔지니어라면 반드시 아
>주 자알~~~ 해야만 하는 언어라고 생각한다.

범용적이지는 않죠. 지금 프로젝트를 해야 할 텐데 운영체제나
컴파일러 이론 공부하려는 거 아니지 않을까요?

>2쓰임새는 많지 않으나...
>
>반드시 알아야 할 언어. 말이 필요없지 않나요?
>
>특히 Linux나 Window에서 노시는 분들, 간지로운 곳을 시원
>하게 긁어줄 것은 역시 이 언어 밖에는 없다고 생각됩니다.

역시 범용적이지 않죠. 지금 프로젝트를 해야 할 거니까요...

>3 C가 파워풀하고 유용하기까지 하지만 역시 한가지 빠진게
>있다면 OOP아니겠습니까?
>
>기왕 OOP를 하겠다면 OOP의 원조격이면서 어느정도(!) 유용
>한 이 랭귀지를 강추해야겠죠?

역사 왜곡에 해당하지 않을까요? C++을 OOP의 원조라고
하시다니요?

>그외의 랭귀지, 툴은 위 세가지 언어의 파생(?) 정도로 생각
>합니다.(표현이 심한가?)

표현이 심하신 게 아니라 역사 왜곡에 해당한다고
봐야 겠죠:<

>몇가지 더 열거하자면...
>
>JAVA --> 쓰임새는 많으나, 속도가 느리고 시스템을 깊이있
>게 공부하여 내공(?)을 쌓기에는 역부족.

역시 범용적인 평가가 아닙니다. 지금 프로젝트를 수행하여야
하기 때문에~~

>또한 C++ 공부한 사람이면 순식간에 습득가능하다.

자바에 대한 신화 아닐까 싶습니다.
과연 C++ 공부한 사람은 자바를 순식간에 정복
가능할지요... 어떻게 보면 자바는 최초의 대중적인
객체 지향 언어라고 해야 할 텐데 말입니다.
그전에 그렇게들 정확하게 C++로 OOP하고 계신 분들이
많았을지 의심스러워 하는 소리입니다.

>C# --> 쓰임새가 많은 것 같으나, 솔직히 위 세개 언어에 능
>숙하다면야 거저 먹고 들어갈 것 같음.

전 C#은 전혀 모릅니다.

>쓰임새로 보면야 답변이 다 틀릴 수 있으나 시스템을 이해하
>는 것을 기준으로하면 제말이 정답에 가깝지 않을까 생각합
>니다.

프로젝트를 기한에 맞추어 튼튼하게, 그리고 유지 보수 용이하게
만들어 주는 것에 기준을 삼아야죠.

딴지 건 이유: 한동안 큰 회사들의 마켓팅 이벤트에 놀아나던 시절,
멀티 태스킹, 구이 환경, 바이트 컴파일, 가비지 콜렉션... 이 따위들이
다 그네들 회사들이 거의 처음 개발한 것으로 착각을 하고 있었습니다.
그런데 아니었죠...-_- 역사는 유구하고, 전통은 깊었으며, 천재들은
넘쳐났고, 세계는 넓었고... 우리의 시야는 그토록 좁았던 것이죠.

김영희의 이미지

제가 brew app개발할 때 아주 비슷한 UI를 중복해서 만들어야
했던게 생각 나네요.

프로그래머로서 그러한 짓을 할라치면 정말 다시한번
하고있는 짓을 생각하게 합니다.
복사해서 붙이기를 몇번을 반복했던지...
C나 C++로 개발한다면 이러한 작업이 엄청 난걸로 알고있습니다.

물론 객체 지향이라 하지만, C++로 작업한 것을
다시 사용한다는 것은 너무도 어렵습니다.
대형 프로젝트 산출물을 다음 프로젝트에서 각 모듈을
다시 사용하려 하면, 원인 모를 에러들(보통 포인터들...)로인해
디버깅 하다가 결국은 다시 모듈을 설계하죠.
하는수 없이 모듈의 일부를 잘 잘라서 붙여 넣어야 하구
그때마다 디버깅에 눈이 빠지더군요...
제대로 된 oop라면 그런일이 발생하지 않아야 했을겁니다.

아무래도 제가 C++을 제대로 모르고 oop를 제대로 몰라서 일겁니다.
헌데 왜? 자바로 하면 그러한 문제가 전혀 발생하지 않죠?

익명 사용자의 이미지

자바는 GC가 있기 때문이겠지요.

익명 사용자의 이미지

"제대로 된 OOP"가 아니라 "제대로 된 Framework"아닐까요..

자바로 하면 그런 문제가 전혀(?) 발생하지 않았다고 하는 것은 아마도 이미 잘 구축된 프레임워크에서 작업을 하셨기 때문일 겁니다.

김영희의 이미지

GG
맞는 말씀 같네요. ㅠㅠ

익명 사용자의 이미지

어느 것이 최고인지 논란을 가질 필요는 없을 것 같다는 생각이 불연듯 듭니다.

그 이유는 바로 Corba입니다.

CORBA!! ^^*

익명 사용자의 이미지

무슨 의미인지..?

저라면 코바 쓸바에 COM을 쓰겠습니다.
리눅스라면 Kpart나..

코바 무지 어렵다면서요..
게다가 무겁기까지하고..

저도 코바를 배워보고 싶은데..
너무 어렵다는 소리에 풀이 죽어있습니다.

코바어렵나요? 그리고 정말 그렇게 무겁나요?
경험자의 이야기를 들어보고 싶군요.

익명 사용자의 이미지

COM은 윈도우 시스템에만 한정된것입니다.

익명 사용자의 이미지

CORBA는 "시스템"과 "언어"의 장벽을 허물어 줍니다.

익명 사용자의 이미지

다들 탁상공론이군여.
최고의 언어? 글쎄...최고의 언어가 존재합니까?
적어도 개발자라면 최고의 언어가 아니라 최상의 언어를 선택해야져....

어떠한 상황이 주어졌을때 그것에 맞는 최상의 언어는 존재합니다. 그렇다고 그 언어가 최고의 언어는 될수 없겠죠?

자바로 스타크래프트를 못만드는것이 아니라 안만드는것이고 금융권에서나 플랫폼에 자유로운 언어가 필요할때 C++쓰는 사람 있나요? ^^

익명 사용자의 이미지

자바론 지금의 스타크래프트와 같은수준 못만듭니다

익명 사용자의 이미지

딴지랍니다.
최상이나 최고나 같은거랍니다. 최상은 맨 위에 있는거고 최고는 가장 높이
있는거니까 그게 그거죠. 최선이라고 해야 옳지요.

Renn의 이미지

binary code compile이 가능한 python이 있다면 그것이 가장 최선의 선택일지도 모른다는 생각이... :)

물론 다른 뛰어난 형식의 언어가 있겠지만, 개인적으로 일관된 인터페이스 및 유연성(허용성?)을 제공하는 python 밖에는 눈길이 가질 않습니다.

헛소리만 했군요..^^;

익명 사용자의 이미지

python 에서
.net binary 와 java binary 를 컴파일 해주는걸 만들은거 같은데
기계어라고 생성해내지 못할 이유가 없을거 같습니다. 다만 안하는것 같은데요?

Renn의 이미지

네. 없으니깐... 있으면 좋겠다는 푸념이죠. :)
일부에서는 소스 코드가 그대로 노출되니까 사용하길 꺼리는 경우도 봐 왔습니다. 물론 바이트코드 컴파일을 이용하지만, 파이썬의 것은 자바의 것과는 틀리죠.

그리고 바이너리코드 프로젝트... 현재 psyco라는 프로젝트가 있긴 하지만요. 이것이 잘 되어도 공식 python에 포함되지 않는다면 별로 정감이 가지 않을지도 모르겠구요. (개인적인 성향만 잔뜩 ^^;;;)

익명 사용자의 이미지

애초 주제글의 의도는 자기가 언어를 하나
디자인한다면 어떤 기능을 넣겠느냐 였죠?
분명 어떤 언어가 더 우수하냐에 대한 얘기는
아니었던 거 같습니다.

저라면 위에 거론된 기능 중에서 가비지 콜렉션,
함수 오버로딩, 추상 클래스 같은 핵심 기능은
반드시 구현하도록 하겠습니다. 반면 다중 상속,
연산자 오버 로딩은 구태여 필요하지 않을 것
같습니다. 강력한 에러 처리 기능 같은 것도 역시
필수이고요. IDE는 벤더들이 알아서 할 거니까
상관은 없고 GUI는 표준 라이브러리로 제공하는 것이
좋을 것 같습니다. 이 라이브러리는 아래에
레이어를 하나 더 두어서 네이티브 라이브러리와
인터페이스하도록 하겠습니다. 즉, 완전한 네이티브
룩앤필을 구현하도록 하는 것입니다.

대충 이래 놓으면 네이티브 컴파일되는 자바(혹은
파이썬) + Qt(혹은 GTK) 정도의 모양이 되리라고 생각합니다.

익명 사용자의 이미지

다중상속은 몰라도 연산자 오버로딩은 있으면 꽤 편할거 같은데요.

익명 사용자의 이미지

연산자 오버로딩 기능은 사실 말이 많은 기능이져..

예를 들어서 한 사람이 (int a + int b) 기능을 구개의 값의 OR 값을 처리하는 기능으로 재정의 했다고 생각해 보세여.. 그리고 다른 사람이 그 라이브러리를 가져다 씁니다.

{
..int c, d, e;
..c = 1;
..d = 1;
..e = c + d;
..cout << "e = " << e;
}

흐흐 그사람은 e = 2라는 결과를 원했을 지도 모르는데 결론은 e = 1이란 결과가 나와버립니다. 음 << 연산자가 틀이 이상하게 움직일 가능성이 높져...

BY 생각하길 원하는 무뇌아 ^__^

익명 사용자의 이미지

약도 잘쓰면 몸에 이롭지만
잘쓰지 못하면 몸에 해로울수도 있지요.

적절히 잘 쓸줄만 안다면 이건 꽤 편한 기능입니다.

기본적이 형에다 연산자 오버로딩을 한다는건 꽤 위험한 것이고요.
보통 연산자 오버로딩은 클래스와 클래스의 처리에 있어서는
대단히 편리한 기능입니다.

익명 사용자의 이미지

음 저 밑에 자바와 C#의 논쟁이 붙었군요.
저는 개인적으로 C#이 자바처럼 decompile되지 않는다면
C#에게 한표 주고 싶습니다.

자바를 죽이던 살리던 그게 상업적이던 아니던
자바랑 너무 똑같아서(?) 나오는 말씀들 같은데요

그러면서도 자바의 단점인 decompile을 피할 수만 있다면
C#이 자바보다 더 좋다고 느껴지는군요.

자바의 decompile 그거 굉장히 무섭습니다.

익명 사용자의 이미지

자바의 디컴파일러가 머가 무서운데요..

나는 편리하던데..

그나저나 이런게 있다는걸 오늘 처음 알았는데, 무지하게 재밌구낭..

글이 갑자기 이상한곳으로 흘러가면 주제의 논지도 확달라지고,,,

진짜 재밌다.

이런곳이 있다니..

우히히..

익명 사용자의 이미지

디컴파일을 막는 java protect라는 툴이 있습니다.

예전에 어느 증권사에서도 생각없이 자바의 클래스파일들을 뿌리다가 중요한 정보들이

노출된 적이 있습니다.

자바의 디컴파일에 관한 부분은 프로그래머의 보안인식에 문제 인거 같군요.

막으려면 막을 수 있는 부분인데.

참고로 java protect 는 비상업적으로 사용할 거라면 무료라고 하는군요.

http://www.javaprotect.com/ 에 가시면 볼 수 있습니다.

이거 약장사 같이 되어 버렸군요.

저는 저기와 상관없는 사람입니다.

익명 사용자의 이미지

물론 님께서 소개해 주신 툴말고도 여러툴이 있습니다.

그것을 프로그래머의 보안인식의 문제라고만 할 수는 없을 것입니다.
애초부터 자바가 디컴파일이 되지 않았으면 발생하지 않을 문제이니
자바 자체의 소스코드 보안에 문제가 많다는 사실에는 변함이 없습니다.

자바의 특성상 (디컴파일) 그정도는 어쩔 수 없다는 말 또한 성립이 안됩니다.
그렇다면 어떻게 그걸 방지하는 프로그램이 존재할 수 있겠습니까?
그게 가능한데도 왜 썬에서는 자바 개발킷에 그 기능을 따로 넣어주지 않는 것일까요? (일종의 디컴파일러인 javap는 있던데... 제가 잘 모르는 것인가요?)

또한 자바를 사용하면 개발기간이 짧아서 비용절감의 효과가 있다고 강조하는 분도 계신데
이러한 자바의 디컴파일을 들어 다음과 같이 말할 수도 있을 것입니다.
자바는 디컴파일을 방지하기 위해 추가비용이 들어간다.

익명 사용자의 이미지

애초에 프로그래밍이 없었다면 이런 논쟁을 하지 않아도 되는거였겠죠?

언어(또는 툴)을 다루는 책임은 이용하는 사람에게 있는게 아닐까요?

익명 사용자의 이미지

다른 언어들도 상태가 자바랑 똑같다면 그렇게 말하실 수도 있겠지만, 컴파일했는데도 다시 읽기 쉽게 소스수준으로 자~~~알 디컴파일해주는 언어는 자바밖에 없습니다.

익명 사용자의 이미지

세상에 디컴파일 안되는 게 어디 있겠습니까?
그렇게 많은 게임들이나 소프트웨어들이 크랙되는 걸 한번 생각해보세요.
C# 역시 당연히 디컴파일 되죠.
윈도우즈에서 실행중에 에러 뜰때 디버그 하면 어셈블리로 뜨지 않습니까?
무엇으로 짜든 간에...
물론 디컴파일되는 걸 조금 어렵게는 만들수는 있겠지만,
원천적으로 봉쇄하는 건 어렵겠군요.

익명 사용자의 이미지

"소스 수준의 디컴파일"이란 의미를 과도하게 확대하셨군요. ^^*

익명 사용자의 이미지

좋은 언어는

프로그래머가 안정적으로 개발할수 있는 개발도구이다..

다시말해,개발도구는 FREE 여야 한다..

개발도구에 돈받아 팔아먹는 M$ 각성하라...~~!!!

(개발도구에 돈받아 팔아먹는 것들은 망해야돼.....)

익명 사용자의 이미지

왜 MS만 걸고 넘어지는지?

IBM은 공짜로 파는가요?

그리고 프리의 뜻도 모르는것 같군요... 공짜보다는 자유에 가깝죠...

언어와 개발도구는 별개입니다!!!

돈주기 싫다면 복사해서라도 쓰시죠?

익명 사용자의 이미지

전 언어가 아니가 개발도구라고 했습니다..

그리고, 많은 예중 M$ 에 대한 예를 든것 뿐입니다..

그것 뿐입니다.. 그 이상도 그 이하도 아닙니다...

익명 사용자의 이미지

처음에 쓴글을 보면 언어는 개발도구라고 안하셨는지요?
이제와서 언어가 아니라하면 무슨...

익명 사용자의 이미지

헤헤..

제가 쓴글이 좀 이상했져...

이상하게 쓴 내가 잘못이져...

난 단지 개발도구를 FREE 로 해 달라는 거 뿐인데.. ㅜ.ㅜ

익명 사용자의 이미지

딴지 같지만 참고 삼아서 말씀드리면
C#은 MSDN에서 꽁짜로 받을 수 있습니다.
.NET SDK라고...

물론 Visual Studio.NET의 IDE는 없습니다.

익명 사용자의 이미지

DB에서 가장 최상의 언어는 SQL입니다. -_-

익명 사용자의 이미지

언어의 편리성 적인 측면에서 보자면 C#에게 점수를 더 주고싶고, 유연성이라면 C++에 점수를 더 주고 싶군요.
-----------
자바는 너무 없어서 불편하고,
C++는 너무 많아 무엇을 써야할지 모른다.
-----------
이러한 측면에서 보자면 C#이 중간의 자리를 지키고 있는것이 아닐까 합니다.

과거로 돌아가서 제가 써온 언어들을 돌이켜 보면,
처음에는 GW-Basic
다음에는 C
다음에는 어셈블러(MASM)
그리고 대학에 들어가서
Scheme -> Oberon, Pascal -> PERL -> Delphi -> Java -> C++ -> Leda -> Powerbuilder -> PHP -> Python
그리고 졸업한 지금은
PHP와 Java 그리고 C#을 쓰고 있네요.

그러고 보니 상당히 많은 언어와 패러다임을 써보았군요.
(물론 수박 겉핧기 였지만...)

프로그래밍을 해가면서 많은 것을 조금씩 해보았다고 생각합니다.
세계 최상의 언어는 없습니다.
그렇다고 이론을 완벽하게 지원하는 언어도 없습니다. (제 생각...)

아래에서도 설명드렸지만 자신의 문제를 이해하고 풀이하는 과정을 가장 쉽게 테스트 할 수 있고, 그로 인해서 문제를 제대로 이해할 수 있게 해주는 언어(테스트와 문제를 이해하기 위한 언어)와 실질적으로 시스템에서 동작하도록 하는 언어(C++, Java, Delphi, C#)들을 쓰는 것이 좋을 것 같기도 합니다.(저도 이렇게 하지는 못하지만...)

두서없는글 읽어주셔서 감사합니다.

익명 사용자의 이미지

C# 은 Java 를 견제하기위해 나온 언어입니다.

C# 은 웹쪽의 편리한 개발을 염두해두고 나왔다고 하는데..

C++ 로 웹쪽의 편리한 개발을위한 라이브러리를 만들수 없었을거라고 생각지 않습

니다.

이건 포인터의 사용을 줄임으로써 Java 같이 포인터를 사용하지 않는 개발자를 끝어들이

기 위한 상업적인 목적이 강합니다.

결코 언어의 발적적인 측면에서 나온건 아니라고 보는데요.

익명 사용자의 이미지

JAVA가 못나서 나온언어겠죠?

그리고 웬 포인터 안쓴다고 자바 쓰는 사람들인지?

정말 자바, C# 제대로 알고 하는 말씀이신지?

공부좀 더하셨으면 합니다.

그리고 C#은 이제 MS만의 것이 아닙니다.

익명 사용자의 이미지

그러면 당신한테 묻겠습니다.

C#의 장점이 무엇인가요?.

편리함?, 과연 포인터를 안쓰는게 편리한것인가요?

코드최적화 ?, 이건 C++ 이 휠씬 최적화 되있습니다.

oop? 이건 요즘왠만한 언어는 기본입니다.

c#이 지금의 언어보다 발적적인게 있다면 무엇인가요?

익명 사용자의 이미지

제가 말해도 못알아듣는거 같으니

님께서 C#책 한번 보셨으면 합니다.

허허...

제 생각에 C#은 C++의 발전형이라고 봅니다. 다만 native코드 최적화가 좀...

포인터를 안쓴다고요? 그러면 unsafe키워드는 뭣때문에 있는지?

또 oop말고 무슨 좋은 패러다임이 있을까요?

무언가 획기적인것을 바라는 것 같은데 특수한 목적 보다는 범용성이 중요하다고 봅니다.

// 처음에 토론 제안 핸것부터 잘못이군요...

// 다 용도에 맞게 최적화(?) 된 언어도 있으며 두루쓰이는 범용적인 언어도 있는데

// 왜 부정적으로 시각을 돌리는지? 쯧쯧...

// 함수형언어가 좋다면 장점을 널리 알려야지. 다른 언어의 단점을 들춰내보았자 누가 함수형언어를 많이 쓴다는 것도 아니며, 단순한 매니아밖에 되지 않음....

C++ 과 C# 은 형제다~~ 흐흐...

저 같으면 C# 욕할바에야 JAVA 씹겠습니다.

익명 사용자의 이미지

흐흐 정말 우습군요 c++ 이 함수형언어라, 과연 oop 나 제대로 이해하고있느지 쯔즈

익명 사용자의 이미지

// 주석부분은 처음 토론 제안자를 문제 삼은거요. 제대로 읽어보지도 않고 쯧...
// 함수형 언어가 좋다하고 C++이 나쁘다 해서 한 말이니...

익명 사용자의 이미지

보는 사람마다 관점이 있습니다. 제대로 읽어보지 않았다는 표현을 하시다니요.
아마 그의미를 모르는 사람이 태반 같군요.

익명 사용자의 이미지

http://ropas.kaist.ac.kr/~kwang/functional-ad.html
의 최준호씨가 문제인가봐요?(순선님 죄송)

익명 사용자의 이미지

위와 같은 사람은 아니지만 지나다가 이상한 얘기 같아서 물어봅니다.
그 링크랑 최준호님이랑은 무슨 상관이 있나요? -_-

익명 사용자의 이미지

죄송... 잘못봤어요... 죄송해요...
T_T

익명 사용자의 이미지

아! 보충설명드립니다.

아예 자바를 죽일려고 나온언어 입니다. -_-

JAVA의 플랫폼과 문법도 비슷하면서 C++의 강력함까지 더했으니 할말없죠.

그래서 C#과 C++을 같이 배울려고 합니다.

가장 범용적인 언어가 될것이기 때문이죠.

Nothing But C# & C++!!!

익명 사용자의 이미지

개인적으로 C# 은 상업적 목적에 의해 개발자들에게 혼란만을 가중시키는 결과를 낳는다고밖에는 생각이 들지 않는군요.

익명 사용자의 이미지

님이 그렇게 생각하신다면 자바도 별거 아니군요. 오죽하면 Money Oriented 라는 말이 나오기 까지 했는지요? 하지만 자바도 좋은 언어입니다. 님처럼 C#을 그렇게 보는 사람들이 예전에 자바를 그렇게 본것이죠...

그러니까 무조건 부정적으로 볼문제가 아닙니다. 다 일장일단이있습니다.

// C# 좀 공부하셔야 될거 같은디요... C# = JAVA + C++ + ... ( 아마도 )

익명 사용자의 이미지

자바의 최대 약점은 decompile이 아닐지...
혹시 C#도? @.@

홍성민의 이미지

밑의 글들을 다 읽어봤는데요...

귀결되는 한 문장이 눈에 들어오는데요...

'자신이 표현하고자 하는 것을 자연스럽게 표현해 줄 수 있는 언어가 좋은겁니다.'...

비단 프로그래밍 언어만이 아닌... 언어라는 측면에서 봤을때도 말입니다...

익명 사용자의 이미지

토론의 주제에서 좀 빗나간 것 아닌가요? 언어 자체의 장단점을 따져보자는 것인데 그런 식의 양가론을 꺼내들면 할 말이 없죠. 한 가지가 무작정 최고라고 우기는 것도 좋은 건 아니지만 그런 식으로 자기한테 맞는 것이 좋다, 혹은 다 장단점이 있다..이런 식의 주장도 생산적이지 못한 것 같군요. 파이썬을 접해보지 않은 사람이 GW-BASIC에 익숙하다고해서 그 사람에게 GW-BASIC이 최고라고 말할 수 있겠습니까? 파이썬 배우는데 약간의 노력만 들이면 금방 GW-BASIC으로 할 때보다 훨씬 더 잘할 텐데도요?

목적에 따라 맞는 언어를 쓰면 된다는 주장을 하는 분도 있던데, 그건 그럴 수도 있고 아닐 수도 있습니다. 델파이로 C/S 하던 사람이 웹하게 될 때 웹에 유리한 PHP나 자바를 배우는 게 나을지 아니면 파스칼로 웹서비스를 하는 방법을 택할지 어느 게 낫다고 단정적으로 말할 수 있습니까? 아무리 언어는 도구라지만 언어 하나 익히는데는 노력이 들어갑니다. 언어 익히는데 드는 노력과 그 언어가 보여주는 생산성을 따져서 선택해야하는 거고 그런 의미에서 이렇게 언어의 장단점을 따져보고 '강력한 언어'의 출현을 기대하는 것 아닙니까?

모든 분야에 걸쳐서 사용할 수 있으면서 빠르고 유연하고 쉽고 객체지향적인 언어를 기대하는 것, 불가능하기만 한 꿈인가요?

좀더 발전적으로 생각했으면 좋겠습니다. 아직도 언어는 발전하는 중이니까요.

익명 사용자의 이미지

그러나 대부분 이런 토론의 결말은 저런 양가론이지요..
사실, 이것도 개인의 취향에 관련된 문제이기에 그럴 수 밖에 없지 않나 싶은데..
누군가가 C/C++이 비생산적이다라고 말하는 동안..
또 누군가는 그런 비생산적인 면을 사랑(?)하고 있으니까요..
(저도 그런 부류 -_-;)
그냥..서로의 생각이 어떤 것인가..그걸 아는 선에서 끝날 듯 합니다..

익명 사용자의 이미지

"모든 분야에 걸쳐서 사용할 수 있으면서 빠르고 유연하고 쉽고 객체지향적인 언어를
기대하는 것" 이라는 표현에서...
객체지향이 꼭 들어가야되나여? 객체지향적 설계를 안 쓰는게 더 편할때도
많습니다.
요즘 객체지향이 유행한다고 모든 것을 객체지향적으로만 볼려는 것도 별로...
그리고 위에 말한 그러한 언어는 절대 나올리가 없습니다.
프로그래밍 언어뿐만 아니라...모든 것에 관해서 진리져...

익명 사용자의 이미지

발전을 근본적으로 부정하시는군요.
C가 처음 나왔을 때 C로 OS를 만드는 것은 불가능하다고 말하는 사람도 있었답니다.

익명 사용자의 이미지

정말 궁금해서 묻는건데요
C는 유닉스의 개발을 위해 만들어진 것에 가깝다고 할 정도로
유닉스의 탄생과 밀접한 것으로 알고 있었는데
정말 그렇게 말하는 사람이 있었던건가요 ?

처음듣는 이야기라서요
자세히 알려주시면 좋겠습니다

익명 사용자의 이미지

네, 말씀처럼, C가 유닉스의 개발을 염두에 두고 만든 것은 사실입니다. 하지만, 초창기 C로 만들었던 유닉스가 어셈블러로 만든 유닉스와 엄청난 성능 차이를 보였고 그로 인해 C에 대한 회의론이 잠시 대두했었죠. 그 당시에 중고급 언어가 없었던 게 아닌데도 C의 성능으로 인해 중고급 언어에 대한 회의론이 고개를 들었었죠. 하지만 얼마 안되어 C의 엄청난 속도 향상으로 이런 얘기가 쑥 들어갔죠. 저두 이거 제가 경험한-_- 사실은 아니고 어떤 뉴스그룹에서 본 건데 꽤 오래전 일이라 링크를 달지 못해 죄송합니다.

지금도 자바나 파이썬 같은 고급 언어가 C/C++에 비해 속도가 느리다는 문제점이 지적되고 있지만 앞으로 어찌될지는 아무도 모르는 일입니다.

김현욱의 이미지

자바나 파이썬의 고민은 하드웨어의 발전으로 해결되지 않을까요?^^

익명 사용자의 이미지

씨는 유닉스를 만들기 위해 만들어진 언어 맞습니다.
즉, 유닉스라는 운영체제를 여러 기계에 이식할 수
있도록 만들어진 언어입니다.
(첫 유닉스는 어셈블리로 짰고 그걸 다시
씨로 포팅한 것으로 알고 있습니다.)
당시에는 각 기계의 머신 랭기지로 운영체제를
만들었습니다. 당연히 그 운영체제는 그 기계에서만
돌아갔죠. 그랬던 것을 리치라는 사람이 씨를 만들었던 건데,
당시 논란은 어셈블리 언어가 아닌 언어는 운영체제를
돌릴 정도의 포퍼먼스가 나오지 않는다는 점에 있었던 것
같습니다.
언뜻 생각하면 지금의 자바와 상황이 유사하다 할 수 있죠.
자바는 이식성을 극대화하기 위해 바이트 컴파일 방식을
선택하였고, 그 댓가로 포퍼먼스에 관한 공격을 지독히 받고 있죠.

익명 사용자의 이미지

H/W를 개발하시는 훌륭한 과학도, 공학도분들이 많이 때문에...
걱정 안 해도 될겁니다.
보다 빠른 H/W가 나오겠져...^^;
소프트웨어 개발자들이 고민하는 문제가 하드웨어 개발자들 덕분에
손쉽게 해결될때가 많이 있져...^^;

익명 사용자의 이미지

발전을 부정하는 것이 아니라...
모든 것에 최선인 한가지가 존재할 수 있다는 것을 부정하는 것입니다.
근본적으로 인간 자체가 다양합니다. 따라서 모든 인간에 대해서 최선일
수는 없습니다.
세상 사람들이 A를 다 좋다고 해도, 난 B가 좋으면 B를 쓰는 겁니다.
세상 모든 사람들이 만족하고 최고라고 생각하는 언어가 나오리라고는
생각치 않습니다.

C로 OS만드는 것이 불가능하다고 말하는 사람이 있었다는 것이
제 글이랑 무슨 연관이 있는지 모르겠네여...
무조건 A는 안 된다라는 부정과 모든 것에 A가 최선일리는 없다라는 부정은
의미가 많이 틀린것 같은데여...
위의 예를 들자면 전 C로 OS만드는 것이 불가능이라고 말한 것이 아니라.
모든 OS를 만드는데 C를 쓰는 것이 최선이 될리는 절대 없다라고 말하는 겁니다.

익명 사용자의 이미지

무슨 연관이 있냐면..
앞서 말한 최선의 언어가 절대 나올 수 없고 그것이 진리라고 말한 것에 대한 반론이죠. C로 유닉스를 만드는 게 불가능이라고 한 사람도 있었지만 얼마 지나지 않아 C가 유닉스 표준으로 자리잡았듯, 모두의 입맛에 맞는, 꼭 모두는 아니라도 거의 대부분의 사람의 입맛에 맞는 언어가 충분히 나올 수 있다는 겁니다.

모든 것에 최선인 한 가지가 존재할 수 없다는 이유는 무엇인가요? 그 다양한 욕구를 충족하는 것이 불가능하다고 말하는 것이 곧 발전을 부정하는 것 아닌가요?

물론 이상은 이상이고, 현실은 현실이지만 제가 보기에 언어의 발전을 제로섬 게임으로 생각하는 사람이 많아보여서 한 말입니다. 이게 나으면 저게 부족할 수 밖에 없고..이런 식의 논리 말이죠. 분명히 언어는 과거보다 많이 발전하고 있고 앞으로 어떤 언어가 나올지, 어떻게 발전할지 아무도 모르지 않습니까? 그런데, 최선이 존재할 수 없다고 아예 단정을 짓는 것은 최선이 존재할 수 있다고 믿는 것보다 더 독선이라고 생각합니다. 가능성의 차단은 프로그래머에게는 금기사항 아닌가요.

그리고, 지금 논의하는 건 좋은 언어가 갖추어야할 점 아닙니까? 그러니까 이 기능도 있으면 좋겠고, 저 기능도 있으면 좋겠고..이런 얘기를 하는 건데, 이 기능이 있으면 저 기능은 안 좋을 수 밖에 없다, 그 기능에 맞는 언어를 써라..이런 식으로 얘기를 한다면 무슨 의미가 있겠습니까.

익명 사용자의 이미지

아...추가를 하자면...
과학자의 입장이던지, 엔지니어의 입장이던지 최상의 극의를 추구하는 것은
좋은 것입니다.
다만 인간 자체의 다양성을 생각해본다면, 모든 인간에 대해서 최선일리는
없다는 것이져...
이상적으로만 보면 모든 인간에 대해서 최선일 수도 있을지 모르지만...
이상은 이상, 현실은 현실...

익명 사용자의 이미지

허허..

어떤 개발에 있어 언어를 선택할 수 있는 권한을

가질수만 있다면 억지로라도 Ada 를 하겠습니다.

왜냐면.. 사용하는 곳들이 뻔때 나잖아요. :)

저는 예전의 파스칼이나 베이직도 참 괜찮은

언어라 생각이 듭니다만..

사실 파스칼과 거의 흡사한 이 언어는 베이직만큼

사용하기 쉬운 언어이면서 성능은 C++만큼 (어쩌면 그보다 더)

뛰어나지요.

프로그래밍이 직업이 된 후로는 책한번 들쳐본적이

없지만 미련이 많은 언어입니다..

관심있으신 분은 이곳에 한번 가셔서 그냥 한번 둘러보세요.

http://adahome.com

예전에 하두 뻔질나게 들락거리던 곳이라 확인해보니 제가

아직도 정확히 사이트명을 기억하는군요. 쿠쿠..

익명 사용자의 이미지

ada...교수님께서 적극 추천하신 언어..

전 갠적으로 파스칼을 좋아한지라 이 언어도 공부해볼까 생각해보긴 했었는디..

못해봤네여..언제함 공부하고 싶은 언어입니다.

익명 사용자의 이미지

Java VM과 C++를 Compiler 한 Native 코드를 퍼포먼스 측면에서 비교한다는게 이해가 되지 않습니다. Language에 대한 토론이 아닙니까?

제안을 합니다.

Java Code를 Native Code로 Compile해서 사용하는 방식을 사용한다는 가정하에(GCJ가 좋은 예가 되겠군요) C++와 비교를 해보는걸 어떨까요?

Generic이 Java에 추가된다면, C++ 부러울것 없는 좋은 언어가 될 수 있지 않을까요?

http://java.sun.com/javaone/javaone2001/pdfs/2733.pdf

http://gcc.gnu.org/java/gcj2.html

익명 사용자의 이미지

위에 말씀하신분은 단지 C에 OOP 의기능이 없다하더라도 OOP 의 테크닉을 포인터로 발휘할수 있다라는 의미로 보이는데요.

그걸가지고 c/c++ 의 언어가 마치 java/C# 언어에 뒤쳐져 있
는것처럼 말하는건 우습군요.

예로 C++ 같은 언어는 님이 말씀하신 특성을 가지고 있을뿐만 아니라. C 퍼포먼스를 고스란히 가지고 있습니다.

C/C++ 이 java/C# 에 비해 퍼포먼스가 우수함을 관가 하시는것 같군요.

java 는 퍼포먼스가 너무 떨어집니다. 그래서 쓸수있는곳은 한정적이라는 생각이 듭니다.

님은 oop를 강조한나머지 퍼포먼스를 우습게 생각하시는거 같은데요 좋은 언어는 퍼포먼스와 생산성의 조합입니다.
그러한것을 고려했을때 현재는 c++가 oop의 생산성과 퍼포먼스를 적절히 조합된 언어가 아닌가 생각합니다.

정규현의 이미지

많은분들이 네트워크 관련 프로그램에서 C의 강점 ( 특히 대용량 처리 )을
말씀하시곤 하는데, 실제 현장에서 부하나 대용량 처리가 문제되는 곳에서
사용하는 플랫폼이 자바(정확히 말하면 J2EE)로 대체되고 있습니다.

금융권같이 대용량처리나 트랜잭션이 특히 중요시되는 보수적인 개발환경에서
웹로직이나 웹스피어같이 자바로 개발된 네트워크 트랜잭션 미들웨어들이
사용되고 있지요.

그리고 1.4부터 도입된 각종 네트워크 I/O에 관련된 강화된 기능들때문에
이러한 문제는 자바자체에서 해결되리라고 봅니다. 1.4에서는 기존의
java.io패키지를 강화한 java.nio가 새로이 네트워크 I/O를 위해 도입됐습니다.
비동기 서버의 구현, 강화된 버퍼링 ( 데이타타잎에 따른 각기 다른 버퍼객체의 사용 )
, 채널개념의 도입을 통한 대용량 처리의 안정화 등 여러가지가 있습니다.

특히 채널은 복수개의 소켓을 묶어서 처리할수 있기때문에 대용량 패킷처리에
상당한 정도의 안정성확보가 가능합니다.

자바가 느리다는 말은 이젠 옛날예기라고 생각합니다.
퍼포먼스가 극도로 요구되는 임베디드 디바이스에서도 자바가 그 세를 넓히고 있습니다.

이정욱의 이미지

딴지 하나 걸겠습니다.

자바는 퍼포먼스가 너무 떨어진다...? ToT

아직도 많은 프로그래머들이 그냥 남들이 그러니까, 원래 있던 얘기니까 하면서

검증되지 않은 이야기들을 그냥 쉽게 받아들이는 것 같습니다.

자바의 퍼포먼스는 매우 매우 매우 크리티컬하거나 완전한 리얼 타임 처리를

제외하고는 그다지 느리지 않습니다. 특히 어제 나온 정식 jdk 1.4 se 는 굉장한

성능 향상을 보이고 있죠.

그런데 여기서 제가 하려는 얘기는 자바도 퍼포먼스 좋다라는 얘기가 아니라,

그냥 자바는 느리다 라고 생각하는 선입관에 대한 것 입니다.

논리와 검증된 결과로 무장해야할 프로그래머들이 이런 선입관을 많이 가지고

있다는 건 모두 부정할 수 없다고 생각합니다.

모두 선입관을 가지지 않도록 충분한 수양을 가져야 하겠습니다. :)

물론 위 글 쓰시분께서 충분한 테스트후에 글을 쓰셨다 면 전 할 말이 없습니다만 ^^;;

그럼.

ihavnoid의 이미지

맞습니다...
전에 어떤 기회가 있어서... 동일한 알고리즘의 데이터처리작업을 C와 java로 짜서 (동일 알고리즘) 수행시간을 비교해 봤습니다....
놀랍게도.. java HotSpot이 gcc no optimization보다 10퍼센트 이상 빨랐습니다.. -_-;;

물론 gcc -O2와 비교했을 때는 gcc -O2가 훨 빨랐지만...

gcj -O0 보다 물론 java HotSpot가 훨 빨랐고요....
gcj -O2랑 java HotSpot랑은 약 10퍼센트 가량의 성능차이가 있었던 듯 합니다...
(정확한 수치는 기억안남)

사용한 버젼은... gcc 2.9.6이랑 java SDK 1.3.1 이었습니다.. -_-
혹시 궁금하신 분은 연산 집중적인 처리작업을 한번 동일한 알고리즘으로 하여 돌려보시기 바랍니다...

C#이랑도 비교해 보고 싶기는 하군요.. ^^;;

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

익명 사용자의 이미지

j2ee 입장에서 보면 java 안느리고... 어차피 jvm 에 의해서
기계어로 번역된다음에 실행되기 때문에.. 거기서 거기지만
클라이언트는 매번 번역할려면 무지 느리죠
제가 보기엔 클라이언트 쪽에서는 소프트 적으로는 가망이 없고
하드웨어가 받쳐줘야 돼지 않을까요?

조기태의 이미지

자바의 성능이 가장 크게 문제가 되는 부분은 클라이언트 GUI, 특히 스윙에 관련한 부분입니다. 서버와는 달리 어플리케이션 마다 새로운 JVM을 시작하는 방식으로는 시작 시간이 느려질 수밖에 없습니다. 1.4에 올라와서 스윙의 실행속도는 크게 개선됐지만 JVM자체의 시작 속도는 여전히 숙제로 남아있습니다. 1.5 Tiger에서는 JVM을 어플리케이션 간에 공유하거나 OS시작시 함께 초기화할 수 있을지 모릅니다. 마침 JavaLobby에 비슷한 내용의 토론이 있으니 참조하시기 바랍니다.

그 밖의 경우는 위의 분 말씀 처럼 일부 리얼타임 시스템 같은 제한된 예를 제외하면 크게 문제되지 않는 것으로 알고 있습니다. 서버의 경우 JVM은 한번 시작하면 서버를 재가동할 때까지 계속 사용하는 만큼 JVM의 초기화로 인한 오버헤드를 무시할 수 있습니다. 단순히 for문을 몇천번 돌렸는데 C++이 50% 빠르다 하는 정도는 최종적으로 엔드유저에게 체감되는 수준에서는 거의 차이가 없는 것입니다. 예를들어 C++로 만든 팝업이 100ms에 시작했는데 자바는 150ms가 걸렸다 해도 50ms의 차이가 눈에 드러나지 않습니다.

오히려 스윙의 경우 남은 문제는 속도보다는 엄청난 메모리 footprint가 아닌가 합니다. SWT나 네이티브 컴파일러 등도 꾸준히 발전 중이니 지켜봐야할 것입니다.

한 가지 짚고 넘어갈 사실은 자바의 경우 실행에 JIT를 사용한다는 점입니다. 이로 인해 어떤 경우 C++보다 빠른 성능을 낼 수 있습니다. 이는 컴파일 타임에 코드만 가지고 얻을 수 있는 정보를 바탕으로 최적화하는 것과 런타임에 실행환경에 맞추어 최적화하는 프로세스의 차이입니다.

또한 갈수록 시스템 사양이 업그레이드 되는 것도 무시 못할 것입니다. 서버측의 경우는 어떤 분말씀대로 맨땅에 헤딩해서 C++라이브러리 만으로 분산환경을 구축하느니 차라리 자바를 써서 생산성과 유지보수 측면에서 절감한 원가를 더 좋은 서버를 사는데 투자하는게 합리적인 경우가 많습니다.

제가 주장하는건 자바가 C++보다 우월하다는게 아니라 퍼포먼스라는 기준은 상당히 가변적이기 때문에 "자바는 퍼포먼스 때문에 C++보다 못해"라는 선입관을 가질 필요는 없다는 점입니다.

C++이던 자바던 간에 각각 설계 사상에 맞는 장점이 있고 최적의 효율을 가져오는 적용분야가 있는 것입니다. 나머지는 개인 취향이나 회사 정책에 따라 달라질 부분이고 언어 자체의 우열을 논하는 근거는 못됩니다.

그럼...

익명 사용자의 이미지

밑에다 올릴글을 잘못 썻군요 죄송.

익명 사용자의 이미지

잘 알지 못하지만, 학교에서 배운 이야기를 조금 적어볼까 합니다. 아래의 글이 너무 많아 다 읽어 보지는 못했지만 저의 이야기를 적어 보도록 하겠습니다.

-----------------------------------
언어를 크게 네가지의 형태로 나눈다고 합니다.
1. 명령형 (C, Pascal, COBOL, etc...)
2. 객체지향 ( C++, Object Pascal, Smalltalk)
3. 함수형 ( Lisp, Scheme, Haskell, etc...)
4. 논리형 ( Prolog, etc...)

아마도 위의 네가 패러다임에서 많이 접하게 되는 패러다임은 아마도 명령형과 객체지향이 아닐까 생각합니다.

많은 분들은 함수형와 논리형을 접할 기회가 그렇게 많지 않다고 생각되는군요. 저도 학교에서 접한이후로 접하지 못하고 있으니까요.

가장 강력한 언어란 이렇게 생각합니다.
'자신이 해결하고자 하는 문제를 얼마나 잘 풀수 있는냐?'
그러나 많은 문제를 한가지 패러다임에 맞추어 풀다보니 쉽게 풀수 있는 문제를 어렵게 풀려지고 있는 것이 현실입니다.

그렇다면 과연 어떤 것이 필요할 까요?

각각 패러다임에 대한 정확한 이해가 필요하겠지요.
그렇지 못할때에는 언어가 아무리 좋아도 무용지물이라는 것이죠.
C++가 좋다, Java가 좋다, C#이 좋다고 따지는 것은 무의미 하도고 봅니다. 자신이 풀려고하는 문제를 얼마나 도움을 많이 주는가 입니다.
만약 Web Service라는 문제를 풀기위해 맨땅에서 C로 개발하는 사람은 별로 없을 것이라는 것이죠. 그러한 문제를 풀기위해서 어떠한 프레임웍위에 개발을 하게 되겠죠. 그러다 보니 C#과 Java라고 하는 언어를 선택하게 됩니다. 이렇다는 것이죠. 간단한 문제를 풀기 위해서 C++를 선택하는 것 보다는 C를 선택하는 것이 좋을 수도 있죠.(여기에서 C++란 객체지향 개념을 도입하여 개발한 것을 말합니다.)

결국 제가 말하고 싶은 것은 세상에 나쁜 언어 아니 좋지 않은 언어는 없다고 봅니다. 님들께서도 말씀하시는 다른 언어들이 좋지 않았다면, 아직 이세상에 남아 있지 않을 것입니다.

그러나 좋은 언어라고 해서 모든 문제를 쉽게 풀수 있는 것으 아닙니다.

자신이 풀고자 하는 문제에 가장 적합한 언어를 선택하시고, 그리고 해결하십시요.

저는 간단한 GUI를 이용한 Applicaiton을 만들때는 Delphi를 이용하지만 Web Service를 만들기 위해서 Delphi를 사용하지는 않습니다. C#을 이용하죠. 가끔 Java도 이용하게 되고요.

그렇다고 봅니다. 예전에 저는 C가 모든 문제를 풀수있는 언어라고 생각하고(이러한 때가 있었죠.), C를 공부 무지 했습니다. 그런데 갑자기 IT의 발전에 따라 C라는 언어가 조금씩 입지가 줄어들고 있습니다. 그리고 대학에서 교수님께 들은 4가지 패러다임을 들었을때는 충격이었습니다. 그리고 그러한 언어들을 조금씩 접해보고 이러한 패러다임들이 있어구나 하는 많은 생각들이 들었죠. 물론 지금은 객체지향 언어들을 주로 사용하고 있습니다. 그러나 그것은 현실이 어쩔수 없으니, 할 수 없이 쓰는것이지 쓰고 싶어 쓰는 것은 아니겠죠.

여러분들도 자신의 문제를 제대로 이해하고, 어떠한 프레임웍, 언어를 이용할 지 심각하게 고려하십시요. 그것이 답이 아닐까 생각합니다.

자신의 문제가 어떤것인지도 모르면서, 그러한 문제를 해결하기위해 무엇인가를 찾는다는것은 맞지 않는 다는 것이죠.

여러분은 Embeded OS를 개발하는데 C#을 쓸사람이 별로 없는 것 처럼(CE .NET용을 만들때는 쓸사람이 있겠지만...)
문제를 제대로 파악하고, 문제를 잘 풀어줄 수 있는 언어를 선택하십시요. 그것이 가장 강력한 언어입니다.

저의 두서없는 글을 읽어주셔서 감사합니다.
( 너무 욕하지 마세요. 저도 잘 알지 못하면서 생각나는데로 적은거라...)

김영희의 이미지

맞는 말씁입니다.
헌데 요즘 만들어 지는 프로그램들은 점점 덩치가 커지고,
여럿이 같이 일을하며, 나중에 유지 보수도 신경써야 하는것들이 태반입니다.

따라서 프로그래머는 단순 코딩이 아닌 그들의 생각을
깔끔하게 옮겨 놓고 싶어하는거구요.
그 망할 놈의 코드 속에서 숨좀 쉴수있게....
성능도 중요하지만 어느정도 같이 공유할수있는 코드이어야 한다 이거죠.

예전처럼 메모리가 쥐꼬리 만해서 그것때문에 골머리 썩힐 필요가
있는 경우가 아니라면, 일반 애플리 케이션 사용자는
그 수행 속도 차이를 잘 느끼지 못하는 경우가 많습니다.
그러한 경우라면 힘들여서 C++로 개발하는것보단 VB로 개발 하는게 효율적이죠.
결국 시스템 사양이 올라갈수록 그러한 방향으로 가지 않을까요?

자바가 지금은 좀 무겁다 하지만, 프로그래머를 단순 코더가 아닌
즐거운 프로그래밍으로 이끌어 줄수있는 언어가 아닌가 싶네요.
지금도 모바일 쪽에서는 자바를 많이 사용하고있구요.
물론 성능면에선 C를 기반으로 한 brew가 좀더 뛰어나다 하지만 자바의
융통성에는 견주지 못할듯 싶네요.

김영희의 이미지

맞는 말씁입니다.
헌데 요즘 만들어 지는 프로그램들은 점점 덩치가 커지고,
여럿이 같이 일을하며, 나중에 유지 보수도 신경써야 하는것들이 태반입니다.

따라서 프로그래머는 단순 코딩이 아닌 그들의 생각을
깔끔하게 옮겨 놓고 싶어하는거구요.
그 망할 놈의 코드 속에서 숨좀 쉴수있게....
성능도 중요하지만 어느정도 같이 공유할수있는 코드이어야 한다 이거죠.

예전처럼 메모리가 쥐꼬리 만해서 그것때문에 골머리 썩힐 필요가
있는 경우가 아니라면, 일반 애플리 케이션 사용자는
그 수행 속도 차이를 잘 느끼지 못하는 경우가 많습니다.
그러한 경우라면 힘들여서 C++로 개발하는것보단 VB로 개발 하는게 효율적이죠.
결국 시스템 사양이 올라갈수록 그러한 방향으로 가지 않을까요?

자바가 지금은 좀 무겁다 하지만, 프로그래머를 단순 코더가 아닌
즐거운 프로그래밍으로 이끌어 줄수있는 언어가 아닌가 싶네요.
지금도 모바일 쪽에서는 자바를 많이 사용하고있구요.
물론 성능면에선 C를 기반으로 한 brew가 좀더 뛰어나다 하지만 자바의
융통성에는 견주지 못할듯 싶네요.

익명 사용자의 이미지

리스프에 대한 한글로 되어있는 자료를 찾아봤는데

단 하나도 없군요-_-;

누구 가지고 계신 강좌 같은거 있으면 공유해주시면 감사

익명 사용자의 이미지

Lisp한글자료들이 조금 있습니다.
http://www.lisp.co.kr

아래는 Scheme입니다만...그리고 영어입니다만... 좋은 책입니다...^^;
http://mitpress.mit.edu/sicp/full-text/book/book.html

익명 사용자의 이미지

thanks god!

익명 사용자의 이미지

http://www.aistudy.co.kr/Lisp/Lisp%20syntax.htm
겨우 한 두개 정도 돌아다닐텐데 이게 그 하나였던 거
같습니다.
lisp.co.kr이라고 울산대인가에서 관리하는 사이트가
있는데 :< 기대하실 바 없을 겁니다.
han.comp.lang.lisp라고 한국어 뉴스 그룹이 있습니다만
거의 죽어 있는 상태죠. 예전 글 중 볼 만한 건 있습니다.
천상 영어를 해야 할 겁니다. http://www.lisp.org입니다.

익명 사용자의 이미지

요즘 C++은 generic programming으로 가더군요.

OOP같은 것들을 generic programming의 범주로
끌어 들이려는군요.

거창 하지만 프로그래머는 참 골치 아플것 같습니다.
배워야 할게 더 많더군요.

아 그리고 잘모르지만 브얀 스트라우럽(?아직 까지 정확한 표기법은 모르겠네요^^)박사께서
다음 두번째 C++ 표준안에 gabage collection, thread, GUI
기능을 넣을거라고 합니다. 흠 잘은 모르지만 이것도 제 생각인데 template를 통한 general한 interface만 정하는 거라 생각 합니다.

앞으로 C++의 미래가 기대되는데요.

익명 사용자의 이미지

감사합니다. 요즘 관심 분야라..

페이지