개인적으로 자바를 싫어하는이유..

ㅡ,.ㅡ;;의 이미지

1)C보다 속도가 늦다..
2)C보다 늦게 나오고 비슷한문법을 사용하면서도 오히려 불편함을느낀다.
3)기존프로그램들의코딩스타일이 주로 문장이 장황하게 길어 간단한것도 무식하게구현된것으로 보인다..모니터에 자리를 많이 차지하여 가독력이 떨어진다
4)C로는 자바를만드는데 자바로는C를 못만든다..
5)결국편리하자고 만들어낸것이 더어렵게변해간다..
6)코딩이 생각하는코딩이 아니라 암기해서타이핑하는코딩이주가된다.
7)주로제공되는함수를 그대로 사용함으로 어떤곳에적합한 최적화된코딩을 하기 힘들다. 따라서 1년전이나 1년후나 거기서거기에 머물러 있을수 있다.
8)java 쪽에서 모듈(?)을제공해주지 않으면 개발하기 힘들다. 나올때까지 기다려야하고 그때는이미 다른사람도 다한다..

카二리의 이미지

1번 빼곤 다 틀려 보이는대... 다른분들의 생각은?...

새 생각 :)

elflord의 이미지

3)번같은 경우...자바의 api를 사용하면 c보다 간결하게 쓰고 가독성도 높일 경우가 꽤 있더군요. c는 없는함수 내가 만들어 쓰니 좀 문제있는 함수 만들때도 있고.

글고 2,3번 빼고나면... 개인적으로 자바를 싫어하는 이유 라는 제목대신 개인적으로 c를 싫어하는 이유라는 제목달고 어셈블러나 기계어를 소개해도 되겠군요.

자바처럼 이식성까지 고려해서 나온 언어를 c와 단순비교하는건 좀 어리석은 짓이 아닐까 싶네요.

아무리 개인직인 취향이라고 제목에 적으셨어도 공개적인 게시판에 글을 올리셨으니 저도 반론을 한번 들어봤습니다.


===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com

sugarlessgirl의 이미지

카이리님 아바타 너무 귀여워요..

꿩인지 닭인지.. 너무 귀엽다...... 뒤에 카이리라고 써진 글씨도 너무 귀엽다..
:lol:

sugarlessgirl의 이미지

여기서..

어떤 언어가 좋다 싫다를 거론하는 것은...

아주 위험한 행동인 듯 합니다.. 으흐흐..

jedi의 이미지

사용자의 입장에서 보면 자바가 좋습니다.
특히 www.yahoo.com에 가면 게임을 할수 있는데 kr.yahoo.com에 가면 게임을 못합니다.
www는 자바로된 게임이고 kr은 ActiveX(이거 C 겠지요?)게임이더군요.
윈도우만 쓴다면 신경쓸 필요가 없겠지만 그외 OS를 쓴다면 게임이 불가능하죠.
이런 것을 C로 해결하려면 어떻게 해야 할까요? 앞으로 보다많은 OS가 PDA에 탑재된다면......

결론적으로 무엇으로 개발하든 상관없다 신경도 안쓴다. 다만 내가 쓸 수 있게 만들어달라.
이것이 사용자의 요구겠죠. 더이상 고압적인 자세로 쓰고 싶으면 니들이 따라와라.. 한다면.....

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

서지훈의 이미지

뭐... 요즘엔 많이 좋아져서 자바로 해도...
별도 차이는 별로 못느낄 정도고(서버로 구현된게 아닌 다음에야)...-_-ㅋ
그러나 제가 Java의 단점으로 들자면...
나와 있는 library와 JMF와 같은 새로운 프로젝트는 많이 생겨 난거 같은데...
제대로 실행이 되는것과 포퍼먼스를 책임을 안진다는게 어쩨 좀...?
거의 항상 Beta 같은 느낌...
이로 인해서 항상 Java로 된 것들은 실행하기전에 드는 뭔가모를 안좋은 느낌(언제 뻗을지 모른다는 막연한 공포(?)감)...
이건 정말 무시 못할 압박이죠...
뭐... 필요한 곳엔 Java 를 사용하긴 하지만...
이런 느낌 너무 싫어서...
정말 할 수 없는... 경우...가 아니면 "Java는 즐~~~" ...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

서지원의 이미지

카二리 wrote:
1번 빼곤 다 틀려 보이는대... 다른분들의 생각은?...

1번도 잘못된 말입니다. 언어 specification 과 implementation 을 구별 하지 않아서 생기는 말입니다. "c의 design이 java design보다 좀더 빠른 실행코드를 만들기에 더 쉽다" 정도면 맞을지도 모르지만...

fender의 이미지

제가 볼 때는 C 프로그래머의 입장에서 자바 언어를 피상적으로 이해하고 계신게 아닌가 싶습니다. 무엇보다 객관적인 기준이 없는 비교는 무의마하지 않나 생각합니다.

'못을 박는데 제일 좋은 공구는?'이런 질문이 아니라 '망치가 좋아요 톱이 좋아요?' 이렇게 물어보고 답하는 것 자체가 의미 없는 일 아닐까요?

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

hurryon의 이미지

C 랭귀지도 하수이지만 개인적인 생각으로 제가 자바을 해야만 하는 이유는 UI 때문입니다. ㅡㅡ;

skjk의 이미지

농담으로 쓰신건가요? 솔직히 논의할 가치도 없는 글이군요. -.-;;

kevinhan의 이미지

"ㅡ..ㅡ;;" 님이 쓰신 글은 다분히 공격적이긴 하지만 그 분 글로 인해 C 나 Java 의 장단점을 역동적(?)으로 토론해 볼 수 있는 좋은 기회가 될 수 있다고 봅니다.

저를 비롯한 많은 newbie 들을 위해 많은 고견을 기대해 봅니다.

너무 고깝게 생각하지는 말아주셨으면 하는 바램입니다.

quid pro quo

Jun92의 이미지

jedi wrote:
사용자의 입장에서 보면 자바가 좋습니다.
특히 www.yahoo.com에 가면 게임을 할수 있는데 kr.yahoo.com에 가면 게임을 못합니다.
www는 자바로된 게임이고 kr은 ActiveX(이거 C 겠지요?)게임이더군요.
윈도우만 쓴다면 신경쓸 필요가 없겠지만 그외 OS를 쓴다면 게임이 불가능하죠.
이런 것을 C로 해결하려면 어떻게 해야 할까요? 앞으로 보다많은 OS가 PDA에 탑재된다면......

결론적으로 무엇으로 개발하든 상관없다 신경도 안쓴다. 다만 내가 쓸 수 있게 만들어달라.
이것이 사용자의 요구겠죠. 더이상 고압적인 자세로 쓰고 싶으면 니들이 따라와라.. 한다면.....


kr에도 자바 게임 아직 있어요.. 8개...

=============================
야후!

fender의 이미지

보다 의미있는 비판이 되려면 과연 클라이언트 어플리케이션을 만드는데 있어서 자바 언어가 적합한지에 대한 이야기를 하는게 낫지 않을까 싶습니다.

서버 쪽에서의 성공과는 달리 애플릿과 스윙 이후 데스크탑 시장에서 자바는 실패한 솔루션으로 치부되어 왔습니다. 실제로 JEdit이나 Limewire 등 몇몇 어플리케이션을 제외하면 자바로된 널리 쓰이는 데스크탑 응용프로그램은 거의 없습니다.

이유를 따져 보자면 :

(1) JRE를 번들해야 하는 부담감.

(2) 패키징의 어려움 - 어느 누구도 간단한 응용프로그램을 띄우려고 콘솔에서 java -jar ....를 입력하고 싶어 하지 않습니다.

(3) 느린 속도와 메모리 점유율 - 자바 자체가 느리지 않다고 해도 최소한 스윙은 *분명히* 느립니다. 1.4에서 비약적인 발전이 있었지만 네이티브 어플리케이션과 비교할 때 어느 정도 차이는 있습니다. 또한 어플리케이션을 띄울 때마다 새 JVM을 띄우기 때문에 속도에 영향을 줍니다.

(4) 프로페셔널한 UI 디자인이 어려움 - 물론 L&F를 잘 지정해주면 어느정도 예쁜 UI를 만들 수는 있지만 다른 네이티브 어플리케이션과 글꼴이나 다른 여러 요소들의 느낌이 다르게 느껴지는 건 어쩔 수 없습니다. 특히 윈도우즈에서는 상황이 낫지만 리눅스는 글꼴 설정 없이는 한글도 보이지 않고 AA도 먹지 않아 다른 세련된 GTK 어플리케이션과 비교했을 때 조잡한 느낌을 줍니다.

이런 이유로 이제까지 데스크탑 시장에서 자바는 별다른 힘을 쓰지 못했다고 봅니다. 하지만 특히 최근에 와서 SWT/JFace와 GCJ 등의 등장으로 상황이 급격히 나아지고 있다고 판단 됩니다. 한 가지씩 따져본다면 :

(1) 고속 인터넷 보급과 윈도우즈 플랫폼에서의 자동 업데이트, 네트워크 인스톨 지원으로 JRE 다운로드의 부담이 줄었습니다. 현재 윈도우즈에서 JRE 설치 프로그램의 크기는 약 400k 정도로 알고 있습니다. 또한 GCJ를 써서 컴파일 할 경우 아예 JRE 자체를 필요로 하지 않습니다. 따라서 리눅스의 경우 JRE 없이 RPM이나 DEB으로 번들할 수도 있습니다.

(2) GCJ를 통해 exe와 같은 네이티브 실행파일을 만들 수 있습니다. 이를 설치프로그램이나 RPM, DEB 등으로 패키징 할 경우 기타 다른 언어로 만든 경우와 같이 쉽게 패키징이 됩니다. 혹은 자바로 만들더라도 InstallAnywhere나 JSmooth 등으로 JRE까지 포함해서 깔끔하게 설치할 수 있습니다.

(3) JRE 1.5 대에 공유 VM이 들어갈 예정입니다. 이미 1.4대에서 VM의 시작 속도가 상당히 개선됐고 만일 공유 VM이 일반화 된다면 경우에 따라선 운영체제 시작과 함께 JRE를 백그라운드에서 시작할 수도 있을 것입니다.

(4) SWT/JFace를 사용하면 윈도우즈, 리눅스, 맥OSX 등에서 네이티브한 UI를 구현할 수 있습니다. 특히 최근 거의 VB와 흡사한 환경에서 SWT로 UI를 디자인하는 이클립스 플러그인들이 속속 개발되고 있어 상황은 더 나아지리라고 봅니다.

이런 단점들이 극복되면 자바 특유의 장점 - 방대한 써드파티 라이브러리, 높은 생산성 및 유지보수성, 크로스 플랫폼 등등이 영향을 주어 데스크탑 시장에서도 자바 어플리케이션이 많이 늘어날 것으로 생각합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

ukira의 이미지

C는 디버깅이 어려워서 힘들어요...
자바는 exception처리가 잘 되어서 너무 좋음.

codebank의 이미지

어차피 --,.--;; 님의 완전한 주관적인입장(제목에도 분명 '개인적인'이라고 써있습니다.)에서 느낀점을
써놓으신것입니다.
물론 게시물자체의 내용이 많은 논란의 여지가 충분하고 또한 읽는 사람에 따라서는 눈살을 찌푸리게
할 수도 있겠죠.

저도 처음 글을 읽으면서 안좋은 이야기들이 나올것 같다는 생각을 했었지요.
하지만 너무 직관적인 눈으로 보지 않았으면하는 바램입니다.
글을 올리신분이 자바를 한번도 써보지 않았으면서 글을 올렸다면 당연히 쓴소리를 들어도 되겠지만
제가볼때는 어느정도 (많이는 아닌것 같네요.) 자바를 경험해보고서 쓴글인것 같네요.

저는 차라리 발전적인 형태로 대화를 이끌어가면 안될까 싶어서 한마디 붙인겁니다.
자바가 좋다 싫다의 이분적인 논쟁은 불필요한것 아닌가하고요. 어차피 처음 스레드를 만든
분의 제목에도 분명히 나와있듯이 개인적인 입장에서 판단한것이니까 저분을 이해 시키기 보다는
(좀 과장된 이야기 일지도 모르지만...) 이참에 '속도도 빠르고 배우기도 쉽고 상당수의 사람들이
좋아할 언어를 만들어보자.'라는 논의로 발전했으면하는 생각이 듭니다.

------------------------------
좋은 하루 되세요.

juicy의 이미지

ukira wrote:
C는 디버깅이 어려워서 힘들어요...
자바는 exception처리가 잘 되어서 너무 좋음.

저는 C에서 디버깅 하기가 더 쉽던데요..
특히 C++에서는 try~catch도 쓸 수 있고..
visual studio는 정말 디버그 하기에 매우 좋은 툴이죠..
(물론 저는 자바 프로그래밍도 충분히 할 수 있습니다..^^)

kwon37xi의 이미지

>> 1)C보다 속도가 늦다..
SWING 은 확실히 늦습니다. 서버 사이드에서 볼때는 그다지 속도 차이를 느끼기 힘들껍니다.

>> 2)C보다 늦게 나오고 비슷한문법을 사용하면서도 오히려 불편함을느낀다.
구체적으로 뭐가 불편한지 언급이 없어서 모르겠습니다.
C와 문법이 비슷할지 모르지만 객체지향 개념은 완전히 다릅니다.

>> 3)기존프로그램들의코딩스타일이 주로 문장이 장황하게 길어 간단한것도 무식하게구현된것으로 보인다..모니터에 자리를 많이 차지하여 가독력이 떨어진다

제가 보기엔 그로인해 가독성이 높어집니다.

>> 4)C로는 자바를만드는데 자바로는C를 못만든다..
해보진 않았지만 자바로 C를 만드는게 가능하다고 보구요, 그리고 근본적으로 자바는 씨언어를 만들기 위해 탄생한게 아닙니다.
그렇다면 C로 분산 웹 어플리케이션을 작성하라면 하시겠습니까?

>> 5)결국편리하자고 만들어낸것이 더어렵게변해간다..
뭐가 어렵다는것인지 구체적으로 제시해주셨으면 좋겠습니다.

>> 6)코딩이 생각하는코딩이 아니라 암기해서타이핑하는코딩이주가된다.
네, 바로이게 자바의 최대 장점이라고 봅니다.
풍부하게 넘쳐나는 API들을 이용해서 아마도 C 보다는 공부를 조금 덜한 프로그래머들도 C보다 더 풍부한 프로그램을 더 빨리 짤 수 있습니다.

>> 7)주로제공되는함수를 그대로 사용함으로 어떤곳에적합한 최적화된코딩을 하기 힘들다. 따라서 1년전이나 1년후나 거기서거기에 머물러 있을수 있다.
6번과 같습니다.
실력을 길러 최적화 하는 것은 프로그래머의 문제이지 Java 자체의 문제는 아닙니다.

>> 8)java 쪽에서 모듈(?)을제공해주지 않으면 개발하기 힘들다. 나올때까지 기다려야하고 그때는이미 다른사람도 다한다..
이거도 뭔뜻인지 모르겠습니다.
제가 보기엔 자바 프로그래머들은 스스로 모듈을 만들 의지나 능력이 없는 사람들이다 라는 비하로 보입니다.
아마도 "비하"라고 까지 하기엔 비약이 큰거겠지만, 남이 입에 떠 넣어주기 전에는 스스로 못떠먹는 사람들이라는 생각을 바탕에 깔고 있다고 보이는데요...
근데, 위에서도 계속 말했지만.. 이게 자바의 큰 장점입니다.
풍부한 API가 공개되어 있어 더 빠르고 쉽게 프로그램을 짜는것...

저는 C를 주로하고 자바를 한지는 1년밖에 안되서 사실 자바를 제대로 알지도 못하지만 암튼...
이 "개인적인 비교"는 사실 C와 자바의 존재 목적이 다르다는 사실을 염두에 두지 않고 썼다는 생각이 들고요...

2번과 5번은... 구체적 예를 제시해주시면 좋을것 같습니다.

matrix의 이미지

전혀 자바를 해보시질 않은듯 합니다.
C도 별로 경험이 없는듯 하구요..

대답할 가치를 못느낄 정도로 수준 이하의 주제을 올리셨네요..

How do you define Real?

불량청년의 이미지

"논할 가치가 없다"는 말은 좀 그렇네요.

분명 제목에도 "개인적"이라고 쓰셨고 또 상당히(?) 개인적인

생각을 썼다고 생각되는데요.

아~ 게시판의 분위기가 상당히 무겁게 느껴집니다. ㅡ,.ㅡ;

그냥 웃으면서 얘기할 수도 있고 논리적으로 차분하게

대화가 오갈 수도 있지 않을까 해서 한마디 했습니다.

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

onemind555의 이미지

ㅎㅎㅎㅎ~~
그냥 웃어 줍니다....

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

galien의 이미지

개인적으로

자바가 너무 좋아요 >.<

:lol:

자바의 기본 이념 자체가 너무 매력적이네요.

nairs의 이미지

뭐 개인적으로 C 와 자바에 대한 의견을 밝혀 주신것 같네요..

뭐.. 그럼 저도 개인적으로 밝혀 보겠습니다.

씨와 자바를 비교 하시면서 느끼실만한 불편이라는거 충분히 이해 합니다.
하지만 이 불편함이 없이 자바에서 제공하는 것을 한번 씨에서 구현을 하려면 어떨까요? 물론 불가능 하지는 않습니다. 하지만 이래저래 골아픈 것이 사실이겠죠...
말씀하시는 것을 기준으로 단적으로 따져보면 C, C++ 을 비교만 해도 될지 않을까 하네요.
왜 굳이 객체를 쓰면서 까지 프로그래밍을 해야만 하는 것일까요? 뭐 객체를 쓰지 않고서도 충분히 원하는 기능을 만들수는 있는데 말입니다.

프로그래밍의 환경과 시대가 변하면서 점점더 처음부터 구현을 한다면 아마 프로그래머 들은 엄청난 코딩양으로 죽어나야 겠죠... 그러기 위해서 많은 개발방식이나 언어들이 등장하고 있습니다.
물론 목적은 다양합니다.
코드의 재사용성이나, 좀더 빠른 개발주기, 특정 플랫폼을 위해서 등등이겠죠..

자바는 지금의 환경에서 씨가 부족한 부분을 매꾸기 위해서 나왔습니다.
그중 가장 큰 부분은 플랫폼으로부터의 독립이라는 것이죠.

이 부분을 씨로 구현을 한다면 가능은 하겠지만 상당한 번거로움과 어려움이 있을 것은 자명한 일입니다. 오히려 위의 그런 번거로움이나 복잡한 과정을 통하면 씨를 통해서 원하는 프로그램을 짜는 것보다는 더 편하고 좋다는 것이겠죠.

뭐... 그렇게 까지 자바가 불편하시다면 자바 쓰시지 않고 씨로 그런 프로그램 만들으셔도 될것 같네요.
자신이 느끼기에 불편하시다면 편하신걸 쓰시면 되는 것이죠.
자바를 쓰시는 분들은 자바가 편하고 좋다고 생각하시기 때문에 쓰시는 것이구요(물론 아니라고 생각하는 분들도 있을수 있습니다.)

자신이 쓰기에는 불편하다고 해서 싫어하는 것은 자유입니다만. 이런식으로 자기의 진영이 아닌곳을 공개적으로 깍아내리는 의견은 그리 좋지 않다는 생각입니다. 이런 예기와 같이 윈도나 리눅이 서로 다투거나 각 언어들끼리 뭐가 좋네 나쁘네 하는건 의도처럼 좀더 발전적인 뭔가를 논의 하는것 보다는 소모성논쟁이 되는 경우가 많아지는 경우가 많은 것을 봐와서 인지... 좀 어려운 논제가 아닌가 합니다.

\ 별을 보며 소원을 빌 때 당신이 누구인지는
\ 중요하지 않습니다. 당신이 소망하는 것이
★ 무엇이든, 포기하지 않는 한 그 꿈은 이루어
집니다. <司法試驗 合格記 中>

Vadis의 이미지

글의 주제에 대해 어설픈 지식으로 반박을 하지는 않겠습니다.그러나 ㅡ,.ㅡ님이

주장하신 글에서 전혀 객관적 자료제시를 하지 않았던 것에 대해 납득할 수가 없

군요.객관적 자료제시를 해주셨으면 합니다.그리고 이번 스레드에서 c프로젝트

와 java프로젝트개발에 있어서의 경험담을 들려주셨으면 좋겠네요.c와 java를

공부함에 있어서 견문을 넓힐수 있는 계기가 되는 좋은 스레드가 되었으면 하는

바람이 있네요^^..

좋은 날 즐거운 날....

nachnine의 이미지

뛰어난 장인은 도구를 가리지 않습니다.

저도 처음엔 c/c++ 로 시작해서
java는 싫어. 느리고, .. 뭔가 쉽고 간단하지만 느린
그런 장난감 같은거야.
C/c++을 못하는 사람들이 쓰는 언어지... 라는
어처구니없는 생각을 가지고 있었습니다만.
지금은 모든언어에 대해 관심을 가지고 있습니다.

심지어 그 ' 가장 나쁜 언어 ' 라 언급되고 있는 VB 까지..
'필요하다면 언제든지 할수 있고, 기본은 아는 상태' 로
만들려고 노력중입니다.

윗분이 쓰셨던것처럼 원글의 C 를 어셈으로 바꾸고
JAVA를 C 로 치환해도 똑같은 이야기가 됩니다.

요즘 푹 빠져들고 있는 PERL에 대해서 이야기하자면
'C' 언어의 나쁜점을 최대한 부각시킨, 즉 보완하는 언어입니다
String 처리에 관해서는 최강이죠. C 언어는 최악에 가깝구요.

좋은언어/나쁜 언어는 없습니다.
특정목적에 부합하는언어/ 그렇지 않은 언어가 있을 뿐이죠.

같은 요건의 프로그래밍이라도
다룰수 있는. 그리고 좋아하여 능숙하게 할수 있는 랭귀지가 많으면
개발자에게 있어서 그만큼 메리트입니다.

시야를 넓혀서 Java도 좋아지도록 노력해보십시오
C로 10시간이 걸려 개발해야할것을 Java로 1시간만에
개발할수도 있을겁니다.

zoops의 이미지

ㅡ,.ㅡ;; wrote:
1)C보다 속도가 늦다..
2)C보다 늦게 나오고 비슷한문법을 사용하면서도 오히려 불편함을느낀다.
3)기존프로그램들의코딩스타일이 주로 문장이 장황하게 길어 간단한것도 무식하게구현된것으로 보인다..모니터에 자리를 많이 차지하여 가독력이 떨어진다
4)C로는 자바를만드는데 자바로는C를 못만든다..
5)결국편리하자고 만들어낸것이 더어렵게변해간다..
6)코딩이 생각하는코딩이 아니라 암기해서타이핑하는코딩이주가된다.
7)주로제공되는함수를 그대로 사용함으로 어떤곳에적합한 최적화된코딩을 하기 힘들다. 따라서 1년전이나 1년후나 거기서거기에 머물러 있을수 있다.
8)java 쪽에서 모듈(?)을제공해주지 않으면 개발하기 힘들다. 나올때까지 기다려야하고 그때는이미 다른사람도 다한다..

저는 C++로도 Java 로도 회사를 다니고 프로젝트를 해봤습니다만..
Java의 최대강점은 방대한 서드파티 라이브러리와 오픈마인드로 만들어진 표준안들 그리고 Java 의 Framework ( 뭐라구 해야할지.. ) 입니다.
속도는 분명히 늦겠지만 UI 가 없다면 미미한 차이일껍니다.
(UI 가 있다면.. 그것이 비록 SWT 라도 속도의 차이는 분명합니다. 현재는... )
어느분이 패킹과 실행이 불편하다고 했는데.. 그것도 다 해결되었습니다.

그렇다면 제가 생각하고 있는 단점은..
첫째로 클라이언트단의 분명한 속도차이와 여러 제한들.. SWT 라해도 느립니다. -.-;;
둘째로 8번하고 비슷한데.. Java 만을 알고 있다면 특정일을 할 수 없습니다.
예를 들어 nio 가 나오기 전까지 비동기 IO 를 할수 없었죠..
(JNI 를 사용해서 만들면 되겠지만.. 그럴려면... 역시 C 를 알아야 합니다.)
세째로 JRE 를 번들해야한다.

이정도 입니다.
이것을 감수할 수 있다면 Java 를 안 할 이유는 없죠..
특히나 요새 C++도 Java 의 스타일을 많이 받아들이고 있는 형편이죠.
(아니.. 언어의 발전이 같은 곳을 향해 가고 있는 거겠죠.. )

그리고 java 로는 c 를 못 만든다고 하셨는데.. 그것은 잘못된 생각입니다.
c 자체는 스팩이니만큼 정확히는 C 컴파일러 이야기겠죠?
java 로도 c 컴파일러는 충분히 만들 수 있습니다.
컴파일러라는게 하드웨어를 제어하거나 하는 특화된 영역은 아닙니다.
구문 분석해 머신코드를 생성해 내면 그만인것이니깐요...
(얼마나 잘 최적화 해서 생성할것인가의 문제등.. 여러가지가 있겠지만여.. )

그럼..

- zoops -

ㅡ,.ㅡ;;의 이미지

오~ 상당히 많은 답변들이..

일단 다변달아주신님들 감사하구요..

제개인적인 취향이 저렇다고해서 저를미워하시는건 아니죠??^^;;
어디까지나 걍 느낀데로 적었습니다. 이유를 들수도 없고 근거 자료도없죠..
제마음을 보여줄수 없으니까요.

제개인적인 느낌을 적으면.. 아니다 나는이렇게 생각한다.. 정도로 나올줄알았는데...
걍도구에 대해 이야기하는것이니.. 사람에대해 확대해서 생각하진마시기 바랍니다...


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

ㅡ,.ㅡ;;의 이미지

zoops wrote:

그리고 java 로는 c 를 못 만든다고 하셨는데.. 그것은 잘못된 생각입니다.
c 자체는 스팩이니만큼 정확히는 C 컴파일러 이야기겠죠?
java 로도 c 컴파일러는 충분히 만들 수 있습니다.
컴파일러라는게 하드웨어를 제어하거나 하는 특화된 영역은 아닙니다.
구문 분석해 머신코드를 생성해 내면 그만인것이니깐요...
(얼마나 잘 최적화 해서 생성할것인가의 문제등.. 여러가지가 있겠지만여.. )

그럼..

코드만 같은걸 만든다면 그건좁게 보는거죠.. 예를들면..
A :"우리회사는 자동차공장을 완비하고 있소.."
B :"그것 별것아니오 우리도 가지고 있소.. -손으로 부품하나하나 만들고 있다오.. 한대만드는데 100년쯤걸리지요.."

B는 공장을가지고 있다고 할수 없겠죠..
같은결과를내면서 .. 거의똑같이 동작되냐는..


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

jedi의 이미지

ㅡ,.ㅡ;; wrote:
zoops wrote:

그리고 java 로는 c 를 못 만든다고 하셨는데.. 그것은 잘못된 생각입니다.
c 자체는 스팩이니만큼 정확히는 C 컴파일러 이야기겠죠?
java 로도 c 컴파일러는 충분히 만들 수 있습니다.
컴파일러라는게 하드웨어를 제어하거나 하는 특화된 영역은 아닙니다.
구문 분석해 머신코드를 생성해 내면 그만인것이니깐요...
(얼마나 잘 최적화 해서 생성할것인가의 문제등.. 여러가지가 있겠지만여.. )

그럼..

코드만 같은걸 만든다면 그건좁게 보는거죠.. 예를들면..
A :"우리회사는 자동차공장을 완비하고 있소.."
B :"그것 별것아니오 우리도 가지고 있소.. -손으로 부품하나하나 만들고 있다오.. 한대만드는데 100년쯤걸리지요.."

B는 공장을가지고 있다고 할수 없겠죠..
같은결과를내면서 .. 거의똑같이 동작되냐는..

저는 컴파일러는 잘 모르지만 어째튼 위의 말은 논리적으로 타인을 설득하는 것에는 도움이 안되는군요.
계속 주장하는 JAVA로 컴파일러를 만들기 힘들다고 주장만 있지 왜 만들기 힘든가는 안 보이거든요.

보다 논리적이고 설득력을 가지려면 왜 JAVA로 컴파일러 만드는 것이 수작업인지를 설명하는 것이 좋을것입니다.

그리고 마음 속에 있으면 개인적인 생각이지만 말을 하면 개인적인 의견 또는 주장이 되는 것입니다. 자신의 의견에 근거도 논리도 없다면 안좋아 보입니다.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

purple의 이미지

예가 적절치 않는 듯 합니다.

Quote:
코드만 같은걸 만든다면 그건좁게 보는거죠.. 예를들면..
A :"우리회사는 자동차공장을 완비하고 있소.."
B :"그것 별것아니오 우리도 가지고 있소.. -손으로 부품하나하나 만들고 있다오.. 한대만드는데 100년쯤걸리지요.."

B는 공장을가지고 있다고 할수 없겠죠..
같은결과를내면서 .. 거의똑같이 동작되냐는..

컴파일러를 만드는 데 자바가 C 보다 아주 많이 불편하거나 시간이 많이 들 꺼라 생각되진 않는데요. 컴파일러가 시스템 로우레벨을 다루는 것도 아니구요. 자바는 그 정도는 담당할 수 있을만큼 충분히 일반적인 언어일텐데요. 네이티브 코드를 생성하는 것은 모르겠지만 jvm 상에서 돌아가게끔 바이트 코드를 생성하는 자바로 만들어진 다른 언어의 컴파일러는 몇개 있습니다.

뭐 자바로 JVM을 만들 수 있냐하면 그건 또 다른 문제겠지만요..

sDH8988L의 이미지

ㅡ,.ㅡ;; wrote:

코드만 같은걸 만든다면 그건좁게 보는거죠.. 예를들면..
A :"우리회사는 자동차공장을 완비하고 있소.."
B :"그것 별것아니오 우리도 가지고 있소.. -손으로 부품하나하나 만들고 있다오.. 한대만드는데 100년쯤걸리지요.."

B는 공장을가지고 있다고 할수 없겠죠..
같은결과를내면서 .. 거의똑같이 동작되냐는..

ㅎㅎㅎ

비유를 잘못 드신 거 같네요...

Compile 자체를 만드는 거라면, Java로 하는 것이 휠씬 편합니다...
지금 대학원 과정에서 Compiler 듣고 있는데, Java가 문자열 연산과 기본 제공하는 Collection Library의 편의성 때문에 Compiler 자체를 만들기는 C보다 휠씬 편합니다...(대략 16개 정도의 조로 편성되어 있는데, C로 하는 조는 하나도 없네요... -___-)

단, Java로 짠 Compiler의 문제라면 Compile Time이겠죠...

C보다 오래 걸립니다... 그러나 그게 극단적인 차이가 나지는 않습니다...

Java로 짜도 사용할 수 있을만큼 빠릅니다...

실제로 Java Compiler를 돌릴 때, Compile 하느라고 도는 것보다는 JVM 띄우느라 더 걸리는 것 같기도 하죠... ㅎㅎㅎ(약간 농담이 섞인 말입니다...)

Compiler 자체를 만드는 설비는 Java 쪽이 나으니 잘 완비된 공장을 C에 비유한 것은 잘못되었고요... 차라리 바꾸는 게 오히려 낫겠습니다... C를 수공으로...
그리고 차이는 그 공장에서 나온 차인데, 잘 만들어진 공장에서 나온 차는 한 200Km/h 밖에 안나오고 수공으로 만든 차는 한 400Km/h 나온다고 비유하는 게 차라리 낫겠네요...

뭐... 200km/h나 400km/h나 의미는 별로 없겠죠... 한 번에 10000km 정도 가야 하는 일 아니면...

ㅡ,.ㅡ;;의 이미지

클레스명과 파일명을 같게줘야하는것도 맘에 안드는..


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

김일영의 이미지

논리적 구성과 물리적 요소는 별개가 될 수 있어야 한다고 생각합니다.

sDH8988L의 이미지

ㅡ,.ㅡ;; wrote:
클레스명과 파일명을 같게줘야하는것도 맘에 안드는..

뭐... 맘에 안드신다니 할 말은 별로 없지만...
(저도 이유없이 사과가 좋거든요...-____-)

Java에서는 하나의 Source File에 1개의 Class를 두는 것이 Convention입니다...

그러면 일일이 Source File을 까보지 않고서도 Class를 구분할 수 있죠...

저는 그게 상당히 맘에 들던데요...

ironiris의 이미지

자바가 플랫폼에 상관없이 실행되고자하는 것은 플랫폼마다 C컴파일러가 지원되어서(특히 gcc) 좀 설득력이 떨어지는 것 같습니다.
조금 알려진 기기라면 아주 약간만.. 기다리면 c로 컴파일된 바이너리를 얻을수 있는데 왜 자바를 쓰겠습니까?
일례를 들어서 샤프의 PDA인 자우루스를 예로 들겠습니다.
이 기기는 기본적으로 "자바"환경이 되어 있으면서 QT환경입니다. 리눅스를 운영체제로 하고 있긴 합니다.
그렇다면 그 이식성이 좋은 자바로 만들어진 응용프로그램이 많아야 하는데.. 자우루스에서 잘돌아가는 자바프로그램을 찾기 어렵더군요. 자바로된 게임을 받아봐도 잘안돌아가고...
하지만 여러 c 로 된 공개소프트웨어를 받아서 gcc 로 컴파일하니 자우루스에 맞는 실행파일을 얻을수 있으니.. 그 바이너리는 호환성이 없는지 몰라도 기기에 최적화된 바이너리를 얻을수 있어서 좋네요.

물론 그냥 컴파일되는 소스도 있고 어느정도 수정해야 컴파일되는 것도 있습니다. 자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요. 수정해서 작동한다면 자바가 내걸고 있는 장점인 플랫폼에 상관없이 작동이라는 말은 말짱 거짓말이 되어버린 것이죠.
c쪽은 장점으로 내세우지 않았음에도.. 결국은 다 지원하는 꼴이 되어버린 것이고요.(컴파일의 과정을 거쳤지만.. 저장공간은 다른 기종과 공유할일도 없는데.. 특수한 경우는 있겠지만..)

뭐 이런 저런 장/단점이 c나 자바나 각각 있겠지만 지금 시점에서는 자바가 장점으로 내세웠던 것이 하나 둘씩 사라지는 느낌이네요.

lacovnk의 이미지

ironiris wrote:

물론 그냥 컴파일되는 소스도 있고 어느정도 수정해야 컴파일되는 것도 있습니다. 자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요. 수정해서 작동한다면 자바가 내걸고 있는 장점인 플랫폼에 상관없이 작동이라는 말은 말짱 거짓말이 되어버린 것이죠.

궁금한점이..."자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요"가 무슨 의미인지 모르겠어요~

"완벽한 이식성을 보장"하는게 vm의 존재 의의 아닌가요?

핸드폰 같이 "제한적인 자원사용"때문에 vm의 종류가 다른 경우가 있는걸로 아는데 (잘 모릅니다 -_-; 지적을 -_-; )
그걸 문제시 삼는다면 "pc와 pda가 똑같은 기능을 해야된다"라고 말하는 격인것 같고...중요한것은 핸드폰 회사에 관계 없이 핸드폰 게임을 할수 있다는게 아닐까요?

으음. 잘 모르지만 궁금해서 남겨봅니다 :)

sDH8988L의 이미지

ironiris wrote:
자바가 플랫폼에 상관없이 실행되고자하는 것은 플랫폼마다 C컴파일러가 지원되어서(특히 gcc) 좀 설득력이 떨어지는 것 같습니다.
조금 알려진 기기라면 아주 약간만.. 기다리면 c로 컴파일된 바이너리를 얻을수 있는데 왜 자바를 쓰겠습니까?
일례를 들어서 샤프의 PDA인 자우루스를 예로 들겠습니다.
이 기기는 기본적으로 "자바"환경이 되어 있으면서 QT환경입니다. 리눅스를 운영체제로 하고 있긴 합니다.
그렇다면 그 이식성이 좋은 자바로 만들어진 응용프로그램이 많아야 하는데.. 자우루스에서 잘돌아가는 자바프로그램을 찾기 어렵더군요. 자바로된 게임을 받아봐도 잘안돌아가고...
하지만 여러 c 로 된 공개소프트웨어를 받아서 gcc 로 컴파일하니 자우루스에 맞는 실행파일을 얻을수 있으니.. 그 바이너리는 호환성이 없는지 몰라도 기기에 최적화된 바이너리를 얻을수 있어서 좋네요.

물론 그냥 컴파일되는 소스도 있고 어느정도 수정해야 컴파일되는 것도 있습니다. 자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요. 수정해서 작동한다면 자바가 내걸고 있는 장점인 플랫폼에 상관없이 작동이라는 말은 말짱 거짓말이 되어버린 것이죠.
c쪽은 장점으로 내세우지 않았음에도.. 결국은 다 지원하는 꼴이 되어버린 것이고요.(컴파일의 과정을 거쳤지만.. 저장공간은 다른 기종과 공유할일도 없는데.. 특수한 경우는 있겠지만..)

뭐 이런 저런 장/단점이 c나 자바나 각각 있겠지만 지금 시점에서는 자바가 장점으로 내세웠던 것이 하나 둘씩 사라지는 느낌이네요.

글쎄요...

Java가 내세우는 것과 C가 각 Architecture independent한 것과 약간 혼동하시고 있는 거 같습니다...

Java는 근본적으로 "아무 수정없이" Application이 도는 것을 지향합니다...
(뭐... 100% 된다고는 말 안하겠습니다... 100% 다는 안되는 거 다들 아시니까요...)

쉽게 말하면 모든 기기에서의 Binary가 같은 것을 의미하는데요... C가 지향하는 바와는 다르죠... C는 모든 환경에서의 "Compiler"를 지원함으로써 Architecture Independent를 이루려는 것이고(물론, 다시 Compile은 필요하죠...) Java는 Binary Level에서 그걸 할려고 하는 겁니다...

물론, Stand-Alone Application에서라면 별로 차이가 발생하지 않을 수도 있습니다만, Java는 Network Application을 겨냥하고 만든 겁니다...

Network Application이면서 모든 기기에서 작동하는 것을 C로 Binary Level에서 짤 수 있습니까??? C의 Compiler가 각 기기마다 존재하는 것만으로는 절대로 Cover될 수 없는 부분입니다...

Java는 Platform-Independent 하지만 "Compile 해야하는" C의 단점을 극복하고자 나온 언어입니다... Mobile 환경과 같이 다양한 Architecture 상에서요...

같은 Level로 보시면 좀 그렇죠...

물론, 이것은 Java가 그걸 어디까지 구현했느냐는 좀 별개의 문제겠죠... 걸리적 거리는 것들이 좀 있으니까요...

우수한의 이미지

고수님들의 논의에 끼어들기엔, 너무 '초보'스런 생각입니다만...

  • Java는 속도가 느리고 무거워서 별로입니다. 이왕이면 더 가볍고 빠른 바이너리를 만들어내는 언어를 쓰고 싶습니다. 그때문에 보편적 이식성을 위해 VM을 채택한다는 아이디어는 실패한게 아닌가 하는 생각이 듭니다. 오히려 C가 더 보편적인 것처럼, 플랫폼별 컴파일 방식을 채택하는게 낫지 않았을까요?
  • 언어의 구조가 발달한 것은 장점이라고 봅니다. 그리고 라이브러리가 많은 것두요. 하지만 그 때문에 공장에서 찍어낸 프라모델을 조립하고 있는 것과 뭐가 다른가 하는 생각이 들곤 하는거 아닐까요?
개인적으로는 C나 JAVA가 아닌 다른 언어(python 이라든가, 닷넷 플랫폼을 제외한 C#)가 대세(?)가 되었으면 좋겠다는 생각을 합니다. :?[/]

우수하지 않아요. '우수한'은 옛날 만화 CityHunter에서 따와서 쓰던 별명. ;-)

vacancy의 이미지

Java가 C보다 생산성 측면에서 더 낫지 않나요.
더 엄격한 언어이기도 하고, 메모리 누수도 없죠.
C/C++에 비해 Java/C#이 생산성이 아무래도 높다고 봅니다.

M$에서 Borland에서 앤더스 헤즐스버그 등을 데려(뺏어)다가
C#을 만든 데는 이유가 있다고 생각합니다만. -_-a

yamainu의 이미지

ironiris wrote:
자바가 플랫폼에 상관없이 실행되고자하는 것은 플랫폼마다 C컴파일러가 지원되어서(특히 gcc) 좀 설득력이 떨어지는 것 같습니다.
조금 알려진 기기라면 아주 약간만.. 기다리면 c로 컴파일된 바이너리를 얻을수 있는데 왜 자바를 쓰겠습니까?
일례를 들어서 샤프의 PDA인 자우루스를 예로 들겠습니다.
이 기기는 기본적으로 "자바"환경이 되어 있으면서 QT환경입니다. 리눅스를 운영체제로 하고 있긴 합니다.
그렇다면 그 이식성이 좋은 자바로 만들어진 응용프로그램이 많아야 하는데.. 자우루스에서 잘돌아가는 자바프로그램을 찾기 어렵더군요. 자바로된 게임을 받아봐도 잘안돌아가고...
하지만 여러 c 로 된 공개소프트웨어를 받아서 gcc 로 컴파일하니 자우루스에 맞는 실행파일을 얻을수 있으니.. 그 바이너리는 호환성이 없는지 몰라도 기기에 최적화된 바이너리를 얻을수 있어서 좋네요.

물론 그냥 컴파일되는 소스도 있고 어느정도 수정해야 컴파일되는 것도 있습니다. 자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요. 수정해서 작동한다면 자바가 내걸고 있는 장점인 플랫폼에 상관없이 작동이라는 말은 말짱 거짓말이 되어버린 것이죠.
c쪽은 장점으로 내세우지 않았음에도.. 결국은 다 지원하는 꼴이 되어버린 것이고요.(컴파일의 과정을 거쳤지만.. 저장공간은 다른 기종과 공유할일도 없는데.. 특수한 경우는 있겠지만..)

뭐 이런 저런 장/단점이 c나 자바나 각각 있겠지만 지금 시점에서는 자바가 장점으로 내세웠던 것이 하나 둘씩 사라지는 느낌이네요.

java개발 , 리눅스 C 개발, 그리고 자우루스 상에서 C 프로그램을 했습니다. 그리고 지금은 j2me 핸드폰 App개발중입니다.
ironiris 님께서는 C와 자바라는 언어(정확히 말해 자바는 플랫폼+언어)의 차이를 정확히 이해하고 있지 않습니다.
자바는 윈도우,NT,Mac등에 JVM(자바가상머신)을 올리고 그위에 자바프로그램을 돌립니다(인터프리터). 물론 그 프로그램은 어떤 OS든 상관없이 동일한 JVM이 설치된 곳이라면 소스의 수정없이 가능합니다.
그러나 C는 언어로서 윈도우/linux,또는 CPU타입에 따라 필요한 헤더파일등 하드웨어와 관련된 부분을 직접 프로그래머가 구현 하게 됩니다.
자바는 이러한 부분에서 편의성의 제공하고 이식성을 제공하는 것입니다.
모바일의 경우는 자원의 제약/차이로 Configrattion,profile등의 그룹을 나누어 PC와는 다른 환경의 JVM을 설치하며 기기제조사의 OEMspecific 한 부분의 코딩만 배제한다면 동일한 이식성과 편리성을 가지게 됩니다.
물론 C언어가 해당OS나머신에 최적화된 코드를 제공할수 있다는것은 큰 장점입니다.
(자바는 공통된 런타임환경을 제공하기위해 os/머신의 특정한 부분의 기능을 배제 시킨것이겠죠)
그러나...기기제조사에서 OEM 의 JAVA API를 제공한다면 이러한 것도 문제가 되지는 않겠죠...

중요한 것은 환경에 알맞은 언어를 선택하면 되는 것입니다.
그리고 언어마다 그 특징이 있고 이를 잘 파악하면 된다는 것!
저는 모든 언어를 사랑합니다.^^*

Programmers never die: They just GOSUB without RETURN.

fender의 이미지

우수한 wrote:
고수님들의 논의에 끼어들기엔, 너무 '초보'스런 생각입니다만...
  • Java는 속도가 느리고 무거워서 별로입니다. 이왕이면 더 가볍고 빠른 바이너리를 만들어내는 언어를 쓰고 싶습니다. 그때문에 보편적 이식성을 위해 VM을 채택한다는 아이디어는 실패한게 아닌가 하는 생각이 듭니다. 오히려 C가 더 보편적인 것처럼, 플랫폼별 컴파일 방식을 채택하는게 낫지 않았을까요?
  • 언어의 구조가 발달한 것은 장점이라고 봅니다. 그리고 라이브러리가 많은 것두요. 하지만 그 때문에 공장에서 찍어낸 프라모델을 조립하고 있는 것과 뭐가 다른가 하는 생각이 들곤 하는거 아닐까요?
개인적으로는 C나 JAVA가 아닌 다른 언어(python 이라든가, 닷넷 플랫폼을 제외한 C#)가 대세(?)가 되었으면 좋겠다는 생각을 합니다. :?

말씀 드렸듯이 GCJ가 어느정도 완성도를 얻게되면 속도 문제는 물론 그 동안 오픈소스 진영에서 자바의 라이센스와 관련한 반감도 해결할 수 있으리라 봅니다.

VM의 효용성에 대해선 많은 논란이 있었지만 MS의 차세대 플랫폼인 닷넷의 경우도 VM 기반인 것을 보면 분명 유용한 부분이 있다고 생각합니다. 점차 하드웨어가 발전할 수록 성능상의 제약은 많이 상쇄를 할 수 있고, 특히 대규모 서버측 어플리케이션으로 갈 수록 플랫폼 독립적인 특성은 장점이 부각되니까요...

프라모델의 비유는... 관점의 차이라고 생각하시면 될 것 같습니다. 건물을 짓는데 건축자재 하나 하나를 장인 정신으로 다듬고 만드는 사람도 필요하지만, 미리 만들어진 조립식 자재를 가지고 보다 고차원적인 문제 - 예를들어 구조라던가 설계, 혹은 미학적인 부분에 신경써야 하는 사람도 있는게 아닐까요? :)

저는 자바가 대세가 되거나 그런 건 별로 신경쓰진 않습니다. 각각 자신이 좋아하고 프로젝트 성격에 알맞는 언어를 고르면 되는 것이고, 다만 가끔씩 접하는 로우레벨 언어 개발자들의 자바 언어에 대한 이유없는 우월의식이나 별로 근거없는 성능에 대한 비판 같은 건 사라졌으면 좋겠군요.

[/]

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

sskim의 이미지

C는 C나름대로 매력이 있고
Java는 Java나름대로 매력이 있어요.
왜 두가지를 억지로 비교하려고 그러죠?

정말정말정말 억지로 어렵게 비교한다면... 음..
음.. 잠시만요.... 3가지만할께요.

C Java
1. 기계적이다. 인간적이다.
2. 완벽하다. 놀랍다.
3. Java가부럽다. C를이길순없다.

ㅋㅋㅋ 너무 SF적인가요?
제가 원래 SF-M*입니다.
*Science Fiction Mania

_________________________________
beyond the compass of your powers!

ㅡ,.ㅡ;;의 이미지

운영체제로 비유( 좀관계가 먼느낌도 있으나 ) 하자면..

C 는 유닉스
java 는 M$윈도우..

같은..

C 확실하고 철저하고 엄격하다
java 융통성이있고 그리엄격하지 않고 확실하지도 않다.


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

sskim의 이미지

저런 그런 큰일날 말씀을?!
절대로 그렇지 않습니다. I never heard of it!
자바가 얼마나 unix-base 한데요~

ㅡ,.ㅡ;; wrote:
운영체제로 비유( 좀관계가 먼느낌도 있으나 ) 하자면..

C 는 유닉스
java 는 M$윈도우..

같은..

C 확실하고 철저하고 엄격하다
java 융통성이있고 그리엄격하지 않고 확실하지도 않다.

_________________________________
beyond the compass of your powers!

sDH8988L의 이미지

ㅡ,.ㅡ;; wrote:
운영체제로 비유( 좀관계가 먼느낌도 있으나 ) 하자면..

C 는 유닉스
java 는 M$윈도우..

같은..

C 확실하고 철저하고 엄격하다
java 융통성이있고 그리엄격하지 않고 확실하지도 않다.

흠... 정말로 ㅡ,.ㅡ;; 님의 생각은 특이하시군요...

보통은 거꾸로 생각하지 않던가요???

Java가 C보다 휠씬 철저하고 엄격하고 그에 반해 C는 융통성이 있고 그리 엄격하지 않고 확실하지도 않죠...

허허... 어떤 점을 보면, C가 Java보다 엄격하고 철저하다는 생각을 가지게 될까요... 이거 참...

마치 티코가 포르쉐보다 빠르다고 하는 거 같네요...

아니면 짚차가 탱크보다 단단하다고 하는 거 같군요...

sDH8988L의 이미지

점점 의심이 가기 시작합니다...

아무래도 그 의심이 사실인 거 같네요...

제가 생각하기에는 글 올리신 분이 장난 하시는 거 같습니다...

말도 안되는 글을 일단 올리고 나서 사람들의 반응을 지켜보는 초딩적인 장난을 하고 계신 거 같네요...

보통 알려진 사실들을 전부 거꾸로 이야기 하고 있는 것도 그렇고요...

다른 사람들이 반박한 글들을 어떤 식으로든 다시 자신의 의견을 관철시키려는 그런 자세도 아니고...

그냥 장난하는 거 같습니다...

뭐... 초딩은 아니신 거 같지만, 장난치는 것 같아서 좀 기분이 안좋네요...

저는 이제 글을 올리지 않으렵니다... 몇 개의 글을 올렸지만, 지금 생각해 보니까 장난질에 놀아난 거 같네요...

더 이상 글쓰신 분에게서 생산적인 뭔가를 기대할 수도 없고...

다들 장난질에서 벗어나시는 게 좋겠네요...

ㅡ,.ㅡ;;의 이미지

sDH8988L wrote:
점점 의심이 가기 시작합니다...

아무래도 그 의심이 사실인 거 같네요...

제가 생각하기에는 글 올리신 분이 장난 하시는 거 같습니다...

말도 안되는 글을 일단 올리고 나서 사람들의 반응을 지켜보는 초딩적인 장난을 하고 계신 거 같네요...

보통 알려진 사실들을 전부 거꾸로 이야기 하고 있는 것도 그렇고요...

다른 사람들이 반박한 글들을 어떤 식으로든 다시 자신의 의견을 관철시키려는 그런 자세도 아니고...

그냥 장난하는 거 같습니다...

뭐... 초딩은 아니신 거 같지만, 장난치는 것 같아서 좀 기분이 안좋네요...

저는 이제 글을 올리지 않으렵니다... 몇 개의 글을 올렸지만, 지금 생각해 보니까 장난질에 놀아난 거 같네요...

더 이상 글쓰신 분에게서 생산적인 뭔가를 기대할 수도 없고...

다들 장난질에서 벗어나시는 게 좋겠네요...

님이 더이상합니다. 자신의 생각과다르다햐여 그렇게말하면안되죠..

앞에도 이야기했지만.. 걍도구에대해 개인취향을 이야기 하는데..

그걸 상대비하식으로 나오시면.. 좀 잘못된거 아닌가요..

"난티고가 작아서 맘에 안든다" 고하면.. "난오히려그게 맘에든다" 면되지.
"너티고가 작어서 맘에안들다니 초딩아냐?" 이런식이될순 없자나요.. 잘아는사람도 아니고말이죠...

좋아하는사람도 있겠죠.. 저같이 안조아하는사람도 있고요.. 사람마다 다른것이죠..

제가 자바가 맘에 안든다고 하여 다른사람한테 그걸강요하는것도 아니고요..
저와다르게생각하시면. 아니다 난 자바의 이런점때문에 오히려 좋다고 생각한다고하면. 그게 설득력이 있으면 그글을읽는 사람도 좋아하게되지 않을까요....

덧붙이자면.. 좋은물건을 보면 난 저게 맘에든다고 이야기 하듯 별로인것을보면
그또한 이야기 할수 있는것 아닌가요?

제가 님보고 머라한것도 아닌데 너무 과민반응하시는것 아닌가요?

그리고 그런이야기를해야 "이런면이 안좋게 보일수도 있구나"하고.. 더발전적이되죠...

그럼 맘에 안드는것도 쉬~쉬~ 하고 있을까요??
그게과연 C나 Java나 프로그래머의 앞날에 발전적인것일까요?

그리고 자바가 정말그리 좋은것이라면.. 그리흥분할필요가 없죠..
전 C를 완전똥이라고 욕해도 전 아무렇지도 않습니다. C가제자신도아니고..
그런말한다해서.. 갑자기 C가 엉터리가 되는것도 아니고..
자신이 장점을알고 사용하면되는것 아니겠어요..


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

yamainu의 이미지

ㅡ,.ㅡ;; wrote:

C 확실하고 철저하고 엄격하다
java 융통성이있고 그리엄격하지 않고 확실하지도 않다.

"철저하고 엄격"이라는 부분...
상당히 개인적인 의견이라고 생각합니다.
오히려 C는 프로그래머의 능력을 믿죠.
컴파일러가 허용하는 문법적 에러 체크를 벗어나는 코드라면
사용자가 매우 자유스럽게 코딩가능하죠..
간단한 일례로

int a;
short b;
b=a;

자바(1.3)에서는 컴파일 안됩니다.
반면 gcc(2.96)에서는 그냥 컴파일 되죠( -Wall) 옵션을 줘도 warning도 없이 컴파일 되버리죠

PS. 오늘 다니던 회사를 그만둡니다. kldp가족 여러분 모두들 건강히...

Programmers never die: They just GOSUB without RETURN.

죠커의 이미지

yamainu wrote:
컴파일러가 허용하는 문법적 에러 체크를 벗어나는 코드라면
사용자가 매우 자유스럽게 코딩가능하죠..
간단한 일례로

int a;
short b;
b=a;

컴파일러가 허용하는 문법적인 에러 체크를 벗어나는 코드가 아니라 정상적인 코드입니다.

sskim의 이미지

그렇군요.
어차피 코드는 컴퓨터가 잘해석해야지 사람이 어떻게 생각하든지는
상관이 없다는 겁니다.
그러면 어셈블리를 하겠습니다.
그게 속편합니다.

그럼
ASM vs C vs JAVA
는 어떤가요?

3파전입니다.

CN wrote:
yamainu wrote:
컴파일러가 허용하는 문법적 에러 체크를 벗어나는 코드라면
사용자가 매우 자유스럽게 코딩가능하죠..
간단한 일례로

int a;
short b;
b=a;

컴파일러가 허용하는 문법적인 에러 체크를 벗어나는 코드가 아니라 정상적인 코드입니다.

_________________________________
beyond the compass of your powers!

Together의 이미지

자바로 제작된 일반 어플리케이션(워드, 스프레드시트 등등)을 쓰보면 체감
하기에 일반 네이티브 언어로 제작된 프로그램과 차이점은 없었습니다.

다만, 자바는 독점 플렛폼(가전용품)으로 발전할 가능성이 있으므로 경계
해야할 필요성은 있다고 생각합니다.

- 험한 세계에서 자주국방 없는 경제력은 경비없는 은행이다. -

이한길의 이미지

저도 내세울것은 없지만...
글쓰신분이 자바로 뭔가 해본것이 없으셔서 그럴 것입니다.
저는 처음에 C++도 그다지 곱게 보지 않았는데...
해보니까 나름데로 특징이 있고 좋더군요..

처음에 ML도 그랬습니다.
이거 머하러 하는건가 싶었는데..
지금은 꽤 맘에 듭니다.

아마도 그런것 같습니다.
무슨 언어든지 나름데로의 특징이 있고..
쓸모가 있고 장점을 활용하면 좋은 것을..

자신이 쓰고 싶은곳에 맞춰 쓰려니 그런 문제가 발생한다고 봅니다.

예를 들어 망치로 나사를 박으려 하면서..
도구중에 망치는 좋지 않고 드라이버가 오히려좋다...
던가.. 드라이버로 못을 박으려 하면서
이걸로는 잘 들어가지 않고 망치로는 잘 들어가니..
도구중 망치가 좋다는 식이 되고 맙니다.

물론 처음부터

난 못을 박는 일을 주로 하기 때문에
드라이버를 별로 좋아하지 않는다고 하셨다면
괜찮았을 텐데..

그렇지 않으시고..

난 드라이버를 좋아하지 않는다. 원하는게 제대로 되지 않는다

이렇게 말씀을 꺼내셨으니...
결국 이렇게 될 수 밖에 없는게 아닌가 싶습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

zoops의 이미지

sskim wrote:

C Java
1. 기계적이다. 인간적이다.
2. 완벽하다. 놀랍다.
3. Java가부럽다. C를이길순없다.

원츄입니다.

ㅡ,.ㅡ;; wrote:

운영체제로 비유( 좀관계가 먼느낌도 있으나 ) 하자면..

C 는 유닉스
java 는 M$윈도우..
같은..

C 확실하고 철저하고 엄격하다
java 융통성이있고 그리엄격하지 않고 확실하지도 않다.

제 느낌도 꺼꾸로 인것 같군요....
java 가 왜 엄격하지 않고 확실하지 않은거죠?? 오픈마인드로 표준안처리하는것보면.. 확실히 java 가 유닉스 쪽에 가까운데...

Together wrote:

자바로 제작된 일반 어플리케이션(워드, 스프레드시트 등등)을 쓰보면 체감
하기에 일반 네이티브 언어로 제작된 프로그램과 차이점은 없었습니다.

다만, 자바는 독점 플렛폼(가전용품)으로 발전할 가능성이 있으므로 경계
해야할 필요성은 있다고 생각합니다.

워드나 스프레드시트등등이 체감하기에 차이가 없다구요??
도데체 컴퓨터를 얼마나 좋은걸 사용하기기에.. 차이가 없나요??
저는 SWT 를 사용하는 이클립스도 짜증나서 안쓰는데....
물론 못쓸정도는 아니지만... 에디터로 비주얼J 사용하고 ant 로 따로 컴파일하는게 작업 능률이 두배는 좋아서리....

- zoops -

ironiris의 이미지

yamainu wrote:
ironiris wrote:
자바가 플랫폼에 상관없이 실행되고자하는 것은 플랫폼마다 C컴파일러가 지원되어서(특히 gcc) 좀 설득력이 떨어지는 것 같습니다.
조금 알려진 기기라면 아주 약간만.. 기다리면 c로 컴파일된 바이너리를 얻을수 있는데 왜 자바를 쓰겠습니까?
일례를 들어서 샤프의 PDA인 자우루스를 예로 들겠습니다.
이 기기는 기본적으로 "자바"환경이 되어 있으면서 QT환경입니다. 리눅스를 운영체제로 하고 있긴 합니다.
그렇다면 그 이식성이 좋은 자바로 만들어진 응용프로그램이 많아야 하는데.. 자우루스에서 잘돌아가는 자바프로그램을 찾기 어렵더군요. 자바로된 게임을 받아봐도 잘안돌아가고...
하지만 여러 c 로 된 공개소프트웨어를 받아서 gcc 로 컴파일하니 자우루스에 맞는 실행파일을 얻을수 있으니.. 그 바이너리는 호환성이 없는지 몰라도 기기에 최적화된 바이너리를 얻을수 있어서 좋네요.

물론 그냥 컴파일되는 소스도 있고 어느정도 수정해야 컴파일되는 것도 있습니다. 자바로 된것도 어느정도 수정을 하면 작동될수도 있겠지요. 수정해서 작동한다면 자바가 내걸고 있는 장점인 플랫폼에 상관없이 작동이라는 말은 말짱 거짓말이 되어버린 것이죠.
c쪽은 장점으로 내세우지 않았음에도.. 결국은 다 지원하는 꼴이 되어버린 것이고요.(컴파일의 과정을 거쳤지만.. 저장공간은 다른 기종과 공유할일도 없는데.. 특수한 경우는 있겠지만..)

뭐 이런 저런 장/단점이 c나 자바나 각각 있겠지만 지금 시점에서는 자바가 장점으로 내세웠던 것이 하나 둘씩 사라지는 느낌이네요.

java개발 , 리눅스 C 개발, 그리고 자우루스 상에서 C 프로그램을 했습니다. 그리고 지금은 j2me 핸드폰 App개발중입니다.
ironiris 님께서는 C와 자바라는 언어(정확히 말해 자바는 플랫폼+언어)의 차이를 정확히 이해하고 있지 않습니다.
자바는 윈도우,NT,Mac등에 JVM(자바가상머신)을 올리고 그위에 자바프로그램을 돌립니다(인터프리터). 물론 그 프로그램은 어떤 OS든 상관없이 동일한 JVM이 설치된 곳이라면 소스의 수정없이 가능합니다.
그러나 C는 언어로서 윈도우/linux,또는 CPU타입에 따라 필요한 헤더파일등 하드웨어와 관련된 부분을 직접 프로그래머가 구현 하게 됩니다.
자바는 이러한 부분에서 편의성의 제공하고 이식성을 제공하는 것입니다.
모바일의 경우는 자원의 제약/차이로 Configrattion,profile등의 그룹을 나누어 PC와는 다른 환경의 JVM을 설치하며 기기제조사의 OEMspecific 한 부분의 코딩만 배제한다면 동일한 이식성과 편리성을 가지게 됩니다.
물론 C언어가 해당OS나머신에 최적화된 코드를 제공할수 있다는것은 큰 장점입니다.
(자바는 공통된 런타임환경을 제공하기위해 os/머신의 특정한 부분의 기능을 배제 시킨것이겠죠)
그러나...기기제조사에서 OEM 의 JAVA API를 제공한다면 이러한 것도 문제가 되지는 않겠죠...

중요한 것은 환경에 알맞은 언어를 선택하면 되는 것입니다.
그리고 언어마다 그 특징이 있고 이를 잘 파악하면 된다는 것!
저는 모든 언어를 사랑합니다.^^*


잘아시는 분들 입장에서는 분명히 차이가 나겠지만
사용자의 입장에서는 자바의 바이트코드나 C언어의 컴파일된 바이너리나 똑같이 생각합니다.
똑같다고 생각하는 바이너리를 가지고 사용자는 한번의 설치과정을 겪었을 것입니다. 그런데 C언어로 만들어진 바이너리는 그냥 이름만 치면 실행되고 로딩도 빠르고 속도도 더 빠릅니다.
자바로 만들어진 바이트코드는 용량은 상대적으로 더 작지만 VM도 같이 떠야 하기 때문에 실행속도가 더 느리고 VM위에서 돌아가기 때문에 C언어로 만들어진 바이너리보다 작업속도도 느립니다.

제가 프로그래밍하다가 프로그래밍의 진수를 알기전에 다른 분야로 가서 각 언어에 대한 개념은 정확하게 모릅니다만..

제 글은 프로그램 사용자의 입장에서 적은 것이지요.
이곳에서의 글들을 보면 프로그래머의 입장에서만 글이 올라오는 것이 안타깝습니다.
코드가 환상적으로 짜여진 프로그램을 사용자들이 좋아할 것이라고 생각하면 곤란합니다. 사용자는 업그래이드했으니까 속도는 더 빨라지고 새로 배우기 귀찮으니까 자신이 전에 알던 인터페이스대로... 사용하길 원할 뿐입니다.
C로 만들어진 프로그램을 자바로 만들어서 배포한다면 사용자들은 어떤 차이점을 느낄까요?
"실행속도가 더 느려졌다. 작업처리속도도 느려졌다. 실행하기 귀찮다." 이 세가지가 가장 크게 와 닿을것입니다.
그럼 자바로 만든 프로그램을 C로 만들어서 배포한다면 사용자들은 어떤 차이점을 느낄까요?
"더 빨라졌다. 작업속도도 더 빨라졌다. 실행하기 편리해졌다." 이렇게 느끼겠죠. 전혀~ 예전에 비해 "소스를 읽기가 편해졌다. 서드파티의 지원이 많아졌다." 등등 이라고 생각하지 않습니다.
또 호환성도 전혀 생각치 않습니다.
자우루스PDA를 언급했었지요? 자우루스용 PDA를 쓰면서 자바로 만든 소프트웨어를 구하면 자우루스에서 작동하기를 원하겠지만 잘작동한다는 보장도 없고, 진정한 컴맹이 아니고서는 아무 프로그램이나 자우루스에 넣고 작동하기를 원하는 사람은 없습니다. 자우루스용으로 컴파일된 프로그램을 자우루스에 넣고 작동하길 원하며 잘작동하지요.
하여간 그렇습니다. 세상은 프로그래머들만 사는 것도 아닙니다.

fender의 이미지

참고로 SWT의 속도에는 좀 의문점이 있습니다. 윈도우즈에서는 거의 네이티브 어플리케이션과 차이가 없는데 GTK2의 경우 특히 픽스맵 테마를 썼을 때 확실히 속도가 떨어지는 걸 느낍니다.

SWT 소스를 봐도 JNI 호출까지 거의 별로 거치는 단계가 없는 것으로 보아 설계상 문제라기 보다 어떤 버그가 아닐까 싶군요.

이클립스의 경우는 SWT가 무거운게 아니라 플랫폼 자체가 워낙 복잡하고 계층이 많아서 느린 거라고 생각합니다. 더구나 '유니버설 툴 플랫폼' 개념으로 확장하면서 모든 것을 플러그인과 feature 등으로 나누고 워크스페이스를 유연하게 구성할 수 있게 설계하는 과정에서 추상화 계층이 상당 수 늘어난 결과라고 생각합니다.

SWT의 속도를 비교하시려면 직접 간단한 샘플을 만들어보시거나 몇몇 안되지만 스탠드얼론 어플리케이션을 테스트해보시는게 좋을 것 같습니다(제가 만든 아르고스 사전은 제외 -_-;; ).

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

youlsa의 이미지

언어가 무슨 상관이겠습니까? 하고자 하는 task에 따라 알맞은걸 골라 쓰면 그만이죠. 하고자 하는 일이 중요한 것이지 수단은 뒷문제라고 생각합니다.

다만 개인별 취향이 있는 법이니 나름대로의 근거에 기반해서 어떤걸 좋아하고 싫어한다고 밝히고 토론하는 것을 즐길수 있는 것인데 너무 민감하게 반응하지 않았으면 좋겠습니다.

오픈 소스 개발자들이 자바를 그리 좋아하지 않는게 사실입니다. 무엇보다 SUN이 일을 해가는 형태와 불투명한 라이센스와 소스코드가 공개되지 않은 등의 이유로 인해 싫어하는 개발자들이 많지요. 위에 보니 자바가 유닉스적이라는 말이 보이는데, 유닉스적인지는 모르겠지만 오픈소스적이지는 않습니다. Perl과 Python등이 더 오픈소스적이지요. 이런 시각은 Eric Raymond의 The Art of Unix Programming의 각 언어 소개 챕터중 자바 섹션을 보시면 알 수 있습니다.

현실적으로 대형 SI프로젝트나 서버 기반의 비지니스 어플리케이션 제작에 있어 자바를 따라갈만한 도구는 없습니다. 수많은 비지니스 로직 등등을 모두 C로 작성한다는건 아무리 대단한 프로그래머라도 절대 하고 싶지 않은 일일겁니다.

=-=-=-=-=-=-=-=-=
http://youlsa.com

aeronova의 이미지

이런식의 언어를 비교하는 주제는 별로 좋아보이지 않습니다.
근래에 C++의 것도 그러했고..
아무래도 kldp의 고질병(?)이 아닌지 생각됩니다.

It's better to burn out than to fade away. -- Kurt Cobain.

죠커의 이미지

fender wrote:
저는 자바가 대세가 되거나 그런 건 별로 신경쓰진 않습니다. 각각 자신이 좋아하고 프로젝트 성격에 알맞는 언어를 고르면 되는 것이고, 다만 가끔씩 접하는 로우레벨 언어 개발자들의 자바 언어에 대한 이유없는 우월의식이나 별로 근거없는 성능에 대한 비판 같은 건 사라졌으면 좋겠군요.

전자의 의견에는 동의하는데 근거없는 성능에 대한 비판이란 것은 문제가 있다고 생각합니다.

현재 다른 파트는 성능이 향상되었다고 하더라도 GUI는 현재 느린게 사실이고 현재 응용프로그램들은 느린게 사실이 아닙니까?

사람들의 의식은 곧 나아질거다. 나아지고 있다. 에 의해서 생겨나는게 아니라 현재의 응용프로그램들을 보고 느낀 게 의식이 되는게 아닐까 합니다.

fender의 이미지

CN wrote:
fender wrote:
저는 자바가 대세가 되거나 그런 건 별로 신경쓰진 않습니다. 각각 자신이 좋아하고 프로젝트 성격에 알맞는 언어를 고르면 되는 것이고, 다만 가끔씩 접하는 로우레벨 언어 개발자들의 자바 언어에 대한 이유없는 우월의식이나 별로 근거없는 성능에 대한 비판 같은 건 사라졌으면 좋겠군요.

전자의 의견에는 동의하는데 근거없는 성능에 대한 비판이란 것은 문제가 있다고 생각합니다.

현재 다른 파트는 성능이 향상되었다고 하더라도 GUI는 현재 느린게 사실이고 현재 응용프로그램들은 느린게 사실이 아닙니까?

사람들의 의식은 곧 나아질거다. 나아지고 있다. 에 의해서 생겨나는게 아니라 현재의 응용프로그램들을 보고 느낀 게 의식이 되는게 아닐까 합니다.

좀 제 문장이 오해의 소지가 있군요. 제가 지적한 부분은 자바의 성능에 대한 비판 자체가 아니라 '근거 없는' 성능에 대한 비판입니다.

자바의 성능상의 제약은 이미 윗글에서 제가 직접 언급한 적이 있습니다. 다만 자바에 대한 말이 나오면 항상 무턱대고 "자바는 느려서 쓸만한게 못된다"라는 식의 비판이 제기되기 때문에 문제를 제기한 것일 뿐입니다.

현재 자바 언어가 널리 쓰이는 분야는 주로 서버측 어플리케이션입니다. 이 분야에서는 오히려 JIT 성능의 향상이나 자바에서 연동할 수 있는 여러가지 캐쉬 기술 등을 통해 성능면에서 우위를 주장할 수도 있을 정도 입니다.

하지만 과거 애플릿이나 무거운 스윙 어플리케이션을 몇개 돌려본 경험으로 싸잡아서 '자바는 느려서 못쓴다'라고 결론 내리는 사람들이 아직도 꽤 많은 것 같습니다.

물론 데스크탑 어플리케이션에 국한해서 자바의 성능을 비판할 수도 있습니다. 하지만 단순히 "내가 어떤 자바 프로그램 써봤는데 느려서 못쓰겠더라" 수준이 되면 곤란하지 않을까 생각합니다.

제 생각에도 아직 자바는 데스크탑 어플리케이션 시장에서 주요 언어로 부상하기에는 문제가 많습니다. 이런 부분에 대한 합리적인 비판이라면 당연히 의미를 부여할 수 있습니다.

하지만 개인적인 판단으로는 GCJ나 SWT 등의 등장으로 이런 제약도 빠른 시일 내에 사라지리라 생각하며, 그런 의미에서 지금부터 시험삼아 이들 기술을 이용해 몇몇 응용프로그램을 만들어 보고 있습니다 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

pebiman의 이미지

항상 하는 말들이겠지만, 나름대로 다 장단점이 있는 것 같습니다.
UI를 만드는데..자바만큼 Performance가 나는 언어도 드물다고 생각하지만, Critical한 프로세스를 요구하는 곳에서는 C보다 처리속도가 현저히 떨어지는 걸 직접 경험 한 적이 있습니다.
Java 만큼 프로그램의 대중화에 기여한 언어도 없다고 생각합니다. 그만큼, 쉽고 가독하기 쉽게 설계되어있으며, 개체지향 패러다임에 아주 근접한 언어가 아닌가 합니다.
반면 C는 자바보다는 훨씬더 자유로운 언어가 아닐까 합니다. 자유롭되 더 책임이 따른 다는 반증이겠죠..
저에게 C를 할래 Java를 할래 물어본다면, 전 C를 택하겠습니다.
넌 자유로운게 좋으니까요..^^

추신. C의 꽁수는 무궁무진하다.

쓰레기는 쓰레기통에...

ㅡ,.ㅡ;;의 이미지

fender wrote:

현재 자바 언어가 널리 쓰이는 분야는 주로 서버측 어플리케이션입니다. 이 분야에서는 오히려 JIT 성능의 향상이나 자바에서 연동할 수 있는 여러가지 캐쉬 기술 등을 통해 성능면에서 우위를 주장할 수도 있을 정도 입니다.

동등한조건에서 평가해야 제대로 평가가 되지요..
하나는 캐쉬를 사용하여 더빠르다 라고한다면.. 더좋은장비에 넣으면 더빨라진다 라는거나 마찬가지 아니겠어요..
캐쉬를 사용한다면 같이 사용하는 프로그램끼리 비교하던가 아니면 둘다 사용하지 않게 하고 비교해야됩니다..


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

fender의 이미지

ㅡ,.ㅡ;; wrote:
fender wrote:
현재 자바 언어가 널리 쓰이는 분야는 주로 서버측 어플리케이션입니다. 이 분야에서는 오히려 JIT 성능의 향상이나 자바에서 연동할 수 있는 여러가지 캐쉬 기술 등을 통해 성능면에서 우위를 주장할 수도 있을 정도 입니다.

동등한조건에서 평가해야 제대로 평가가 되지요..
하나는 캐쉬를 사용하여 더빠르다 라고한다면.. 더좋은장비에 넣으면 더빨라진다 라는거나 마찬가지 아니겠어요..
캐쉬를 사용한다면 같이 사용하는 프로그램끼리 비교하던가 아니면 둘다 사용하지 않게 하고 비교해야됩니다..

음... 그래서 애초에 속도를 가지고 자바와 C를 단순비교하는게 무의미하다고 생각하는 겁니다. /. 등에서 이런 논쟁이 시작되면 'apple과 orange를 비교하는 건 무의미하다'는 답글이 많이 올라오더군요 :)

C와 자바의 선택은 절대적 퍼포먼스와 생산성/디자인의 trade-off 관계입니다. 즉, 처음부터 동등한 조건에서 비교하는게 무의미한게 아닐까요?

예를들어 성능만이 모든 것의 척도라면 파이선, 펄은 물론 C/C++조차도 살아남지 못했을 겁니다. 심지어 홈페이지 하나 제작하는데도 어셈블리로 HTTP 서버부터 코딩하고 있지 않을까요?

엔터프라이즈 웹 어플리케이션에서 많이 쓰이는 분산캐쉬나 자동화된 퍼시스턴스 프레임워크 등은 제가 아는 한 C/C++로 구현되어 있는 경우 자체가 거의 없습니다. 생산성이나 디자인, 써드파티 툴 지원 등등을 무시하고 오직 성능만을 생각한다면 이해가 가지 않는 부분이 아닐지요...

이런 부분만 봐도 언어마다 적합한 영역이 따로 있다고 봅니다. 개인이 자바를 좋아하건 C를 좋아하건 여부는 자유지만 다른 언어를 과소평가하거나 자신의 언어를 모든 문제해결에 적합한 'silver bullet'으로 인식하는 건 좀 위험한 일이라고 봅니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

liongo의 이미지

참으로 어려운 내용입니다

전에 언제 비슷한 글을 보다가 다른사람과 얘기를 해보았습니다..

언어는 하나의 종교라고 생각될정도로 중요한 부분입니다..

확실한 느낌만으로 기독교나 , 불교 등등의 종교를 비판하는것은

좋지 않은 예라고 생각이 드는군요..

전 C C++ Java Python 을 주로 씁니다..

그리고 내용적인면에서 토론의 주제가 명확하지 않은것 같습니다만.

다들 다른각도 측면 으로 비교를 하고 있지 않나 생각합니다..

제생각에는 언어는 표현의 도구일뿐이라고 생각합니다..

그리고 하시는 프로젝트의 적절한 언어를 선택하는것이 중요하겠지요..

표현의 도구를 가지고 표현된것만을 보며 평가하는것은 이상하지 않나

생각이 됩니다만.. 표현하기 나름입니다.. 그리고 목적을 이뤘다면..

성공한거 아닌가요? 속도만 따진다면 어셈을 써도 되고 쉬움을따진다면

스크립트를.. 이런 극단적인것만이 아니기에 씨나 씨++ 자바를 쓰는것

아닙니까? 프로그래머로써 느낌만으로 몬가를 평가한다는것은 조금은..

경솔하지 않나 싶습니다.. 물론 제생각입니다.. 그래도.. 다른종교를

비평할때는 좀더 .. 객관적인 입장은 가지고 겸허한 마음을 가집시다~!

지나가다 잡설이었습니다..

P.S 프로그래밍을 시작 하시는 분들이 이런내용으로 혼란을 겪지 않으시길~!

' 형식이 내용을 규정한다. '

GivenJazz의 이미지

ㅡ,.ㅡ;; wrote:
sDH8988L wrote:
점점 의심이 가기 시작합니다...

아무래도 그 의심이 사실인 거 같네요...

제가 생각하기에는 글 올리신 분이 장난 하시는 거 같습니다...

말도 안되는 글을 일단 올리고 나서 사람들의 반응을 지켜보는 초딩적인 장난을 하고 계신 거 같네요...

보통 알려진 사실들을 전부 거꾸로 이야기 하고 있는 것도 그렇고요...

다른 사람들이 반박한 글들을 어떤 식으로든 다시 자신의 의견을 관철시키려는 그런 자세도 아니고...

그냥 장난하는 거 같습니다...

뭐... 초딩은 아니신 거 같지만, 장난치는 것 같아서 좀 기분이 안좋네요...

저는 이제 글을 올리지 않으렵니다... 몇 개의 글을 올렸지만, 지금 생각해 보니까 장난질에 놀아난 거 같네요...

더 이상 글쓰신 분에게서 생산적인 뭔가를 기대할 수도 없고...

다들 장난질에서 벗어나시는 게 좋겠네요...

"난티고가 작아서 맘에 안든다" 고하면.. "난오히려그게 맘에든다" 면되지.
"너티고가 작어서 맘에안들다니 초딩아냐?" 이런식이될순 없자나요.. 잘아는사람도 아니고말이죠...


ㅡ,.ㅡ;;님의 주장을 비유하자면 "티코가 작아서 맘에 안든다"가 아닙니다.
"BMW는 티코보다 승차감이 나뻐서 맘에 안든다." 혹은
"포르쉐는 티코보다 속도감이 안나서 맘에 안든다" 수준입니다.

개인적으로 티코를 편하게 혹은 빠르게 느낄 수 있겠지만 적당히 억지를 써야죠.
이런 글은 KLDP에서 되도록 보지않았으면 좋겠습니다.

ㅡ,.ㅡ;;님의 글을 보시면 대충 수준을 아실 수 있을겁니다.
http://bbs.kldp.org/viewtopic.php?t=29753&highlight=

ㅡ,.ㅡ;;님은 장난이 아니라 나름대로 진지한 것같습니다.
그렇다면 더욱 문제겠지요.

jos77의 이미지

java 로 코딩 시작한지 3개월 되었습니다.

그전까지는 C , C# 으로 embedded programming 했었고 (경력 약 3년)
이번에 web 하면서 cgi 하다가 java 하게 되었는데
3번 7번 은 좀 이해가 안 가긴 하지만 나머지는 전부 공감가네요.

java 가 오로지 web 환경에서만을 위해서 개발된 언어인 건가요? --; embedded 에서도 많이 쓴다고 알고 있었는데
제일 짜증 나는 건 역시 8번 모듈 제공 ... 제가 MS 환경에서만 너무 개발해와서 그런지 한번에 안되는 건 기분나쁘더군요. 모듈 찾기도 귀찮고 서드파티 라이브러리도 한번에 안 붙으면 짜증나고
5번 같은 경우는 적극 찬성. C 로 하면 한 줄 코딩하면 되는데 java 로 하면 두세 줄 코딩으로 늘어나면 그것만 가지고도 짜증나는 판국에 (사실 그거 때문에 C# 도 배울 때 고생 좀 했음) method 나 api 모르는 거 사용할 때에는 답답해 미치고... 6번 같은 경우도 뭐랄까... 개인적으로 library 없으면 내가 만들어 쓰는게 당연히 다운받아 쓰는 것보다 '좋다'고 생각하는 사람으로서는... 암기 위주 코딩... 엄청 짜증납니다.
c와 java 를 비교하자는 뜻은 아니지만, 저는 엄청 공감가네요... 뭐랄까 java 가지고 '개발'을 하자는게 아니라 '프로그래밍' 자체를 이리 저리 머리 돌려가면서 연구해보자... 즉 필요한 제품 개발이 아닌 java 로 '무엇'을 할 수 있느냐를 생각해볼 때 프로그래머로서 java 가 마음에 안 들게 되는 것 같습니다...

-----
안녕하세요 소프트웨어 공학센터 장원석 책임입니다.
http://www.software.kr

appler의 이미지

또 다시 전쟁은 시작되는건가요..-_-;;

java로 임베디드 하는건 wipi쪽이 아닌가 싶네요

얼핏 들은거 같아서..


laziness, impatience, hubris

不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.
하지만 모르는것에 대해서


laziness, impatience, hubris

不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.

zepinos의 이미지

저도 익숙해지기 전까지는 뭐가 이래...라고 했습니다만...

자바 경력이 C/C# 경력보다 길어져버린 지금에서는

C 로 짜라고 하면 무지 성질날 듯...

완소 apache/jakarta/commons 가 있는 이상...

cleol의 이미지

쓰신 글을 요약하자면... "나는 자바를 잘 몰라서 짜증난다." 이군요 :)

하드웨어를 직접 다룰 일만 아니면 필요한 거 그냥 jos77님 스타일대로 만들어쓰시면 됩니다.

화내지 말고 찬찬히 공부해보세요.

jos77의 이미지

구글에서 'java 싫어' 를 쳤더니 나온 사이트가 여기라서 글 올린 거였습니다.
그리고... java 싫어하는 분들도 분명히 세상에는 있을 텐데 찬성하는 사람이 아무도 없길래 몇 마디 올린 거구요.
(낚시라든가 도발성 의도로 쓴 글이 아닙니다만... 그렇게 보인다면 지송)

개인적으로는 주로 C / C# 으로 local 이나 embedded 에서 돌아가는 프로그램 만드는 일 하다가... 직장 옮기면서 시스템/웹 환경 와서 개발자 일을 하려니 그것 자체가 짜증나는데 php 나 cgi 는 그래도 할만한데 하필 java 가 제 성격과 안 맞는 건지 안 배워봐서 그런건지 답답한 구석이 많네요. eclipse 도 C#.net studio 랑 비교하기엔 불편한 구석이 많고...
뭐 잘 모르니까 나오는 불만이라는 점에는 동의하지만, 앞으로 java 를 좋아하게 될지는 아직 미지수네요...

-----
안녕하세요 소프트웨어 공학센터 장원석 책임입니다.
http://www.software.kr

nonots의 이미지

php 가 있는데.. 머할라고..

=== 건달의 경지를 꿈꾸며 ===


=== 건달의 경지를 꿈꾸며 ===

semmal의 이미지

결국 아무것도 못배우죠.

배울 때는 좋고 싫은걸 따지는 것이 아니라 무엇을 배워야하는지에 집중해야하는데 말이죠.

이 세상에서 이것 싫고 저것 싫어서 배우는 것을 거부하면 결국 무엇을 배울 수 있을까요?

그냥 이 글타래에 대한 느낌을 많이 심하게 말하자면 포크레인은 스포츠카보다 느려서 싫고, 할리데이비슨에는 눈이 돌아가도 택트는 우습게 보고, 코란도가 티코보다 무식해보이고, 사람은 차를 만드는데 차는 사람을 못만든다고 불만이고, 멀리가는데 편리하자고 만든 차를 엔진이 복잡하다고 싫다고 하고, 운전대도 못잡아봤으면서 운전면허필기시험을 왜 해야하냐고 불만터트리고, 차 점검도 못하면서 차 성능이 어떻네 하는 것 처럼 들리는 글이군요.

좀 제대로 배워보고 불만을 터뜨립시다. 차라리 Java에서 템플릿 지원이 별로라서 싫다던가, 언어에서 covariance/contravariance가 안되서 불만이라고 한다면 고개는 끄덕이겠습니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

JuEUS-U의 이미지

자바를 버리긴 했지만 -ㅅ-;; 자바가 딱히 나쁘다고는 생각 안합니다.

비교적 깔끔한 GUI 라이브러리에서 감동,
왠만한건 플랫폼 상관 없이 돌아가서 감동,
빵빵한 공짜 툴들에 감동 백만배....

그런데도 Java로 갈아타고 싶은 생각이 안드는게 조금은 신기하네요.....

김일영의 이미지

EJB등은 하는 일에 비해 프레임웍이 너무 복잡하고 직관적이지 못합니다.
거창한 VM에 비해 동적인 최적화는 이론적으론 대단한걸로 알고 있지만 실제 체험할 수 있는건 별로입니다.
처음에 JAVA 언어 만들때 syntax sugar에 대한 고려가 부족했습니다. getter/setter 같은 것... 좀 더 단순하게 됐어야 합니다.
클래스패스 잡는거 짜증... 좀 이런 쪽에 여러가지 방법 선택의 여지를 주면 안 되는 것인지?
여하튼 쓰다 보면 좀 갑갑합니다. 당분간 쓸 일이 없어서 다행...

cleol의 이미지

> EJB등은 하는 일에 비해 프레임웍이 너무 복잡하고 직관적이지 못합니다.

전적으로 동감합니다. 그러니까 무수히 많은 다른 프레임워크들이 쏟아져 나온게지요. 그 녀석들마저 쓸데없이 복잡한 경우가 많았습니다만, 요새 Wicket 같은 것을 보고 있노라면 (EJB 와는 하는 일이 다르지만) 좀 정리가 되어간다는 느낌이 듭니다.

>거창한 VM에 비해 동적인 최적화는 이론적으론 대단한걸로 알고 있지만 실제 체험할 수 있는건 별로입니다.

별로라고 판단한 근거가 있으신가요? 아마도 없을것 같은데요. 실제로 체험한다는 것이 어렵지요. 비교할 대상을 찾을 수가 없으니까요. 같은 문제를 놓고 정적 최적화와 실행 시간 동적 최적화를 비교해야하는데 "예제 문제" 가 아닌 엔터프라이즈 비지니스의 "실제 세상 문제" 에서 그렇게 두 구현을 만드는 것도 어렵고, 비교하는 기준/방법을 정하는 것도 어렵지요. 그냥 좋아졌으려니.. 하는게지요.

>처음에 JAVA 언어 만들때 syntax sugar에 대한 고려가 부족했습니다. getter/setter 같은 것... 좀 더 단순하게 됐어야 합니다.

동감합니다. 자바를 보고 있노라면 적어도 문법에서만은 클래스를 추가한 C 라는 생각이 듭니다.

>클래스패스 잡는거 짜증... 좀 이런 쪽에 여러가지 방법 선택의 여지를 주면 안 되는 것인지?

이것은 전혀 동의하지 못하겠습니다. 이보다 더 유연한 방법이 있나요? 환경 변수로 잡을 수도 있고, 명령행 인자로 줄 수도 있고, 코딩을 몇 줄 해야하기는 하지만 런타임에 클래스패스를 변경할 수도 있지요. 코드를 몇 줄 더 넣으면 원하는 방식으로 클래스를 찾도록 클래스로더를 직접 작성하는 것도 어려운 일이 아닌데 이보다 더 유연할 수가 있을지요.

뭐 어쨌거나 업무상 자바를 가장 많이 사용하지만 "언어 자체"가 그다지 매력적이지 않은 것은 분명합니다. 그런데 그 커뮤니티는 꽤나 매력적이지요. 정말 많은 "오픈 소스" 라이브러리들과 좋은 "오픈 소스" 툴들, 그리고 활발한 온라인 커뮤니티가 있으니까요.