자바 와 씨 언어중 어디가 빠른가요?

제 생각에는 서버 쪽에서는 자바는 충분히 빠르다. 라고 생각합니다.

C보다 더 빠르냐는 질문은 크게 의미가 없는 거 같구요.

가능한 온갖 최적화 다 하면, Java도 C 만큼 빠를 수 있는 것도 있습니다. (ByteCode 말고 그냥 Native Code로 만들어 버릴 수도 있으니까요.)

하지만, 그런 게 의미가 있느냐 하는 겁니다. 충분히 빠르다고 본다면...

더 중요한 것이 얼마나 편하게 버그 없이 빨리 프로젝트를 진행할 수 있느냐겠지요.

그런 면에 있어서 Java가 C보다 유리하다고 봅니다.

빈틈없이 잘 짜여졌다는 것도 규모가 어느 정도 커지면 의미 없는 것이 됩니다. 반드시 실수나 버그가 들어가게 마련입니다.

프로그래밍 언어가 왜 플랫폼을 지향하는 지를 생각해 보시면 됩니다. 실수나 버그를 플랫폼 래벨에서 쉽게 찾아내고 고칠 수 있느냐도 중요한 요소입니다.

마지막 질문에 대해서는 카이리님과 같은 의견입니다. 넓게 알고 있으면서도 집중적으로 알고 있어야 합니다.

좁은 분야의 스페셜리스트라면 그 분야 이외에 쓸 수가 없고, 다방면에 알고는 있지만 하나라도 잘 알지 못하면 실질적으로 쓸 수가 없습니다.

당연한 말 아니겠냐고 하시겠지만, 당연한 만큼 중요한 겁니다.

그리고 그 2가지 중에 반드시 하나만 택해야 하는 건 아닙니다. 둘 다 할 수 있죠...

이건 정말 해묵은 논란인데....

http://kldp.org/node/96772

해묵다 못해 사골 국물까지 쪽쪽 빨아먹은 논쟁이군요..

결론은 빠르다고 다 좋은게 아닙니다.

씨가 적당한 곳엔 씨를 쓰는것이 좋고, 자바가 적당한 곳엔 자바를 쓰는것이 좋습니다.

무엇이 어디에 적당한가는 개발자가 결정하는 것입니다.

그 기준은 개발자마다 다 다르며 개개인의 능력과 선호도에 따라 또 다릅니다.

결국 답은 없습니다. 둘중 어떤게 빠르다고 그것만 할것이 아니라, 둘 다 잘해야 한다가 제가 내린 답입니다.

그리고

이런 질문을 하신것 보니, 아직 학생인것 같네요. (아니라면 죄송합니다.)

개발자로서 목표를 잡고 스스로 열심히 노력하다 보면 (1)번은 자연스럽게 됩니다. 연봉이나 경력을 위해서가 아니라 스스로 열심히 하다보면 어느 순간 주변 사람들이 자기 자신을 인정하게 되는걸 알게 될겁니다. 연봉이나 경력은 그것에 따라 부수적으로 따라오는 것이지 목표가 아닙니다.

제가 (2)번 질문을 제대로 해석 못한것일 수도 있는데, 알골 계열 언어라면 어느것 하나만 수준이상으로 하면 다른것들 모두 쉽게 할 수 있습니다. 그러므로 이것저것 안다고 다른것을 제대로 못하는 것도 아니고, 하나만 집중적으로 판다고 다른 언어를 할 줄 모르는 것도 아닙니다.

지금은 정말 궁금해서 이런 글을 올리셨겠지만,
지금의 열의를 가지고 한 3~4년 열심히 프로젝트 하고 프로그램 짜고 공부하십시오.
알바(어디 서빙알바 같은거 말고 프로그래밍 알바)도 열심히 하고
이것저것 많이 경험해 보십시오.

그리고 시간이 흘러서 sunyata01님의 질문을 다시 읽게 된다면, 본인이 얼마나 시각이 좁았는가를 알 수 있게 됩니다.

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

우리 모두 싸워보자는 글이 또 생겨났내요...
티맥스와...C언어...자바는 먼가 공통점이 있는듯하내요
심심할때마다 이슈를 재기해주는...센스!!

언어 논쟁이 나올때마다 드는 생각인데..
모든것은 "누가 어떤 언어로 어떻게 짜느냐"로 판가름난다고 생각합니다.
캐허접이 C로 짜는 것 보다 고수가 자바로 짜는 것이 당연히 빠릅니다.
캐허접이 자바로 짜는 것 보다 고수가 C로 짜는 것이 개발도 빠르고 유지보수도 잘 됩니다.

이 떡밥에 대한 일반적인 얘기는 접어두고 개인적인 경험만 얘기하자면.
전 C가 자바보다 쉽습니다. 일단 자바는 원하는 기능이 있는지, 어느 클래스에 붙어 있는지 javadoc을 딱 보고는 알기 힘들더라구요; 그냥 man .. 하는 것보다 문서 보기가 어려워서 C가 더 개발이 빠릅니다. 이거 말고는 자바에 특별한 불만이 없네요.
성능은 지금까지 항상 C가 좋았던게 해보다 해보다 안되면 C가 언제나 마지막 선택이었기 때문인 듯. 자바는 성능으로 배신한 적 있는데 C는 그런 적 없는 것 같습니다.
제한적인 하드웨어에서 개발할 때는 어쩔 수 없이 C를 선택한 경우도 많고요.

보통 성능 얘기 나오면 자바 관련해서는 런타임 옵티마이즈 얘기가 자주 나오는데 같은 로직, 같은 데이터가 반복이 계속 되어서 성능 향상이 될 케이스가 현실에서는 거의 존재하지 않는다는게 제 생각이고, 시스템적으로 이 역할은 캐싱이 해야 한다고 생각합니다. 런타임 옵티마이즈의 장점이 더 있는데 자꾸 이런 케이스의 장점으로 부각시키면 오히려 가치를 깍아먹는 느낌입니다.

저는 자바 개발만 계속 해온 편입니다만
거의 최근 자바의 동향을 잘 모르고 살다가

최근에 좀 인력풀이 다양한 회사로 옮겨서 많은걸 배우게 되었습니다...
그러면서 느낀건데

자바 이제 너무 복잡해 졌습니다.
이넘, 어노테이션, 제네릭스 등등.. 머리가 아파 옵니다.

단순함이 무기였던 자바가 하나도 단순하게 안보였습니다.
대신 편함이라는 부분이 생기기도 했지만..

그리고 컨커런트에 목숨을 걸고 있는 듯 합니다.
멀티쓰레드 기반에서 동기화 퍼포먼스에 머리를 짜내고 있는것 같습니다.
이런거 고민할 바에 처음부터 정교하게 C언어로 짜는게 낫지 않을까 하는 생각마저 듭니다.
몰라서 하는 질문인데 C언어에서는 멀티쓰레드 프로그래밍에서 자바의 컨컨런트쪽 패키지에 대응하는 대량의 자료를 최소 동기화 비용으로 처리하는 충분한 라이브러리가 없는건가요?
어차피 자바쪽도 더그리 아저씨가 만든거에 기반해서 만든거라면 C언어에도 있을법도 한데요.

전에는 자바 개발이 쉽다고 생각했는데 이런 요소들을 생각하면 결국 쉽다고만은 볼 수 없을것 같습니다.

이렇든 저렇든 언어와 관계없이 기본공부 많이 해야겠다는 생각이 들었습니다.

공부할 시간이 필요해.......

자바가 안티?가 많죠... 자바만 해온사람은 그이유를 정말 모르는거 같군요..
실제로 자바가 좋다면 환영할일이지 안티할일은 전혀아니라고 생각합니다.
하지만 실제로 그럴만한 이유에대해선 고민안하는거 같습니다.
무엇이 잘못된것이나.. 잘못알려져있거나 그게 잘못된방향으로 나아간다면 그건 그렇지 않다고 얘기할수도 있어야겠죠..
그러기위해선 장단점을따져야하고 실제로 그게 사실인지를 비판할줄알아야합니다.
(S사나 J계열에서 에서내놓은것만 믿을수 없다는얘기죠)

그러나 자바의 장단점을 얘기하는데 마치 자기의 치부가드러나는일도아닌데....
상대를 비꼬거나 무시하는말투를 썩으며 자바를 잘모르면 말을하지마라..
나한테 묻지말고 다있으니 찾아알아봐라.. 너희들은 자바를 잘몰라서그렇다..
식으로 나오게되면 이내 토론이 난장판이되죠..

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

자바계열에서는 특히나 새로운개념? 이나 용어를 많이 내놓는다...
하지만 이게 과연새로운것일까? 아니다. 한마디로 새로운것같지만 대부분 기존에 일상적으로 쓰던것을 이것저것 모아
무엇이다.. 라고 하고 그걸 사용안하면 큰일이라도 날것처럼 설명되어있으며..
뭐뭐아느냐? 모르면 말을하지마...이렇다 저렇다 새로운개념이 어떻고...말은많이 하는데 직접해보라면 자기도 아직 잘못한다...

반면 C 에서는 그런게 필요가 없다. 왜냐.. 이것저것 복잡하게 할필요가 없다는것이다.. 훨씬더간단한방법이 있는데도 그걸모른다.
그러한방법은 구체적으로 이것이다 라고 할수가 없다 그렇게 해서도 안된다. 왜냐..그런게 있다면 아예 함수 하나로 만들어두면되지.
뭣하러 필요할때 그때그때 상황에 맞게 조합해서 쓰라고 있겠는가.. C에서 몇안되는표준함수로 웬만큼다할수 있는것이 바로그런이유에서이다..
작은 블럭같은것을 몇개조합하면 원하는기능이 거대한성과 맞먹는 위력을가진다.

그블럭은 하나만 놓고보면 아무볼품이 없다 대체 이것으로 무엇을할수 있냐 싶으다.
하지만 이벽돌은 그냥벽돌이 아니다. 모양세가다른 벽돌 몇개를 조립하면.. 벽돌이마술을 부리듯 엄청난일을해낸다. 아직이해못한다.

유닉스 작은쉘명령어들을 몇몇조합해서 프로그램으로 짜기엔 많은시간과 노력이 들일을 매우 간단히 명령어한줄로 해결하는일들을 경험했을것이다.
이런류의 사용은아마 C와 유닉스의 비슷한철학에서 비롯된것이라본다.
C 에서 Trim 함수를 사용하지않고도 포인터한두개 나오더니 한줄에 Trim 해버리는... 류의 코딩을 종종본적있을것이다.
함수라고 만들어둘필요가 없을정도이다.
작은것을모아 중간것을만들며 중간것을모아 거대한것을 이룬다.
그만큼 매우유용하며 그자체로서 모든요소에 모든일을 간단히 해결가능한방법이 있다.
그방법은 구체적인 사례에따라 그방법이나 구현법이 다르기때문에..또한 개인적인 취향이나, 사상과도 관련이 있을것이다.

거대한 덩어리하나 만들어두고 이것이 모든것을 할수 있다는 개념이 아니라.
작은것들을 모아두고 이것을 조립하면 모든것을 할수 있다는 개념이다.
전자는 덩치만 컷지 버그도 많으며 효율은 비효율적이고 응용력도 떨어지고, 리스소도 많이 먹으며 할수 있는일의범위도 작다.
그런데 왜 전자를 추구한단말인가..(마치 M모사의 윈도우처럼) J모언어의 어떤덩어리를보라. 덩어리째굴러다닌다.
(하지만 덩치크면 돈은될것이다 덩치큰걸팔아야 돈이 되지 않겠는가?
또한 버그도 많아야 유지보수비용을 받겠지. 더구나 기능이딱 정한것만 가능해야 추가기능제공에도 돈을받겠지.
상업적측면에서봤을땐 왜..S모사나 개발업체들이 이러한 것을 사용하는지 한편이해는간다.)

테스트하기 쉬운 구조로 코드를 개발하는 것을 원하는가? 테스트때문에 한때고민은 했지만 지금은 그런것때문에 고민해본지 오래된거같다...
내심 이상한게 좀 나타났으면 하는바램도 있다..
더구나 테스트하기 쉬운 라이브러리제작하여 사용가능하다 하지만 누가또쓸지?
대부분 그냥한다. 안써도 쉽다는것이다. 그런데 머하러 그걸 만들고 배포하는가? 실제로는..무지 많다.

더구나 뭣하러 인스턴스의 생성과 클래그간의 의존관계에 대한 고민을 하는가..
필요가 없다는것이다. 한마디로 C에선 너무나 당연하거나.고려할필요도 없는일을 자바에서는 매우많은 비용을들여고민하고 있다는것이다.
그러고는 어렵사리 해결방법을제시하고 대단한무엇을 한것인양 말을한다.

C에 없는것이 있다면 그게 불필요하기때문에 없는것이라 생각하면 거의 정답이다.
다른말로 고민할필요도 없거나 이미 쉽게 구현할수 있고 구현된것도 흔하다.

어떤기술이 실제와 이론이 동떨어져있고... 이론만으로 내세우려하면 어찌 신뢰를 얻겠는가..
더구나 방향자체가 잘못되어있다면..