자바가 정말 쉬운 언어인가요?

anfl의 이미지

문득 자유게시판에 올라온 글중에 "자바책" 관련 내용을 보고 평소 궁금했던게 떠올랐습니다.
자바가 대부분 쉽다라고 이야기들 하시는데 자바가 정말 쉬운가요?

이렇게 물어보는 이유는 제가 경험해본 자바는 모호해서 쉽지 않았기 때문입니다.

제가 모호하다는 표현을 쓰는것은 자바가 감추는게 너무 많아(주로 JVM 쪽에서) 명확하지 않은 언어란 느낌을 받았습니다.

또한 이런 느낌을 받은 배경에는 제가 apple BASIC부터 시작해서 MSX BASIC,
pascal, C, assembly, C++을 거치면서 주로 system쪽을 해왔기 때문입니다.

C++ 배울때 가장 넘어가기 힘들었었는데 이유는 그냥 논리적으로 받아들여야 될부분을
자연스럽게 물리적으로 해석하려 했기 때문입니다.
예를들면 class의 memory map은 어찌 될것인가? 함수 오버로딩은 어떻게 구현될것인가?
등등 이런식으로 생각을하니 C++을 처음 배울때 항상 의문 투성이였고 그래서 모호했었습니다.

결국 class의 memory map과 함수 오버로딩의 원리를 모두 파악하고 나서야 C++이 이해가 되더군요.

그러다가 2000년도에 처음으로 JAVA를 접했습니다.
저에게는 안좋은 기억밖에 없는데 첫번째로 최종 결과물이 너무 느렸다는것(당시의 PC 사정과 JVM 성능 때문이라 생각합니다.) 그리고 너무도 모호했다는 것입니다.

JVM을 믿어봐라고 이야기하는데 JVM을 어떻게 믿어라는 말인지.
지금 사용하는 processor도 못 믿을 판국에...

이게 JAVA를 처음 접하면서 부정적인 시각을 가지게된 원인이고 그로인해 JAVA가 쉬운 언어로 느껴지지는 않았습니다.

그리고 프로그래밍은 기본적으로 if, for, function call로만 조합하면 어떠한 프로그래밍도 가능하다라고 생각했는데 JAVA는 아닌것 같더군요. 이러한 control-flow보다는 오히려 API를 누가 더 많이 아느냐가 중요한것 같았습니다. 결국 JAVA의 플렛폼에 완전히 적응을 해야하는 것이죠.

JAVA를 디자인한 사람이 제임스 고슬링인가요?
프로그래밍 하는데 고슬링의 생각을 계속 따라야 하다는게 너무 거슬리더군요. 결국 느린 JVM에(2000년도 당시에), 대책없는 믿음에(JVM에 대한 신뢰), 이해가 안가는 구조(memory map, 동작 방식, 지금은 이해가 가지만...), API의 강요에 대한 거부감으로 인해 저에게 JAVA는 무척 싫고도 어려운 언어였었습니다.

그런데 사람들은 한결같이 JAVA가 쉽다고 말을 합니다.
저는 이 부분이 정말 이해가 안가서 이 글을 씁니다.

저는 JAVA가 어렵고 API 찾기 귀찮은 언어인데 왜 대부분의 사람들은 JAVA가 쉽고 편하다 느끼는걸까요?

youlsa의 이미지

핵심을 잘 찔러서 말씀하셨는데요... 대책 없는 믿음, 이해안가는 구조, API 강요에 대한 거부감으로 저도 자바를 그리 좋아하지는 않는데요... (여담이지만... 제가 기독교에 느끼는 거부감과 비슷한 이유인 것 같습니다)

아마 프로그래밍을 처음부터 자바를 배운 분들은 별다른 거부감 없이 잘 쓰시는거 같습니다. 사실 복잡한 포인터 관련 오퍼레이션들이나 시스템별로 차이가 나는 부분등등을 잘 숨겨주고 있어서 API와 그 체계만 잘 따르면 크게 어려운 언어는 아닙니다. 그리고, 잘 사용한 경우에 좋은 효과를 보는 경우도 많이 봐왔구요.

하지만.. 아무리 생각을 해보아도 그 체계를 따르기가 싫습니다. 좀 뭐랄까 고슬링 개인의 강박관념(?)이 그대로 투영된 환경이라는 생각을 지울 수가 없습니다. 저는 빠른 vi, emacs에서 강박관념/고정관념 적고 빠르게 프로그래밍 할 수 있는 C와 Python, Django, 쉘 스크립트가 좋습니다.

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

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

terzeron의 이미지

저도 C/C++ 개발로 먹고 사는 사람이지만, Java의 completeness랄까 그런 특징이 장점이라고 봅니다. 기본적으로 제공되고 있는 API대로 따라서 작성하면 쉽게 완결성을 가지는 프로그램이 작성된다는 점은 초보 개발자들에게는 큰 매력이 아닐 수 없습니다.

또한 프로그래머의 어지간한 실수는 compiler가 잘 잡아주잖아요. (물론 logic error는 어쩔 수 없지만요.) 이거 하나만으로도 C/C++이 가지는 위험성을 많이 방지해주죠. GC도 장점이고...

각각 나름 유용하게 쓰이는 영역에서 자리잡고 있는 상태입니다. C/C++은 시스템 프로그래밍, Java는 웹이나 애플리케이션에서 강세를 보이고 있죠.

JuEUS-U의 이미지

궁금한게 있는데요,
비지니스 영역에서의 App말고,
일반적인 용도로써의 App에서 자바를 쓰는 모습이 잘 보이지 않습니다.

왜 그런걸까요 = ㅅ=)?;;;

압축 프로그램같이 플랫폼 특성을 타지 않는 프로그램이라면
크로스 플랫폼도 제대로 되고 좋을텐데 말입니다.

endofhope의 이미지

역시 jre 가 널리 퍼지지 않았기 때문이겠지요.
다른 글타래에서도 볼 수 있듯 거부감을 느끼는 사람들도 많으니까요.
jre 를 내장할 수도 있겠습니다만, 어지간히 큰 애플리케이션이 아닌 작은 용도로 기획되었다면
배보다 배꼽이 더 큰 경우가 될테니까요.

perl 의 경우처럼 대부분의 *nix 계열에서 설치되어 있을 것이라는 가정이 통하면이야 좋겠지만,
친구에게 java class 나 .jar 만 달랑 던져주고 "한번 돌려봐 꽤 괜찮아" 란 말을 하긴 어렵지요.

제 기계에는 jdk 가 깔려 있는 상태라 압축할때 대충 jar 를 써서 zip 으로 만들기도 합니다.
압축프로그램은 jar 라는 유틸러티가 이미 존재하고,
거기에 껍데기를 GUI 로 덮어 씌운다 해도 기존의 GUI 압축 프로그램보다
특출난 (개발을 한번 해도 된다는 것 외의 - 디버깅은 플랫폼 별로 해야 되겠지만 :) )
일반 사용자에게 어필할 편리한 점이 그닥 없기 때문이 아닐까요?

--
말할 수 있는 것은 분명하게 말해질 수 있다;
말해질 수 없는 것에 대해서는 침묵해야한다.
논리철학논고 - 루드비히 비트겐슈타인

--
말할 수 있는 것은 분명하게 말해질 수 있다;
말해질 수 없는 것에 대해서는 침묵해야한다.
논리철학논고 - 루드비히 비트겐슈타인

select99의 이미지

저또한 공감하는 말씀이네요....

대책 없는 믿음, 이해안가는 구조,API 강요에 대한 거부감...

마치 모 종교와 같은느낌을 저만 받은게 아니군요...

그것의 단점을 파헤쳐 이야기하면 매우 공격적인 자세를 취하는것또한 그렇구..

아무튼 저또한 개인적인 판단으로 절대 쉽다는 표현은 잘못되었다고 봅니다.

윗분또한 장점을 얘기하셨지만 저는 단점으로 보입니다.그만큼 복잡한거거든요..

그런 오류를 안내도록노력하는편이 훨씬 쉬워보입니다.
기본개념만 재대로 파악하면 오류난부분도 쉽게 눈에들어온다는게 제생각입니다.

fender의 이미지

자바 개발자의 관점에서는 오히려 KLDP와 같이 리눅스/C 개발자가 많은 커뮤니티에서는 정 반대의 느낌이 더 강하게 듭니다. ㅎㅎ;

이 곳에서 누가 감히 '자바가 최고다' 같은 식의 주장을 했는지는 기억이 나지 않지만, 반대로 자바는 무조건 C보다 못하다거나 무조건 느려서 못쓴다는 식의 극단적 주장은 심심찮게 올라오는 것 같은데요...

남이 어떤 편견을 가지고 있건 제가 일일이 상관할 필요야 없겠지만 리눅스와 자바 양쪽에 한발씩 담그고 있는 입장에서는 이런 오픈소스 커뮤니티에서 그런 글을 볼 때마다 맘이 편하진 않는군요...

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

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

fender의 이미지

자바는 범용언어로 분류하지만 실제로 주된 용도는 고차원적인 어플리케이션 및 프레임워크 제작에 많이 쓰이고 있습니다. 따라서 저차원 언어가 적합한 분야에서 자바의 효용을 판단한다면 별다른 메리트가 없다고 느껴지는 것이 당연합니다.

고차원적이라 쉽다거나 반대로 더 어렵다라고 단정지어서 말할 수는 없습니다. 저차원은 저차원대로의 복잡함이 있고 고차원은 고차원 대로의 어려움이 있는 것입니다.

비행기를 하나 만드는데 들어가는 개별 부품들을 보면 최첨단 신소재도 있을 것이고 복잡한 전자부품도 많을 것입니다. 예컨대 그런데 쓰이는 칩 하나 설계하는게 전체 비행기를 조립하는 것에 비해 하찮은 일이냐면 그렇지도 않을 것입니다. 하지만 반대로 비행기 조립에 필요한 모든 부품에 대한 제작 공정을 다 학습하면 공기역학적 측면을 포함한 항공기술을 모두 습득할 수 있는 것도 아니고 더구나 비행기 조종 따위는 쉽게 배울 수 있는 것도 아닙니다.

자바가 널리 쓰이는 분야에서 자바 개발자의 관점은 보통 기체를 어떻게 설계해야 항속거리가 더 나오는지 선회율이 더 좋아지는 지 같은 고차원의 고민이지 무슨재료를 쓰면 타이어의 수명을 더 오래가게 할 것인가 내지는 어떻게 하면 레이더에 들어가는 반도체의 제조단가를 낮출 수 있을까 하는 개별 부품레벨, 시스템 레벨의 고민이 아닙니다.

물론 완성된 기체의 전체적 성능은 개별 부품과 기체 설계가 복합적으로 작용한 결과일 것이고 때때로 작은 부품의 차이가 큰 성능의 차이를 보일 수도 있습니다만, 결코 최고의 타이어, 최고의 반도체 부품 같은 걸 모아서 대충 비행기 모양으로 뭉쳐 놓는다고 최고 성능의 전투기가 탄생하는 것도 아닙니다.

자바에서 각광받는 스프링이나 하이버네이트 같은 프레임워크를 보시면 자바 개발자들이 보통 어떤 문제를 고민하고 어떤 해법을 찾고 있는지에 대한 이해에 도움이 될 수 있습니다. 그런 프레임워크들이 다루는 문제들은 포인터나 저차원의 메모리 관리 같은 문제들과 단지 다른 종류의 문제일 뿐 더 쉽거나 덜 중요한 것은 아닙니다.

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

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

select99의 이미지

저는 그러한 비유에 동의할수 없군요..

사람마다 생각하는바가다르니.. 강요할순 없는부분이고..

저는 객관적인 결과로 말해야한다고 봅니다.

J사가 비행기 만들었고 C사가 비행기만들었죠..

누가빠른기간내에.. 적은투자로.. 더성능좋은비행기를 만들었냐는거죠..

물론 님은 J사 손을들지 모르겠으나.. 제가 여테보아오기론 소문과는 달리 모두 C사였다는거죠..

fender의 이미지

비유를 이해 못하신게 아닐까요? 저는 'J사'가 좋다라고 한 것이 아니라, 'J사'가 항공기 회사라면 'C사'는 부품회사기 때문에 같은 마켓에서 같은 제품으로 경쟁하는게 아니라는 뜻이었습니다. 'C사도 항공기를 만들었다'라고 하셨는데, 비즈니스 어플리케이션 시장에서 C언어를 주력으로 개발하는 프로젝트는 데스크탑에서 널리 쓰이는 자바 어플리케이션 찾기 보다 더 어렵습니다.

그리고 '객관적 사실로 판단해야 한다'고 하셨지만, 자바는 실제로 실무에서 가장 많이 쓰이는 언어라는 것도 '객관적 사실'입니다. (논란을 없애기 위해 '가장 많이 쓰이는 언어 중 하나'라고 표현하는 게 나을지도 모르겠습니다만..)

대부분의 데스크탑사용자들이 쓸만한 자바 어플리케이션을 구경도 못해봤다고 해서 자바가 널리 쓰인다는게 헛소문이 되는 건 아닙니다. 데스크탑 어플리케이션은 자바의 주요 시장이 아니라는 것이 그 이유니까요.

아무튼 아무리 자바나 C가 범용언어적 성격을 공유한다 해도 실제로 쓰이는 영역과 언어적 특성이 상당히 차이를 무시하고 한쪽 기준에서 비교를 할 수는 없다고 봅니다.

기업용 어플리케이션 시장에서 아직까지 파이선, 루비, 펄 등을 거의 찾아보기 힘들다쳐도 이들 언어가 다른 면에서 매우 훌륭한 언어라는 사실이 바뀌는 건 아닙니다. 단지 기업용 어플리케이션 시장이 이들 언어의 특화된 시장이 아니라는 것 뿐이죠.

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

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

select99의 이미지

님이 잘못알고 계신부분이 바로 이부분인것같군요..
"자바는 실제로 실무에서 가장 많이 쓰이는 언어라는 것도 '객관적 사실'입니다"
또한 "'C사'는 부품회사기 때문에.. " 이부분도요..

평가대상이나 평가기준을 어떻게 설정하느냐에따라 결과가 다르게나오죠..

그러나 아무리 훌륭하다 어떻다해도.. 결국엔 실제로 느끼는건..어렵고, 느리고,시스템리소스 많이 먹고..
유지보수비용도 적지 않게 든다는것..
또 여기 실제 일하는(둘다하는) 많은사람들이 그렇게 얘기합니다..
여기 진행되고있는 자바프로젝트가 수백억 이 투자됬습니다만.. 매우비관적입니다..이미 예상을훨씬벗어나버렸죠..
우리는 애초부터 눈에 보였고 당연한결과라고 봅니다.하지만 그들에게 그것이 안보인다는거죠..

notpig의 이미지

"자바는 실제로 실무에서 가장 많이 쓰이는 언어(중에 하나)라는 것도 '객관적 사실'입니다"

select99의 이미지

마치 북한이자신들이 최고라고 주장하고 그들이 그것을 객관적인 사실이라고 한다면 어찌 설득해야할까요?

notpig의 이미지

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

이것을 대신할만한 순위를 보여주시면 됩니다.

select99의 이미지

이싸이트의 조사를 보면..

C/C++ 은 자바보다높군요.. 여기조사에서는 나누에서 표기를 했습니다만..

그러니 무작정객관적사실이다 라는표현은 좀 무리가 있지 않나요?

일단 그자료를 신뢰하기 위해서는..

저것을조사한 방법이나 기준이 무엇인지 알고 그것지 정말 재대로 조사되었는지도 생각해봐야겠죠?

조사방법이나 기준이 무엇인지 말씀해주세요..

fender의 이미지

C와 C++을 합쳐서라도 '자바보다 많이 쓰인다'를 강조하고 싶으시다면 인정해드리겠습니다. 전 뭐 자바가 1등이고 2등이고 하는데 집착할 이유는 없습니다. 그런데 그게 최초의 제 글에 대한 반박이 되나요?

저는 처음부터 논란을 피하기 위해서 '실무에서 가장 널리 쓰이는 언어 중 하나'라고 했습니다만, 거기에 대해 제가 무언가 잘못 알고 있다고 하지 않으셨던가요?

또 TIOBE의 신뢰성을 부정하고 싶으시다면 각종 구직사이트의 자바 관련 프로젝트 광고들은 모두 자바의 마케팅을 위해 조작한 결과일까요? ㅎㅎ;

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

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

select99의 이미지

그럼 가장 많이 쓰이는 언어는 아니라는데 동의하신다는거죠?

저는 정확하게 짚고넘어가고 싶군요.. 그러니까 위싸이트통계가 맞다고 하더라도.
1등은 C/C++ 이고 2등은 자바다 라고 말할수 있다는거군요..

또.. 신뢰성을 부정부분에서도 그러면 무조건 믿어야하는건가요?

"조작의결과.." 아니라고 누가 장담할수 있나요? 조작까진 아니겠죠.. 하지만

누구를 대상으로 조사했으며 기준이 무엇이었냐에따라. 나오는 결과는 천지차이라는거죠.

예를들면 인터넷으로 대통령후보 투표했다하여 실제로 대통령당선될까요?

또한 구직싸이트에 출몰하는 사람들의 성향으로보아 일반적으로 인터넷프로젝트위주의 구직하는사람들이면요?

상당한 경력과 실력을 가진 프로그래머가 구직싸이트를 전전긍긍하며 다니는경우가 많을까요?

그러한것들은 설사 조작이 아니더라도 상당히 잘못되었을수 있다는겁니다.

fender의 이미지

C와 C++이 얼마나 친한지는 모르겠지만, 합쳐서 '1위다'라고 생각하셔도 좋습니다. 뭐 C#까지 합치셔도 뭐라고 안합니다. 그래봐야 실무에서 가장 널리 쓰이는 언어 중 하나라는 주장에 대한 반박이 아니니까요.

아무튼 자바 개발자는 실력이 없어서 직업하나 구하려면 근근히 구직광고 내고 고생하는데 C/C++은 배우기만 하면 어디선가 소리 소문없이 스카웃해가나 봅니다.

더 늦기전에 C/C++ 개발자로 전업해야 하지 않을까 고민을 해보겠습니다.

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

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

select99의 이미지

가장이라는말은 원래 1위라는뜻이 있어서요..님말은좀 오해의소지가 있어보이는군요.

반드시 그렇다는건 아니고.. 가정을좀해보겠습니다.

예를들어 C/C++ 은 웹이 아닌경우가 많다보니.. 단기 프로젝트가 아닌경우가 많고 그러다보면 한곳에 오래있게되어

아무래도 구직싸이트를 방문하는경우는 그만큼줄겠죠. 또한 그러다보면 인맥으로 엮여 이직하는경우가 종종생기고그만큼

구직싸이트갈일은 별로 없어질가능성이 커지는거죠..

fender의 이미지

그것도 인정해 드리죠. TIOBE 랭킹은 잘못된 결과이거나 아무튼 C하고 C++을 합치면 자바보다 몇 프로 많으니 1위이고, 구인 구직 사이트 등에는 자바관련 글이 더 많지만 아마도 보이지 않는 곳에서 암약하는 C/C++ 개발자가 훨씬 더 많을지 모르니 1위일지 모른다라고 하죠.

그런데 계속 말씀 드리지만 그게 과연 자바가 실무에서 가장 많이 쓰는... 아니 '가장'도 빼달라고 하셨으니 바꾸죠 - '자바는 실무에서 많이 쓰는 언어'라는 원래 주장에 대한 반박이 되나요? 아니면 C/C++뿐 아니라 파이선, 루비, 펄, 기타 등등등의 언어의 개발자도 보이진 않지만 자바보단 상대적으로 매우 많을테니 자바는 실무에서 별로 안쓰인다는 뜻인가요?

그리고, 이제까지 주장하신 내용으로 따지면 자바와 C/C++의 용도는 비슷하니 자바가 쓰일 일은 모두 C/C++로 대체하면 훨씬 빠르고 돈도 덜 들고 결과도 좋을텐데 왜 자바 구인 구직 글을 그렇게 많이 보이는 걸까요? 더구나 말씀대로라면 보이는 자바 개발자보다 안보이는 C/C++ 개발자가 훨씬 더 많을 수 도 있을테니 인력 수급도 문제 없을 텐데 말입니다.

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

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

select99의 이미지

자바가 실무에서 많이 쓰이지 않는다고 하진 않았습니다.
가장 많이 쓰인다는데 반박했을뿐이죠..

자바나 혹은 다른언어중 어떤것을 슬지는 단지 "대책없는 믿음" 으로 선택하는것이아니라.

합리적 평가기준을 마련하고 객관적으로 평가해서 선택해야겠죠..

fender의 이미지

본문에서 처음부터 제가 논란의 소지를 없애기 위해 '가장 많이 쓰이는 언어 중 하나'라는 표현을 썼고, select99님이 반박하신 후에도 다른 분이 그 부분을 지적하셨습니다. 그럼 이제까지 쓰신 글은 결국 select99님께서 제 글을 오독하셔서 허수아비 논증을 하신 것 밖에 되지 않는 게 아닌가요?

그리고 이 글타래에서 아무도 자바 언어를 '대책없이 믿으라'라고 한 적 없습니다. 반면 select99님은 분명 자바는 지적하신 '합리적 평가기준' 없이 매우 '주관적'으로 자바는 (경우와 무관하게) 느리고, 비용 많이 들고, 어렵고 무겁다고 주장하셨죠.

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

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

select99의 이미지

저도 주관적일수 있죠..
하지만 많은사람이 느리다 어렵다 느낀다면 문제가좀있죠..

creativeidler의 이미지

C와 C++은 같은 언어가 아닙니다. 대체 무슨 근거로 C/C++을 하나로 묶으시는 겁니까? 현재는 쓰이는 영역도 많이 다릅니다. C와 C++의 차이는 자바와 C++의 차이보다 적다고 할 수 없습니다.

select99의 이미지

관점에따라 묶어야된다는사람도 있겠고 묶지 않아야한다는사람도 있겠죠..

"C와 C++의 차이는 자바와 C++의 차이보다 적다고 할 수 없습니다." < 아니라고 봅니다.

죠커의 이미지

C와 C++을 묶어서 얘기한다면 C 마니아와 C++ 마니아 모두 분개할 겁니다. C와 C++는 다른 언어며 차이는 점차 늘어나 다음 표준에는 더 많아 질겁니다. int i[a]라는 간단한 문장이 C언어와 C++에서 동작하더라도 동작하는 "이유"는 전혀 다릅니다.

- 죠커's blog / HanIRC:#CN

fender의 이미지

오히려 전 자바에 대한 개인적 반감을 논리적인 토론에 조차 우격다짐으로 앞세우는 경우에 거의 종교적인 무언가를 느낍니다.

참고로 tiobe.com이나 jobs.com, jobkorea.co.kr 등은 모두 북한과는 관계 없습니다 ㅎㅎ;

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

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

fender의 이미지

당연히 망하는 자바 프로젝트도 있습니다만, 모든 프로젝트가 '자바 때문에' 필연적으로 망하는 것은아닙니다. 쓰기만 하면 망하는 언어를 실무에서 10년 넘게 쓰고있으며 대부분의 대형 SI의 주력 언어로 쓰인다는 건 있을 수 없는 일이니까요. IT업계에 불합리한 일은 널려있지만, 최소한 개발자들이나 관리자들 모두가 바보는 아닙니다.

자바가 좋건 나쁘건 국내외 개발자 구인구직 정보, 프로젝트 수, 관련 제품의 시장규모, 온라인 리소스와 서적의 비중, 심지어 TIOBE 랭킹 등 모든 부분에서 자바는 상당히 오랜기간동안 최소한 실무에서 가장 널리 쓰이는 언어중 하나이고 심지어 '최고로 많이 쓰이는 언어다'까지도 주장할 수 있는 근거도 많습니다.

그건 '내가 어느 프로젝트를 봤는데 망했다더라'라던가 '난 자바가 어렵더라'는 이야기와는 완전히 별개의 문제입니다.

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

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

select99의 이미지

님이 말씀하셨듯이.. 최소한 개발자나 관리자들 모두가 바보는 아니죠..
그렇기때문에.. 보통사람들이 그렇게 느끼는 바도 중요한겁니다..

뭐 무슨어디에 이렇게 조사됬더라... 이런내용에대해 따져보고싶지만.. 너무 소모적일것같군요..

fender의 이미지

소모적인 걸 떠나서 의미가 없는 이야기일 것 같은데요...

저도 이 분야에서 실무를 10년 넘게 하고 있고 작은 프로젝트부터 대기업 프로젝트까지 다양한 프로젝트를 자바로 진행했고, 또 주변에서 수많은 프로젝트가 진행되는 걸 보았고, 온오프라인 상에서 자바로 먹고 사는 꽤 많은 사람을 안다고 생각합니다.

그리고 제 개인적 경험을 떠나서도 위에서 언급한 소스나 관심있게 보는 커뮤니티와 사이트 등을 통해서도 자바가 얼마나 많이 쓰이는 지에 대해선 '일반인의 직감' 같은 거 보다는 좀 더 정확하게 알고 있다고 봅니다.

그런데 덮어 놓고 자바는 무조건 느리고, 심지어 실무에 쓰면 망한다거나 실무에서 널리 쓰이지 않는다는 식의 주장을 들으면 그냥 황당할 뿐입니다.

어떤 실제적 근거를 제시하거나 하다 못해 URL이라도 제시한다면 '그런가?' 하고 궁금해서라도 한 번 살펴나 보겠지만, 그냥 '보통사람은 그렇게 느낀다'라면 글쎄요... ㅎㅎ;

심지어 북한 이야기까지 나왔습니다만; 뭐 보통 북한 사람이 우리나라에 대해 어떻게 생각하는지 우리나라에서 태어나서 이제까지 잘먹고 잘살고 있는 제가 왜 신경을써야 할까요?

그런 건 통일부 관계자나 신경 쓸 일이고, 이 경우엔 썬의 마케팅 직원이나 도대체 어쩌다 자바에 대한 일반, 혹은 리눅스 진영의 인식이 이지경이 되었는지 심각하게 고민해볼 문제가 아닌가 싶습니다.

저로서는 그런 황당한 이야기가 나오는게 재밌기도하고 어이없기도 하고 도대체 왜 그런 생각을 하는가 가끔은 따져보고 싶을 뿐이죠. 끝까지 책임지고 그런 사람들의 편견을 타파할 의무 따위는 없습니다.

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

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

select99의 이미지

논쟁이 두갈래에서 진행되는군요..

님이 무슨일을 얼마나 했건 그것은 어떤 근거가 되지못합니다.

일반인들의 직감보다 님이 좀더 정확하게 알고 있다는것또한 님만의 생각이지 어떤 근거가 있는게 아닙니다.
물론 반대도 마찬가지겠죠..
하지만 한두명도 아니고 다수가 느낀다면 그것은 "어렵다"등의 어떤 평가 에 근거가될수 있는것이죠.

토론을하다보면 예를들일이생기고 그러다보면 북한이 아니라 멍게 해삼도 나올수 있는것입니다.
말의요지는 단지 예를든것이고 의미를전달하자하는것이지 북한문제를 고민하자는게 아닌거죠..님이 지금말씀하신북한에
관한내용은 일종의 딴지로 생각되는군요..

토론을하고 싶다면 냉정히 토론에만 집중하면되지.. 괜한딴지는 토론을 하지말자라는 의도로밖에 보이지 않습니다.

님은 근거를 URL 로 근거를 보여달라시지만. 그런것이 그다지 신뢰성 있어보이지 않아서요..
그렇다면 다른근거를 하나 제시해보죠.. 님이사용하는 컴퓨터들에 어떤언어로된것이 많은지 한번보시죠..
또한 님주변사람들컴도 보시구요..또한 각종 TV, 리모콘, 오디오,자동차,비행기, mp3, 등등 한번살펴보시죠..
각종영상칩의 프로그래밍은 무엇으로 되었는지도 한번보시죠..

인터넷 홈페이지가 전부는 아닙니다.특히나 우리나라그 그쪽에만 치중하고 있는것도 그다지유쾌하지 않지만말입니다.

fender의 이미지

냉철한 토론 저도 좋아합니다. 괜한 딴지도 싫어하죠.

그래서 자바는 '종교적'이고 자바개발자는 '공격적'이라고 몰아 붙이셔도, 또 '자바가 실무에서 가장 많이 쓰이는 언어 중 하나다'라는 말에 대뜸 '북한사람 같다'라고 커멘트 다셔도 일일이 발끈 하지 않고 논리와 근거로 반박해 드리는 거겠죠 ㅎㅎ

아무튼 충고 하신 대로, 자바가 정말 실무에서 많이 안쓰는 언어인지, 집에 있는 냉장고와 리모컨을 들여다 보면서 연구해봐야 겠습니다.

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

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

select99의 이미지

제가 "북한사람같다" 라고 한적은 없습니다만.. 님이 느끼시기에 비유가기분나빴다면 죄송합니다.
저는 설명할수 있는방법을알고 싶었죠..

fender의 이미지

이쯤에서 select99님의 논점을 환기시켜 드리겠습니다.

(1) 자바는 종교와 같고('개신교'로 추정됩니다) 자바를 비판하면 자바 개발자는 매우 공격적이 된다.
(2) C/C++이 항상 자바보다 적은 비용으로 더 성능 좋은 결과를 낸다.
(3) 자바는 어렵고, 느리고, 무겁고 개발 비용이 많이 든다.
(4) 자바가 실무에서 가장 많이 쓰이는 언어중 하나라는 주장은 거짓이다.
(5) (4)에 대한 근거로 자바 개발자의 수년 간 프로젝트 경험은 무의미하다. 하지만 (3)에 대한 근거로 본인이 전해 들은 한 건의 프로젝트 사례는 유효하다.
(6) 냉장고, 리모콘 등 수많은 가전제품을 만드는데 자바를 쓰지 않기 때문에 (4)는 사실이 아니다.
(7) 구인/구직 사이트에 자바 관련글이 많은 것은 아마도 실력이나 경력이 부족해서 그런데 광고를 냈을 것이다.
(8) (1)과 같은 주장은 '딴지'가 아니지만 부적절한 비유를 지적하는 것은 '딴지'에 해당한다.

뭔가 느껴지시는 게 없나요? ㅎㅎ;

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

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

select99의 이미지

역시 말은 "아"다르고 "어"다르다는걸 느꼈습니다.

저도 님의 논점 몇가지 상기시켜드리면.
1. 자바는고차원적 언어고 다른언어는 부품에 불과하다.
2. 자바는 최고로 많이 쓰이고
3. 다른사람들은 우격다짐격이다..
4. 자바하는사람들이 바보가 아니라서 자바한다. 그러니 자바를 비판하는사람은 말안해도 무엇이 되는줄알것이다.
5. 특정싸이트를 이용하는사람들이 특정통계조사할만한 평균적이고 일반적이라는 가정이 없음에도
그것을 지적한말을 "그렇다면 우리는 실력이 없어서 구직싸이트 이용하는사람들이냐" 라는식으로 삐딱하게 받아들이겠다.
6. 자바는 비용이적게들고, 쉽고, 빠르다.
7. C/C++ 보다도 더빠르기도 하다.(마치 대부분 더빠르다고 말하고 싶은..)
8. 인터넷관련이 아닌개발은 별로 보고싶지 않다.

뭔가 느껴지시는게 없나요?

fender의 이미지

제가 정리한 select99님의 논점이 윗 글처럼 명백한 왜곡은 아니라고 보는데요. 그렇게 생각하지 않으신다면 저처럼 하나하나 인용해서 한 번 반박해 보시죠 ㅎㅎ;

1. 자바는고차원적 언어고 다른언어는 부품에 불과하다.
-> 그런말 한 적 없습니다만... 설마 언어가 '고차원적', 저차원적'이다라는 용어를 수준이 높고 낮다는 걸로 착각하고 계신 건 이니겠죠?

2. 자바는 최고로 많이 쓰인다.
-> 정확하게 실무에서 가장 많이 쓰이는 언어일 수도 있고, 좀 더 정확히 말하면 가장 많이 쓰이는 언어 중 하나라고 했습니다. 그나마 이게 제일 정확한 인용이군요.

3. 다른사람들은 우격다짐격이다.
-> 불특정 다수가 아닌 select99님의 특정 주장에만 해당하는 말입니다.

4. 그러니 자바를 비판하는사람은 말안해도 무엇이 되는줄알것이다.
-> 해석이 안되서 패스... ㅎㅎ

5. 특정싸이트를 이용하는사람들이 특정통계조사할만한 평균적이고 일반적이라는 가정이 없음에도 그것을 지적한말을 "그렇다면 우리는 실력이 없어서 구직싸이트 이용하는사람들이냐" 라는식으로 삐딱하게 받아들이겠다
-> 보통 구인 구직 사이트에 자바관련 글이 많다는 지적에 대해 '실력있는 C/C++개발자들은 근근이 그런데 광고 안올릴 수 있다'라는데 그럼 뭐라고 받아 들여야 되나요?

6. 자바는 비용이적게들고, 쉽고, 빠르다.
-> 그런 말 한 적 없습니다만... 저는 select99님과 달리 특정 언어가 용도와 환경에 무관하게 무조건 비용이 어떻고 성능이 어떻고 하는 판단을 하지 않습니다.

7. C/C++ 보다도 더빠르기도 하다.(마치 대부분 더빠르다고 말하고 싶은..)
-> 제가 아닌 다른 분의 발언인데 흥분하셨는지 착각하셨네요. 그런데 최소한 '빠르기도 하다'는 건 사실입니다.

8. 인터넷관련이 아닌개발은 별로 보고싶지 않다
-> 그런 말 한 적 없는대요? 한 번 찾아봐 주시겠습니까? 참고로 모르실까봐 말씀드리자만... 자바 개발자들 SI하는게 모두 웹기반도 아니지만, 웹기반이라도 모두 다 밖으로 보이는 인터넷 홈페이지 같은 거 만드는 게 아닙니다. 기업 내부 시스템 많이들 하죠.

앞서도 말씀드렸지만, 제가 정리한 논점도 왜곡된게 있다라고 생각하시면 한 번 인용해서 반박해 보시기 바랍니다. 전 나름대로 정확하게 select99님의 발언을 정리했다고 생각하거든요. ㅎㅎ;

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

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

select99의 이미지

(1) "자바는 종교와 같고('개신교'로 추정됩니다)"
==> 같다고 하지 않았습니다. 같은느낌을 받았다고 했죠. 도둑놈이다 라는말과 도둑이미지다 라는말은
완전히 다른말이죠..

(2) C/C++이 항상 자바보다 적은 비용으로 더 성능 좋은 결과를 낸다.
==> 전 그런말을한적 없는거 같은데 어디부분에 그런말이 있던가요?

(3) 자바는 어렵고, 느리고, 무겁고 개발 비용이 많이 든다.
==> 제가받은느낌이죠.. 물론 이글타래의 글들로보아 저만느낀게 아닌것같은데요.

(4) 자바가 실무에서 가장 많이 쓰이는 언어중 하나라는 주장은 거짓이다.
==> 물론 그렇게 생각은 하고 있지만 그렇게 말하지 않았습니다.
믿을수없다라고 한것이지 거짓이라고 한적은 없습니다.

(5) (4)에 대한 근거로 자바 개발자의 수년 간 프로젝트 경험은 무의미하다. 하지만 (3)에 대한 근거로 본인이 전해 들은 한 건의 프로젝트 사례는 유효하다.
==> 님경험은 무의미하다고 한적 없으며 그것이 자바가 쉽다는 개관적 근거가 되지 못한다고 했죠.
제가 전해들은? 이야기도 아니며 그것이 유효하다고 한적도 없습니다. (전해듣다라는말은 제3자의말을 다른사람으로부터 전해서 듣는다는뜻이죠)

(6) 냉장고, 리모콘 등 수많은 가전제품을 만드는데 자바를 쓰지 않기 때문에 (4)는 사실이 아니다.
==> 이역시 "특정한곳에 자바를쓰지 않았기때문에 사실이 아니다" 라고한적없습니다.
예를들어 이러한곳도 함께 고려되어야한다고 한것이지 특정한곳에 쓰지 않았다고 부정한것은 아니죠..
고려대상에 A,B,C..도 있다 라고한것이지 A 에 없으니 B는 아니다 라는 말이 어찌 같을수가 있나요?
"비행기이면 날수 있다." 와 "날수 있으면 비행기다" 라는말을 구분할줄 아시죠?
이말은 위말보다 더구분하기 어려운말인데요..비슷해보이지만 크게다르죠.
님은 전반적으로 "비행기이면 날수 있다" 라는말을 "날수 있으면 다 비행기 라는말이냐" 라는식으로 반박하셨습니다.

(7) 구인/구직 사이트에 자바 관련글이 많은 것은 아마도 실력이나 경력이 부족해서 그런데 광고를 냈을 것이다.
==> 이역시 그런말한적없습니다.
(8) (1)과 같은 주장은 '딴지'가 아니지만 부적절한 비유를 지적하는 것은 '딴지'에 해당한다.
==> 저는 비유를하여 설명의방법을듣고 싶었습니다만
"북한에대해 잘먹고잘사는내가 왜신경쓰나" 식의 말을하셖군요..
제가북한 신경써달라는말이아닌데도 불구하고 말이죠.. 저는 님말은 좀 벗어났다고 판단되는데요.

전반적으로 (6) 의 부분에 썼듯이.. 비슷한말처럼보이지만 의미가 다른말을 님은 쓰셨습니다.

반박해달라고 해서 반박은 해드렸습니다. 하지만 정말몰라서 반박해달라고 하셨나요?
정말 님이 이글이 제대로 표현했다고 쓰셨다면 난감한데요..

오늘 여기까지 하겠습니다. 늦었네요.. 이럴려구 시작한것도 아니고...
님이 또무슨말씀하시겠지만... 댓구언제할지 모르겠습니다..
날마다 이러긴 시간낭비같아서요..

fender의 이미지

"자바는 종교와 같고('개신교'로 추정됩니다)"
==> 같다고 하지 않았습니다. 같은느낌을 받았다고 했죠. 도둑놈이다 라는말과 도둑이미지다 라는말은 완전히 다른말이죠..

:::: 저는 select99님이 억지를 쓰고 있다는 *느낌*을 받았습니다.

자바가 실무에서 가장 많이 쓰이는 언어중 하나라는 주장은 거짓이다.
==> 물론 그렇게 생각은 하고 있지만 그렇게 말하지 않았습니다. 믿을수없다라고 한것이지 거짓이라고 한적은 없습니다.

:::: 저는 select99님이 '반박'하신 내용이 단순 말꼬리 잡기라고 생각하고 믿고 있습니다만 물론 그렇게 말하진 않겠습니다. ㅎㅎ;

님경험은 무의미하다고 한적 없으며 그것이 자바가 쉽다는 개관적 근거가 되지 못한다고 했죠. 제가 전해들은? 이야기도 아니며 그것이 유효하다고 한적도 없습니다.

:::: selec99님은 자바가 실무에서 잘 쓰이지 않는다고 말씀...이 아니라 믿으시기에 제가 실무에서 제가 10년 넘게 프로젝트를 하고 보고 들은 내용을 말씀드렸더니 "님이 무슨일을 얼마나 했건 그것은 어떤 근거가 되지못합니다"라고 안하셨습니까? 그러면서 본인이 경험한 단 1사례 - "여기 진행되고있는 자바프로젝트가 수백억 이 투자됬습니다만.. 매우비관적입니다..이미 예상을훨씬벗어나버렸죠" 라는 말로 자바는 무겁고 유지보수 비용 많이 들고 느리다는 주장의 근거를 삼지 않으셨나요? 그런 말 안하셨다고 하실까봐 수정없이 인용했습니다만...

:::: 구인 구직 사이트에 자바 관련 글은 많지만 C/C++관련 글이 적은 이유는 실력있는 C/C++ 개발자는 근근히 그런 데 구인글 안올려도 취직될 수 있다는 말이, 실력이 부족하니 근근히 그런 곳에 구인글이나 올린다와 뭐가 다릅니까? 물론 글자수 빼고 말이죠...

::: 자바가 실무에서 가장 많이 쓰는 언어중 하나라니 대뜸 '마치 북한이 자기네들 최고라고 우기는 것' 이라기에 그건 토론이 아니라 딴지 아니냐 했더니 그건 딴지가 아니라 '비유'라는 건가요? ㅎㅎ;

*비유*하자면 요새 유행하는 '오해다'와 비슷하네요...

아무튼 재밌는 토론(?)이라 저도 좀 일일이 반박글 달고 했었는데, 더 나가면 난장판 되겠습니다. 저도 이쯤에서 줄이죠 ㅎㅎ

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

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

creativeidler의 이미지

결국 느린 JVM에(2000년도 당시에)

2009년 현재, Java는 일반적인 케이스에서 C++보다 빠른 성능을 보입니다. 물론 튜닝에 많은 시간을 투자할수록 다시 C++이 앞서지만, 성능 튜닝 없이 그냥 짜면 Java가 더 빠릅니다. 대신 메모리를 2배에서 10배까지 더 많이 먹죠. 저 위에 진흙탕 싸움에서 Java GUI가 느리다고 주장하긴 했으나, 서버 사이드에서는 성능을 고려한다면 최고의 선택일수도 있습니다.

대책없는 믿음에(JVM에 대한 신뢰)

Java는 메모리 릭이 가장 적게 발생하는 언어입니다. VM 류 중에서도 가장 가비지 컬렉션의 신뢰도가 높습니다. 즉, 대책 있는 믿음이라는 것이지요. 플랫폼 호환성도 높습니다. 성능 면에서도 Java가 점점 오라클과 비슷해져가고 있습니다. 요컨대, "니들은 대충 짜라, 옵티마이저가 성능 내주겠다"라는 전략이죠. 덕분에 이제 프로그래머들은 기술적인 차원에 신경을 덜 쓰고 남는 에너지를 고객에게 쓸 수 있게 되었죠.

이해가 안가는 구조(memory map, 동작 방식, 지금은 이해가 가지만...)

맞는 얘기라고 봅니다만, 이건 어려운 이유가 아니라, 반대로 쉬운 이유라고 봅니다. 이해가 안 가는 구조라기보다 이해할 필요가 없는 구조라고 보는 게 맞겠지요. 자바로 코딩할 땐 메모리에 뭐가 어떻게 들어갈지 별로 고민할 필요 없으니까요.

API의 강요

C에서 printf를 써야 하니까 C도 API를 강요하는 건가요?

전, 자바가 어려운 언어라고 봅니다. 자바가 처음 나올 때는 쉬운 편에 속하는 언어였지만 지금은 아니죠. 하지만, 위의 이유들은 동의하기 어렵습니다.

p.s. 이번 쓰레드에서는 fender님과 한 편일런지도? --;

anfl의 이미지


위 이유들에 대해 동의 못하신다 하시는 것은 관점의 차이인것 같습니다.
제 관점에서만 주장한다면 반론하신것들에 대해 반박할수도 있겠지만
어떠한 관점에서 쓰신글이라는걸 이해하기에 하지 않겠습니다.

서로 관점은 다르지만 JAVA가 어렵다것에는 일치점이 있네요.

JAVA에 잘 아시는 분이신것 같은데
잘 아시는 분도 이렇게 어려운 언어라 이야기 하시는데
왜 사람들은 JAVA가 쉽다라고 이야기 하는지 이해를 못하겠습니다.

처음 나왔을때 쉬웠다고 이야기 하시는데 저에게 JAVA는 processor에서 바로 실행되는
native language에 비해 처음부터 이해가 어려운 언어였습니다.

혹시 그 이해란 JAVA의 구조와 원리 즉, javac의 IR(이라는 표현이 맞을지 모르겠네요.
최종 JVM 아키텍쳐 코드니깐), JVM architecture, JVM 동작 방식을 떠난
단순히 어떠한 일을 수행하는데 있어 메모리에 대한 이해없이 필요한 API의 조합으로
원하는 일을 수행할수 있다는 것이 초반에 JAVA가 쉬웠다는 것인지요?


notpig의 이미지

전 자바가 쉽다고 생각하는 사람으로서 한가지 예제를 생각해보겠습니다.

int a[10];
a[10]=10;

이런 코드가 있을때
이 코드가 잘못된 코드란건 동의하시죠?

C 하고 자바하고 실행하면 어떻게 동작할까요??
최소한 자바가 오류 찾기 좀더 쉽다고 생각합니다.

lifthrasiir의 이미지

자바는 해야 할 일을 제대로/정확히 수행하는 것 뿐이고 그게 쉽고 어렵다의 기준이 되기는 힘듭니다. 물론 그것도 제대로(여기에 대해서는 반론이 있을 수 있지만, 일단 일반 애플리케이션에서는 이런 행동이 "제대로" 된 건 아니기에) 안 해 주는 C는 어려울 수 밖에 없습니다만.

creativeidler의 이미지

어렵다 쉽다를 절대적인 기준이 아니라 상대적인 기준으로 볼 때 그렇다는 뜻입니다. 자바가 처음 나올 때는 C/C++, 파스칼, 스몰토크, Objective C, 포트란, 코볼 정도의 언어가 시장에서 주류(?)를 형성하고 있었습니다. 대체로 자바보다 어려운 언어들이지요. 님과 달리, 전 자바가 C/C++에 비하면 여전히 쉬운 언어라고 봅니다.

제가 어렵다는 이야기를 할 때 비교군은 파이썬, 루비, 자바스크립트 등의 언어입니다. 이런 언어에 비하면 자바가 확실히 어렵습니다. 자바가 나올 때에 비해 이런 쉬운 언어들이 많아졌으니 이제 자바는 상대적으로 어려운 언어가 된 것이지요.

물론, 자바 5부터 generics 등의 어려운 문법이 추가된 것도 "어려운 자바"에 한 몫을 하고 있습니다.

molla의 이미지

미리 말씀드리면, 저는 C만 좀 알고, C++이나 JAVA쪽은 잘 모릅니다.
요즘엔 Java 쪽 사람들의 이야기를 들어보면, creativeidler 님의 말씀처럼 C++과 비슷한 (더 빠른?) 성능을 보인다 라고 하는 말을 합니다.
하지만, 그냥 제가 알고 있는 한에서만 생각해 보면 Java 는 byte code를 JVM 에서 일종의 interpreting(native CPU 입장에서만 본다면요) 을 한다고 할 수 있는데, 이런 구조가 어떻게 compile 방식보다 빠르다는지 쉽게 이해가 안 갑니다. (거기에 GC가 돌아가면 최악의 경우 all stop하는 경우도 있다고 알고 있는데요...)
물론 요즘엔 hotspot 이니 하면서 runtime 에 최적화를 하여, 경우에 따라서는 compile 방식보다 빨라질 수 있다는 것도 알고는 있습니다만, 어디까지나 특수한 경우가 아닌가 라는 생각을 하고 있습니다.

결국 제가 궁금한 것은 일반적인 경우에 C++보다 Java 가 더 빠르다고 하셨는데, 그 일반적인 경우라는 것이 대충 어떤 상황인지 입니다.
뭐 일반적인 경우라는게 일반적인 경우지 뭐냐? 라고 하신다면 뭐 저도 드릴 말씀은 없지만, 그래도 좀 더 자세한 전제가 궁금합니다.

1. 비슷한 실력을 가진 사람들이 비슷한 시간을 들여 동일한 일을 하는 프로그램을 작성했을 때 C++보다 Java 가 더 빠르다 (= C++ 이 비슷한 또는 더 효율이 좋은 프로그램을 작성하기 위해서는 시간이 더 필요하다?)
2. 프로그램을 작성하는 시간과 상관 없이 비슷한 실력을 가진 사람들이 동일한 일을 하는 프로그램을 작성하면 C++ 보다 Java 가 더 빠르다

중 어느쪽인가요?

그리고 또 다른 쪽으로는, 일반적인 경우라는 것이 주로 어느 쪽인지도 궁금합니다.
이는 몇년 전에 Java쪽을 하던 사람에게 들었던 이야기가 생각나서 인데요, 정확히 어느쪽이었는지 잘 기억은 안 납니다만, Disk I/O 인지, Network I/O 인지 화면 I/O 인지 어느쪽인가가 JVM의 설계(?)상 너무 많은 layer 를 거칠 수 밖에 없는 구조라 도저히 native 쪽의 속도를 따라갈 수가 없다는 이야기를 들었던 기억이 있습니다. 물론 몇년 전 이야기 인지라 지금은 해당 문제가 해결되었을 수도 있겠지만요.

뭐 정말로 제가 잘 몰라서, 이해가 안 가서 물어보고 싶어서 질문 드려 보는 것입니다.

죠커의 이미지

대부분의 프로그램에서 분기와 반복이 있습니다. 이런 부분에 대해선 runtime 최적화를 할 수 있습니다. 일반적인 프로그램에서 분기와 반복은 여러 조건들이 동일한 비중을 가지고 작성되게 됩니다. 컴파일 타임에서 최적화를 할 수 없는 대상이기 때문입니다. 하지만 반복적으로 VM에서 실행되는 프로그램의 경우에는 지속적으로 어떤 경로가 최적의 경로인지 데이터를 쌓을 수 있습니다. 그렇기 때문에 "반복적으로 오래동안 런타임 실행된다면" 분기나 반복문이 더 효과적으로 최적화 됩니다.

물론 C/C++로 작성하면서 코드 레벨에서 런타임 최적화를 할 수 있도록 하는 프로그래머도 있습니다. 그런 지엽적인 노력을 하는 것 보다 도구를 바꾸는 것이 더 낫겠지요.

- 죠커's blog / HanIRC:#CN

molla의 이미지

뭐 분명 계속 동작하면서 점차 최적화를 진행해 나간다는 방식보다는 많이 뒤떨어졌다고 할 순 있겠지만, C나 C++ 에서도 profiling 이란 것이 있습니다.
compile 할 때 특정 옵션을 사용하여 (compiler 마다 다르고 지원하지 않는 것도 있습니다) 만든 바이너리를 사용하면 사용 패턴에 대해 로깅을 남깁니다. 그런 뒤 다음에 다시 컴파일할 때 해당 로그를 사용하면 해당 패턴에 대해 최적화를 해서 바이너리를 만들어 줍니다.
굳이 일일이 코드를 보면서 최적화를 해 준다거나 까지 할 필요는 없지요.

뭐 그런 걸 떠나서, 기본적으로 반복의 경우는 거의 최적화가 되어 있습니다. 오죽하면 CPU쪽 하는 사람들은 CPU의 분기 예측 능력이 99.x% 이상이라고 하겠습니까?

그리고 말씀하신 것처럼 저 경우도 "반복적으로 오래동안 런타임 실행된다" 는 전제가 붙어 있는 것입니다. 일반적인 프로그램이 모두 저렇다고 보긴 힘들 것 같습니다.

죠커의 이미지

PGO(profile-guided optimization)를 말씀하시는 거군요. 런타임 로그를 통해 추가적인 최적화를 할 수 있다는 점에서 이점은 있다고 생각합니다. 수동으로 코드를 최적화할 필요가 줄어들었다는 것에 대해서는 동의합니다.

하지만 기본적으로 CPU에서 반복이 최적화되었다는 것은 사실이 아닙니다. 예와 아니오의 문제는 예측이 가능합니다만 여러가지 선택 중 하나를 택하는 것에 있어서는 많은 부분에서 실패합니다. CPU가 이런 분기에 대해서도 최적화를 하기 위해 CPU의 branch target buffer를 이용합니다만 완전한 해결책은 아닙니다. 특히 가상함수의 호출에서 이런 문제가 더 커집니다.

PGO가 이런 문제들을 일부 해결할 수 있습니다. 여러 선택지 중의 하나를 선택하는 문제를 예/아니오 문제로 바꾸어서 정복할 수 있게 도와줍니다. 하지만 현재 상황에 맞춘 부분적인 최적화이기 때문에 상황에 따른 추가적인 최적화를 놓치게 됩니다. PGO된 코드가 false sharing 등이 발생하는 경우가 있는데 이런 문제는 dynamic optimization이 아니면 풀기 어렵습니다.

반복적으로 런타임이 실행되는 프로그램이 실행될 경우 자바로 작성된 프로그램이 C/C++보다 우수한 경우가 있는데 일반적으로 이런 경우는 "서버에서 실행되는 프로그램"일 겁니다. 일반적인 프로그램이 모두 이런 경우는 아니라서 데스크탑 프로그램에서는 이점이 적겠지만 서버용 프로그램에선 이점이 있다고 생각합니다.

- 죠커's blog / HanIRC:#CN

molla의 이미지

CPU 쪽에서 반복에 최적화 되었다는 것은 죠커님의 말씀처럼 runtime 의 상황에 맞게 최적화가 되었다는 것은 아니지요. 그 전에 말씀하신 분기와 반복이 있다고 하신 데에서의 반복쪽에 최적화가 되었다는 것이었습니다.
뭐 어찌 되었건, 한계가 있다는 데에는 저도 동의합니다. (가상함수 쪽에서 문제가 더 커진다는 것은 제가 OO 쪽을 잘 모르는 관계로... 여튼 그 문제가 좀 더 심각해 진다 정도로 이해하겠습니다. ^^a)

여튼 runtime 에 최적화를 하는 것이, 해당 바이너리가 계속 메모리에 남아 계속해서 불리는 상황에서라면 최종적으로는 더욱 뛰어난 최적화가 된다는 것에는 동의합니다. 하지만, 저는 헝그리한 상황만 봐서 그런지 과연 그런 경우가 얼마나 될 것인가 싶은 생각이 듭니다.

즉 C 에서는 코드 부분은 데이터보다 우선순위(?) 가 낮아 메모리가 부족할 땐 언제든지 메모리에서 쫒겨날 수 있는 그런 상태입니다. 그런데 Java 쪽에서는 저렇게 하기 위해서는 코드 부분이 항상 메모리에 남아 있어야만, 그것도 최적화를 위해서는 과거 패턴에 관한 자료도 어느정도 될 텐데 그런 것들을 모두 들고 있어야만 할 듯 합니다. 덩치가 크고 복잡한 프로그램이라면, 과연 그런 것들을 항상 메모리에 들고 있어야 할까 라는 생각이 듭니다. (뭐 제가 최근 작업한 내용들이 매우 큰 자료들을 다루기 때문에 다른 메모리를 아낄수록 성능이 좋아지는 쪽의 작업을 해서 저런 생각이 더 강하게 드는 것일수도 있겠습니다.)

뭐 어찌되었건 서버처럼 계속해서 메모리에 올라온 상태로 반복 실행되는 경우라면 Java 가 C 나 C++ 보다 빠를 수 있다는 것은 이해할 수 있겠습니다.

(처음 이야기를 꺼냈던 것은 creativeidler 님이 일반적인 상황에서 Java 가 C++ 보다 빠르다고 하셔서 어떻게 그럴수 있을까 였는데... 일반적이진 않더라도 특정 분야 쪽에서는 Java 가 더욱 효율적일수 있다는 것은 확실히 알 것 같습니다. : )

select99의 이미지

runtime 최적화가 C가 안될이유가없죠..
마치 자바만의 전유물인것처럼 생각하시는데.. C로 그렇게 안된다구요?..
하다못해 C로 VM 자체를 만듭니다...정말안될까요?

오히려 C가 더최적화가되겠죠.. 자바는 모두 가지고 선택해야할문제가 있는반면에 C는 해당 프로그램에.. 필요한
runtime 최적화 모듈만을 포함할수있겠죠?
물론 VM 처럼 실행시 최적화가 내장된 프로그램이죠..거기에 컴파일단계의 최적화까지도요..비교가안되겠죠?

이렇게 이야기하면 또 "자바는기본적으로 내장인데. C는 구현하기 힘들다" 이런사람있습니다.
지금구현예기하는건 아니죠? 되냐 안되냐를 이야기 했으며.

구현부분에서도 이유가 있습니다. C는 그게 필요없기때문에 안쓴다는겁니다.
성능이 그다지 나지 않기때문이죠..만일 그것이 정말 성능에 큰효과가 있었다면..
C자체는 이미 lib누군가가만듭니다. 이미 누군가가 lib 만들어놨을 가능성도 매우큽니다...
최소한 누군가는 VM에 내장된 최적화 모듈을 만들었을것이고... 그모듈만든사람은 바로 그 lib를가지고 있겠죠?

또한 마치 런타임시 실행모듈최적화하면 +효과가 있을것이라 예측하는데.. -효과에대해서도 고려하셔야합니다.
어떤 부대원들이 목적지까지 가는데.. 가는교통수단을 미리 여러번의경험에의해 짜여진순서에의해 가는것과.
일단 출발한후에.. 나름데로 가장적합한 선택을 해가면서 목적지에 도착한다고 생각해봅시다.
가는중간에.. 어떤것이 좋은지 판단과 회의를통해 결정을해야합니다. 이시간과 비용은 무시하나요?

실제로 실행시 최적화가이루어지기위해선 그최적화를선택하기위한 비용이듭니다.

뿐만아니라.. 실제 자바진영에서주장하는 그런코드들이 프로그램에서 거의 눈씻고찾아봐도 나오기힘들코드입니다..
또한 그렇게 했다해도 그런 아주특수한코드조차도 C보다 빠른경우가 거의 없다는겁니다.
(자바측에서 내세운코드들이 실제론 최신자바로수행하는반면 C컴파일러는 오래되거나 최적화옵션을안주고 컴파일하거나하는등의)
그런데도불구하고 그런주장을내세워 자바가 빠르다 주장하는건 너무억지라고봅니다.

또한 자바가 자원을 많이 먹고도 자원은 장비로떼우면된다식의 주장을하시는분도 있지만.그것도 억지입니다.
메모리 두배먹는거나 CPU 두개먹는거나 뭐가다른가요?

BSK의 이미지

위에 분이 얘기했듯이 웹단 비즈니스단에는 자바가 대세고 시스템단에는 C, C++이 대세죠

SI 프로그래머로써 경제적인 관점에서 얘기하면 :)

C, JAVA 둘다 어느정도 수준까지 알면 '배고프지는 않다' 입니다.

한가지 언어에만 목메는 것보다 다른 언어에도 관심을 가지면 좋을듯 하네요. ( 저도 그러려고 노력중임 ㅋ )

기술적인 관점은 위에 분들이 얘기를 잘 해 주셔서 :)

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

gurugio의 이미지


자바/C# 정말 좋지요.
저는 겨우 간만 본 수준이지만 그래도 그 편리함이나
효율적인 개발하며 감탄이 절로 나왔었습니다.

도스 시절에 첨 Windows 3.1을 봤을 때 신기했던
그런 기분이 살짝 들었었습니다.

엄청난 내부 디자인과 철학이 있을텐데 제가 다 소화를 못해서
못써먹고 있지만 만든 사람도 정말 대단한것 같습니다.
소프트웨어의 오의? 극의? 에 가깝지 않을까 생각됩니다.

아참 자바가 좋다 나쁘다에 대한 글타래가 아닌데 왜 헛소리를...

자바는 저한테는 무지 어렵습니다.
ASP, SQL 배울 때의 막막하고 깜깜했던 느낌이 자바에서도 느껴졌었습니다.
그게 제가 쌓아온 테크트리하고도 상관이 있고
제가 일하는 분야와의 괴리감도 작용할 것 같습니다.
이 바닥에 쉬운게 없지요.
정말 필요해서 절실히 배운 사람들에게는 더 쉽겠고
저처럼 한번 간이나 본 사람에게는 어렵겠지요 뭐...

----
섬기며 사랑하면 더 행복해집니다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr

yielding의 이미지

제가 아는 대학원 DB 선배가 UniSQL을 커스터마이징해서 밥벌이를 하는데(요즘도 그걸하는지 몰겠습니다만..) 그 선배말을 빌면 UniSQL 코드나 기타, DBMS source, 논문 등을 보면 인간이 생각할 수 있는 모든 꼼수가 다 들어가 있다고 하더군요. 오라클 쓰면서 SQL이 정상적으로 동작하지 않으면 어떻하지? 이렇게 생각하지 않지요 보통..
저도 JVM 프로젝트에 있으면서 GC 관련 논문을 survey할 기회가 있었는데요.. GC만 해도 train-algorithm이 나오기 까지 정말 많은 사람들이 생각을 짜내고 짜내서 오늘의 JVM이 있는거지요.

자바는 자바가 제공하는 메타포를 그 프로그래머에게 주는 메타포를 그대로 받아들이면 많은 분야에서 상당한 생산성과 수고를 덜어주는게 분명합니다. 하지만 예전처럼
메모리 관리를 두고 'LISP 프로그래머는 메모리 관리처럼 중요한 걸 어떻게 프로그래머에게 맡기냐고 생각하는 반면 C 프로그래머는 메모리 관리처럼 중요한 걸 어떻게 프로그램에게 맡기냐' 라는 식의 싸움에서 자신이 C 프로그래머 측에 있다고 생각하면 자바에 상응하는 다른 조합의 기술을 선택하면 됩니다.

저는 자바보다 더 말랑말랑한 언어와 자바보다 딱딱한 언어에 임베딩해서 두 언어의 장점을 취해서 프로그램하고 있습니다.

Life rushes on, we are distracted

Life rushes on, we are distracted

anfl의 이미지

"저는 자바보다 더 말랑말랑한 언어와 자바보다 딱딱한 언어에 임베딩해서 두 언어의 장점을 취해서 프로그램하고 있습니다."

어떤 언어의 조합인지 궁금하네요.


sDH8988L의 이미지

Java가 쉽냐는 물음에 대한 답이야 천차 만별 아니겠습니까...

내부 돌아가는 구조를 모른다하여 쉽지 않게 느껴질 수도 있겠죠... 반면에 다른 사람들은 복잡한 부분을 가려 주어 쉽다고 생각할 수도 있습니다.

그럼 이건 어떤 가요...

운전이 쉽습니까?

자동차 내부 돌아가는 구조를 몰라서 어렵게 느껴진다면, 운전도 당연히 어렵게 느껴질 수도 있죠...

세상 사는 대부분의 일들이 Trade-off라고 생각합니다...

얻는 것이 있으면 잃게 되는 게 있는 것이죠...

사람이 왜 바퀴를 발명하고 자동차를 사용합니까... 걷는 거보다 이해하기 어려운데...

freestyle의 이미지

Quote:
내부 돌아가는 구조를 모른다하여 쉽지 않게 느껴질 수도 있겠죠...
반면에 다른 사람들은 복잡한 부분을 가려 주어 쉽다고 생각할 수도 있습니다.

저는 전자에 해당하는데,
JVM의 목적은 논외로 하고, 구현이 그리 마음에 들지 않더군요.
날잡아서 분석해 봐야지라는 생각은 항상 하고 있습니다 ^^

-----------------------------
Go to the U-City

----------------------------------------------------------------------------------------
Don't Feed the Trolls!
----------------------------------------------------------------------------------------

anfl의 이미지

내부 구조를 모른다하더라도 쉬운 언어는 아니라고 생각합니다.
스틱으로 운전하건 오토로 운전하건 운전을 잘하기란 쉬운게 아니니깐요.

그런데 제가 만난 사람들은 JAVA가 쉽다라고들 이야기하니
그점이 궁금하다는 것이지요.

정말 쉬워서 쉬운건지, 아니면 운전을 제대로 안해봐서
동네 운동장만 돌아봐서 쉽다고 하는 것인지.
아니면 일단 운전법 익히기 쉬우니깐
운전을 잘하기까지 스틱보다는 쉽기 때문에 쉽다고 하는것인지.


지리즈의 이미지

메뉴얼 7년 오토메틱 8년...
12인승 봉고부터 스포츠카,티코까지 몰아 본 제가 답변을 드리면...

확실히 메뉴얼보다 오토메틱이 쉽습니다.

보편적인 스팩의 차량이면... 메뉴얼/오토메틱 양쪽다 익숙한 운전자라면...
메뉴얼쪽이 연비도 좋고... 차도 생각대로 잘 움직입니다.
하지만... 스팩이 비싸고 성능이 좋은 차량이라면
메뉴얼/오토메틱 그 차이는 거의 안납니다.

사실 c 개발자라서... 자바가 쉽다라는 말이 와닫는 편은 아니였는데...

anfl님의 비유대로 C/C++은 메뉴얼이고,
자바가 오토매틱이라면 자바가 C/C++보다 확실히 쉬운 언어입니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

select99의 이미지

자바가 비슷한구현에 코딩량 더많고

익혀야할 클레스나 함수도 더많고

툴의존도가 높은데...

자바가 더수동으로 봐야 될거같은데요.

samerook의 이미지

Java 배우는 중입니다 참고하지요 :)

notpig의 이미지

한가지 궁금한게.. JVM 에서뭐가 모호하고 뭘 감춘다는건지 궁금합니다.
VC 에 비하면 모든게 공개되어있는거 같은데요.

freestyle의 이미지

컴파일러의 하나와 가상머신 비교하신 것 맞나요?
----------------------------------
Go to the U-City

----------------------------------------------------------------------------------------
Don't Feed the Trolls!
----------------------------------------------------------------------------------------

notpig의 이미지

생각해보니 그렇군요...

다음과 같이 변경하겠습니다.
JVM 에서 자바 컴파일러로 컴파일된 자바 바이트 코드를 실행하는것과
x86 컴퓨터에 설치된 윈도우에서 Visual C++ 로 컴파일된 실행 화일을 실행하는것과
x86 컴퓨터에 설치된 리눅스에서 GCC 로 컴파일된 실행 화일을 실행하는것과

비교하면

어떤 부분이 모호한건가요?

anfl의 이미지

너무도 당연한걸 물어보시네요.

instruction으로 실행하는 것은 거의 대부분 확인 가능하죠.
메모리 사용정도, 실행되는 context, 하다 못해 CPU 버그까지도 확인 가능하죠.
kernel 소스까지 있으면 감쳐진 부분이 하나도 없죠.

하지만 JVM에서 실행되는 Bytecode는 이러한 것들이 감춰져 있지 않습니까.
이러한 점이 모호하다 봅니다만.


notpig의 이미지

제가 답변을 잘못 이해한게 아니라면
"CPU 버그까지도 확인" 빼면 JVM 이라서 확인 불가능한게 뭔가요?

anfl의 이미지


JVM 자체요.
가상 머신 말입니다.

소스 있나요?
소스 있어도 확인하기 쉽나요?
어떤 thread에 메모리 어떻게 활당해주는지 쉽게 확인 가능하나요?

JVM은 완벽할까요?
JVM에 문제가 있으면 어떻게 찾죠?


notpig의 이미지

C/C++ 공부하는거 반만 자바쪽에 투자하셨으면 지금 이런 말씀은 안하셨을꺼 같습니다.

"소스 있나요?"
예~~첨 나올때 부터 소스 코드는 계속 공개되어있습니다. (오픈 소스는 아닙니다.)
최근부턴 오픈 소스 라이센스로 공개되어있습니다.

"소스 있어도 확인하기 쉽나요?"
"어떤 thread에 메모리 어떻게 활당해주는지 쉽게 확인 가능하나요?"
리눅스나 윈도우에선 쉽게 확인 가능한가요?

"JVM은 완벽할까요?
JVM에 문제가 있으면 어떻게 찾죠?"
이건 모호하단 이야기랑은 상관 없는거 같습니다.

추가로 C/C++ 에서 다음과 같은 내용에 대해서 설명하고 있나요?

http://java.sun.com/docs/books/jls/third_edition/html/memory.html

anfl의 이미지

C/C++ 공부하는거 반만 자바쪽에 투자하셨으면 지금 이런 말씀은 안하셨을꺼 같습니다.
-- 그럴지도 모르겠네요.

예~~첨 나올때 부터 소스 코드는 계속 공개되어있습니다. (오픈 소스는 아닙니다.)
최근부턴 오픈 소스 라이센스로 공개되어있습니다.
-- 직접 보셨는지요?

리눅스라 윈도우에선 쉽게 확인 가능한가요?
-- 네 쉽게 확인가능하죠. 디버거로 읽어봐도 알수 있고, 리눅스라면 kernel level에서도 확인가능하죠.

"JVM은 완벽할까요?
JVM에 문제가 있으면 어떻게 찾죠?"
이건 모호하단 이야기랑은 상관 없는거 같습니다.
-- 잘 알지못하고, 잘 찾지 못한다면 모호하다 할수 있지 않을까요?


notpig의 이미지

-- 직접 보셨는지요?

예~
HotSpot 최적화 문서를 살펴보고 요즘 그부분 소스 코드 살펴보고 있습니다.

- 네 쉽게 확인가능하죠. 디버거로 읽어봐도 알수 있고, 리눅스라면 kernel level에서도 확인가능하죠.
자바도 디버거있습니다.

-- 잘 알지못하고, 잘 찾지 못한다면 모호하다 할수 있지 않을까요?
잘 모르는 거하고 알 방법이 없는거하곤 다른거 같습니다.

anfl의 이미지

다 확인할수 있다니 좋습니다. 인정하죠.
제가 JVM, JAVAC를 알아보지도 않고 모호하다 했을지도 모르겠네요.

하지만

C 혹은 C++ -> compiler -> assembly -> assembler -> relocatable object -> linker -> exe -> processor

이렇게 가는 구조와

C++ -> compiler -> bytecode -> ... -> ... -> JVM -> processor

이렇게 가는 구조중 JVM이 중간에 들어감으로써 파악하기 어려워진 점은 분명한 사실인것 같네요.


lifthrasiir의 이미지

내부 구조를 보통 모르고 프로그래밍하는 건 C/C++와 호환되지 않는 거의 모든 프로그래밍 언어, 그러니까 동적인 언어(파이썬 펄 루비 루아 어쩌구)나 패러다임이 다른 언어(하스켈 ML 리스프 J 어쩌구) 등에 모두 해당되지 않나요? 예를 들어 하스켈 컴파일하는 걸 보니까 C를 intermediate code로 사용하면서 컴파일하는데 내부 내용은 전혀 알아 볼 수가 없더군요. (이게 C인지 어셈블리인지...) 실제로 하스켈은 lazy evaluation 때문에 일반적인 C/C++ 프로그램으로 변환하는 게 꽤 어렵죠.

디버깅이 문제라면, 해당 언어 단에서 적절한 디버거와 메모리 프로파일러가 존재한다면 이 문제는 오히려 C/C++가 불리한 문제가 아닌가 싶습니다. 자바를 포함한 대부분의 언어는 둘 다 제공하고요.

anfl의 이미지

링크 추가되서 말씀드리면...

저 부분은 JAVA보다는 운영체제 내용과 가까울것 같네요.
무수히 많은 운영체제 이론 + C, C++로 작성된 code에서 확인가능하고요.

mutex, semaphore, message queue, mail box, conditional variable, ...
모두 C, C++로 만드는게 가능하죠.

interrupt disable/enable만 있으면 말이죠.

SMP라면 spin lock & interrupt disable까지 있어야겠네요.


notpig의 이미지

제목만 보신거죠??
답변 늦게 보내주셔도 되니까~
내용을 읽어보시기 바랍니다.

특히 17.3 17.4 가 중요한 내용이니까요.

그리고 17.3 과 17.4 에서 설명한 내용에 대해 다른 언어에는 설명한 문서가 존재하는지 궁금합니다.

anfl의 이미지

다 읽어보았습니다.

언어에서는 설명하진 않죠. 저 내용도 언어의 내용은 아닌것 같네요.
synchronization만의 문제, reorder만의 문제, synchronization과 reorder 문제는
JAVA만의 문제가 아니라는 생각이드네요.

그런데 굳이 저 내용을 첨부하신 저의는 무엇인지 궁금합니다.
GCC에서 어찌 처리하는지 알려드리면 다음과 같네요.

http://www.iamroot.org/bbs/view.php?id=arm11_kernel_4&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=hit&desc=desc&no=58

덧붙여서 말씀드리면 synchronization과 reorder(compiler, processor) 문제는 언어에서 설명하진 않지만 설명한 문서나 코드는 많이 있습니다. 저는 오히려 저 내용을 언어 문서에서 소개한다는 것이 JAVA가 JVM을 통해 실행시키기 때문에 어쩔수 없는 선택이였다는 생각이 드네요.

시간되시면 kernel의 synchronization code, compiler 최적화, OOO processor architecture등을 찾아보시면 좋을것 같네요.


notpig의 이미지

Java Language Specification의 17.3 과 17.4 에서는

동기화 되지 않은 프로그램에서 최적화로 인해 instruction 의 실행 순서가 변경될때
변수의 값이 어떻게 읽고 어떻게 쓰여지는지에 대해서 설명하고 있습니다.
이를 통해서 멀티 스레드 프로그램의 실행 결과를 계산 가능합니다.
동기화 되지 않은 멀티 스레드 프로그램을 실행했을때 어떤 실행 결과든 그 결과가 나온 이유를 설명할 수 있습니다.

하지만 제가알기론 C/C++ 에서는 동기화되지 않은 프로그램에서 예상하지 못한 실행결과가 나온 이유를 설명 불가능합니다.

그리고 보내주신 링크는 동기화 방법을 설명하는 내용이군요..

anfl의 이미지


kernel만 알고 있으면 예상 가능합니다.
직접 kernel을 만들었다면 더더욱 예상 가능하겠지요.

세상에 그냥 이루어지는 일은 하나도 없습니다.


notpig의 이미지

제가 알기론 커널에서는 instruction 의 실행 순서 변경을 수행하지 않습니다.
프로세서에서 하죠..프로세스에서 제공하는 메모리 모델을 이해해야합니다.
그런데 컴파일러에서도 실행 순서를 변경합니다.
하지만 대부분의 컴파일러에서는 앞에서 말한 메모리 모델에 대한 문서가 존재하지 않습니다.

자바에서는 링크에서처럼 자바 메모리 모델을 제공하기 때문에 프로그램의 실행 결과를 분석하는것이 (쉽진 않아도) 가능하지만
C/C++ 에서는 현실적으로 불가능에 가깝습니다.

anfl의 이미지

instruction reorder은 말씀하신것 처럼 compiler과 processor에서 합니다.
kernel을 말씀드린것은 thread 수행 순서를 우선 이야기 한것이고
barrier, interrupt disable/enable, mutex, spin lock등과 같은
kernel의 synchronization primitive를 사용할수 있다는 관점에서 말씀드린것입니다.
즉 통제나 제어가 가능하다는 것이지요.


anfl의 이미지

JIT, AOC까지는 이해합니다.
그나마 native code로써 동작하니 말이죠.
하지만 제대로 알지도 못하는 JVM에 얹어서 동작시키는건 저에게는 썩 좋아 보이지 않네요.


serialx의 이미지

우리가 CPU 내부가 어떻게 동작하는지 상관 안하듯이 JVM 내부가 어떻게 동작하는지는 보통 상관 안합니다.

Intel x86 아키택쳐는 286부터 지금까지 수없이 변해왔습니다. 예전과 다르게 지금 인텔 CPU는 CISC아키택쳐도 아니고 내부적으로 micro instruction을 사용해 RISC 아키택쳐에 가깝습니다. 내부적 동작 방식이 확연하게 달라졌지요. 따라서 예전과는 확연하게 다른 성능을 보이지요. 따라서 그에따른 부작용도 많이 생겼지요.

캐쉬/파이프라인 문제도 있습니다. CPU는 같은 instruction에 대해서 정확히 같은 시간에 일을 처리하지 않습니다. 주어진 상황에 따라서 일을 처리하는 시간이 들쭉날쭉하고 예측하기가 매우 어렵습니다.

CPU자체 버그도 많습니다. 우리가 요즘 많이 쓰는 Core 2 Duo 씨리즈는 버그가 200개도 넘게 있습니다.
http://en.wikipedia.org/wiki/Intel_Core_2#Chip_bugs

인공위성이나 탐사위성같은것의 내부에서 사용하는 CPU를 옛날것을 사용하는 이유가 있습니다. 버그도 적고, 성능이 predictable 하기 때문입니다.

혹자는 JVM성능이 들쭉날쭉하고 아직까지 발견못한 버그로 신뢰성에 믿음이 안간다고 말합니다. 하지만 컴파일러는 어떨까요? CPU 는 어떨까요? 컴파일러가 JVM 보다 훨씬 이전에 만들어진거라 해서 버그가 적다고 장담할 수 있을까요? C++스팩을 완벽하게 지원하는 컴파일러가 있기는 한가요? 신뢰성에 대한 믿음은 직접 현업에서 많이 사용하셨던 분들이 제일 잘 알것입니다. 하지만 Java 개발자나 C 개발자나 다 자신의 환경에 신뢰성 문제가 있다고 얘기하시진 않는군요. 따라서 저는 두 환경 다 현업에 사용하기엔 문제가 없는 환경이라고 생각합니다.

JVM의 내부동작을 몰라 신뢰성이 안가시나요? Compiler도 JVM못지 않게 수많은 버그가 존재합니다. CPU도 마찬가지죠. 어차피 추상화를 하는 계층들은 다 불완전성을 내포하기 마련이고, 이 계층들에 대한 신뢰성은 그 계층을 제일 많이 사용해본 사람들이 잘 알고있지 않을까요? 막연한 불안감은 배제해야 한다고 생각합니다.

anfl의 이미지


어느정도 인정합니다.

하지만 제 관점에서 CPU 버그와 컴파일러 버그는 확인 가능한 버그입니다.
최근 VMM을 만드는 과정에서 intel VT-x에 버그가 있다는 것을 확인했네요.
CPU 버그는 당연히 있다고 보는것이 현명할것 같습니다.
말씀하신것 처럼 요즘 나오는 x86은 확실히 복잡하죠.
register renaming과 instruction scheduling을 통해 ILP를 높이고 있죠.
그리고 clock을 높이기 위해 내부 timming delay를 줄이려고 pipe line이 여러 단으로 두기도 하고요.
instruction 수행 시간이 들죽 날쭉한건 cache/pipe line, inter locking, OOO등등 여러 문제가 있을수 있겠네요.

복잡하더라도 믿고 쓰는거죠. 하지만 정말 문제가 터졌을때는 굳이 확인하자면 확인이 가능하다 봅니다.

컴파일러 역시 마찮가지 입니다. 물론 버그가 많이 있습니다. 하지만 컴파일러 버그는 instruction으로 확인 가능합니다. GCC 같은 경우에는 IR인 RTL과 GIMPLE tree를 덤프 떠볼수 있기 때문에 더욱 확인이 쉬울것입니다.

compiler, processor 버그가 있다는 것을 모르는 것이 아닙니다.

그럼

코드 -> compiler -> processor

코드 -> compiler -> JVM -> processor 중에서

어떤게 더 불안정할수 있을까요?


sDH8988L의 이미지

단순히 단계가 하나 더 추가되었다고 해서 복잡도가 증가할 거라는 건 어떻게 증명합니까?

Compiler에서 Processor로 바로 감으로써 생기는 복잡도가 JVM이 Compiler 결과를 받아 Optimize하여 Processor에 보내는 코드가 더 단순하며, 에러가 적을 수도 있습니다.

오컴의 날에서 얘기하는 것처럼 단순한 것이 정답에 가깝다는 것이 있지만, A->C의 확률이 10E-10이고 A->B->C의 확률이 10E-3 이라면 어떤 것이 더 단순한 것입니까?

anfl의 이미지


지금 복잡도 문제를 논하는게 아닌것 같은데요.
처리 과정에서의 오류를 논하는 것으로 압니다만.


sDH8988L의 이미지

그럼 단계가 늘어남에 따라 처리 과정의 오류도 늘어날 것이라는 가정은 어디서 옵니까...

anfl의 이미지


그건 당연하지 않습니까?
좀 황당한 질문인것 같은데요.


sDH8988L의 이미지

허허... 당연하다라...

그것이 어찌 당연합니까?

비오는 날 우산 쓰고 가면 비 더 많이 맞습니까?

비하고 나 사이에 우산이 하나 더 있는데, 비 더 많이 맞아야 하지 않습니까?

anfl의 이미지


비유가 적절하지 않은것 같습니다.

철수가 책을 읽고 영희에게 이야기해주었습니다.

철수가 책을 읽고 영수에게 이야기해주고, 영수가 영희에게 이야기해주었습니다.

가 더 적절한 비유라 봅니다만.


sDH8988L의 이미지

아니오...

상당히 적절하다고 생각합니다...

개발자가 만들어낼 수 있는 온간 오류 섞인 코드를 프로세서에 직접 전달하는 것보다,

중간에 오류 체크와 단순화/옵티마이즈를 할 수 있는 단계가 있는 것이 더 오류를 줄일 수 있습니다.

비와 우산은 그래서 말씀드린 겁니다...

anfl의 이미지

제 관점은 개발자가 오류 썪인 코드를 만들었다면
이미 오류라는 말입니다.

오류->오류

상황을 말씀드리는 것이 아니라

오류가 아닌 -> 오류

를 말씀드리는 것입니다.


sDH8988L의 이미지

물론, 중간 VM이 있음으로 해서 False Error를 만들어 낼 수 있습니다...

이건 분명히 있는 사실입니다.

다만, 개발자가 오류를 오류라고 인식할 수 있고 그 오류를 잡아낼 수 있는 가능성과

VM이 개발자가 인식할 수 없는 오류를 잡아내는 경우가 훨씬 많을 수 있습니다.

전체 오류의 입장에서 본다면, VM이 막아주는 부분이 압도적으로 많다고 볼 수 있겠죠.

물론, 절라게 실력 좋은 개발자라면 오류를 상당 부분 잡아낼 수 있으리라 보지만, 일의 크기가 커지면 그런 가정은 하지 않는 것이 좋겠죠.

anfl의 이미지


그러한 관점에서 하신 말씀이라면
프로그래머의 오류를 잡아줄수 있다는 측면에서 인정하겠습니다.

저는 지금까지 JVM 자체의 오류에 대해 말씀드린것이 였습니다.
서로 생각하는 바가 달랐었네요.


sDH8988L의 이미지

지금 더 적절하다고 하신 비유에는 한 가지 숨겨진 가정이 있습니다...

그 가정은 단계를 거침에 따라 뭔가의 소실이 생길 것이며. 오류가 생갈 것이라는 가정입니다...

그런 가정이 옳은 것이라고 생각하십니까...

페이지